1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@NKKTechGlobal(NKKTech Global)

Snowflake vs BigQuery vs Databricks：TPC-H準拠ベンチマークとクエリコスト比較検証

1
Posted at

Snowflake vs BigQuery vs Databricks：TPC-H準拠ベンチマークとクエリコスト比較検証

Feature(225).png

はじめに

こんにちは、NKKTech Global 技術チームです。

現代のエンタープライズデータスタックにおける「Big 3」である Snowflake、Google BigQuery、Databricks。
それぞれの優位性は営業資料で語られますが、現場のデータエンジニアが本当に知りたいのは**「実業務に近い複雑な集計・多重結合クエリを実行した際、1回あたりのコストと秒数がどう異なるか」**です。

本記事では、公正性を担保するためTPC-H標準クエリ群を用い、同一データ規模（1TB）でベンチマークを実施。それぞれのアーキテクチャ特性、クエリ実行時間、および課金モデルに基づくコスト効率を徹底検証しました。

1. 3大プラットフォームのアーキテクチャと課金モデルの相違点

ベンチマーク結果を読み解く上で、各プラットフォームのコンピュート構造の違いを理解することが不可欠です。

項目 Snowflake Google BigQuery Databricks (SQL Warehouse)
中核エンジン 独自分散SQLエンジン Dremel 分散実行エンジン Photon (C++ネイティブベクトル化)
ストレージ主権 Snowflake管理 (Icebergも可) BigQuery管理 (BigLakeも可) 自社オブジェクトストレージ (Delta Lake)
コンピュート管理 サイズ指定型 (M, L, XL等) 完全サーバーレス (動的スロット) サイズ指定型 (Serverless SQL可)
課金形態 コンピュート稼働秒数課金 スキャンデータ量 / スロット時間 DBU (Databricks Unit) ＋ VM原価

2. ベンチマーク検証環境の設定

リソースの公平性を保つため、コンピュート規模が同等（中小〜中規模エンタープライズの標準スペック）になるよう調整しました。

  • データセット: TPC-H 準拠データ（Scale Factor = 1000 / 生データ容量 約1TB / 行数 約60億行）
  • 対象リージョン: AWS東京（ap-northeast-1）/ GCP東京（asia-northeast1）
  • コンピュートリソース設定:
    • Snowflake: Warehouse Size: Large（8ノード / 16クレジット/時間 = 約$48〜64/h 相当）
    • BigQuery: Capacity-based (Autoscaling) 最大スロット上限 200 スロット設定（比較検証用にオンデマンドスキャン課金も並行計測）
    • Databricks: Serverless SQL Warehouse: Medium（Photon有効化 / 8〜16ワーカー相当）
  • キャッシュ無効化: 測定ごとに結果キャッシュ（Result Cache）を完全クリアしたコールドスタート状態で計測

3. ベンチマーク実行結果（代表クエリの所要時間比較）

TPC-Hの全22クエリの中から、実業務で頻出する4つの典型的な処理パターンを抽出して比較しました。

  • Q1 (大量集計): ほぼ全行スキャンを伴う集計・グループ化処理
  • Q6 (絞り込み集計): 高選択性フィルタによる大量スキャン・単純集計
  • Q9 (多重テーブル結合): 6テーブルの大規模JOINを伴う複雑なマージ処理
  • Q21 (多層サブクエリ・アンチジョイン): ラインアイテム間の依存性判定を伴う超高負荷クエリ

実行時間比較（秒単位 / 数値が小さいほど高速）

クエリ種別 特徴 Snowflake (Large) BigQuery (200 Slots) Databricks (Medium)
Q1 (大量集計) 全件走査・多段集計 14.2 秒 22.8 秒 11.5 秒
Q6 (選択走査) カラムスキャン効率 4.8 秒 3.6 秒 4.1 秒
Q9 (多重結合) 6テーブル複合JOIN 48.6 秒 62.1 秒 36.2 秒
Q21 (高負荷結合) EXISTS・サブクエリ 68.4 秒 84.5 秒 51.8 秒
平均実行時間 (Geometric Mean) 総合レイテンシ 24.5 秒 31.8 秒 20.4 秒

