説明
この質問は、フィルター条件をチェーンする方法に関する知識を対象としています。各フィルタリング条件は括弧内に入れる必要があります。「or」の正しい演算子はパイプ文字 (|) であり、単語 or ではありません。もう 1 つの重要な演算子は等価演算子です。比較のために、等しいことは 2 つの等号 (==) で表されます。
静的ノート | 動的ノートブック: テスト 2 を参照

説明
アキュムレータの値はドライバーのみが読み取ることができ、エグゼキュータは読み取ることができません。
正しい。したがって、たとえば、エグゼキュータ間のワークロードを調整するためにアキュムレータ変数を使用することはできません。アキュムレータ値の典型的な正規の使用例は、デバッグ目的などでデータをドライバーに報告することです。たとえば、デバッグ目的で UDF 内の特定の条件に一致する値をカウントしたい場合、アキュムレータはそれを行うための優れた方法を提供します。
アキュムレータでは数値のみを使用できます。
いいえ。pySpark のアキュムレータは数値 (int と float を考えてください) のみをサポートしますが、AccumulatorParam インターフェイス (以下にリンクされているドキュメント) を介してカスタム型のアキュムレータを定義できます。
アキュムレータは遅延評価に従いません。
不正解 - アキュムレータは遅延評価に従います。これは実際に影響を及ぼします。アキュムレータが変換でカプセル化されると、そのアキュムレータは後続のアクションが実行されるまで変更されません。
アキュムレータは、ハードウェア障害によりタスクを再実行する必要があるかどうかに関係なく、一度だけ更新されるため、デバッグに使用するのは困難です。
間違い。アキュムレータに関する懸念は、実際、特定の条件下では各タスクに対して複数回実行される可能性があることです。たとえば、アキュムレータ変数が増加した後、タスクが終了する前に、タスク中にハードウェア障害が発生し、障害に応じて Spark が別のワーカーでタスクを起動した場合、すでに実行されたアキュムレータ変数の増加が繰り返されます。
Spark UI では、名前のないアキュムレータのみを検査できます。
いいえ。現在、PySpark では、Spark UI でアキュムレーターを検査できません。Spark の Scala インターフェイスでは、名前付きアキュムレーターのみが Spark UI で検査できます。
詳細: Spark アキュムレータを使用した結果の集計 | Sparkour、RDD プログラミング ガイド - Spark 3.1.2 ドキュメント、pyspark.Accumulator - PySpark 3.1.2 ドキュメント、および pyspark.AccumulatorParam - PySpark 3.1.2 ドキュメント

説明
静的ノート | 動的ノートブック: テスト 1 を参照

