「DWH弱者の自分」がSnowflake入門シリーズDay2を見て、Snowflakeならではの仕組みだけをまとめてみた

AI その他 コンピュータ 勉強会

前回（Day1のノート）に続いて、Snowflake公式の「お昼休みに学ぶ」Snowflake入門シリーズ、今回は Day2「Snowflakeの基礎技術 – コア機能編」 を受講しました。

Day2はとにかく情報量が多かったので、全部をなぞるのはやめて、「これは他のDBではこうはならないな」と感じた"Snowflakeらしい"仕組みだけ に絞ってノートにしています。SLAの数字やバージョン差分みたいな細かい話は、公式ドキュメントを見ればいいかなと割り切っています。

自分はIoT・アプリケーション寄りの人間なので、DWHの内部構造なんて気にしたことがなかったレベルです。なので「なんでそうなるの？」を自分なりに噛み砕いて整理しています。

なお前提として、Day1で出てきた EASY（簡単）/ CONNECTED（接続）/ TRUSTED（信頼） という3つの指針を、Day2では 技術的にどう実現しているか が語られる、という流れでした。

⚠️ この記事の情報は2026年5月時点のものです。最新情報はSnowflake公式ドキュメントも併せて確認してみてください。

【関連】

uepon.hatenadiary.com

1. マイクロパーティションがSnowflakeの速さを支えている

ここがDay2の主役でした。「この概念だけはお持ち帰りいただきたいです！」 といわれていたので、自分も一番時間をかけて理解しました。後半に出てくる機能の多くが、この仕組みの上に乗っかっています。

1.1 DBで一番遅いのはディスク読み書き

スライドいわく、データベースで一番遅い処理はディスクの読み書き（I/O） だそうです。なので高速化の基本方針は超シンプルで、

ディスクから読むデータ量を、可能な限り減らす

これに尽きると。マイクロパーティションは、この「読む量を自動的に減らす」ための仕組み、という位置づけです。

ちなみに、適切なインデックスやパーティショニングを設定していないDBだと、SELECT count(*) FROM t1 WHERE ID = 3 AND DATE = '11/5' のようなクエリで、テーブルを広く読みながら条件に合う行を探す ことになります。スライドの例では目的のデータが23行目にあって「やっと見つかった」状態。これが数億行あったら…と考えると、無駄に読む量の多さが分かります。自分はアプリ屋なので「インデックス貼れば？」と思いますが、Snowflakeはインデックスを手で貼る文化ではなく、以下の自動の仕組みで殴ってくる感じでした。

1.2 マイクロパーティションとは

マイクロパーティションは、テーブルのデータを、ロード・挿入時の並びを利用しながら小さなカタマリへ自動で分割して保存する仕組み です。

ポイント 内容
自動分割 ユーザーが意識しなくても自動でパーティション化される
サイズ 1パーティションあたり 50〜500MB（圧縮前）
列指向 パーティション内は 列指向（カラムナ）形式 で、列ごとに独立して圧縮
不変 一度書き込まれたら イミュータブル（不変）

地味につまずいたのが 「列指向」 でした。普段のRDBのイメージ（行ごとに保存）と逆で、列ごとにまとめて保存する考え方です。

格納方式 得意なこと
行指向（OLTP寄り） 「この1件を取ってきて／更新して」
列指向（OLAP寄り、Snowflakeのコア） 「この列だけを大量に集計して」

分析は「日付の列だけ」「金額の列だけ」のように 特定の列を縦に大量集計 することが多いので、列指向だと必要な列だけ読めて速いし、似た値が並ぶので圧縮も効く。Day1でOLAPが「列単位のアクセスに最適化」と書いてあったのが、ここで腹落ちしました。

1.3 メタデータとプルーニングで読む量を減らす

ただ分割するだけだと結局全部開く羽目になります。効いてくるのが メタデータ で、Snowflakeは各パーティションについて 値の範囲（MIN/MAX） や個別の値の数（DISTINCT COUNT）を自動で持っています。

パーティション IDの範囲 Dateの範囲
パーティション1 ID: 2〜4 11/2 のみ
パーティション2 ID: 1〜5 11/2〜11/3
パーティション3 ID: 2〜5 11/2〜11/4
パーティション4 ID: 1〜5 11/3〜11/5

