Clustering Keysとは？マイクロパーティション最適化

Clustering Keys（クラスタリングキー）は、Snowflakeの大規模テーブルでパーティションプルーニングの精度を最大化するためのパフォーマンスチューニング機能です。指定した列に基づいてデータの物理的な配置（マイクロパーティション内のソート順）を最適化し、クエリのスキャン量を大幅に削減します。Enterprise Edition以上で利用可能です。

マイクロパーティションとパーティションプルーニング

Snowflakeは全テーブルのデータを50〜500MBの圧縮されたマイクロパーティションに自動分割して格納します。各マイクロパーティションは列指向形式で保存され、各列の最小値・最大値・NULL数などのメタデータがCloud Services Layerに記録されます。

クエリにWHERE句が含まれると、Snowflakeはメタデータを参照して条件に合致する可能性のないマイクロパーティションをスキャン対象から除外します。この仕組みがパーティションプルーニングです。データが物理的にソートされているほどプルーニングの精度が高くなり、スキャン量が減少します。

自然クラスタリングとクラスタリング深度

データが挿入された順序で自然にソートされている場合（例：タイムスタンプ列で時系列INSERTされる場合）、そのテーブルは自然にクラスタリングされた状態です。この場合、追加のClustering Keys設定は不要です。

クラスタリング深度（Clustering Depth）は、テーブルの物理的なデータ配置がどの程度整理されているかを示す指標です。値が小さいほどデータが整理されており、プルーニングが効率的に機能します。

-- 特定列のクラスタリング深度を確認
SELECT SYSTEM$CLUSTERING_DEPTH(
  'analytics.orders',
  '(order_date, region)'
);

-- クラスタリングの詳細情報を取得
SELECT SYSTEM$CLUSTERING_INFORMATION(
  'analytics.orders',
  '(order_date, region)'
);

system$clustering_information() の出力項目

Clustering Keysの定義と変更

-- テーブル作成時にClustering Keysを指定
CREATE TABLE analytics.orders (
  order_id    INT,
  order_date  DATE,
  region      VARCHAR(50),
  customer_id INT,
  amount      NUMBER(12,2)
)
CLUSTER BY (order_date, region);

-- 既存テーブルにClustering Keysを追加
ALTER TABLE analytics.orders
  CLUSTER BY (order_date, region);

-- Clustering Keysの変更（上書き）
ALTER TABLE analytics.orders
  CLUSTER BY (order_date, customer_id);

-- Clustering Keysの削除（Automatic Clusteringも停止）
ALTER TABLE analytics.orders DROP CLUSTERING KEY;

列選定のガイドライン

Automatic Clustering

Clustering Keysを定義すると、SnowflakeのAutomatic ClusteringサービスがCloud Services Layer上で自動的にリクラスタリングを実行します。ユーザーのWarehouseを消費せず、Serverless Creditとして課金されます。

• DML操作後にクラスタリング状態を自動的に監視・維持
• 手動でのリクラスタリング実行は不要
• テーブルごとにAutomatic Clusteringを一時停止・再開可能

-- Automatic Clusteringを一時停止
ALTER TABLE analytics.orders SUSPEND RECLUSTER;

-- Automatic Clusteringを再開
ALTER TABLE analytics.orders RESUME RECLUSTER;

モニタリングとコスト管理

-- Automatic Clusteringのクレジット消費履歴（直近7日間）
SELECT *
FROM TABLE(INFORMATION_SCHEMA.AUTOMATIC_CLUSTERING_HISTORY(
  DATE_RANGE_START => DATEADD(DAY, -7, CURRENT_DATE()),
  DATE_RANGE_END => CURRENT_DATE(),
  TABLE_NAME => 'ANALYTICS.ORDERS'
));

-- Account Usageビューで長期的なコストトレンドを分析
SELECT
  table_name,
  SUM(credits_used) AS total_credits,
  SUM(num_bytes_reclustered) AS total_bytes_reclustered
FROM SNOWFLAKE.ACCOUNT_USAGE.AUTOMATIC_CLUSTERING_HISTORY
WHERE start_time >= DATEADD(MONTH, -1, CURRENT_TIMESTAMP())
GROUP BY table_name
ORDER BY total_credits DESC;

導入判断フローチャート

テーブルサイズは数十億行以上か？
  ├─ NO → Clustering Keys不要（自然なプルーニングで十分）
  └─ YES
       ↓
  Query Profileでパーティションプルーニングの効率を確認
       ↓
  スキャンされたパーティション数が総数に比べて多いか？
  ├─ NO → 自然クラスタリングが効いている → Clustering Keys不要
  └─ YES
       ↓
  WHERE句で頻繁にフィルタされる列を2〜4列選定
       ↓
  ALTER TABLE ... CLUSTER BY で定義
       ↓
  AUTOMATIC_CLUSTERING_HISTORYでコスト監視

ベストプラクティス

• まずQuery Profileで診断：パーティションプルーニングの状況を確認し、改善の余地がある場合のみClustering Keysを検討する
• 時系列データの自然クラスタリングを活かす：INSERT順が時系列順のテーブルは日付列のクラスタリングが自然に維持されるため、追加設定が不要な場合がある
• 定期的なコスト監視：AUTOMATIC_CLUSTERING_HISTORYでクレジット消費を追跡し、費用対効果を検証する
• 式ベースのClustering Keys：TO_DATE(timestamp_col) や MONTH(order_date) のように式を使って、高カーディナリティ列のカーディナリティを下げてから指定する手法も有効

問題で確認

よくある質問