【テクニカル・上級編】分散クエリ実行の仕組み – Cloud Spanner

分散クエリの深淵：Cloud Spannerがいかにして「不可能」を可能にするか

Cloud Spannerを単なる「強力なRDBMS」と呼ぶのは、ジェットエンジンを「よく回る扇風機」と呼ぶのに等しい。

多くのエンジニアは、Spannerが提供する外部整合性と水平スケーラビリティに目を奪われる。だが、真に恐ろしいのはそのクエリ実行エンジンだ。数ペタバイトのデータが数千のノードに散らばっている環境で、なぜ数ミリ秒で複雑な結合が完結するのか。今日は、ドキュメントの表面をなぞるような解説はしない。Spannerの心臓部、分散クエリ実行の深淵を解剖する。

—

1. 物理配置を超越する実行プランナー

Spannerのクエリエンジンは、Colocation（配置）を至上の命題とする。しかし、データは常に理想的な配置にはない。このとき、エンジニアがSQLを投げると、Spannerのクエリプランナーは以下の階層で実行戦略を決定する。

実行の3大フェーズ

1. Local Execution: 各Split（データの断片）が存在するノード内での処理。
2. Distributed Execution: 複数ノード間でのデータ交換（Shuffle/Broadcast）。
3. Aggregation: 各ノードからのストリームをマージし、クライアントへ返す。

ここで重要なのは、「ネットワークI/Oは極悪」という分散システムの鉄則をプランナーが骨の髄まで理解している点だ。

—

2. 結合戦略の「極限」：シャッフル vs ブロードキャスト

Spannerが結合（Join）を処理する際、プランナーはデータのCardinality（カーディナリティ）と統計情報を基に、以下のいずれかのモードを選択する。

A. Distributed Hash Join (Shuffle Join)

大規模なテーブル同士を結合する場合、両方のテーブルを結合キーでハッシュ化し、特定のノード群へ再配置（Shuffle）する。

深層知見: Shuffleのコストはネットワーク帯域を食い尽くす。そのため、Spannerは「Partial Aggregation（部分集計）」をShuffleの直前に行う。各ノードで結合キー単位の集計を行い、Shuffleするデータ量を減らすことでネットワーク負荷を極限まで押し下げる。

B. Broadcast Join

片方のテーブルが十分に小さい場合、そのテーブルを全ノードに「バラまく（Broadcast）」。

深層知見: これにより、ネットワークを跨ぐShuffleを完全に排除する。プランナーは、統計情報からテーブルサイズを判定し、もしBroadcastが計算コストより安いと判断すれば、迷わずメモリへ展開する。この際、メモリのオーバーコミットをいかに回避するかが、Spannerのメモリ管理アルゴリズムの腕の見せ所だ。

—

3. 分散実行モデルの裏側：Pipeline Execution

Spannerのクエリ実行は、基本的にパイプラインモデルだ。演算子（Filter, Project, Join, Aggregate）は、データが完全に揃うのを待たずに、ストリーミングで次段へ渡される。

— 分散クエリ実行の概念的イメージ
— 1. 各スプリットでローカルスキャン
— 2. 結合キーによるShuffle
— 3. パイプライン化されたハッシュ結合
SELECT u.name, o.amount
FROM Users@{FORCE_JOIN_ORDER=TRUE} u
JOIN Orders o ON u.id = o.user_id;

アーキテクトの視点: なぜSpannerは速いのか？それは「データ転送と演算を完全にオーバーラップさせているから」だ。ネットワークパケットが届いたその瞬間に、デコード済みタプルが演算器（Iterator）に供給される。I/O待ちによるCPUのアイドル時間は、極限まで排除されるように設計されている。

—

4. 性能を極めるための「禁忌」と「特効薬」

現場のアーキテクトとして、一つだけ忠告しておく。Spannerのクエリプランナーを過信してはならない。

1. Joinの爆発: 分散クエリにおいて、最も避けるべきは「Broadcastされるテーブルの肥大化」だ。統計情報が古いと、プランナーが誤った判断を下し、メモリ不足（OOM）を引き起こすことがある。
2. 実行プランの固定: 重要なクエリには`Query Optimizer Version`を固定し、統計情報の揺らぎによる実行計画の「急変」を封じ込めろ。
3. スプリット境界の意識: 結合キーが主キーの先頭である場合、Spannerはローカル結合を優先する。これこそが「最強の最適化」だ。分散クエリを走らせる前に、テーブル設計段階で結合キーのColocationを達成しているか、今一度見直せ。

—

結論：ブラックボックスを紐解く勇気

Cloud Spannerの分散クエリは、魔法ではない。極めて高度に調整された、ストリーム処理、メモリ管理、ネットワークトポロジーの融合体だ。

君たちが書くSQLの一行は、裏で何百ものノードのCPUを同期させ、テラバイト級のデータをミリ秒単位でシャッフルしている。この仕組みを理解し、クエリプランを確認し、物理設計を最適化する。それこそが、Spannerを使いこなす唯一の道だ。

次のデプロイでクエリプランを `EXPLAIN ANALYZE` してほしい。そこに、我々が築き上げたエンジニアリングの真髄が可視化されているはずだ。