Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
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
110
Join Algorithm in Spark
Sparkを扱う上で最も重要な概念のひとつであるJoinについて、どういったアルゴリズムが使われているのかを解説します。
yabooun
June 28, 2022
Tweet
Share
More Decks by yabooun
See All by yabooun
データ分析基盤の要件分析の話(202201_JEDAI)
yabooun
1
1.1k
Other Decks in Technology
See All in Technology
特別捜査官等研修会
nomizone
0
570
Identity Management for Agentic AI 解説
fujie
0
470
AI with TiDD
shiraji
1
280
Amazon Connect アップデート! AIエージェントにMCPツールを設定してみた!
ysuzuki
0
140
Authlete で実装する MCP OAuth 認可サーバー #CIMD の実装を添えて
watahani
0
180
ActiveJobUpdates
igaiga
1
320
【開発を止めるな】機能追加と並行して進めるアーキテクチャ改善/Keep Shipping: Architecture Improvements Without Pausing Dev
bitkey
PRO
1
130
オープンソースKeycloakのMCP認可サーバの仕様の対応状況 / 20251219 OpenID BizDay #18 LT Keycloak
oidfj
0
170
Oracle Database@Azure:サービス概要のご紹介
oracle4engineer
PRO
2
200
マイクロサービスへの5年間 ぶっちゃけ何をしてどうなったか
joker1007
20
7.7k
AIエージェント開発と活用を加速するワークフロー自動生成への挑戦
shibuiwilliam
5
850
MariaDB Connector/C のcaching_sha2_passwordプラグインの仕様について
boro1234
0
1k
Featured
See All Featured
First, design no harm
axbom
PRO
1
1.1k
Information Architects: The Missing Link in Design Systems
soysaucechin
0
720
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.3k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
66
How to Think Like a Performance Engineer
csswizardry
28
2.4k
The Cult of Friendly URLs
andyhume
79
6.7k
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
100
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
0
22
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
850
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
0
1.8k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.2k
What's in a price? How to price your products and services
michaelherold
246
13k
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が使われているか、実行プランを確認しよう