このメタデータを 先に見るだけ で、「Date = '11/5' はパーティション4にしか無いな」と分かる。そして不要なパーティションを丸ごと読み飛ばすことを パーティションプルーニング（pruning＝枝刈り） と呼びます。

  • パーティション1〜3 → 該当データなし → 読まない
  • パーティション4 → ここだけ読めばOK🤗

自分の理解は、

マイクロパーティション ＝ データを小分け＆統計メモ付きで保存 パーティションプルーニング ＝ 統計メモを見て、関係ない箱は開けずに済ます

の2点セット。インデックスを手で設計しなくてもこれが自動で効くのはラクですね🤗（ちなみに新しい Snowflake Optima には2つの仕組みがあって、Optima Metadata はクエリ履歴を分析して、UPPER() や LIKE、日付変換のように通常のMIN/MAXだけでは枝刈りしにくい条件に合わせた軽量な追加メタデータをバックグラウンドで生成。Optima Indexing はワークロードを分析して、検索最適化用のインデックスをバックグラウンドで自動作成・維持してくれるそうです。どちらも「ユーザーが細かくチューニングしなくても読む量を減らす」という世界観の延長だなと感じました）。

2. ストレージとコンピュートの分離

Snowflakeのアーキテクチャでいちばん"らしい"のがこれでした。ストレージ（データ置き場）とコンピュート（計算する人）が分離されている 点です。

普通は「データとそれを処理するマシンはセット」になりがちですが、Snowflakeは切り離していて、

  • データは1箇所（唯一無二のデータソース）に集約
  • 計算リソース（仮想ウェアハウス）は 用途ごとに何個でも 立てられて、互いに影響しない

従来型との違いを表にすると、こうなります。

方式 特徴
従来型の密結合な構成 ストレージと計算リソースが強く結び付いていて、複数ワークロードの競合を避けるには設計や調整が必要
Multi-Cluster, Shared Data（Snowflake） データは中央で一元管理しつつ、用途別に独立したコンピュートを用意できる

イメージは、

  • 従来：ストレージと計算が密結合で、同じリソースを取り合う → 誰かが重い処理を回すと全員が遅くなる「もう無理…」状態
  • Snowflake：データは共有のまま、計算する人だけ部署ごとに別々に雇える → 競合しない

BI部門が重い集計を回していても、ETLジョブやデータサイエンスの処理が巻き添えで遅くならない。アプリ屋からすると、この"取り合いが起きない"設計はかなり気持ちいいです。

3. 仮想ウェアハウスは用途別に分けて、使わない時は止める

分離されたコンピュート側が 仮想ウェアハウス（Virtual Warehouse, VW） と呼ばれるものです。XS / S / M / L / XL / 2XL … のTシャツサイズが用意されていて、用途に応じて手軽に立ち上げられます。

スケールの方向が3種類あって、ここは用語が紛らわしかったので整理しました。

スケール 行えること ひとことで表現すると…
スケールアップ / ダウン サイズを上げ下げ（M→XL） 1台を強くする（パワー不足対策）
スケールアウト / イン クラスタ数を増減 台数を増やす（同時アクセス対策）
スケールアクロス 用途ごとに別のWHを用意 用途別に分ける（競合対策）

アップ／アウトはアプリ開発でもなじみがありますが、「アクロス（用途で分割）」がSnowflakeらしい 考え方かなと感じました。第2章の「計算する人を部署ごとに分ける」が、まさにこれです。

そしてもう一つ"らしい"のが、使っていない時間は自動で止める 仕組み。

  • 自動サスペンド … クエリが来なくなったら自動でウェアハウスを停止
  • 自動再開 … クエリが来たら自動で起動

従量課金なので、暇な時間に止まってくれる＝そのままコスト削減になります。さらに、条件が合えば（同じクエリ結果が残っていて、参照データも変更されていない場合など）ウェアハウスでクエリを再実行せず保存済みの結果を返せるため、コンピュート消費を抑えられるケースもあります。「止まっていてもいい」「動かさなくても返せる」という発想が、固定コスト前提の従来DWHとはだいぶ違うなと思いました。

4. 「不変」だからできるタイムトラベルとゼロコピークローン

