Snowflakeの新機能を追っていると、「共有」と「アクセス管理」に力を入れているのが目立ちます。共有ワークスペース機能やカスタムレジストリ機能など、最近の発表はそっち系が多い。
設計思想を調べてみたら、「データを動かさない」という発想がベースにあることがわかりました。
ストレージとコンピュートの分離
従来のデータベースは、ストレージ（データの保管）とコンピュート（計算）が一体でした。サーバーを増やすと、ストレージもコンピュートも両方増える。
Snowflakeはこの2つを完全に分離しています。
従来のDB:
[サーバー] = ストレージ + コンピュート（一体）
→ データが増えたらサーバーごと増やす
Snowflake:
[ストレージ] ← データはここに置きっぱなし
[コンピュート A] → 分析チームが使う
[コンピュート B] → データ投入チームが使う
→ 各チームが互いに影響しないこれの何が嬉しいかというと、 使わないときはコンピュートを止められる ということです。止めたらお金がかからない。
BigQueryも同じ思想ですが、課金モデルが違います。BigQueryはスキャンしたデータ量で課金、Snowflakeはコンピュートの稼働時間で課金。どちらが安いかはユースケースによります。
Data Sharing: データを動かさずに共有する
ここがSnowflakeの設計で一番面白いと思ったところです。
従来のデータ共有は、だいたいこうです。
- CSVでエクスポート
- メールで送る（パスワード付きZIPで…）
- 相手がインポート
- どれが最新版かわからなくなる
SnowflakeのData Sharingは、 データを動かさない 。Snowflake上にデータは1つだけ存在し、相手にはアクセス権を渡すだけです。
- コピーが発生しない（ゼロコピー）
- 元データが更新されたら、共有先も自動で最新になる
- アクセス権を消せば、即座にアクセスできなくなる
お客さんの「データを渡すのが怖い」という声をよく聞きます。これなら「渡す」のではなく「見せる」だけ。根本的にアプローチが違う。
共有ワークスペースとカスタムレジストリ
最近リリースされた機能も見てみました。
共有ワークスペースは、チームで同じファイルやフォルダを共同編集できる仕組みです。Googleドライブに近い感覚で使える。権限は管理者・編集者・閲覧者の3段階。
カスタムレジストリは、リソースを整理して管理する仕組み。タグ付けやグルーピングで、増えていくデータアセットを見失わないようにする。
これを見たとき、お客さん先の「ファイルを5段階の承認フローでアップロード」問題が浮かびました。ワークスペースで共有すれば、あの手順がだいぶ減るはず。
BigQueryとの設計思想の違い
自分はBigQueryをメインで使っているので、比較も整理してみます。
| 観点 | BigQuery | Snowflake |
|---|---|---|
| 課金モデル | スキャン量課金 | コンピュート時間課金 |
| データ共有 | Analytics Hub | Data Sharing（ゼロコピー） |
| マルチクラウド | GCPのみ | AWS / Azure / GCP |
| 共同作業 | 弱め | 共有ワークスペースが充実 |
どちらが優れているというより、設計思想が違います。BigQueryは「Google流の全自動」、Snowflakeは「ユーザーに選択肢を渡す」設計。使う側の好みや状況で選べばいい話です。
まとめ
- 「データを動かさない」設計思想は、セキュリティとコスト両方の問題を解く
- Data Sharingのゼロコピーは、「データを渡すのが怖い」問題の根本解決になりうる
- BigQueryとの違いは優劣ではなく思想の違い
- 次の記事では、Cortex Code CLIを実際に触ってみます