Snowflake Dynamic Tables宣言型パイプライン

Dynamic Tablesは、Snowflakeが提供する宣言型データパイプラインの仕組みです。 従来のStreams＋Tasksでは「どのように変換するか」「いつ実行するか」を手続的に定義する必要がありましたが、 Dynamic Tablesでは「最終的にどのような結果セットが欲しいか」をSELECT文で宣言するだけで、 Snowflakeがリフレッシュスケジュール・増分処理・依存関係の解決をすべて自動管理します。

宣言型パイプラインの基本概念

Dynamic Tablesは内部的にDAG（有向非巡回グラフ）を形成します。 ソーステーブルAを参照するDynamic Table Bと、Bを参照するDynamic Table Cがある場合、 Snowflakeは自動的にA→B→Cの依存関係を検出し、適切な順序でリフレッシュを実行します。 ユーザーがTaskの実行順序やStream消費タイミングを管理する必要はありません。

リフレッシュにはIncremental（増分）とFull（全量）の2モードがあり、 Snowflakeがクエリの内容を解析して自動的に最適なモードを選択します。 単純なSELECT / JOIN / WHERE / GROUP BYで構成されるクエリはIncrementalリフレッシュの対象となり、 変更されたデータのみを処理するためコスト効率が高くなります。

CREATE DYNAMIC TABLE構文

-- 基本的なDynamic Tableの作成
CREATE OR REPLACE DYNAMIC TABLE silver_orders
  TARGET_LAG = '5 minutes'
  WAREHOUSE = transform_wh
AS
  SELECT
    o.order_id,
    o.order_date,
    o.customer_id,
    c.customer_name,
    c.segment,
    o.total_amount
  FROM raw.orders o
  JOIN raw.customers c ON o.customer_id = c.customer_id
  WHERE o.order_date >= '2025-01-01';

-- 作成後の確認
SHOW DYNAMIC TABLES LIKE 'SILVER_ORDERS';
DESCRIBE DYNAMIC TABLE silver_orders;

TARGET_LAGはソースデータの変更がDynamic Tableに反映されるまでの最大許容遅延です。WAREHOUSEはリフレッシュ処理に使用するウェアハウスを指定します。

TARGET_LAGの設計指針

DOWNSTREAMによるDAG依存解決

メダリオンアーキテクチャのように複数のDynamic Tableをチェーンする場合、 中間レイヤーにはTARGET_LAG = DOWNSTREAMを設定します。 最下流のDynamic Tableに具体的なラグ値を設定すると、 Snowflakeが逆算して上流の各テーブルのリフレッシュタイミングを自動調整します。

-- Bronze → Silver → Gold のメダリオンパイプライン

-- Silver層: DOWNSTREAMで下流に追従
CREATE OR REPLACE DYNAMIC TABLE silver_daily_sales
  TARGET_LAG = DOWNSTREAM
  WAREHOUSE = transform_wh
AS
  SELECT
    DATE_TRUNC('DAY', order_date) AS sale_date,
    product_category,
    COUNT(*) AS order_count,
    SUM(total_amount) AS revenue
  FROM bronze_orders
  GROUP BY 1, 2;

-- Gold層: 具体的なラグ値を設定（DAG末端）
CREATE OR REPLACE DYNAMIC TABLE gold_sales_summary
  TARGET_LAG = '10 minutes'
  WAREHOUSE = transform_wh
AS
  SELECT
    sale_date,
    product_category,
    order_count,
    revenue,
    revenue / NULLIF(order_count, 0) AS avg_order_value
  FROM silver_daily_sales
  WHERE sale_date >= DATEADD(MONTH, -12, CURRENT_DATE());

リフレッシュ監視

Dynamic Tableのリフレッシュ履歴はINFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORYテーブル関数およびACCOUNT_USAGE.DYNAMIC_TABLE_REFRESH_HISTORYビューで確認できます。

-- 直近24時間のリフレッシュ履歴を確認
SELECT
  name,
  refresh_trigger,
  refresh_action,       -- INCREMENTAL or FULL
  state,                -- SUCCEEDED / FAILED / CANCELLED
  state_message,
  data_timestamp,
  refresh_start_time,
  refresh_end_time,
  DATEDIFF('SECOND', refresh_start_time, refresh_end_time) AS duration_sec
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME_PREFIX => 'SILVER_',
  ERROR_ONLY => FALSE
))
WHERE refresh_start_time >= DATEADD(HOUR, -24, CURRENT_TIMESTAMP())
ORDER BY refresh_start_time DESC;

運用操作

-- TARGET_LAGの変更
ALTER DYNAMIC TABLE silver_orders SET TARGET_LAG = '15 minutes';

-- ウェアハウスの変更
ALTER DYNAMIC TABLE silver_orders SET WAREHOUSE = new_transform_wh;

-- リフレッシュの一時停止と再開
ALTER DYNAMIC TABLE silver_orders SUSPEND;
ALTER DYNAMIC TABLE silver_orders RESUME;

-- 手動リフレッシュ（デバッグ・検証用）
ALTER DYNAMIC TABLE silver_orders REFRESH;

Streams/Tasksとの違い

設計ベストプラクティス

• 末端に具体ラグ、中間はDOWNSTREAM：DAGの末端テーブルにのみTARGET_LAGの時間値を設定し、中間テーブルはDOWNSTREAMで自動調整させる
• IncrementalリフレッシュをSELECT設計で活かす：WINDOW関数やSELECT DISTINCTを避け、JOIN / GROUP BY / WHEREベースのSQLにすることでIncremental対象になる確率が上がる
• 専用ウェアハウスを割り当てる：クエリワークロードとリフレッシュワークロードが競合しないよう、Dynamic Table用のウェアハウスを分離する
• DYNAMIC_TABLE_REFRESH_HISTORYで継続監視：Full Refreshが意図せず頻発していないか、リフレッシュ失敗が起きていないかを定期的に確認する
• 初期ロード時はウェアハウスサイズを一時的に拡大：初回のFull Refreshは全データを処理するため、通常より大きいウェアハウスサイズを使い、完了後に元のサイズに戻す

問題で確認

よくある質問