第1章で「マイクロパーティションは一度書いたら不変（イミュータブル）」と書きました。昔のパーティションがそのまま残る から実現できているのが、この2つの機能です。

タイムトラベル は、過去のバージョンのデータを参照・復元できる機能。

-- 変更前（T1時点）の状態を見る
SELECT * FROM mytable AT(TIMESTAMP => ...);
SELECT * FROM mytable BEFORE(STATEMENT => ...);
  • CLONE AT | BEFORE … 過去のバージョンを復元
  • UNDROP … 誤って削除する前の状態に回復

「うっかり UPDATE や DROP をやらかしても、ちょっと前に戻せる」というのは精神的にかなり安心できるやつですね😅

⚠️ ただし、過去データを参照できるのは設定された 保持期間内 だけです。標準では1日で、エディションやオブジェクト種別によって最大90日まで延長できます（期間を過ぎるとタイムトラベルからは直接操作できなくなります）。「いつでも戻せる」ではないので、そこは過信しないようにしたいところです。

ゼロコピークローン は、データの実体をコピーせずにクローンを作る 機能です。

方式 やること ストレージ
従来 本番DBを丸ごとコピーして開発環境を作る コピー分のストレージが必要
ゼロコピークローン 作成時点では同じマイクロパーティションを共有する 作成直後の追加ストレージは不要。変更後は差分が発生

クローン直後は元と同じマイクロパーティションを共有しているだけで容量を食わず、どちらか（元・クローンどちらでも）に変更を加えたときだけ差分が分離 されます。アプリ開発でいうGitのブランチを切る感覚にちょっと近いかもしれません。本番データで気軽に検証環境を作れるのは強烈だなと思いました。

5. データをコピーせずに共有する

Day1でMarketplaceが「コピー不要でライブ参照」と書いてあった仕組みがようやく理解できました。Snowflakeは、プロバイダーとコンシューマーが同じデータ（マイクロパーティション）を参照する 形で共有します。

  • 同一リージョン内 では、データの物理的コピーや転送なしで共有できる
  • ライブデータを参照するので、更新内容が速やかに反映される
  • 共有オブジェクトは 読み取り専用、不要になれば共有を無効化するだけ
  • 列レベル／行レベルのポリシーで、共有後もガバナンスを効かせられる

「データをコピーして渡す」のではなく「同じ実体への参照権だけを渡す」イメージですね。毎月CSVを送り合う運用が要らなくなる、というのはDay1の内容とも一致します。

⚠️ ただ、リージョンやクラウドをまたぐ場合 はレプリケーションや自動配信（Cross-Cloud Auto-Fulfillment）の仕組みが使われるので、そこは「完全にコピーゼロ」ではない点に注意です。「同じリージョンに揃えるならコピーゼロ、またぐと裏で複製が走る」と整理しておくと混乱しなさそうです。

発展形として、他社データに直接アクセスできる Snowflake Marketplace、個人情報を見せ合わずに突合できる Data Clean Room なども紹介されていました。

6. 他にも"らしい"と思った機能

紙幅の都合で詳細は省きますが、個人的に"Snowflakeらしいな"と感じたものを箇条書きで。

  • VARIANT型 … JSONなどの半構造化データを、あらかじめRDBの列へ細かく分解せずに格納して、後からパス記法（obj:address.city）で取り出せる型。「とりあえず入れて、構造はあとで」ができる
  • Icebergテーブル … データを自社のストレージにオープンフォーマット（Apache Iceberg）で置いたまま、Snowflakeから操作できるテーブルタイプ。ロックインを避けたいとき向け
  • Streamlit in Snowflake … PythonのWebアプリフレームワークがSnowflakeにネイティブ統合。外部にデータを取りに行かず、その場で可視化アプリが作れる🤗

ハマりポイントまとめ

Day2を聞きながら、自分が「あ、ここは勘違いしそう」と感じたところを表にしておきます。後で読み返した自分のための備忘録です😅

