Databricksチューニングあれこれ（JEDAI 2023 X‘mas/忘年会 Meetup! LT登壇資料）

© 2023 NTT DATA Group Corporation 1
Databricksチューニングあれこれ
～JEDAI 2023 X‘mas/忘年会 Meetup!～
株式会社NTTデータグループ技術革新統括本部技術開発本部北波紘子
データブリックス・ジャパン株式会社 Sr. Specialist Solutions Architect 板垣輝広

まずは自己紹介

きたなみではなく、きたばです
＜アジャイル開発プロジェクト立ち上げ＞
• 製薬会社向けデータ活用プロジェクト
• アジャイル開発性能評価ツール開発
• 金融業向け基盤開発プロジェクト
2023
Databricks Solutions Architect Champion
を取得しました
北波紘子
Hiroko Kitaba
株式会社NTTデータグループ技術開発本部
IOWN推進室高度OSSサポート担当主任
＜略歴＞
金融・製薬・エネルギーなど様々な業界で、
OSS使用プロジェクトの開発・性能検証支援やアジャイル開発のコンサルティングに従事
代表例：
＜ビッグデータ関連プロジェクト支援＞
• 流通業向け性能検証
• 電力業界向けシステムの基盤性能検証
• Bigtop資材開発
• 自動車業界向け基盤開発
今年9月のDATA+AIで
パネルディスカッション
しました
最近はまっているもの
株式会社マクニカ
太田さん
Databricks
徳元さん
ジャズ
タップダンス・着付け
どれも初心者。教えてください！

＜競艇AIモデル作成プロジェクト＞
• 分類、回帰、ランキング学習の組み合わせ
で2023/8月-11月の収支において回収率
110%を達成
2023
最近、記憶力が低下していると感じており
メモを取るように心がけています
板垣輝広
Mitsuhiro Itagaki
Databricks Japan
シニア・スペシャリスト・ソリューションアーキテクト
＜略歴＞
元プロボクサー
Databricksではデータエンジニアリング、データウェアハウスの領域のスペシャリスト・
ソリューションアーキテクトとして様々な案件において技術支援を実施
＜Databricks麻雀選手権＞
• 2023/10月の麻雀選手権ではトップを獲得
最近はまっているもの
競艇・麻雀
麻雀はけっこう打てます。
一局どうですか？
得意技はワンツーからの
右フックです。
代表例：
ニックネームはがっきーです

わたし普段、Sparkの性能チューニング
ばかりやっている
たのしいけどせつない
きっと君(おだやかな日々)は来ない
ひとりきりのクリスマス・チューニング
チューニングの
予定はあるやん
やったね

この繰り返し
性能改善時のフローの概要
実行(性能測定)
処理時間確認
ソースコードの
設計の確認/修正
リソース使用
状況確認
クラスタ設定
確認
リソース
設定値修正
Spark設定値
修正
Spark UI
(Spark History Server)
バージョン管理
システム
Ganglia
issueを確認す
る
ソースコードを
読む
※EMRの画面
バグ・設計の確認
クエリの
実行状況確認

この繰り返し
性能改善時のフローの概要
実行(性能測定)
処理時間確認
ソースコードの
設計の確認/修正
リソース使用
状況確認
クラスタ設定
確認
リソース
設定値修正
Spark設定値
修正
Spark UI
(Spark History Server)
バージョン管理
システム
Ganglia
issueを確認す
る
ソースコードを
読む
※EMRの画面
バグ・設計の確認
クエリの実行
状況
確認

目が回っている場合じゃない！
Databricksには
性能チューニングの新機能というものが
あったな！

新機能であれこれ解決して
たのしいクリスマスを過ごせないかな

● Databricksの新機能と従来手法での性能チューニング方法での
4つのクエリの走行時間を比較してどちらが有用か確認したい (そして楽しいクリスマスを)
★Databricksの新機能リキッドクラスタリング/Predictive IO
● 4つのクエリ
● 対象テーブル
● 概要：3テーブル(TPC-Hベンチマークのテーブル)
● サイズ：約3.8TB(CSVテキスト換算) 一番大きなテーブルは約300億件(CSVテキスト換算：約3.7TB)
ということで、Databricksチューニングあれこれ
クエリ概要選定観点
1 フルスキャン素早く取得できるか。コンパクションとPredictive IOが有用そう
2 3つのカラムでの絞り込みこれはやらないとね
従来手法でのチューニング（パーティション＋Zorder)との全力
での競り合いを見たい
3 パーティションキー指定なし
2つのカラムでの絞り込み
リキッドクラスタリングのかっこいいとこみてみたい♪
4 パーティションキー指定のみ
新機能と従来のパーティション設計手法どちらが有用か…

