説明
itemsDf.printSchema()
正しい！itemsDf.printSchema() が示す例を次に示します。列名と型の両方を含むツリー状の構造がわかります。
根
|-- itemId: 整数 (null 許容 = true)
|-- 属性: 配列 (null 許容 = true)
| |-- 要素: 文字列 (Null = true を含む)
|-- サプライヤー: 文字列 (null 可能 = true)
itemsDf.rdd.printSchema()
いいえ、DataFrame の基礎となる RDD には printSchema() メソッドがありません。
スパーク.スキーマ(itemsDf)
不正解です。spark.schema コマンドはありません。
print(itemsDf.columns)
print(itemsDf.dtypes)
間違い。このコード ブロックの出力には列名と列タイプの両方が含まれていますが、情報はツリー状に配置されていません。
itemsDf.print.schema()
いいえ、DataFrame には print メソッドがありません。
静的ノート | 動的ノートブック: テスト 3 を参照

説明
ディレクトリ filePath 内のファイルは、gzip 圧縮を使用してエクスポートされた DataFrame のパーティションです。
Spark はこの状況を自動的に認識し、CSV ファイルを個別のパーティションとして単一の DataFrame にインポートします。ただし、Spark が header オプションを使用して CSV 内のファイル ヘッダーをロードするように指定する必要があります。このオプションはデフォルトで False に設定されています。

説明
正しいコードブロック:
transactionsDf.orderBy('value', desc_nulls_last('predError'))
predError 列は降順でソートし、null を最後に置く必要があります。
正しい！デフォルトでは、Spark は昇順にソートし、null を最初に配置します。したがって、デフォルトのソートの逆ソートは実際には desc_nulls_last です。
orderBy の代わりに、sort を使用する必要があります。
いいえ、DataFrame.sort() はパーティションごとにデータを順序付けしますが、グローバルな順序は保証しません。このため、ここでは orderBy がより適切な演算子となります。
列の値は、col() 演算子でラップする必要があります。
正しくない。DataFrame.sort() は、文字列オブジェクトと列オブジェクトの両方を受け入れます。
列 predError は、代わりに desc_nulls_first() でソートする必要があります。
間違い。Spark のデフォルトのソート順序は asc_nulls_first() と一致するため、反転する場合は null が最後に来る必要があります。
1 つの orderBy ステートメントに両方の列を含めるのではなく、個々の列を呼び出す 2 つの orderBy ステートメントをチェーンする必要があります。
いいえ、これは DataFrame を最後の列で並べ替えるだけであり、質問に記載されているように、両方の列からの情報は考慮されません。
詳細: pyspark.sql.DataFrame.orderBy - PySpark 3.1.2 ドキュメント、pyspark.sql.functions.desc_nulls_last - PySpark 3.1.2 ドキュメント、Spark の sort() と orderBy() | データサイエンスに向けて 静的ノートブック | 動的ノートブック: テスト 3 を参照

説明
これは非常に難しい質問であり、マージに関する知識と、寄木細工のファイルを読み取るときのスキーマの両方の知識が必要です。
smile.read.option("mergeSchema", "true").parquet(filePath)
正しい。両方のパーティションに表示される列のデータ型が一致するため、Spark の DataFrameReader の mergeSchema オプションはここでうまく機能します。両方のパーティションに存在する同じ名前の 1 つ以上の列のデータ型が異なる場合、mergeSchema は失敗することに注意してください。
スパーク.read.parquet(ファイルパス)
正しくない。これにより両方のパーティションからデータが読み込まれますが、最初に読み込まれる寄木細工ファイルのスキーマのみが考慮されるため、2 番目のパーティションにのみ表示される一部の列 (tax_id など) は失われます。
nx = 0
dbutils.fs.ls(filePath) のファイルの場合:
file.name.endswith(".parquet") でない場合:
続く
df_temp =spark.read.parquet(file.path)
nx == 0の場合:
df = df_temp
それ以外：
df = df.union(df_temp)
nx = nx+1
DF
間違い。このソリューションの重要なアイデアは DataFrame.union() コマンドです。このコマンドはすべてのデータをマージしますが、両方のパーティションに同じデータ型のまったく同じ数の列が必要です。
smile.read.parquet(filePath, mergeSchema="y")
間違い。mergeSchema オプションを使用することがこの問題を解決する正しい方法であり、コード ブロックのように DataFrameReader.parquet() で呼び出すこともできますが、値 True をブール値または文字列変数として受け入れます。ただし、「y」は有効なオプションではありません。
nx = 0
dbutils.fs.ls(filePath) のファイルの場合:
file.name.endswith(".parquet") でない場合:
続く
df_temp =spark.read.parquet(file.path)
nx == 0の場合:
df = df_temp
それ以外：
df = df.join(df_temp, how="アウター")
nx = nx+1
DF
いいえ。これにより完全外部結合が引き起こされます。結果の DataFrame には両方のパーティションのすべての列が含まれますが、両方のパーティションに表示される列は重複します。質問では、パーティションに含まれるすべての列が 1 回だけ表示される必要があると述べています。
詳細: Apache Spark での異なるスキーマのマージ | チアゴ・コルドン著 | データアリーナ | 中型静的ノートブック | 動的ノートブック: テスト 3 を参照

