分析基盤を運用していると、「重いバッチが走るとダッシュボードが遅くなる」「月末に処理が集中して詰まる」という干渉に悩まされます。同じ計算資源を取り合うからです。Snowflakeは、この問題を「仮想ウェアハウス」という仕組みで正面から解いたクラウドデータウェアハウスです。まず、その中心となる考え方を押さえてください。

Snowflakeは、データを1か所の共有ストレージに置き、計算は「仮想ウェアハウス」と呼ぶ計算資源を必要なときに起動して行います。ストレージとコンピュートが分離しているので、用途ごとに別々の仮想ウェアハウスを割り当てれば、互いに干渉しません。バッチ用とBI用を分ければ、片方が重くてももう片方は影響を受けません。

3層アーキテクチャ

Snowflakeの構造は、大きく3つの層に分かれています。この分離が、柔軟さの源です。

層役割
ストレージ層データを圧縮して1か所に保管（クラウドストレージ）
コンピュート層仮想ウェアハウスが計算を実行。用途ごとに複数立てられる
クラウドサービス層認証・メタデータ・最適化・トランザクション管理

仮想ウェアハウスは、サイズ（XS〜大規模）を選んで起動し、使い終われば止められます。多くの場合、一定時間アイドルになれば自動停止し、課金も止まる設定にできます。負荷が増えたら自動で台数を増やす（マルチクラスタ）設定もできます。

-- 用途ごとに仮想ウェアハウスを分ける例
CREATE WAREHOUSE bi_wh
  WAREHOUSE_SIZE = 'SMALL'
  AUTO_SUSPEND = 60      -- 60秒アイドルで自動停止
  AUTO_RESUME = TRUE;    -- クエリが来たら自動再開

-- バッチ用は別ウェアハウスにして干渉を避ける
CREATE WAREHOUSE batch_wh
  WAREHOUSE_SIZE = 'LARGE'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

Snowflakeならではの強み

Snowflakeには、運用を楽にする特徴的な機能があります。代表的なものを挙げます。

機能何ができるか
ゼロコピークローンデータを物理コピーせず、瞬時に複製を作る（検証用環境など）
タイムトラベル過去の一定期間の状態にさかのぼってデータを参照・復元
データ共有コピーを渡さず、相手に直接データを共有（社外連携にも）
半構造化データ対応JSONなどをそのまま取り込み、SQLで扱える

とくにデータ共有は、Snowflakeの目玉です。従来はデータを相手にコピーして渡していましたが、Snowflakeでは保管したデータへの参照を共有でき、コピーの手間も鮮度のずれもなくせます。ゼロコピークローンも便利で、本番データをコピーせずに検証環境を瞬時に用意できます。

課金の考え方

Snowflakeの費用は、おおまかに「ストレージ」と「コンピュート」に分かれます。コンピュートは、仮想ウェアハウスを動かした時間に応じた「クレジット」で課金されます。サイズが大きいほど、また動かす時間が長いほどクレジットを消費します。止めている間は計算の課金がかかりません。

費用を抑えるコツは、ウェアハウスの自動停止（AUTO_SUSPEND）を短めにし、用途に合ったサイズを選ぶことです。むやみに大きなウェアハウスを動かしっぱなしにすると、クレジットを浪費します。クラウド全般のコストの考え方は、初期より運用で効く点も含めて、データ基盤のコスト設計の観点が参考になります。

向く用途・注意点

SnowflakeはSQL中心の分析基盤として扱いやすく、とくに次のような場合に力を発揮します。

  • SQLでの分析が中心：使い慣れたSQLで、すぐ分析を始められます。
  • 同時実行の干渉を避けたい：用途ごとにウェアハウスを分けて解決できます。
  • 社内外でデータを共有したい：コピーなしの共有が強力です。
  • 複数クラウドで使いたい：主要クラウド上で動かせます。

注意点もあります。第一に、機械学習やSpark的な大規模分散処理が主役なら、Databricksのほうが向くことがあります。第二に、便利だからと大きなウェアハウスを動かしっぱなしにすると費用が膨らみます。自動停止と適切なサイズ選定が前提です。なお、取り込んだデータをそのまま分析するのではなく、層に分けて整える設計が品質を左右します。その考え方はメダリオンアーキテクチャの解説、dbtでの実装はdbt実装ガイドにまとめています。

まとめ

  • Snowflakeはストレージとコンピュートを分離し、計算は「仮想ウェアハウス」で行うクラウドDWH。
  • 用途ごとにウェアハウスを分ければ、重い処理と軽い参照が干渉しない。
  • ゼロコピークローン・タイムトラベル・データ共有が運用を楽にする。
  • 課金は計算時間（クレジット）が軸。自動停止と適切なサイズ選定が費用管理の要。

3つのクラウドDWHの位置づけと選び方はクラウドDWH入門に、ほかの選択肢はBigQueryとは・Databricksとはにまとめています。DWHの選定や設計を一緒に詰めたいときは、DE-STKの初回スポット相談を壁打ち相手に使っていただけたらうれしいです。

よくある質問（FAQ）

Q. 仮想ウェアハウスは、いくつ作ればいいですか？

A. 干渉を避けたい単位で分けます。よくあるのは、バッチ処理用・BIダッシュボード用・データ分析/ML用の3系統です。重い処理と軽い参照を同じウェアハウスに混ぜると遅くなるので、ワークロードの性質ごとに分けるのが基本です。小さく始めて、干渉が起きた単位で増やせば十分です。

Q. ウェアハウスのサイズは、大きいほどよいですか？

A. いいえ。大きいほど速い反面、クレジットの消費も増えます。まず小さいサイズで試し、処理が遅すぎる場合だけ上げます。一度に大量データを処理する重いバッチは大きめ、軽いクエリの参照は小さめ、と用途に合わせます。サイズを上げるより、無駄に動かしっぱなしにしないことのほうが、費用には効きます。

Q. データ共有は、相手もSnowflakeが必要ですか？

A. 相手もSnowflakeを使っていれば、コピーなしで直接共有できます。Snowflakeを持たない相手向けには、閲覧用のアカウントを発行して共有する仕組みも用意されています。いずれの場合も、データを物理的にコピーして渡すより、鮮度のずれや管理の手間を減らせるのが利点です。

Q. SnowflakeはどのクラウドでもDWHとして同じように使えますか？

A. SnowflakeはAWS・Azure・Google Cloudのいずれの上でも動き、操作の仕方はほぼ共通です。どのクラウドに置くかは、データの所在や既存環境、社内の規定に合わせて選べます。特定のクラウドに縛られにくいのは利点ですが、データの転送には費用がかかる場合があるので、主なデータがある場所に寄せて配置するのが無難です。