ポイント 内容 / 自分の整理
列指向の発想転換 普段のRDBの「行ごとに保存」と逆。列ごとにまとめて圧縮・集計するOLAP向きの形式なんですよね
スケール用語が3種類ある アップ/ダウン（強くする）・アウト/イン（台数を増減）・アクロス（用途別に分ける）。Snowflakeらしいのはアクロス
サイズ変更とクラスタ自動増減は別物 サイズ（M→XL等）はユーザー操作。クラスタ数の増減は同時実行数に応じた自動調整。混同しがち
タイムトラベルは保持期間内だけ 標準1日、エディションやオブジェクト種別で最大90日。期間を過ぎると直接は戻せない
ゼロコピークローン＝ずっと無料ではない 作成直後の追加ストレージはゼロ。変更を加えた瞬間から差分が発生してストレージを消費する
共有も「完全コピーゼロ」ばかりではない 同一リージョン内なら参照型でコピー不要。リージョン/クラウドをまたぐとレプリケーションが入る

まとめ

Day2「コア技術編」から、"Snowflakeならでは"だけを抜き出すとこんな感じでしょうか。

  • 速さの正体は マイクロパーティション。小分け＋統計メタデータ＋プルーニング で読む量を自動で減らす
  • ストレージとコンピュートの分離（Multi-Cluster, Shared Data）で、ワークロードが競合しない
  • 仮想ウェアハウスは 用途別に分け（アクロス）、使わない時は止める（自動サスペンド） のがらしい
  • マイクロパーティションが不変だから、タイムトラベルとゼロコピークローンが成立する
  • 共有は 物理コピーなしの参照型。だからMarketplaceやクリーンルームが成り立つ

ぜんぶ突き詰めると、「ディスクから読む量を減らす」「計算リソースを分離する」「必要以上にデータを動かさない」 の3つの思想に集約される、というのが今回の収穫でした。

おわりに

最初は用語の壁で気が遠くなりかけたんですが😅、一個ずつ「なんで速いの？／なんでラクなの？」を追っていくと、上の3つの思想に全部つながっていることが見えて急にスッキリしました。アプリ／IoT寄りの自分でも、「インデックスを手で貼らなくていい」「コピーせずに検証環境や共有が作れる」あたりは素直に魅力的です。次のDay3は「セキュリティ・ガバナンス・AI編」なので、また格闘ノートを残せたらと思います。

用語集

用語 説明
マイクロパーティション テーブルを取り込み順に自動分割した、不変・列指向のストレージ単位（50〜500MB／圧縮前）
パーティションプルーニング メタデータ（MIN/MAX等）を見て、不要なパーティションの読み込みをスキップする仕組み
列指向（カラムナ） 列ごとにまとめて格納する方式。集計と圧縮に強くOLAP向き
Snowflake Optima Metadata クエリ履歴を分析し、頻出する式に合わせた軽量な追加メタデータをバックグラウンドで生成して、プルーニングを強化する仕組み
Snowflake Optima Indexing ワークロードを分析し、検索最適化用のインデックスをバックグラウンドで自動作成・維持する仕組み
Multi-Cluster, Shared Data データを1箇所に集約しつつ、複数の独立コンピュートで処理するSnowflakeの構成
仮想ウェアハウス（VW） クエリ処理用の計算リソース。XS〜2XL等のサイズで指定
スケールアクロス 用途ごとに別のウェアハウスを用意して競合を防ぐこと
自動サスペンド／自動再開 未使用時に自動停止し、クエリ到来時に自動起動するコスト最適化機能
タイムトラベル 過去バージョンのデータを参照・復元できる機能（AT/BEFORE、CLONE、UNDROP）
ゼロコピークローン 作成時点では同じマイクロパーティションを共有して複製を作る方式。作成直後の追加ストレージは不要で、変更後に差分が発生
データ共有（セキュアシェア） 同一リージョン内なら物理コピーなしで、同じデータを読み取り専用で共有する仕組み（リージョン/クラウドをまたぐ場合はレプリケーションを使用）
VARIANT型 JSON等の半構造化データを、列へ細かく分解せず格納できる型。パス記法でアクセス
Icebergテーブル Apache Icebergのオープンフォーマットで外部にデータを置くテーブルタイプ
Streamlit in Snowflake Snowflake内でPythonのWebアプリを作れるネイティブ統合機能
Snowflake Marketplace コピー不要・ライブ参照でデータ／アプリを配布・収益化できる場