データ基盤の設計支援をしていると、「SnowflakeとBigQueryどちらがいいですか」という質問をよく受けます。料金比較表を出して終わりにすることもできますが、それでは本質を見落とします。

両者の違いは価格体系ではなく、 アーキテクチャの設計原則 にあります。特にSnowflakeが徹底している「データを動かさない」という思想は、単なる技術選定を超えた判断基準を含んでいます。

なぜ「分離」が原則として重要なのか

従来のデータベースでは、ストレージ（保管）とコンピュート（計算）が一体でした。サーバーを増やすと、使っていないストレージも一緒に増える。逆にデータが増えたら、不要な計算リソースまで追加される。この密結合が、コスト最適化を構造的に難しくしていました。

Snowflakeはこの2つを 完全に独立したレイヤーとして設計 しています1。これは機能追加ではなく、アーキテクチャの根幹です。

従来型の密結合アーキテクチャと分離型アーキテクチャの比較図

この分離がもたらす変化は3つあります。

コスト構造が透明になる。 誰がどれだけ計算リソースを使ったかが明確になり、部門別のコスト配賦が可能になります。夜間や週末にウェアハウスを停止すれば、その分の課金はゼロです。

ワークロードが互いに干渉しない。 分析チームの重いクエリが、データ投入パイプラインを遅延させるという問題が構造的に発生しません。これは本番環境と分析環境を同じコンピュートで共有してしまう、よくある失敗パターンへの解です。

スケーリングの粒度が細かくなる。 データ量の増加とクエリ負荷の増加を、別々の問題として対処できます。

ゼロコピー共有という発想の転換

データ共有の現場で最もよく見る光景があります。CSVにエクスポートして、パスワード付きZIPにして、メールで送る。相手がインポートして、数日後に「これ最新版ですか」と聞かれる。

このプロセスには データのコピーが必ず発生 します。コピーが存在する限り、バージョン管理・アクセス制御・最新性の保証は原理的に困難です。

SnowflakeのData Sharingは、この問題を「コピーしない」ことで解決します2。データは提供元のストレージに1つだけ存在し、共有先にはメタデータレベルのアクセス権だけが付与されます。

ゼロコピーData Sharingにおけるデータ提供元と共有先の関係図

「データを渡す」のではなく「データへのアクセスを渡す」。この違いは根本的です。元データが更新されれば共有先にも即座に反映され、アクセス権を取り消せば即座にデータは見えなくなります。

ゼロコピー共有の落とし穴

ただし、アーキテクチャがエレガントであることと、運用が安全であることは別の話です。

ゼロコピー共有を導入しても、以下の課題は 自動的には解決されません 。

  • 誰がどのデータを見られるのか の権限設計（RBAC / カラムレベルセキュリティ）
  • アクセスログの監査 と異常検知の仕組み
  • PIIを含むカラム のマスキングやトークン化
  • 共有先が さらに別の組織に再共有 するリスクの管理

「コピーしないから安全」と短絡するのは危険です。むしろ、データが一箇所に集約されるからこそ、ガバナンス設計の重要性が増します。ゼロコピー共有の導入は、データガバナンスポリシーの整備とセットで考えるべきです。

BigQueryとの設計思想の違い

BigQueryも同様にストレージとコンピュートを分離していますが、課金モデルに明確な違いがあります3。

観点BigQuerySnowflake
課金モデルスキャン量課金（オンデマンド）コンピュート時間課金
スケーリング完全自動（サーバーレス）ウェアハウスサイズを手動選択
データ共有Analytics HubData Sharing（ゼロコピー）
マルチクラウドGCPのみ（BigQuery Omni除く）AWS / Azure / GCP

ここで重要なのは、 利用パターンによって有利不利が逆転する 点です。

アドホックに月数回だけ大量データを分析する場合、BigQueryのスキャン量課金は合理的です。一方、毎日定常的にクエリを実行するETLパイプラインでは、Snowflakeの時間課金と自動サスペンドの方がコスト効率が高いケースがあります。

「どちらが安いか」ではなく「自社の利用パターンにどちらの課金モデルが合うか」が正しい問いです。料金表だけを比較して選定するのは、サイズだけ見て靴を買うようなものです。

設計原則から学べること

Snowflakeのアーキテクチャから得られる教訓は、Snowflakeを使うかどうかに関わらず有効です。

  • 密結合はコスト最適化の敵 。ストレージとコンピュートに限らず、システム設計全般に当てはまる原則
  • データのコピーは負債 。コピーが増えるほど、整合性と安全性の維持コストが増大する
  • アーキテクチャの美しさとガバナンスの成熟度は別軸 。技術的に優れた仕組みほど、運用設計に手を抜くと被害が大きくなる

自社のデータ基盤がどの程度「分離」できているか。データ共有のプロセスにコピーが何回発生しているか。この2つを棚卸しするだけでも、改善の方向性は見えてきます。

Footnotes

  1. Dageville, B. et al. “The Snowflake Elastic Data Warehouse.” Proceedings of the 2016 International Conference on Management of Data (SIGMOD ‘16), ACM, 2016. https://dl.acm.org/doi/10.1145/2882903.2903741 ↩

  2. Snowflake Documentation. “Introduction to Secure Data Sharing.” https://docs.snowflake.com/en/user-guide/data-sharing-intro ↩

  3. Google Cloud. “BigQuery pricing.” https://cloud.google.com/bigquery/pricing ↩