リキッドクラスタリング Databricksランタイム13.2以降
• クラスタリングキーを柔軟に定義してくれる機能パーティション設計要らずかも
Predictive IO Databricksランタイム11.2以降
• ディープラーニングでクエリの検索条件の確率を計算して最適な読み込みをしたり、
不要な列や行のデコードを行ってくれる機能
Databricksの新機能(ざっくり説明)
この場には詳しい方がたくさん
周りの皆さんにも聞いてください

比較対象となる実行パターン
比較実行パターンは
実行パターン概要
1 チューニングなしチューニングを全くしないケース。
以下２つのチューニングの効果を測るための基準値として計測。
2 従来のチューニング
(パーティション＋Z-Order)
従来TB以上の大規模テーブルでは一般的に実施されているパー
ティション＋Z-Orderによる鉄板チューニング。
明示的なデータパーティションをユーザ側で指定できるのが強み
3 新機能のチューニング
(リキッドクラスタリング)
リキッドクラスタリングでパーティション設計なしで、コンパク
ション＋データクラスタリングを実施する。
※ランタイム13.x以上でサポート

© 2023 NTT DATA Group Corporation

SELECT
l_orderkey,
sum(l_extendedprice * (1 - l_discount)) as revenue,
o_orderdate,
o_shippriority,
count(1)
FROM
customer,
orders,
lineitem <-- 約300億件(CSVテキスト換算：約3.7TB)
WHERE
c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND l_comment like '%final%'
GROUP BY
l_orderkey,
o_orderdate,
o_shippriority
ORDER BY
revenue desc,
o_orderdate
LIMIT 20;
Where句にチューニングで設定した
フィルタ条件がないためフルスキャン。。
クエリ1：フルスキャン
1 フルスキャン素早く取得できるか。
コンパクションとPredictive IOが有用そう
従来手法でのチューニング（パーティション＋Zorder)との全力で
の競り合いを見たい
従来のチューニングパターン
：
L_SHIPDATE：パーティションキー
L_LINENUMBER：Z-Orderキー1
L_SHIPMODE：Z-Orderキー2
リキッドクラスタリング：
L_SHIPDATE：クラスタリングキー1
L_LINENUMBER：クラスタリングキー2
L_SHIPMODE：クラスタリングキー3

SELECT
l_orderkey,
o_orderdate,
o_shippriority,
count(1)
FROM
customer,
orders,
Lineitem <-- 約300億件(CSVテキスト換算：約3.7TB)
WHERE
c_mktsegment = 'BUILDING'
AND L_SHIPDATE between '1997-01-01' and '1997-12-31'
AND L_LINENUMBER = 1
AND L_SHIPMODE = 'AIR'
AND c_custkey = o_custkey
GROUP BY
l_orderkey,
o_orderdate,
o_shippriority
ORDER BY
revenue desc,
o_orderdate
LIMIT 20;
両ケースとも絶好調の状態！！
クエリ2：3つのカラムで絞り込み
：
従来手法でのチューニング（パーティション＋
Zorder)との全力での競り合いを見たい


SELECT
l_orderkey,
o_orderdate,
o_shippriority,
count(1)
FROM
customer,
orders,
WHERE
AND L_LINENUMBER = 1
AND L_SHIPMODE = 'AIR'
GROUP BY
l_orderkey,
o_orderdate,
o_shippriority
ORDER BY
revenue desc,
o_orderdate
LIMIT 20;
パーティションキー指定がないので
実力が発揮できないケース。。
アドホック分析にも強いところ
が見せられる？？
：
リキッドクラスタリングのかっこいいとこみてみた
い♪

SELECT
l_orderkey,
o_orderdate,
o_shippriority,
count(1)
FROM
customer,
orders,
WHERE
AND L_SHIPDATE between '1997-01-01' and '1997-12-31'
GROUP BY
l_orderkey,
o_orderdate,
o_shippriority
ORDER BY
revenue desc,
o_orderdate
LIMIT 20;
パーティションキーでのみフィルタ
される！
１つのクラスタリングキーでのみ
フィルタされる！
：
新機能と従来のパーティション設計手法どちらが有
用か…