説明
スキューを軽減するために、Spark は結合時にキーの null 値を自動的に無視します。
このステートメントは正しくないため、質問に対する正しい答えになります。NULL 値を含むキーの結合は、データ スキューに関して特に懸念されます。
実際のアプリケーションでは、結合キーとして使用される列に値が割り当てられていないレコードがテーブルに多数含まれる場合があります。結合中、データは大きく偏る危険があります。これは、NULL 値の結合キーを持つすべてのレコードが単一の大きなパーティションとして評価され、NULL キー以外のレコードの潜在的に多様なキー値 (したがって小さなパーティション) とはまったく対照的であるためです。
Spark は特にこれを自動的に処理しません。ただし、Null 値を一時的に破棄し、後でマージし直すなど、この問題を軽減するための戦略がいくつかあります (下記の最後のリンクを参照)。
スキューのある DataFrame では、最大のパーティションと最小のパーティションで消費されるメモリ量が大きく異なります。
この発言は正しいです。実際、パーティション サイズが大きく異なることが、まさにスキューの定義です。最大のパーティションが単一のエグゼキュータを長時間占有するため、スキューによって Spark のパフォーマンスが低下する可能性があります。これは Spark ジョブをブロックし、大きなパーティションが処理されるまで小さなパーティションを処理する他のエグゼキューターをアイドル状態にする必要があるため、リソースの非効率的な使用になります。
ソルティングによりデータの偏りを解決できます。
この発言は正しいです。ソルト化の目的は、ソルト化されたパーティション化キーに基づいて、データを同様のサイズのパーティションに再分割する機会を Spark に提供することです。
ソルト分割キーは通常、均一に分散された乱数で構成される列です。パーティション化キー列の一意のエントリの数は、希望するパーティション数の数と一致する必要があります。ソルト付きキーで再パーティション化した後は、すべてのパーティションのサイズがほぼ同じになるはずです。
Spark は、デフォルトではスキュー結合を自動的に最適化しません。
この発言は正しいです。自動スキュー結合最適化は、Adaptive Query Execution (AQE) の機能です。
デフォルトでは、AQE は Spark で無効になっています。これを有効にするには、Spark のspark.sql.adaptive.enabled 構成オプションをデフォルトの false のままにするのではなく、true に設定する必要があります。
スキュー結合を自動的に最適化するには、Spark のspark.sql.adaptive.skewJoin.enabled オプションも true (デフォルト) に設定する必要があります。
スキュー結合の最適化が有効になっている場合、Spark はスキュー結合を認識し、大きなパーティションを小さなパーティションに分割することで最適化するため、パフォーマンスが向上します。
ブロードキャスト結合は、ソートマージ結合よりも偏ったデータの結合パフォーマンスを向上させる実行可能な方法です。
この発言は正しいです。実際、ブロードキャスト結合は、条件によっては、偏ったデータの結合パフォーマンスを向上させるのに役立ちます。結合される DataFrame の 1 つは、他の DataFrame からのパーティションに沿って、各エグゼキュータのメモリに収まるのに十分な大きさである必要があります。この場合、ブロードキャスト結合はソートマージ結合よりも結合パフォーマンスを向上させます。
その理由は、偏ったデータを含むソートマージ結合には過剰なシャッフルが含まれるためです。シャッフル中にデータがクラスター内に送信され、最終的に Spark アプリケーションの速度が低下します。偏ったデータの場合、データ量とそれに伴う速度の低下が特に大きくなります。
ただし、ブロードキャスト結合はデータのシャッフルを減らすのに役立ちます。小さいテーブルはすべてのエグゼキューターに直接保存されるため、大量のネットワーク トラフィックが排除され、最終的にソートマージ結合と比較して結合パフォーマンスが向上します。
小さい方の DataFrame がデフォルトで設定されている 10 MB より大きい場合、スキュー結合の動作を最適化するために、Spark のspark.sql.autoBroadcastJoinThreshold 構成プロパティを手動で調整することが合理的である可能性があることに注意してください。
より詳しい情報：
- パフォーマンス チューニング - Spark 3.0.0 ドキュメント
- Spark のパフォーマンスを向上させるデータ スキューとガベージ コレクション
- セクション 1.2 - 歪んだデータの結合 * GitBook

説明
正しいコードブロック:
transactionsDf.repartition(1).write.option("sep", "\t").option("nullValue", "n/a").csv(csvPath) ここで、質問が具体的に求めていることを理解することが重要です。 DataFrame を単一の CSV ファイルとして書き込みます。これは、パーティションについて考えるきっかけとなるはずです。デフォルトでは、すべてのパーティションは個別のファイルとして書き込まれるため、呼び出しに repatio(1) を含める必要があります。ここでも、coalesce(1) が機能します。
次に、この質問は、DataFrameWriter.csv (以下のリンク) で動作する Spark ドキュメント内のパラメーターを検索するよう促すものです。これらのパラメーターを適用するには、option() ステートメントが必要であることも知っておく必要があります。
最後の懸念は、一般的な呼び出し構造に関するものです。DataFrame の accessed write を呼び出すと、オプションが続き、csv を使用して DataFrame を書き込みます。ここでは csv(csvPath) の代わりに、save(csvPath, format='csv') を使用することもできます。
詳細: pyspark.sql.DataFrameWriter.csv - PySpark 3.1.1 ドキュメント 静的ノートブック | 動的ノートブック: テスト 1 を参照