第1章 Snowflake AI Data Cloudの特徴とアーキテクチャ(Features & Architecture, 31%)
🎯 この節の学習目標
Snowflake のテーブルデータは、内部的にマイクロパーティション(micro-partition)と呼ばれる小さな単位に分割して保存されます。ユーザーがパーティションを設計・管理する必要はなく、データをロードすると Snowflake が完全に自動で作成します。主な特徴は次のとおりです。
| 特徴 | 内容 |
|---|---|
| サイズ | 1つあたり50〜500MB(非圧縮相当)のデータを格納する |
| 不変(イミュータブル) | 一度作成されたマイクロパーティションは書き換えられない。更新・削除は新しいマイクロパーティションの作成として処理される |
| 作成タイミング | データの挿入(ロード)順に自動作成される。手動でのパーティション定義は不要 |
| 格納形式 | 列指向(カラムナ)形式で格納され、列ごとに自動的に圧縮される |
従来型のデータベースで管理者が行っていた「パーティションキーの設計」「パーティションの追加・削除」といった作業が一切不要である点が、Snowflake の管理レス思想をよく表しています。また「不変」という性質は、後の章で学ぶ Time Travel(過去データの参照)やゼロコピークローンを支える土台にもなっています。
Snowflake は、各マイクロパーティションについて次のようなメタデータをクラウドサービス層で保持しています。
クエリに WHERE 句などのフィルタ条件があると、Snowflake はまずこのメタデータを参照し、「条件に合致する行を含む可能性のないマイクロパーティション」をスキャン対象から除外します。これをパーティションプルーニング(pruning:枝刈り)と呼びます。
図:パーティションプルーニングの流れ。メタデータによる絞り込みはクラウドサービス層で行われる
📝 試験のポイント
プルーニングの判定はクラウドサービス層が保持するメタデータを使って行われるため、この段階では仮想ウェアハウス(コンピュート)を起動する必要がありません。「どの層がマイクロパーティションのメタデータを管理するか」→クラウドサービス層、「プルーニングの効果は何か」→スキャン対象のマイクロパーティション数の削減、という対応を押さえておきましょう。
マイクロパーティションは挿入順に作られるため、データはロードした順序で自然にクラスタリングされます。たとえば日次でデータを追加していくテーブルでは、日付列の値が近い行は同じマイクロパーティションに集まりやすく、日付でのフィルタに対してプルーニングがよく効きます。多くのテーブルでは、この自然なクラスタリングだけで十分です。
一方、テーブルが非常に大きくなり、かつ「よくフィルタに使う列」と「挿入順」がずれてくると、プルーニングの効きが悪くなることがあります。その場合に検討するのがクラスタリングキー(clustering key)の指定です。
💡 具体例:クラスタリングキーの指定と確認
-- 既存テーブルにクラスタリングキーを指定する
ALTER TABLE sales_history CLUSTER BY (region, order_date);
-- テーブル作成時に指定することもできる
CREATE TABLE sales_history (
region VARCHAR,
order_date DATE,
amount NUMBER
) CLUSTER BY (region, order_date);
-- クラスタリング状態を確認する
SELECT SYSTEM$CLUSTERING_INFORMATION('sales_history');
SELECT SYSTEM$CLUSTERING_DEPTH('sales_history');
クラスタリングキーを指定すると、Snowflake は指定した列の値が近い行が同じマイクロパーティションに集まるよう、データを並べ替えていきます。
ただし、クラスタリングキーはすべてのテーブルに指定すべきものではありません。有効なのは、おおよそ次の条件がそろった場合に限られます。
| 観点 | クラスタリングキーが有効なケース |
|---|---|
| テーブルサイズ | TB級の大きなテーブル(マイクロパーティション数が非常に多い) |
| クエリパターン | 特定の列に対する範囲フィルタや等価フィルタを多用するクエリが繰り返し実行される |
| 効果とコスト | 再クラスタリングにはクレジットがかかるため、クエリ改善の効果がコストを上回ると見込めること |
クラスタリングキーを指定したテーブルでも、その後の挿入・更新によってデータの並びは少しずつ乱れていきます。これを整え直すのが再クラスタリング(reclustering)で、Snowflake では Automatic Clustering というサービスが担います。
「クラスタリングキーを指定する=Automatic Clustering の対象になり、維持コストが継続的に発生する」という関係を理解しておくと、「大きなテーブルで効果が見込める場合のみ指定する」という設計判断の理由が腑に落ちます。
テーブルのクラスタリングがどれだけ整っているかは、システム関数で確認できます。
| 関数 | 内容 |
|---|---|
| SYSTEM$CLUSTERING_INFORMATION | 指定した列(またはクラスタリングキー)に関するクラスタリング状態の詳細(深さの分布など)を JSON で返す |
| SYSTEM$CLUSTERING_DEPTH | クラスタリングの深さ(clustering depth)の平均値を返す |
clustering depth は、「ある値を検索したときに、値の範囲が重なり合っているせいで読む必要のあるマイクロパーティションがどれくらい重複しているか」を表す指標です。マイクロパーティション同士の値の範囲の重なりが少ないほど depth は小さく(浅く)なり、プルーニングがよく効く状態を意味します。
📝 試験のポイント
clustering depth は「小さい(浅い)ほど良くクラスタリングされている」ことを示します。値が大きくなってきたテーブルは、値の範囲の重なりが増えてプルーニング効率が落ちているサインです。関数名(SYSTEM$CLUSTERING_INFORMATION / SYSTEM$CLUSTERING_DEPTH)と、この指標の読み方をセットで覚えておきましょう。
✅ この節のまとめ
問1. Snowflake のマイクロパーティションの説明として正しいものはどれか。
正解:B
マイクロパーティションは 50〜500MB(非圧縮相当)の不変な単位で、挿入順に完全自動で作成され、列指向・自動圧縮で格納されます。Aは従来型データベースのパーティション管理の説明で、Snowflake では不要です。Cは誤りで、マイクロパーティションは不変であり、更新・削除は新しいマイクロパーティションの作成として処理されます。Dは格納形式(列指向)と圧縮(自動)の両方が誤っています。
問2. パーティションプルーニングに関する説明として正しいものはどれか。
正解:B
プルーニングは、クラウドサービス層のメタデータを使って「読む必要のないマイクロパーティション」をスキャン前に除外する仕組みです。Aは順序が逆で、プルーニングはスキャンの前に行われるからこそデータ読み取り量を減らせます。Cのような手動指定の仕組みはありません。Dはデータ保持・削除の話であり、プルーニングとは無関係です。
問3. クラスタリングキーの指定を検討すべきケースとして最も適切なものはどれか。
正解:B
クラスタリングキーが有効なのは、TB級の大テーブルで特定列のフィルタが多く、自然なクラスタリングではプルーニングが効きにくい場合です。Aの小さなテーブルでは効果がコストに見合いません。Cは誤りで、再クラスタリングのクレジット消費が継続的に発生するため、全テーブルへの一律指定は推奨されません。Dのように自然なクラスタリングで十分な場合は指定不要です。
問4. Automatic Clustering と clustering depth に関する説明として正しいものを2つ選べ。
正解:A・C
Automatic Clustering はサーバーレスのコンピュートでバックグラウンド実行され、実行分のクレジットを消費します(A)。clustering depth はマイクロパーティション間の値の範囲の重なりを表し、浅い(小さい)ほど良好です(C)。Bは誤りで、ユーザーのウェアハウスや手動メンテナンスは不要です。Dは depth の読み方が逆です。