Runtime 14.2での処理結果
※文字数のため以下で省略
青：チューニングなし
橙：既存...Partition＋Z-Order
灰：新機能…LiquidClustering
クラスタサイズ：
i3.2xlarge (61GB / 8cores) ✖️12 worker

Runtime 14.2での処理結果
フルスキャン
コンパクションが優秀
新機能と既存の差はあまり見られない
3カラムでの絞り込み
どちらも有効に働いている
新機能と既存の差はあまり見られな
い
2カラムでの絞り込み(パーティショ
ンキー以外)
リキッドクラスタリングが有効に働
いている
1カラム（パーティションキー）での
絞り込み
新機能と既存の差はあまりみられな
いがどちらも有効に働いている
※文字数のため以下で省略
青：チューニングなし
橙：既存...Partition＋Z-Order
灰：新機能…LiquidClustering
クラスタサイズ：
i3.2xlarge (61GB / 8cores) ✖️12 worker

Runtime 10.4 LTS( Predictive I/Oなし） Runtime 14.2( Predictive I/Oあり）
Predictive I/Oのメトリクス

Runtime 14.2とRuntime 10.4LTSによる処理時間の違い
※10.4LTSなので新機能のチューニング比較はできない

どちらも特殊なソート技術でデータをクラスタリングするため、I/O削減効率は全く同じなのですが、
リキッドクラスタリング
- データ書き込み時(512MBまでのWrite)に自動クラスタリングが実行されるため、クエリパフォーマンス
劣化が起きにくく、明示的なOptimizeコマンドの実行時間が短縮されます！！
- 将来的な機能拡張でリキッドクラスタリングキーの自動選定が可能になります！！！
- テーブル属性として定義され、カタログ情報から参照可能
- レコードレベルの同時更新をサポート
- パーティションテーブルとの併用は不可
- 先頭の32カラムのうち最大4カラムまで
- テーブル属性として定義され、カタログ情報から参照可能
Z-Order
- パーティションテーブルとの併用が可能
- 先頭の32カラムにZ-Orderに定義可能（ただし実際に効果があるのは4カラムまで程度です！）
- テーブル属性として定義されないためカタログ情報には記録されません。
Z-Orderとリキッドクラスタリングの違いは？？
これからは
リキッドクラスタリング！

新機能：
プレディクティブオプティマイゼーション！
デルタ・テーブルを最適化するためのオペレーションを自動的に識別
管理オペレーションを自動化
フェーズ1
OPTIMIZE(物理ファイル最適化)実行
VACUUM(データ物理削除)実行
※UnityCatalog管理テーブルが対象
フェーズ2
ANALYZE(統計情報取得)実行
※UnityCatalog外部テーブルサポート
フェーズ3
リキッド・クラスタリングキー
設定の最適化
ALTER CATALOG [catalog_name] {ENABLE | DISABLE} AUTO MAINTENANCE
ALTER {SCHEMA | DATABASE} schema_name {ENABLE | DISABLE} AUTO MAINTENANCE
1 2 3
プレビュー中 TBD TBD

今回は一部チューニングをやったが他にもチューニングポイントはあるまだあるのでTo be continued…
いろいろチューニングやりたいこと盛りだくさん
チューニング観点方法汎用性想定ユースケース結果・効果
データの最適化
(OPTIMIZE)
Z-Orderによりマッピングして並び替えるあり全体的な最適化に向いている今回実施
コンパクションを実施するあり全体的な最適化に向いている今回実施
シャッフルサイズ
の最適化
spark.sql.shuffle.partitions=auto
spark.databricks.adaptive.autoOptimizeSh
uffle.enabled=True
にして、シャッフルサイズを最適化する
ありシャッフルサイズが大きくて
処理に時間がかかっている場
合は有効
今回実施
→今回はシャッフル
サイズは200のまま
であった
パーティションサイズ
の調整
カーディナリティが適切なキーで
repartitionを使用する
なしバッチ処理や特定の処理特化
型
今回実は実施
→古いLTSでも有効
Join方法の調整 Broadcastを指定するなしサイズの小さいマスタなどを
扱う際に使用する
JOIN方法を明示的に指定するなし INNERJOINは効果ありそう
キャッシュヒット率を
上げる
Cashを使用するなしメモリに乗り切るデータサイ
ズの場合
何度もデータを使用する場合

• リキッドクラスタリング機能はかなり有用なので
これからパーティショニング設計は要らない...かも
• Databricksの新機能は従来手法と比べ高速かつチューニングコストが削減できる
新しいランタイムにしてぜひ使ってみましょう！
• 現在のコンパクション、バキュームの自動化機能に加え、統計情報の取得、
リキッドクラスタリングキーの自動設定が可能になる予定です！
まとめ

ありがとうDatabricks
今年のクリスマスは
特に予定はないけれどたのしく過ごせそうです

付録

チューニングなし従来のチューニング
(コンパクション＋パーティ
ション＋Z-Order)
新機能のチューニング
(コンパクション＋リキッド
クラスタリング)
参考：チューニングあり
(コンパクション＋Z-Order)
クエリ１ 129.0 41.16 41.25 42.52
クエリ２ 58.85 2.60 1.57 1.56
クエリ３ 58.49 16.64 2.64 2.86
クエリ４ 55.98 7.05 7.64 7.58
実行結果の詳細 Runtime 14.2

実行結果の詳細 Runtime 10.4LTS
チューニングなしチューニング１
(コンパクション＋パーティ
ション＋Z-Order)
チューニング２
(コンパクション＋リキッド
クラスタリング)
参考：チューニングあり
(コンパクション＋Z-Order)
クエリ１ 196.8 85.8 N/A 87.6
クエリ２ 93.0 6.44 N/A 1.94
クエリ３ 88.2 48.52 N/A 4.57
クエリ４ 89.4 14.06 N/A 15.95

取り扱っていたデータサイズの詳細
Lineittem表のCSVテキ
ストサイズ：3.72TB
チューニングなし従来のチューニング
(コンパクション＋パーテ
ィション＋Z-Order)
新機能のチューニング
(コンパクション＋リキッ
ドクラスタリング)
Lineitem表物理サイズ
（Deltaフォーマット
）
965.6GiB 237.5GiB 351.8GiB
物理ファイル数 8807 5634 6367
予想より圧縮が効いているのは増幅データのためかも

Pysparkが好きなのでテーブルデータの物理配置の変更をrepartitionでも試してみました。
テーブルデータの物理配置はテーブル/パーティションテーブル再作成 or クラスタリングする際に時間がかかるのが難点。
Where句での絞り込みに使用するカラムを変更してテーブルを再作成したい場合などはこの方法もあるよ。
この方法だとデータスキッピンングに使用するカラムが複数の場合はパーティショニング・クラスタリングほどのI/O削減はできま
せんが、テーブル再作成＋Optimizeよりもクイックにファイル物理配置の変更ができるためバッチ処理などでは使用できるかも。
おまけ：こういうチューニング方法もあるよ
でもさ
リキッドクラスタリングの方が楽だねわかる
ソースコード例
LTS 14.2 Repartition
+saveAsTable
Create table as select +Z-
Order
所要時間
22分
14分(CTAS)＋50分(Zorder) =
64分
LTS
14.2
チューニング
なし
Repartition
+saveAsTable
Create table as
select＋Z-Order
クエリ1 129.0秒 46.42秒 103.8秒
クエリ2 58.9秒 8.39秒 7.21秒
クエリ3 58.5秒 23.21秒 35.57秒
クエリ4 56.0秒 10.68秒 8.84秒
spark.conf.set("spark.sql.adaptive.coalescePartitions.minPartitionNum", "3000")
spark.conf.set("spark.sql.adaptive.coalescePartitions.minPartitionSize","10mb")
from pyspark.sql.functions import col, substring
df = spark.table('main.db_notuning.lineitem')
df = df.repartition(3000,col('L_SHIPDATE'))
df.write.saveAsTable('lineitem_vt')
例：別の検索キー（キーは１つ指定）に要した時間
例：キー変更後、先の４つのクエリに要した時間

Databricksチューニングあれこれ（JEDAI 2023 X‘mas/忘年会 Meetup! LT登壇資料）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Databricksチューニングあれこれ（JEDAI 2023 X‘mas/忘年会 Meetup! LT登壇資料）

Similar to Databricksチューニングあれこれ（JEDAI 2023 X‘mas/忘年会 Meetup! LT登壇資料） (20)

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

Recently uploaded

Recently uploaded (9)

Databricksチューニングあれこれ（JEDAI 2023 X‘mas/忘年会 Meetup! LT登壇資料）