目次 › 第3章 › 3-5

第3章 データ変換とモデリング / 想定学習時間:30〜40分 / 最終確認:2026年8月

3-5. 基本チューニングパラメータ(shuffle.partitions・parallelism・memory・broadcastJoinThreshold)

1. チューニングの前提:シャッフルとパーティション

3-2 で見たとおり、結合や集約(groupBy)では、同じキーの行を同じワーカーに集めるシャッフルが発生します。シャッフル後のデータはパーティションという単位に分割され、パーティション1つが処理タスク1つに対応します。つまり「パーティション数=並列度と1タスクあたりのデータ量を決めるダイヤル」であり、本節のパラメータの多くはこのダイヤルの調整です。

大原則を先に述べます。チューニングは計測とセットです。パラメータを変えたら Spark UI やジョブの実行時間で効果を再計測し、改善しなければ戻す。「とりあえず値を変えて放置」は、データ量が変わった半年後に別の問題を引き起こします。

2. 4つの基本パラメータ

2-1. spark.sql.shuffle.partitions(既定:200)

シャッフル後に作られるパーティションの数です。DataFrame/SQL の結合・集約の後の並列度を決めます。既定値は 200 で、データ量に関係なく一律です。

• 小さなデータで 200 は多すぎる → 1タスクあたり数KBのような「小さすぎるタスク」が大量にでき、タスク起動のオーバーヘッドが支配的になる → 値を減らす
• 巨大なデータで 200 は少なすぎる → 1タスクが抱えるデータが大きくなりすぎ、メモリ溢れ(ディスクへのスピル)や OOM の原因になる → 値を増やす

# 現在値の確認と変更(PySpark)
spark.conf.get("spark.sql.shuffle.partitions")   # '200'
spark.conf.set("spark.sql.shuffle.partitions", 64)

-- SQL でも設定できる
SET spark.sql.shuffle.partitions = 64;

2-2. spark.default.parallelism

RDD 系 API の既定並列度です(既定値はクラスタの総コア数などから決まります)。名前が似ていて混同しやすいのですが、DataFrame/SQL のシャッフル並列度を決めるのは spark.sql.shuffle.partitions の方です。DataFrame 中心の現在の開発でこの値を触る場面は限られますが、試験ではこの「どちらが何に効くか」の区別が問われます。

2-3. spark.executor.memory / spark.driver.memory

各 executor(ワーカー上の実行プロセス)とドライバに割り当てるメモリ量です。Databricks ではクラスタのインスタンスタイプ選択でほぼ決まるため直接指定する場面は少ないものの、意味の理解は必須です。

• executor メモリ不足の症状:タスクの OOM、シャッフルやソートでの大量スピル(メモリに収まらずディスク退避)による低速化。対処は、メモリの大きいワーカーへの変更のほか、パーティション数を増やして1タスクあたりのデータ量を減らす方が効くことも多い
• ドライバメモリ不足の症状:collect() で大量データをドライバに集めた、巨大テーブルを broadcast した、などでドライバが OOM。対処はまずコード側の見直し(collect をやめる、broadcast 対象を見直す)

2-4. spark.sql.autoBroadcastJoinThreshold(既定:10MB)

結合時に「このサイズ以下のテーブルは自動で broadcast join にする」という閾値です(3-2 の復習:broadcast join は小テーブルを全ワーカーに配ってシャッフルを回避する方式)。-1 を設定すると自動 broadcast を無効化できます。

• 閾値を上げる:数十MB程度のマスタテーブルも broadcast してシャッフルを避けたいとき(ワーカーのメモリに余裕がある前提)
• 閾値を下げる/無効化(-1):統計情報の不正確さなどで実際は大きいテーブルが broadcast されてしまい、OOM や遅延が起きているとき

spark.conf.set("spark.sql.autoBroadcastJoinThreshold", 50 * 1024 * 1024)  # 50MB
spark.conf.set("spark.sql.autoBroadcastJoinThreshold", -1)                # 無効化

3. 症状→パラメータの対応表

試験でも実務でも、「この症状のとき何を変えるか」という形で問われます。

4. AQE(Adaptive Query Execution):多くは自動化されている

ここまで手動チューニングを説明してきましたが、現在の Spark / Databricks では AQE(Adaptive Query Execution)が既定で有効であり、実行時の統計を見ながら多くを自動調整します。

つまり、shuffle.partitions の「多すぎる」側の問題や、broadcast 判断の多くは AQE が吸収してくれます。それでも本節の知識が必要な理由は次の3つです。

• AQE の自動調整にも上限・前提があり、異常時に何が起きているか読み解くには各パラメータの意味の理解が要る
• shuffle.partitions は AQE にとっても初期値(上限の目安)として意味を持つ
• 試験では「各パラメータが何を制御するか」「AQE が何を自動化するか」の両方が問われる

練習問題