実行性能に関する考察

  1. 複雑結合におけるDatabricks (Photon) の強さ:
    Q9やQ21のように、巨大ファクトテーブル同士のShuffleやHash Joinが多発するクエリでは、C++でスクラッチから書かれたベクトル化実行エンジン「Photon」を持つDatabricksが最も速いタイムを記録しました。
  2. 単純スキャンにおけるBigQueryの瞬発力:
    Q6のようにシンプルなフィルタリングとスキャンに特化したクエリでは、BigQueryの巨大な内部I/Oスケーリングが機能し、最速レスポンスを叩き出しました。
  3. Snowflakeの圧倒的な安定性:
    Snowflakeは突出した最速値こそ少ないものの、オプティマイザの優秀さにより、どんな構造のSQLであっても破綻せず安定した実行時間を維持しました。

4. 1クエリあたりのコスト効率（Cost per Query）比較

「どれだけ速いか」と同じくらい重要なのが「実行1回あたり何円かかるか」です。各プラットフォームの標準価格（リストプライス）をベースに試算しました。

代表クエリ実行コストの試算比較（米ドル換算）

クエリ Snowflake (Large) BigQuery (オンデマンド: $6.25/TB) Databricks (Serverless SQL)
Q1 (大量集計) 約 $0.19 約 $1.85 (約300GB走査) 約 $0.16
Q6 (選択走査) 約 $0.06 約 $0.48 (約75GB走査) 約 $0.05
Q9 (多重結合) 約 $0.65 約 $3.20 (約512GB走査) 約 $0.49
Q21 (高負荷結合) 約 $0.91 約 $4.50 (約720GB走査) 約 $0.70

コストに関する重大な発見

  • BigQuery（オンデマンド課金）の罠:
    1回あたりの手軽さは魅力ですが、スキャン量ベースで課金されるため、結合や全走査を含む重いクエリではコンピュート秒数課金（Snowflake/Databricks）に比べて5〜10倍割高になります。定常的なバッチや巨大DWH用途では、BigQuery Editions（スロット予約型）への切り替えが必須です。
  • アイドルコストの比較:
    • Snowflake: auto_suspend = 60 により、クエリ停止後60秒で課金が完全停止。
    • Databricks Serverless: 自動スケーリングと停止が高速化されたが、起動オーバーヘッドが数秒発生。
    • BigQuery: 完全サーバーレスのため、クエリが走っていない待機時間は完全ゼロ円。

5. 同時実行性（Concurrency）と運用の手離れの良さ

実稼働では「全社員が朝9時に一斉にダッシュボードを開く」といった並行負荷に耐えうるかが焦点となります。

  • Snowflake (Multi-cluster Warehouse):
    キューの蓄積を検知すると、数秒で同一サイズのウェアハウスが自動スケールアウト（クラスタ増設）。同時実行性能とスループットの安定性はBig 3の中で群を抜いています。
  • BigQuery (Reservations):
    自動でスロットが融通されるため設定不要で並行処理をさばけますが、スロット上限に達すると全クエリの実行速度が均等に遅延します。
  • Databricks:
    Serverless SQLの進化により過去の弱点だった起動遅延は大幅に解消されたものの、クラスタ管理やDelta Lakeのコンパクション（VACUUM/OPTIMIZE）など、依然としてエンジニアによるチューニング余地（管理工数）が存在します。

6. 結論：あなたの組織はどれを選ぶべきか？

まとめマトリックス

  • Snowflake を選ぶべきケース:
    エンタープライズの統合DWH、BIダッシュボードの高スループット運用、データシェアリングを重視する場合。専任のインフラ管理者を置けない組織にとって最もROIが高くなります。
  • Google BigQuery を選ぶべきケース:
    GCPを主軸とする環境、GA4等のマーケティングデータ分析、アクセス頻度が不定期で「使った分だけ払いたい」場合。
  • Databricks を選ぶべきケース:
    データレイク上の生ログ加工、Apache Sparkパイプライン、機械学習（MLflow）や生成AI（LLM）基盤までを一気通貫で統合したい場合。

お問い合わせ先

大規模データ基盤のアーキテクチャ選定、Snowflake / BigQuery / Databricks の移行設計やコスト削減診断に関するご相談は、下記よりお気軽にお問い合わせください。

著者：NKKTech Global 技術チーム
私たちは、中立的な技術知見とグローバルな開発力で、お客様のビジネスに最適なデータアーキテクチャの実現を支援します。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?