説明
正しいコード ブロックの出力:
+-----+-----------------------------+------------ -------+
|itemId|属性 |サプライヤー |
+-----+-----------------------------+------------ -------+
|1 |[winter, cosy, blue] |Sports Company Inc.|
|2 |[夏、赤、爽やか、涼しげ]|YetiX |
|3 |[旅行、夏、緑] |Sports Company Inc.|
+-----+-----------------------------+------------ -------+
PySpark のさまざまな並べ替え関数を区別するのは混乱する可能性があります。この場合、sort_array に関する特殊性を考慮する必要があります。ソート方向は、desc メソッドではなく、2 番目の引数によって指定されます。幸いなことに、これはドキュメントに記載されています (以下のリンク)。また、この質問を解決するには、sort と sort_array の違いを理解する必要があります。並べ替えでは、配列内の値を並べ替えることができません。また、sort は DataFrame のメソッドであり、sort_array は pyspark.sql.functions のメソッドです。
詳細: pyspark.sql.functions.sort_array - PySpark 3.1.2 ドキュメント 静的ノートブック | 動的ノートブック: テスト 2 を参照

説明
distinct() は DataFrame のメソッドです。これを知ること、またはドキュメントからこれを認識することが、この質問を解決するための鍵です。
詳細: pyspark.sql.DataFrame.distinct - PySpark 3.1.2 ドキュメント 静的ノートブック | 動的ノートブック: テスト 2 を参照

説明
アキュムレータの値はドライバのみが読み取ることができ、エグゼキュータは読み取ることができません。
正しい。したがって、たとえば、executor 間のワークロードを調整するためにアキュムレータ変数を使用することはできません。アキュムレータ値の典型的で標準的な使用例は、たとえばデバッグ目的で、ドライバにデータを報告することです。たとえば、デバッグ目的で UDF の特定の条件に一致する値をカウントしたい場合、アキュムレータはそれを行うための優れた方法を提供します。
アキュムレータでは数値のみを使用できます。
いいえ。pySpark の Accumulator は数値 (int と float を考えてください) のみをサポートしていますが、AccumulatorParam インターフェイス (以下にリンクされているドキュメント) を介してカスタム型のアキュムレータを定義できます。
アキュムレータは遅延評価に従いません。
不正解 - アキュムレータは遅延評価に従います。これは実際には意味があります。アキュムレータが変換でカプセル化されている場合、そのアキュムレータは後続のアクションが実行されるまで変更されません。
アキュムレータは、ハードウェア障害のためにタスクを再実行する必要がある場合でも、独立して 1 回しか更新されないため、デバッグに使用するのは困難です。
間違い。実際、アキュムレータに関する問題は、特定の条件下で、各タスクに対して複数回実行できることです。たとえば、アキュムレータ変数が増加した後、タスクが終了する前にタスク中にハードウェア障害が発生し、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 ドキュメント

説明
動的パーティション プルーニングは、クエリの実行中に収集されたランタイム統計に基づいて、クエリ プランを再最適化します。
いいえ - これはアダプティブ クエリ実行の機能ですが、動的パーティション プルーニングではありません。
動的パーティションのプルーニングは、同様のデータ型の列を連結して、結合のパフォーマンスを最適化します。
間違っています。特に動的パーティションのプルーニングに関連して、この答えは意味がありません。
動的パーティション プルーニングは、データ型とブロードキャスト変数に基づいて物理計画を再最適化します。
ブロードキャスト変数を使用した結合で動的パーティションのプルーニングが機能することは事実です。これは、論理的な最適化と物理的な計画段階の両方で実際に発生します。ただし、データ型は再最適化の役割を果たしません。
動的パーティション プルーニングは、メモリ内ではなくディスク上でワイド トランスフォーメーションを実行します。
この答えは意味がありません。動的パーティション プルーニングは、Spark を高速化することを目的としています。メモリ リソースの代わりにディスクを含む変換を実行すると、Spark が減速し、動的パーティション プルーニングの目的とは逆の効果が確実に得られます。

説明
スタンドアロン モードでは、アプリケーションごとにワーカーごとに 1 つのエグゼキューターのみが使用されます。
これは正しく、Spark のスタンドアロン モードの制限です。
スタンドアロン モードは、複数のフレームワークを実行するクラスターの実行可能なソリューションです。
正しくない。スタンドアロン モードの制限は、Apache Spark がクラスターで実行される唯一のフレームワークでなければならないことです。Apache Spark や Apache Flink など、同じクラスターで複数のフレームワークを並行して実行する場合は、YARN デプロイ モードを検討します。
スタンドアロン モードでは、単一の JVM を使用して Spark ドライバーとエグゼキューター プロセスを実行します。
いいえ、これがローカル モードの機能です。
スタンドアロン モードは、Spark が YARN および Mesos クラスターで実行される方法です。
いいえ。YARN と Mesos モードは、スタンドアロン モードとは異なる 2 つの展開モードです。これらのモードにより、Spark はクラスター上の他のフレームワークと一緒に実行できます。Spark がスタンドアロン モードで実行されている場合、クラスターで実行できるのは Spark フレームワークのみです。
スタンドアロン モードは、クラスターにドライバーが含まれていないことを意味します。
不正解です。クラスターにはクライアント モードのドライバーは含まれていませんが、スタンドアロン モードではクラスター内のノードでドライバーが実行されます。
詳細: Learning Spark、第 2 版、第 1 章