説明
複数の文字列列を 1 つの列に連結すると、メモリ不足エラーを防ぐことができます。
まさに、これは不正解です！文字列列を連結してもデータのサイズは減りません。構造が異なるだけです。これは Spark によるデータの処理方法にはほとんど影響せず、メモリ不足エラーは明らかに減りません。
パーティション サイズを小さくすると、メモリ不足エラーを防ぐことができます。
いいえ、これは間違いではありません。エグゼキューターはパーティションを処理する前にメモリにロードする必要があるため、パーティション サイズを減らすことはメモリ不足エラーを防ぐための有効な方法です。これを行うのに十分なメモリがエグゼキュータにない場合、メモリ不足エラーがスローされます。したがって、パーティション サイズを減らすことは、それを防ぐのに非常に役立ちます。
各エグゼキュータで使用できるコアの数を減らすと、メモリ不足エラーを防ぐことができます。
いいえ、これは間違いではありません。パーティションを処理するには、このパーティションをエグゼキュータのメモリにロードする必要があります。すべてのエグゼキュータのすべてのコアが、他のエグゼキュータと並行してパーティションを処理すると想像すると、エグゼキュータをホストしているマシン上のメモリがすぐにいっぱいになることが想像できます。したがって、特に複数のパーティションが同時に処理される場合、エグゼキュータのメモリ使用量が問題になります。パフォーマンスとメモリ使用量のバランスをとるには、コアの数を減らすとメモリ不足エラーを防ぐことができる場合があります。
ドライバーに返されるシリアル化されたデータの最大サイズに制限を設定すると、メモリ不足エラーの防止に役立つ場合があります。
いいえ、これは間違いではありません。クラスターからドライバーへの潜在的に大量のデータの送信をトリガーするcollect() などのコマンドを使用すると、ドライバーでメモリ不足エラーが発生する可能性があります。これを回避する 1 つの戦略は、ドライバーに大量のデータを送り返すcollect() などのコマンドの使用に注意することです。もう 1 つの戦略は、パラメーター spar.driver.maxResultSize を設定することです。ドライバーに送信されるデータがパラメーターで指定されたしきい値を超えると、Spark はジョブを中止するため、メモリー不足エラーが発生するのを防ぎます。
結合で自動的にブロードキャストされるデータの量を制限すると、メモリ不足エラーの防止に役立ちます。
違います、これは間違いではありません。Spark の内部最適化の一環として、Spark は (通常は比較的小さい) テーブルをエグゼキューターにブロードキャストすることで操作を高速化することを選択する場合があります。このブロードキャストはドライバーから行われるため、最初にすべてのブロードキャスト テーブルがドライバーにロードされます。これらのテーブルが比較的大きい場合、または複数の中サイズのテーブルがブロードキャストされている場合、メモリ不足エラーが発生する可能性があります。Spark がブロードキャストを考慮する最大テーブル サイズは、spark.sql.autoBroadcastJoinThreshold パラメーターによって設定されます。
詳細情報: 構成 - Spark 3.1.2 ドキュメントおよび Spark OOM エラー - クローズアップ。次のような場合に見覚えはありますか? アミット・シン・ラソール著 | スタートアップ | 中くらい