目次 › 第3章 › 3-5

第3章 データロード・アンロードと接続 / 想定学習時間:30〜40分 / 最終確認:2026年8月

3-5. Dynamic Tables(宣言的パイプラインとTARGET_LAG)

1. Dynamic Table とは:結果を宣言するテーブル

3-4 の Streams+Tasks では、「差分を捕捉する Stream を作り、MERGE を書き、タスクをスケジュールして RESUME する」という手続きを自分で組み立てました。Dynamic Table(ダイナミックテーブル)は、この発想を逆転させます。「欲しい結果(SELECT)」と「どれくらい新鮮であってほしいか(TARGET_LAG)」だけを宣言すれば、リフレッシュの段取りは Snowflake が自動で管理する——これが宣言的パイプラインです。

-- 「この SELECT の結果を、5分以内の鮮度で保ち続けてほしい」と宣言する
CREATE DYNAMIC TABLE sales_clean
  TARGET_LAG = '5 minutes'
  WAREHOUSE = etl_wh
  AS
  SELECT sale_id,
         CAST(amount AS NUMBER(10,2)) AS amount,
         sale_date
  FROM raw_sales
  WHERE amount IS NOT NULL;

作成後は、ソースの raw_sales が変化すると、Snowflake が TARGET_LAG を満たすように自動でリフレッシュします。Stream の作成も、MERGE 文も、タスクのスケジュール管理も不要です。

2. TARGET_LAG と DOWNSTREAM:鮮度の指定

Dynamic Table の鮮度はラグ(lag)=「ソースの変更が反映されるまでの遅れの目標値」で指定します。指定方法は2つあります。

3. 自動リフレッシュ:増分とフル

Dynamic Table のリフレッシュは Snowflake が自動で実行します。このとき、クエリの内容に応じて2つの方式が使い分けられます。

• 増分リフレッシュ(incremental refresh):ソースの変更分だけを計算して結果に反映します。可能な場合はこちらが選ばれ、効率的です。
• フルリフレッシュ(full refresh):クエリが増分計算に向かない場合(複雑な構文など)は、結果全体を再計算します。

どちらを使うかはクエリの内容から Snowflake が自動判定します。ユーザーが MERGE 文や差分ロジックを書く必要はありませんが、「増分で処理できるクエリの方がコスト効率が良い」という感覚は持っておきましょう。なお、Dynamic Table の定義クエリには一部使えない構文があります(たとえば外部関数など)。細かい一覧を暗記する必要はありませんが、「どんな SELECT でも増分化できるわけではなく、制約もある」という点は覚えておいてください。

4. Streams+Tasks との比較

同じ「継続的な変換パイプライン」を作るにも、Streams+Tasks(手続き的)と Dynamic Tables(宣言的)では発想が異なります。

5. モニタリング

Dynamic Table のリフレッシュ状況は、次の方法で確認できます。

• Snowsight:Dynamic Table の詳細画面で、パイプラインの依存関係のグラフ表示や、リフレッシュの履歴・ラグの推移を視覚的に確認できます。
• DYNAMIC_TABLE_REFRESH_HISTORY:テーブル関数で、各リフレッシュの実行時刻・方式(増分/フル)・結果をクエリで確認できます。

-- リフレッシュ履歴の確認
SELECT name, refresh_start_time, refresh_action, state
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY())
WHERE name = 'SALES_CLEAN'
ORDER BY refresh_start_time DESC;

練習問題