説明
Spark で RDD を手動で永続化すると、RDD がガベージ コレクションされるのを防ぐことができます。
このステートメントは正しくないため、質問に対する正しい答えです。Spark のガベージ コレクターは、"LRU" 方式ではありますが、永続化されたオブジェクトも削除します。LRU は、Least Recent Used の略です。
そのため、ガベージ コレクションの実行中は、最も長い時間前に使用されたオブジェクトが最初にガベージ コレクションの対象になります。
詳細については、以下のリンクされた StackOverflow の投稿を参照してください。
シリアル化されたキャッシュは、ガベージ コレクションのパフォーマンスを向上させるための戦略です。
このステートメントは正しいです。ガベージ コレクション中に Spark が収集する必要がある Java オブジェクトが多いほど、時間がかかります。複雑なスキーマを持つ DataFrame などの多くの Java オブジェクトのコレクションを単一バイト配列としてシリアル化して格納すると、パフォーマンスが向上します。つまり、シリアライズされた DataFrame では、シリアライズされていない DataFrame よりもガベージ コレクションにかかる時間が短くなります。
Spark でガベージ コレクションのパフォーマンスを最適化すると、キャッシュ機能が制限される場合があります。
このステートメントは正しいです。フル ガベージ コレクションを実行すると、Spark アプリケーションの速度が低下します。持ち歩くとき
ガベージ コレクションの「チューニング」とは、これらの速度低下の量または期間を短縮することを意味します。
古い世代の Java ヒープ スペースがほぼいっぱいになると、フル ガベージ コレクションの実行がトリガーされます。(この概念に慣れていない場合は、以下のガベージ コレクション チューニング ドキュメントへのリンクを参照してください。) したがって、ガベージ コレクションの実行のトリガーを回避する 1 つの方法は、ヒープ領域の古い世代の共有がほぼいっぱいになるのを防ぐことです。
これを達成するために、そのサイズを小さくすることができます。Old ジェネレーション スペースよりも大きなサイズのオブジェクトは、スペースにキャッシュ (格納) される代わりに破棄され、スペースが「ほぼいっぱい」になるのを助けます。
これにより、フル ガベージ コレクションの実行回数が減り、全体的なパフォーマンスが向上します。
ただし、必然的に、必要なときにオブジェクトを再計算する必要があります。そのため、このメカニズムは、Spark アプリケーションがキャッシュされたデータをできるだけ再利用する必要がない場合にのみ機能します。
ガベージ コレクション情報は、Spark UI のステージ詳細ビューでアクセスできます。
このステートメントは正しいです。Spark UI のステージ詳細ビューのタスク テーブルには、タスクごとに必要なガベージ コレクション時間を示す「GC 時間」列があります。
Spark では、デフォルトの Parallel ガベージ コレクタを使用する代わりに、G1 ガベージ コレクタを使用します。
このステートメントは正しいです。ガベージ ファースト ガベージ コレクタとも呼ばれる G1 ガベージ コレクタは、デフォルトの Parallel ガベージ コレクタに代わるものです。
デフォルトの Parallel ガベージ コレクタはヒープをいくつかの静的領域に分割しますが、G1 ガベージ コレクタはヒープを動的に作成される多くの小さな領域に分割します。G1 ガベージ コレクターには、特に高スループットと低待機時間を必要とする Spark ワークロードのパフォーマンスを向上させる、Parallel ガベージ コレクターよりも優れた利点があります。
G1 ガベージ コレクターは既定では有効になっていません。有効にするには、引数を明示的に Spark に渡す必要があります。2 つのガベージ コレクターの詳細については、以下にリンクされている Databricks の記事を参照してください。

説明
正しいコード ブロック:
transactionsDf.withColumnRenamed("storeId", "storeNumber")
詳細: pyspark.sql.DataFrame.withColumnRenamed - PySpark 3.1.1 ドキュメント 静的ノートブック | 動的ノートブック: テスト 1 を参照

説明
スロットはエグゼキュータの通信インターフェイスであり、コマンドを受信し、結果をドライバに送信するために使用されます。
間違っています。エグゼキュータはドライバと直接通信します。
スロットは、executor のワークロードに従って動的に作成および破棄されます。
いいえ、Spark はワークロードに応じて積極的にスロットを作成および破棄しません。エグゼキューターごとに、エグゼキューターあたりのコア数 (プロパティ spark.executor.cores) とタスクあたりの CPU 数 (プロパティ spark.task.cpus) に従って、Spark 構成が要求するスロットが使用可能になります。
スロットは常に 1 つのコアに制限されます。
いいえ、スロットは複数のコアにまたがることができます。タスクが複数のコアを必要とする場合、複数のコアにまたがるスロットを介して実行する必要があります。
Spark のドキュメントでは、「スレッド」の方が正確な言葉ですが、「コア」は「スレッド」と同じ意味で使用されることがよくあります。1 つの物理コアで複数のスレッドを使用できる場合があります。したがって、スロットは複数のスレッドにまたがることができると言った方が適切です。
I/O パフォーマンスを最適化するために、Spark はディスク上の複数のスロットにデータを保存します。
いいえ - Spark は、スロットではなく複数のパーティションのディスクにデータを保存します。
詳細: Spark アーキテクチャ | 分散システム アーキテクチャ

説明
実行は変換によってトリガーされます。
正しい。実行は、変換ではなく、アクションによってのみトリガーされます。
リネージュにより、Spark は変換をステージに結合できます。
正しくない。Spark では、系統とは変換の記録を意味します。この系統により、Spark での遅延評価が可能になります。
述語プッシュダウンは、遅延評価から生じる機能です。
間違い。述語のプッシュダウンは、たとえば、Spark がプロセスのできるだけ早い段階でフィルターを実行することを意味します。これにより、後続の変換で最小限の量のデータを処理し、パフォーマンスが向上します。
アキュムレータは、Spark の遅延評価モデルを変更しません。
正しくない。Spark では、accumulator は、 を参照するクエリが実際に実行されたときにのみ更新されます。つまり、遅延評価のためにクエリが (まだ) 実行されていない場合、それらは更新されません。
Spark は実行時にのみジョブを失敗させますが、定義時には失敗させません。
間違い。定義中、遅延評価のためにジョブが実行されないため、存在しないファイルからの読み取りなどの特定のエラーをキャッチできません。キャッチするには、アクションなどを通じてジョブを実行する必要があります。

説明
正しいコード ブロックの出力:
+----------------------------+
|size(split(supplier, , -1))|
+----------------------------+
| | 3|
| | 1|
| | 3|
+----------------------------+
この質問は、分割コマンドの典型的な使用例を示しています: 文字列を単語に分割します。さらに難しいのは、単語を数えるように求められることです。ここでは count メソッドを使用したくなるかもしれませんが、実際には size メソッド (配列のサイズなど) を使用するのが正しい方法です。以下のリンクされたドキュメントを使用して、分割とサイズの方法を理解してください。
より詳しい情報：
Split メソッド: pyspark.sql.functions.split - PySpark 3.1.2 ドキュメント サイズ メソッド: pyspark.sql.functions.size - PySpark 3.1.2 ドキュメント Static notebook | 動的ノートブック: テスト 2 を参照