説明
DataFrameクラスのメソッドpartitionOn（）は存在しないため、代わりにpartitionBy（）を使用する必要があります。
正しい！ドキュメント（以下にリンク）でpartitionBy（）の詳細を確認してください。
オペレーターは、mode（）オプションを使用してDataFrameWriterを構成し、filePathの場所にある既存のファイルを置き換える必要があります。
いいえ。質問でファイルを上書きする必要があるかどうかについての情報はありません。
パーティショニング列とファイルパスは、コードブロックのように追加されたコマンドとしてではなく、DataFrametransactionsDfのwrite（）メソッドに直接渡す必要があります。
正しくない。DataFrameをディスクに書き込むには、DataFrame.writerプロパティを介してアクセスできるDataFrameWriterオブジェクトを操作する必要があります。括弧は関係ありません。
列storeIdはcol（）演算子でラップする必要があります。
いいえ、これは必要ありません。問題は、partitionOnコマンドにあります（上記を参照）。
partitionOnメソッドは、writeメソッドの前に呼び出す必要があります。
違う。まず第一に、partitionOnはDataFrameの有効なメソッドではありません。ただし、partitionOnがpartitionBy（有効なメソッド）に置き換えられると仮定しても、このメソッドはDataFrameWriterのメソッドであり、DataFrameのメソッドではありません。したがって、DataFrameWriterオブジェクトにアクセスするには、常に最初にDataFrame.writeを呼び出し、その後、partitionByを呼び出す必要があります。
詳細：pyspark.sql.DataFrameWriter.partitionBy--PySpark3.1.2ドキュメント静的ノートブック| ダイナミックノートブック：テスト3を参照

説明
キャッシングとは、パーティションのコピーをエグゼキュータに保存することを意味します。これにより、再計算する必要がなく、後続の操作でより迅速にアクセスできます。cache（）は、DataFrameの遅延評価されたメソッドです。count（）はアクションであるため（filter（）はアクションではありません）、キャッシュプロセスをトリガーします。
詳細：pyspark.sql.DataFrame.cache-PySpark 3.1.2ドキュメント、Learning Spark、第2版、第7章静的ノートブック| ダイナミックノートブック：テスト2を参照

説明
クラスターモードでは、ドライバーはワーカーノードに常駐し、クライアントモードではエッジノードに常駐します。
正しい。Sparkのクライアントモードの考え方は、クラスターの外部から、ゲートウェイマシンとも呼ばれるエッジノードからワークロードを実行できることです。ただし、Sparkを実行する最も一般的な方法は、ドライバーがワーカーノードに存在するクラスターモードです。
実際には、クライアントモードでは、クラスター内のワーカーノード間のデータ転送速度に比べてデータ転送速度に厳しい制約があります。また、エッジノードに障害が発生すると、クライアントモードで実行されるジョブはすべて失敗します。これらの理由から、クライアントモードは通常、実稼働環境では使用されません。
クラスターモードでは、クラスターマネージャーはワーカーノードに常駐し、クライアント実行モードではエッジノードに常駐します。
いいえ。どちらの実行モードでも、クラスターマネージャーはワーカーノードに常駐できますが、クライアントモードのエッジノードには常駐しません。
クラスタモードでは、エグゼキュータプロセスはワーカーノードで実行されますが、クライアントモードではゲートウェイノードで実行されます。
これは正しくありません。ドライバーのみがクライアントモードのゲートウェイノード（「エッジノード」とも呼ばれます）で実行され、エグゼキュータープロセスでは実行されません。
クラスターモードでは、Sparkドライバーはクラスターマネージャーと同じ場所に配置されませんが、クライアントモードでは同じ場所に配置されます。
いいえ、クライアントモードでは、Sparkドライバーはドライバーと同じ場所に配置されません。クライアントモードの要点は、ドライバーがクラスターの外部にあり、クラスターを管理するリソース（クラスターマネージャーを実行するマシン）に関連付けられていないことです。
クラスタモードでは、ゲートウェイマシンがドライバをホストし、クライアントモードではエグゼキュータと同じ場所に配置されます。
いいえ、まったく逆です。クラスターモードのゲートウェイマシンはありませんが、クライアントモードでは、ドライバーをホストします。

説明
正しいコードブロック：
transactionDf.select（["transactionId"、 "predError"、 "value"、 "f"]）
DataFrame.selectは、DataFrameから特定の列を返し、リストを唯一の引数として受け入れます。
したがって、これはここでの正しい選択です。col（["transactionId"、 "predError"、
"value"、 "f"]）は無効です。これは、col（）内では、リストではなく単一の列名のみを渡すことができるためです。同様に、「transactionId、predError、value、f」のような単一の文字列で指定されているすべての列は、有効な構文ではありません。
filterと、条件に基づいて行をフィルターする場合、それらはどの列を返すかを制御しません。
静的ノートブック| ダイナミックノートブック：テスト2を参照

説明
transactionDf.sort（ "predError"、ascending = False）
正しい！DataFrame.sort（）を使用し、ascending = Falseを設定すると、DataFrameは指定された列で降順で並べ替えられ、欠落しているすべての値が最後に配置されます。代替案は、ここでは回答としてリストされていませんが、transactionsDf.sort（desc_nulls_last（ "predError"））になります。
transactionDf.sort（asc_nulls_last（ "predError"））
正しくない。これは有効な構文ですが、DataFrameは列predErrorで降順ではなく昇順で並べ替えられ、欠落している値が最後に配置されます。
transactionDf.desc_nulls_last（ "predError"）
間違って、これは無効な構文です。Spark APIにはメソッドDataFrame.desc_nulls_last（）はありません。ただし、Spark関数desc_nulls_last（）があります（リンクは以下を参照）。
transactionDf.orderBy（ "predError"）。desc_nulls_last（）
いいえ。transactionsDf.orderBy（ "predError"）は正しい構文であり（DataFrameを列predErrorで昇順で並べ替えますが）、DataFrameを返しますが、Spark APIにはメソッドDataFrame.desc_nulls_last（）はありません。ただし、Spark関数desc_nulls_last（）があります（リンクは以下を参照）。
transactionDf.orderBy（ "predError"）。asc_nulls_last（）
正しくない。Spark APIにはメソッドDataFrame.asc_nulls_last（）はありません（上記を参照）。
詳細：pyspark.sql.functions.desc_nulls_last-PySpark3.1.2ドキュメントおよびpyspark.sql.DataFrame.sort-PySpark3.1.2ドキュメント（https://bit.ly/3g1JtbI、https://bit.ly/2R90NCS ）静的ノートブック| 動的ノートブック：テスト1（https://flrs.github.io/spark_practice_tests_code/#1/32.html、
https://bit.ly/sparkpracticeexams_import_instructions）