説明
SparkはDAG形式でデータを保存することで優れたパフォーマンスを実現しますが、Hadoopは寄木細工のファイルしか使用できません。
間違って、「DAG形式」はありません。DAGは、「有向非巡回グラフ」の略です。DAGは、Sparkの計算ステップを表す手段です。ただし、HadoopがDAGを使用しないのは事実です。
SparkにDAGが導入されたのは、データをディスクに継続的に読み書きする必要があるHadoopのマップリデュースフレームワークの制限の結果でした。
ApacheSparkのグラフDAG-DataFlair
SparkはHDFS形式でデータを保存することで優れたパフォーマンスを実現しますが、Hadoopは寄木細工のファイルしか使用できません。
いいえ。Sparkは確かにHDFS（およびその他の形式）でデータを保存できますが、これはHadoopに比べてパフォーマンス上の重要な利点ではありません。Hadoopは、寄木細工だけでなく、複数のファイル形式を使用できます。
Sparkは、Hadoopとは異なり、Kubernetesにデプロイできるため、クエリの復元力が高くなります。
いいえ、弾力性は質問で求められていません。問題は、パフォーマンスの向上についてです。
HadoopとSparkの両方をKubernetesにデプロイできます。
Sparkは、ユーザーフレンドリーなAPIを使用してHadoopのDataFrameを拡張することにより、開発者のパフォーマンスを向上させます。
いいえ。DataFrameはSparkの概念ですが、Hadoopでは概念ではありません。

説明
Sparkは、JSON形式の文字列をスキーマとしてダイジェストする方法を提供します。ただし、使用するのは簡単ではありません。試験の難易度をわずかに上回っていますが、この質問は、読んでいるデータにスキーマを適用するという概念（試験の範囲内のトピック）を理解するのに役立つため、試験の準備に役立ちます。
ここで飛び出す最初の答えは、spark.read.jsonの代わりにspark.read.schemaを使用するものです。spark.read.schema（以下にリンク）のドキュメントを見ると、オペレーターが最初の引数としてタイプpyspark.sql.types.StructTypeまたはstrを予期していることがわかります。変数json_schemaは文字列ですが、ドキュメントには、strは「DDL形式の文字列（たとえば、col0 INT、col1 DOUBLE）」である必要があると記載されています。変数json_schemaにはこのタイプの形式の文字列が含まれていないため、この回答オプションは間違っている必要があります。
4つの正解の可能性があるので、spark.read.json（）のスキーマパラメーターを見てみましょう（以下にリンクされているドキュメント）。ここでも、スキーマパラメータは、タイプpyspark.sql.types.StructTypeまたは「DDL形式の文字列（たとえば、col0 INT、col1 DOUBLE）」の入力を想定しています。json_schemaがこの形式に従わないことはすでにわかっているので、json_schemaをpyspark.sql.types.StructTypeに変換する方法に焦点を当てる必要があります。これにより、schema=json_schemaのオプションも削除されます。
spark.read.jsonはpyspark.sql.types.StructTypeタイプではなく、DataFrameを返すため、schema = spark.read.json（json_schema）を含むオプションも間違った選択です。
schema_of_json（json_schema）を含むオプションを除外することはかなり困難です。オペレーターのドキュメント（以下にリンク）には、「[p] JSON文字列を解析し、そのスキーマをDDL形式で推測する」と記載されています。このユースケースは、現在のケースとは少し異なります。json_schemaはすでにスキーマ定義であり、そこからスキーマを「推測」することは意味がありません。ドキュメントでは、違いをよりよく理解するのに役立つユースケースの例を見ることができます。ここでは、文字列'{a：1}'をschema_of_json（）に渡すと、メソッドはそこからDDL形式のスキーマSTRUCT <a：BIGINT>を推測します。
この場合、スキーマ自体を使用する代わりに、JSONスキーマのスキーマを記述するschema_of_json（）の出力スキーマになってしまう可能性があります。これは正しい答えの選択肢ではありません。
ここで、StructType.fromJson（）メソッドを検討することを検討してください。これは、StructType型の変数を返します。これは、spark.read.jsonのスキーマパラメーターが期待する型とまったく同じです。
正解の選択肢は以前に見ていたかもしれませんが、この説明は、間違った答えの選択肢を体系的に排除する方法を教えるために、必要に応じて徹底的に説明されています。
より詳しい情報：
--pyspark.sql.DataFrameReader.schema--PySpark3.1.2ドキュメント
--pyspark.sql.DataFrameReader.json-PySpark3.1.2ドキュメント
--pyspark.sql.functions.schema_of_json-PySpark3.1.2ドキュメント
静的ノートブック| ダイナミックノートブック：テスト3を参照

説明
詳細：Sparkの実行：Sparkのランタイムアーキテクチャの概要-Manning（https://bit.ly/2RPmJn9）

説明
show（）は、ここで探す正しいメソッドです。質問では、行を適切にフォーマットされた方法で表示することが具体的に求められているためです。これがshowの出力です（数行のみが表示されています）。
+ ------------- + --------- + ----- + ------- + --------- +- --- + --------------- +
| transactionId | predError | value | storeId | productId | f | transactionDate |
+ ------------- + --------- + ----- + ------- + --------- +- --- + --------------- +
| 3 | 3 | 1 | 25 | 3 | null | 1585824821 |
| 5 | null | 2 | null | 2 | null | 1575285427 |
| 4 | null | 3 | 3 | 2 | null | 1583244275 |
+ ------------- + --------- + ----- + ------- + --------- +- --- + --------------- +
ソートに関しては、特に最小値を最初に表示する必要があるため、昇順で、次の式が有効です。
--transactionsDf.sort（col（ "value"））（ "ascending"は、sortメソッドのデフォルトのソート方向です）
--transactionsDf.sort（asc（col（ "value"）））
--transactionsDf.sort（asc（ "value"））
--transactionsDf.sort（transactionsDf.value.asc（））
--transactionsDf.sort（transactionsDf.value）
また、orderByは単なるソートのエイリアスであるため、これらの式はすべて、orderByを使用しても同様に機能します。
静的ノートブック| ダイナミックノートブック：テスト1を参照

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