Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Join Algorithm in Spark
Search
yabooun
June 28, 2022
Technology
0
97
Join Algorithm in Spark
Sparkを扱う上で最も重要な概念のひとつであるJoinについて、どういったアルゴリズムが使われているのかを解説します。
yabooun
June 28, 2022
Tweet
Share
More Decks by yabooun
See All by yabooun
データ分析基盤の要件分析の話(202201_JEDAI)
yabooun
1
1k
Other Decks in Technology
See All in Technology
生成AI活用の組織格差を解消する 〜ビジネス職のCursor導入が開発効率に与えた好循環〜 / Closing the Organizational Gap in AI Adoption
upamune
5
4.6k
AWS Organizations 新機能!マルチパーティ承認の紹介
yhana
1
230
CI/CD/IaC 久々に0から環境を作ったらこうなりました
kaz29
1
200
ハッカソン by 生成AIハッカソンvol.05
1ftseabass
PRO
0
150
生成AI開発案件におけるClineの業務活用事例とTips
shinya337
0
190
Lazy application authentication with Tailscale
bluehatbrit
0
110
OPENLOGI Company Profile for engineer
hr01
1
33k
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
0
1.3k
モバイル界のMCPを考える
naoto33
0
360
Should Our Project Join the CNCF? (Japanese Recap)
whywaita
PRO
0
300
Claude Code Actionを使ったコード品質改善の取り組み
potix2
PRO
6
2.6k
AIとともに進化するエンジニアリング / Engineering-Evolving-with-AI_final.pdf
lycorptech_jp
PRO
0
140
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Adopting Sorbet at Scale
ufuk
77
9.4k
GitHub's CSS Performance
jonrohan
1031
460k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
Building an army of robots
kneath
306
45k
The Straight Up "How To Draw Better" Workshop
denniskardys
234
140k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
4 Signs Your Business is Dying
shpigford
184
22k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Transcript
Join Algorithm in Spark 2022/06/28 @yabooun
自己紹介 藪本 晃輔 @yabooun 株式会社ジオロジック CTO 趣味: 登山、ピアノ、日本酒 晴れてると、空ばかり眺めてしまうので、今週末山に行ってきます。
Joinとは • 複数のテーブルを一定のルールに基づいて結合する処理 • SQLの基本的な構文のひとつ • LEFT JOIN, RIGHT JOIN,
INNER JOIN, CROSS JOIN, LEFT LATERAL JOIN, ・・・ • サブクエリも全部JOINで書ける • ただし、同じJOINでも、データ量やクエリによって違うアルゴリズムが使われる ◦ 使われるアルゴリズムは基本的に処理系が決める ◦ アルゴリズムによって全然速さが違う • RDBMSやHadoop/Spark等のビッグデータ系のシステムでは別のアルゴリズム ◦ ビッグデータ系はRDBMSより多くのアルゴリズムがある • 意外と奥が深いJOIN
RDBMSにおけるJOIN 1. Hash Join 2. Sort Merge Join 3. Nested
Loop Join
Hash Join 大きいテーブルと小さいテーブルを結合するときに使う。結合条件がシンプルなA=Bのときに利用可能。 1. 小さいテーブルの結合キーでハッシュを作成 2. 大きいテーブルをスキャン 3. 1行ごとに小さいテーブルをハッシュ検索 •
大きい方のテーブルをScanするだけなので最速 • 一番優先されるアルゴリズム • 片方が小さくないとHashがメモリに乗らない • インデックスがあるとさらに高速
Sort Merge Join 大きいテーブル同士を結合するときに使う。結合条件がシンプルなA=Bのときに利用可能。 1. 両方テーブルをそれぞれ結合キーでソート 2. それぞれのテーブルを上から順番に読みながら、結合 結果を出力する (ソート順が若い方のテーブルのカーソルを進めながら処理し
ていくイメージ) • 大きいテーブル同士では有効 • 結合キーにインデックスがないとソートに時間がかかる • 複雑な結合条件に対応できない
Nested Loop Join Hash JoinとSort Merge Joinで対応できないときに使用 1. 片方のテーブルをScan 2.
Scanしながら1行ごとにもう一方のテーブルを全部 Scan 3. 結合条件にマッチしていたら結合 • N * N のコストがかかる • どんな条件でもできる • 基本的には使わせたくない
RDBMSにおけるJOIN • 基本的にはHash Joinが使われるようにしよう • せめてSort Merge Joinが使われるようにしよう • Joinのキーはインデックス登録しておこう
• 文字列結合したり変な条件で Joinすると遅い
SparkにおけるJOIN • Sparkでもほとんど似た考え方の Joinが使われる • 複数のノードからなるクラスタで実行されるため、同じアルゴリズムでも複数パターン • アルゴリズムひとつ変わると、クエリの速度が 1,000倍くらい余裕で変わる
SparkにおけるJOIN 1. Broadcast Hash Join 2. Shuffle Hash Join 3.
Shuffle Sort Merge Join 4. Broadcast Nested Loop Join 5. Cartesian Join
Broadcast Hash Join 大きいテーブルと小さいテーブルを結合するときに使う。結合条件がシンプルなA=Bのときに利用可能。 1. 小さいテーブルの結合キーでハッシュを作成 2. ハッシュをすべてのノードにコピー 3. 各ノードでHash
Join 4. 結果を結合 • 一番早い。とにかくこれを使え。 • Sparkの仕様上小さいテーブルが8MBまで。 (Sparkのデフォルトはたしか1MBくらいになっているこ とが多い)
Shuffle Hash Join 大きいテーブルとそこそこ大きいテーブルを結合するときに使う。結合条件がシンプルなA=Bのときに利用可能。 1. それぞれをテーブルを結合条件でshuffle 2. 各ノードでHash作成 3. 各ノードでHash
Join 4. 結果を結合 • Broadcast Hash Joinの次に早い • おそらくShuffleでIOが発生するケースがあるからか、 想像より遅い
Shuffle Sort Merge Join 大きいテーブル同士を結合するときに使う。結合条件がシンプルなA=Bのときに利用可能。 1. それぞれをテーブルを結合条件でshuffle 2. 各ノードでSort Merge
Join 3. 結果を結合 • あまり早くない • Shuffleが発生する上に、各ノードでソート • Shuffle、ソートはどちらも大きなデータでは時間のかか る処理
Broadcast Nested Loop Join 結合条件が複雑なときに使用。両方が大きすぎると手の打ちようがない。 1. 小さいの方のテーブルを全ノードにコピー 2. 大きい方のテーブルを各ノードに分散 3.
各ノードでNested Loop Join 4. 結果を結合 • 使ってはいけないくらい重い • 使ったらエラーを出すオプションもある
JOINの敵、Skew Skewとはデータの偏り。偏りが大きいと全体の結果がなかなか返ってこない。 Shuffle系のJoinで問題になる。 このケースだと、Worker1の処理が終わるまで全体のJoinが完了しない。
Skewの最適化 Spark 3.0でSkew Hintを与えることにより(条件によってはHintがなくても)Skewを検知してデータを再分散し、偏りによる問題 を最小化する機能が追加された。 Skewの発生しているWorker1を再分散して別のWorkerで処理をする。
結論 • できるだけBroadcast Joinを使おう ◦ マスタとの結合は明示的に Bradcast Hash Joinを使わせたりする •
どうしても出来ないときでも、複雑な条件では Joinしないようにしよう • Shuffle Joinが発生するカラムは均等に分散される設計にしよう ◦ IDFAやランダムな文字列などは基本的に偏りがない ◦ ステータスやtype系のものでJoinしようとするとSkewが発生しやすい • あとは実際どのJoinが使われているか、実行プランを確認しよう