Dynamic Tables で宣言的な増分変換を実現する

データ変換パイプラインを組むとき、これまでは Stream で変更を捉え、Task で順序を並べ、MERGE で反映し……と手続きを積み上げてきました。テーブルが増えるほど、その依存グラフ(DAG)の保守自体がコストになります。Snowflake の Dynamic Tables は発想を反転させ、「最終的にこの SELECT の結果になっていてほしい」とだけ宣言すれば、変更検知・増分反映・依存順序を Snowflake が引き受けます。本稿では TARGET_LAG と自動増分リフレッシュの挙動、Streams / Tasks との使い分け、AWS(S3・Iceberg)との接点、そして検証段階で先に踏み抜いておくべきコストの落とし穴を、現場目線で整理します。

01なぜ「宣言的」なのか — 手続き的パイプラインの負債

Streams & Tasks は強力で柔軟ですが、運用の主語が常に「人」になります。どの Stream を消費し、Task を AFTER でどう連結し、MERGE でどう反映し、失敗時にどこから再実行するか——これらを設計・保守し続ける必要があります。ソース層・整形層・ディメンション・ファクト・マートと段が増えるほど、Task の依存グラフそのものが技術的負債になっていきます。Dynamic Tables はこの関係を反転させます。中間状態の手続きではなく「望ましい最終結果」を SELECT として宣言し、そこへ至る変更検知・増分適用・更新順序の決定は Snowflake に委ねる、という考え方です。

02Dynamic Table の基本 — SELECT が唯一の真実

CREATE DYNAMIC TABLE ... TARGET_LAG = '...' WAREHOUSE = ... AS SELECT ... の形で定義します。テーブルにデータを INSERT していくのではなく、クエリの結果がテーブルの中身になる、という点がすべての起点です。ある Dynamic Table が別の Dynamic Table を参照すれば、Snowflake はその参照関係から依存グラフを構成し、上流から下流へ順序付けてリフレッシュします。Task のように「AFTER」で連結を手書きする必要はありません。下図のように、整形層とディメンションが更新され、それらに依存するファクト、さらにマートへと、スナップショット整合を保ちながら伝播します。

03TARGET_LAG — 「更新間隔」ではなく「鮮度の目標」

TARGET_LAG は「データがベーステーブルからどれだけ遅れてよいか」という鮮度目標であって、固定の更新間隔ではありません。'10 minutes' のように期間で指定すると、Snowflake はベース更新から概ね10分以内に収まるようリフレッシュを自律的にスケジュールします。指定できる最小値は60秒です。もう一つの指定が DOWNSTREAM で、これは「自分では独立したスケジュールを持たず、下流の Dynamic Table が必要とするタイミングにのみ更新する」という意味です。中間層を DOWNSTREAM にしておくと、鮮度要件はマート側の一点だけを管理すればよくなります。ただし TARGET_LAG はあくまでベストエフォートで、ウェアハウスの容量やデータ量、クエリの複雑さ、パイプラインの深さによっては実ラグが目標を超えることもあります。上流に、下流より短いラグを設定しないのが原則です。

04リフレッシュモード — AUTO / INCREMENTAL / FULL

リフレッシュには増分(INCREMENTAL)と全量(FULL)、そして既定の AUTO があります。INCREMENTAL は前回リフレッシュ以降に変わった行だけを解析してマージするため、最もコスト効率が良い一方、対応する構文でクエリが書かれていることが条件になります。中央値や厳密パーセンタイル、EXCEPT / INTERSECT のような集合演算、UUID_STRING・RANDOM・SEQ 系といった非決定的な関数は、その性質上「全行を見ないと答えが変わりうる」ため増分では扱えません。重要なのは AUTO の挙動です。AUTO は作成時に一度だけ増分か全量かを解決して固定し、以後のリフレッシュで再評価しません。上流の変化で後から増分が成立しなくなった場合、モードが自動で切り替わるのではなくリフレッシュが失敗します。さらにリフレッシュモードは ALTER では変更できず、変えるには CREATE OR REPLACE / CREATE OR ALTER が必要で、当該テーブルと下流の再初期化を伴います。