Dynamic Tables vs Streams/Tasks使い分け

Snowflakeのデータパイプラインを構築する際、Dynamic TablesとStreams＋Tasksのどちらを採用するかは設計上の重要な分岐点です。 両者はまったく異なるパラダイムで動作し、適するユースケースも異なります。 この記事では7つの比較軸で両者の違いを整理し、設計判断のフレームワークを提供します。

軸1：宣言型 vs 手続型

Dynamic Tablesは宣言型アプローチです。 「このSELECT文の結果を常に最新に保ってほしい」と宣言するだけで、 Snowflakeが変更検知・増分処理・リフレッシュスケジューリングをすべて管理します。

Streams＋Tasksは手続型アプローチです。 StreamでCDC（変更データキャプチャ）を取得し、TaskでMERGE/INSERT文を実行する手順を明示的にコーディングします。 変換ロジック・実行順序・エラーハンドリングのすべてを開発者が制御します。

-- 宣言型: Dynamic Table
CREATE DYNAMIC TABLE gold_revenue
  TARGET_LAG = '10 minutes'
  WAREHOUSE = etl_wh
AS
  SELECT region, SUM(amount) AS total_revenue
  FROM silver_orders
  GROUP BY region;

-- 手続型: Stream + Task
CREATE STREAM orders_stream ON TABLE silver_orders;

CREATE TASK merge_revenue
  WAREHOUSE = etl_wh
  SCHEDULE = 'USING CRON */10 * * * * UTC'
  WHEN SYSTEM$STREAM_HAS_DATA('orders_stream')
AS
  MERGE INTO gold_revenue t
  USING (
    SELECT region, SUM(amount) AS total_revenue
    FROM orders_stream
    GROUP BY region
  ) s ON t.region = s.region
  WHEN MATCHED THEN UPDATE SET t.total_revenue = t.total_revenue + s.total_revenue
  WHEN NOT MATCHED THEN INSERT (region, total_revenue) VALUES (s.region, s.total_revenue);

軸2：SLA制御

軸3：開発・運用の複雑さ

軸4：JOIN処理

Dynamic TablesではSELECT文にJOINを自由に記述でき、Snowflakeが依存テーブル全体を追跡します。 Streams＋Tasksの場合、Streamは単一テーブル（またはビュー）に対して作成するため、 複数テーブルの変更をJOINするにはStreamを複数作成してTask内で結合するか、 変更検知のタイミングがずれる問題に対処する設計が必要です。

-- Dynamic Tables: JOINを含むSELECTをそのまま宣言
CREATE DYNAMIC TABLE enriched_orders
  TARGET_LAG = '5 minutes'
  WAREHOUSE = etl_wh
AS
  SELECT
    o.order_id,
    o.order_date,
    p.product_name,
    p.category,
    o.quantity * p.unit_price AS line_total
  FROM raw_orders o
  JOIN raw_products p ON o.product_id = p.product_id;

-- Streams/Tasks: 複数Streamの管理が必要
CREATE STREAM orders_cdc ON TABLE raw_orders;
CREATE STREAM products_cdc ON TABLE raw_products;
-- → Task内で両Streamを参照し、MERGEロジックを実装
-- → 片方のStreamだけにデータがあるケースの処理が必要

軸5：増分ロジック

Dynamic TablesのIncrementalリフレッシュはSnowflakeが自動判定・自動実行します。 開発者はリフレッシュモードを意識せずSELECT文を書くだけです。 ただし、WINDOW関数やSELECT DISTINCTを含むクエリはFull Refreshにフォールバックする点に注意が必要です。

Streams＋Tasksでは、StreamがINSERT/UPDATE/DELETEの変更行をMETADATA$ACTION列等で提供するため、 MERGE文で精密な増分処理を記述できます。DELETE操作の追跡やUPDATE前後の値の比較など、 きめ細かい制御が可能です。

軸6：コスト構造

軸7：監視とオブザーバビリティ

-- Dynamic Tablesのリフレッシュ監視
SELECT name, refresh_action, state, data_timestamp
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY())
WHERE state = 'FAILED'
ORDER BY refresh_start_time DESC
LIMIT 10;

-- Streams/Tasksの実行監視
SELECT name, state, error_message, scheduled_time
FROM TABLE(INFORMATION_SCHEMA.TASK_HISTORY(
  SCHEDULED_TIME_RANGE_START => DATEADD(HOUR, -24, CURRENT_TIMESTAMP())
))
WHERE state = 'FAILED'
ORDER BY scheduled_time DESC;

設計判断フローチャート

パイプラインの要件は？
│
├─ SELECT文で表現可能な変換か？
│   ├─ YES → JOINや集計が中心か？
│   │         ├─ YES → Dynamic Tables推奨
│   │         └─ NO（条件分岐・外部連携あり）→ Streams/Tasks
│   └─ NO（ストアドプロシージャが必要）→ Streams/Tasks
│
├─ 厳密なCRONスケジュールが必要か？
│   ├─ YES（毎時0分に実行等）→ Streams/Tasks
│   └─ NO（最大遅延指定でOK）→ Dynamic Tables
│
├─ DELETE/UPDATEの変更前後の値を追跡する必要があるか？
│   ├─ YES → Streams/Tasks（METADATA$ACTION / $ISUPDATE）
│   └─ NO → Dynamic Tables
│
└─ 運用負荷を最小化したいか？
    ├─ YES → Dynamic Tables
    └─ 細かい制御が必要 → Streams/Tasks

7軸サマリー比較表

問題で確認

よくある質問