Snowflake アーキテクチャの内部構造：3層設計、マイクロパーティション、クエリ処理

この記事について

Snowflake は「クラウドのために一から設計された DWH」である。この記事では Snowflake の3層アーキテクチャ、マイクロパーティション、クエリ処理の仕組みを解説する。

1. 3層アーキテクチャ

1-1. 全体像

┌─────────────────────────────────────────────────┐
│          Cloud Services Layer                    │
│                                                 │
│  認証・認可  メタデータ管理  クエリ最適化           │
│  トランザクション管理  インフラ管理                 │
│  結果キャッシュ  セキュリティ                      │
└──────────────────┬──────────────────────────────┘
                   │
┌──────────────────┴──────────────────────────────┐
│          Virtual Warehouse Layer                 │
│                                                 │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐      │
│  │ WH: XS   │  │ WH: L    │  │ WH: XL   │     │
│  │ BI用     │  │ ETL用    │  │ DS用     │      │
│  │          │  │          │  │          │      │
│  │ 1ノード  │  │ 8ノード  │  │ 16ノード  │      │
│  └──────────┘  └──────────┘  └──────────┘      │
│  ← 各 Warehouse は完全に独立 →                   │
└──────────────────┬──────────────────────────────┘
                   │
┌──────────────────┴──────────────────────────────┐
│          Storage Layer                           │
│                                                 │
│  クラウドオブジェクトストレージ（S3 / Azure Blob / GCS）│
│  マイクロパーティション（圧縮・列指向・不変）         │
│  ← すべての Warehouse が同じデータにアクセス →      │
└─────────────────────────────────────────────────┘

1-2. 各層の役割

1-3. なぜ3層分離が重要か

従来の DWH（Redshift Provisioned）:
  コンピュート + ストレージが結合
  → ストレージを増やすにはノードを追加 → コンピュートも増える → コスト増
  → コンピュートを増やすにはノードを追加 → ストレージも増える → コスト増

Snowflake:
  ストレージを増やす → データを入れるだけ（コンピュートに影響なし）
  コンピュートを増やす → Warehouse サイズを変更（ストレージに影響なし）
  → 必要なものだけスケール

2. マイクロパーティション

2-1. 基本構造

Snowflake はテーブルのデータを自動的にマイクロパーティションに分割する。

テーブル: sales（1億行）
  │
  ├── マイクロパーティション 1（50〜500MB、圧縮後 16MB 程度）
  │   ├── Column: order_id  [1, 2, 3, ..., 50000]
  │   ├── Column: date      [2024-01-01, ..., 2024-01-15]
  │   ├── Column: amount    [100, 250, ..., 9999]
  │   └── Column: region    [東京, 大阪, ..., 福岡]
  │
  ├── マイクロパーティション 2
  │   ├── Column: order_id  [50001, ..., 100000]
  │   ├── ...
  │
  └── ... （数千〜数百万パーティション）

特徴： – 列指向で格納（必要なカラムだけ読み取り） – 自動的に圧縮 – 不変（Immutable）：更新は新しいパーティションを作成し、古いものを論理削除 – ユーザーが設計する必要なし（自動分割）

2-2. メタデータとプルーニング

各マイクロパーティションのメタデータを Cloud Services Layer が管理する。

マイクロパーティション 1 のメタデータ:
  date:   min=2024-01-01, max=2024-01-15
  amount: min=100, max=9999
  region: distinct_values=[東京, 大阪, 名古屋, 福岡]
  rows:   50000

クエリ実行時にメタデータを使って不要なパーティションをスキップする（パーティションプルーニング）。

SELECT * FROM sales WHERE date = '2024-04-01';

-- Cloud Services が判定:
-- パーティション 1: date min=01-01, max=01-15 → スキップ
-- パーティション 2: date min=01-16, max=01-31 → スキップ
-- ...
-- パーティション 91: date min=04-01, max=04-15 → 読み取り ✓
-- → 全パーティションの1%だけ読む

2-3. Redshift / Databricks との比較

Snowflake の「チューニング不要」は、マイクロパーティションの自動管理によるもの。

3. Virtual Warehouse

3-1. サイズと構成

サイズを1段階上げるとノード数が2倍になり、理論上の処理速度も2倍になる。

3-2. マルチクラスタ Warehouse

同時実行が増えたときに自動的にクラスタを追加する。

通常時:
  Warehouse "analytics" → Cluster 1（1つだけ稼働）

同時クエリが増加:
  Warehouse "analytics" → Cluster 1
                        → Cluster 2（自動追加）
                        → Cluster 3（自動追加）

負荷が下がる:
  Warehouse "analytics" → Cluster 1（2, 3 は自動停止）

設定： – 最小クラスタ数（常時稼働） – 最大クラスタ数（スケールアウト上限） – スケーリングポリシー（Standard / Economy）

3-3. 自動サスペンドと自動レジューム

クエリなし → 5分後に自動サスペンド（コスト $0）
クエリ到着 → 自動レジューム（数秒で起動）

4. クエリ処理の流れ

1. ユーザーが SQL を投入
   │
2. Cloud Services Layer
   ├── SQL パース・検証
   ├── メタデータからプルーニング対象を決定
   ├── 結果キャッシュを確認（同じクエリが過去にあれば即返却）
   └── 実行計画を生成
   │
3. Virtual Warehouse
   ├── 必要なマイクロパーティションを Storage から読み取り
   ├── ローカル SSD キャッシュを確認（あればキャッシュから読む）
   ├── クエリを実行（MPP で並列処理）
   └── 結果を返却
   │
4. 結果をユーザーに返す
   └── 結果を Cloud Services の結果キャッシュに保存（24時間）

4-1. 3層のキャッシュ

結果キャッシュが効くと、Warehouse を起動せずに結果を返せる。クレジット消費ゼロ。

5. データの更新（Copy-on-Write）

Snowflake のマイクロパーティションは不変。更新は「新しいパーティションを作って古いものを論理削除」する。

UPDATE sales SET amount = 500 WHERE order_id = 42;

Before:
  パーティション A: [order_id=42, amount=100], [order_id=43, amount=200], ...

After:
  パーティション A: 論理削除（タイムトラベルで参照可能）
  パーティション A': [order_id=42, amount=500], [order_id=43, amount=200], ...
  ← 変更された行を含むパーティション全体を書き直す

この仕組みにより： – タイムトラベルが可能（古いパーティションが残っている） – 読み取りと書き込みが干渉しない（MVCC） – VACUUM が不要（Snowflake が自動的に古いパーティションを回収）

6. Clustering Key

マイクロパーティションは自動分割だが、データの物理的な並び順を指定したい場合に Clustering Key を設定できる。

-- date でクラスタリング
ALTER TABLE sales CLUSTER BY (date);

Clustering Key は Redshift の Sort Key に相当するが、メンテナンスが自動である点が異なる。

必要なケース： – TB級の大きなテーブル – 特定カラムでのフィルタが非常に多い – プルーニング効率が悪い（SYSTEM$CLUSTERING_INFORMATION で確認）

7. まとめ

参考文献

• Snowflake. “Key Concepts & Architecture.” https://docs.snowflake.com/en/user-guide/intro-key-concepts
• Snowflake. “Micro-partitions & Data Clustering.” https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions
• Dageville et al. “The Snowflake Elastic Data Warehouse.” SIGMOD, 2016.