データ基盤

Snowflake Dynamic Tablesとは？SELECTだけで結果の表を最新に保つ

2026/10/29 （更新: 2026/11/3） シリーズ「Snowflake 入門」 第9回 / 全13回

🤖 AIを使用して執筆

注文   顧客  日付        数量  単価    状態
1001   1     2025-01-15  3     29.99   completed
1002   2     2025-01-15  1     49.99   completed
1003   1     2025-01-15  2     29.99   pending
1004   3     2025-01-16  5     12.50   completed
1005   2     2025-01-16  1     49.99   returned

日付        地域     区分        注文の数  売上
2025-01-15  US-East  Mid-Market  1         49.99
2025-01-15  US-West  Enterprise  2         149.95
2025-01-16  EU-West  Startup     1         62.50

CREATE OR ALTER DYNAMIC TABLE daily_sales
    TARGET_LAG = '30 minutes'
    WAREHOUSE = transform_wh
    REFRESH_MODE = INCREMENTAL
AS
    SELECT o.order_date::DATE AS order_day,
           c.region, c.segment,
           COUNT(*) AS order_count,
           SUM(o.quantity * o.unit_price) AS daily_revenue
    FROM raw_orders o
    JOIN dim_customers c ON o.customer_id = c.customer_id
    WHERE o.order_status != 'returned'
    GROUP BY ALL;

Dynamic Tables とは：SELECT とターゲットラグ

Dynamic Tables は、SELECT の結果を表として持ち、最新に保つ。利用者は SELECT とターゲットラグを決め、Snowflake が依存関係を把握して更新する¹。

• 更新の結果は一度に入れ替わるので、読む人が更新の途中を見ることはない¹。
• Snowflake は依存の順に更新するので、後ろの段は、前の段の食い違いのない状態を見る¹。依存を宣言したり、実行の順を書いたりする必要はない¹。Dynamic Tables は、別の Dynamic Tables を元にして段を重ねることもできる。後ろの段のターゲットラグは、前の段と同じかそれより長くする⁴。

ターゲットラグ： ターゲットラグは、更新の間隔ではなく、データがどれだけ古くてよいかの目標である。10 分なら「10 分ごとに更新する」ではなく、「データが 10 分より古くならないようにする」という意味である⁵。

• 最短は 60 秒で、それより短い値は通らない⁵。
• 保証ではない。更新が長引けば、実際の遅れは目標を超える¹。アプリは、データがいつも目標の内にあると考えてはいけない⁵。
• 遅れは、すぐ前の段ではなく、いちばん元の表から測る⁵。
• TARGET_LAG = DOWNSTREAM にすると、自分のスケジュールを持たず、後ろの段に合わせて更新する。後ろの段が無いと、自動では更新されず、Snowflake は警告も出さない⁵。

Snowflake の技術者らは、2025 年の論文で、この考え方を説明している。ビューは、読むたびに SELECT を動かして結果を返す。Dynamic Tables の中身は、そのビューを過去のある時点で読んだ結果と同じになる。その時点と今との差が遅れである⁸。論文によれば、多くの実用の場面は数秒から数十分の遅れで足り、Dynamic Tables は数秒から数時間の処理の遅れを想定して作られている⁸。ただし、今のドキュメントでは、ターゲットラグの最短は 60 秒である⁵。

更新の方法：変わった分だけか、全部か

Dynamic Tables の更新（リフレッシュ）には、増分とフルの二つのやり方がある。後で述べる AUTO と ADAPTIVE は、どちらで動かすかを Snowflake に選ばせる指定である⁶。

• 増分リフレッシュ（INCREMENTAL）： 前の更新から変わったデータだけを調べて、結果に反映する。
• フルリフレッシュ（FULL）： SELECT を元の表の今の状態で全部やり直し、結果を入れ替える。

REFRESH_MODE を書かないと AUTO になり、作るときに Snowflake が増分か全部かを選ぶ⁴。2026 年 7 月には、増分を基本にしつつ、変わった量が多いときは作り直す ADAPTIVE が一般提供になった。Snowflake は、増分で回す処理には ADAPTIVE を勧め、本番では AUTO に任せずに方法を明示するよう書いている⁹⁶。AUTO が ADAPTIVE を選ぶことはない⁶。

増分リフレッシュに向かない書き方もある。EXCEPT や INTERSECT、FROM の外の副問い合わせ（WHERE EXISTS など）を含むと、増分では作れない¹⁰。INCREMENTAL を指定していれば作成が失敗し、AUTO なら全部の更新になる¹⁰。どちらになったかは、SHOW DYNAMIC TABLES の refresh_mode と refresh_mode_reason で確かめる⁴。作った後に ALTER で方法を変えることはできず、変えるには CREATE OR ALTER か CREATE OR REPLACE で作り直す⁶。

費用：更新のウェアハウスと、変更の確かめ

Dynamic Tables には、更新を動かすウェアハウスが要る¹¹。費用は次のように出る¹²。

• 更新の計算： 元の表に変化があると、ウェアハウスが動いて更新する。絞り込みの結果、出力の行が無くても動く。
• 変化の確かめ： 更新のたびに、元の表が変わったかをメタデータで確かめる。この確かめはクラウドサービスの計算で、変化が無い回にも動く。変化が無ければ、ウェアハウスは止まったままで、ウェアハウスのクレジットはかからない。クラウドサービスの料金は、アカウント全体で、その日のウェアハウスのクレジットの 10% を超えた分だけ請求される。
• 保存： 更新が多いと、Time Travel の履歴が増える。

更新の記録は、関数 DYNAMIC_TABLE_REFRESH_HISTORY で 7 日分を見られる¹³。元の表に変化が無かった更新は NO_DATA と記録される¹⁴。

Streams と Tasks、マテリアライズドビューとの使い分け

Dynamic Tables より前から、Snowflake には変換を回す仕組みとして Streams と Tasks がある。

• Streams： 表の変更を記録するオブジェクトである。データそのものは持たず、前に読んだ位置（オフセット）から今までの変更を返す²。
• Tasks： SQL（Structured Query Language）の文を決まった時刻に、またはストリームにデータが来たときに動かすオブジェクトである³。

Snowflake の使い分けの指針は、次のとおりである⁷。

• Dynamic Tables： 結合、集計、ウィンドウ関数を含む、新しい複数の表のパイプラインに勧める。
• Streams と Tasks： ストアドプロシージャ、MERGE、外部の関数の呼び出し、独自のやり直しの処理、CRON のスケジュールが要るときに使う。1 分より新しいデータを独自の処理で作りたいときも、こちらを使う。
• マテリアライズドビュー： 問い合わせの結果をあらかじめ計算して持っておくビューで、パイプラインを作るためではなく、読む速さを上げたいときに使う。元の表は一つだけで、元の表への問い合わせを Snowflake が自動でこのビューを使う形に書き換え、中身はいつも最新である。遅れの無いデータが要るときも、Snowflake はこれを勧めている。

Dynamic Tables には、次の制限がある⁷。

• 定義の中で、ストアドプロシージャ、外部の関数、タスクを呼べない。SELECT で書く定義には MERGE を使えない。
• 元の表に、ストリーム、外部テーブル、マテリアライズドビューなどは使えない。
• 定義を変えると、作り直し（全部の処理のやり直し）になる。
• 今の状態を表すもので、変更の履歴を残す表には向かない。
• 一つのアカウントに置けるのは 50,000 まで。

ただし、更新の方法を CUSTOM_INCREMENTAL にすると、更新の処理を MERGE か INSERT で書ける⁶。Snowflake は、一文の MERGE か INSERT で書いた Streams と Tasks の処理は、SELECT に書き直さずにこの方法へそのまま移せるとしている¹⁵。

Dynamic Tables は読み取り専用で、INSERT や DELETE はできない⁷。例外として、2026 年 7 月に、定義で更新の対象から外すと決めた範囲（凍結された範囲）の行に限って、INSERT、UPDATE、MERGE、DELETE ができる機能が一般提供になった¹⁶。

Streams の動き： ストリームのオフセットは、SELECT で読むだけでは進まず、INSERT のような DML（Data Manipulation Language）の文の中で読むと進む²。METADATA$ACTION の列が INSERT か DELETE かを示し、更新は DELETE と INSERT の組として、METADATA$ISUPDATE を TRUE にして表す²。オフセットが元の表のデータ保持期間の外に出ると、ストリームは古くなって使えず、作り直す²。保持期間が 14 日より短い表では、読まれていないストリームのために、既定で最大 14 日まで保持期間が延び、その分の保存の料金がかかる²。

Tasks の動き： タスクは止まった状態で作られ、ALTER TASK … RESUME で動き出す³。Snowflake が計算資源を用意するサーバーレスと、自分のウェアハウスを使う方式を選べる³。複数のタスクは、起点となるルートタスクと子タスクからなるタスクグラフでつなげる¹⁷。ストリームに変更が来たときだけ動くタスクも作れる¹⁸。

変換の前：データを取り込む

変換の元になるデータは、まず Snowflake の表に入れる。Snowflake は、クラウドストレージにあるデータファイルを置く場所を、ステージという¹⁹。

• 外部ステージ： Amazon S3 などのクラウドストレージの URL（Uniform Resource Locator）と、つなぐための設定を持つ¹⁹。
• 内部ステージ： Snowflake の中のステージで、ユーザーごと、表ごと、名前を付けたものの三種類がある。手元のファイルは PUT で上げる¹⁹。

COPY INTO も Snowpipe も、読み込みながら結合や集計はできない。生のデータを表に入れてから、Dynamic Tables か Streams と Tasks で変換する²⁰。

COPY INTO： ステージのファイルを表に読み込む命令である。まとめて読み込むとき（一括ロード）は、利用者が用意したウェアハウスで動く¹⁹。

• 読み込んだファイルの記録を、表のメタデータに 64 日持ち、同じファイルをもう一度読み込まない²¹。読み込み直すには、FORCE = TRUE を付けるか、ファイルを変えて置き直す²²。
• 一括ロードでは、既定で、誤りが一つでもあれば読み込みを止める（ABORT_STATEMENT）²²。
• Snowflake は、ファイルを並列に読み込めるよう、圧縮した大きさで 100〜250 MB かそれより大きいファイルにするよう勧めている。100 GB 以上のような大きなファイルは勧めていない²³。

Snowpipe： ファイルが届くたびに、決めた COPY INTO を自動で動かす仕組みである。Snowflake が用意する計算資源で動き、クラウドストレージからの到着の知らせか、REST（Representational State Transfer）の API（Application Programming Interface）の呼び出しで、新しいファイルを知る²⁰。

• 新しいファイルは、ふつう知らせを受けてから 1 分ほどで読み込まれるが、保証はない²⁰。
• 読み込んだファイルの記録は、パイプごとに 14 日分である。COPY INTO と記録は別なので、同じファイルを両方で読み込まないようにする²⁰。
• 料金は、読み込んだデータ 1 GB あたり決まったクレジットで、ウェアハウスの時間やファイルの数では決まらない²⁰。CSV（Comma-Separated Values）や JSON（JavaScript Object Notation）のようなテキストのファイルは圧縮前の大きさで数え、Parquet などは保存した大きさで数える²⁰。Standard と Enterprise のアカウントがこの方式になったのは 2025 年 12 月である²⁴。

Snowpipe Streaming： ファイルではなく、行を SDK（Software Development Kit）や API で直接表に書き込む仕組みである¹⁹。遅れは短ければ 5 秒ほどである²⁰。数秒で要るデータが行やイベントとして届くなら、こちらを使う²⁰。

データベースや SaaS（Software as a Service）のアプリから直接取り込むなら、Snowflake のデータ連携のサービス Openflow のコネクタを使う²⁰²⁵。

dbt と運用

SQL の変換を定義し、テストし、デプロイするオープンソースの枠組みを dbt（dbt Core）といい²⁶、ワークフローをプログラムで書き、スケジュールし、見張るプラットフォームを Airflow という²⁷。Snowflake は、更新をこうした外のツールから動かす使い方も書いている¹。dbt の Snowflake 用のアダプターは、Dynamic Tables を作れる²⁸。dbt v1.12 以降では、scheduler と target_lag の両方を書かずに作ると SCHEDULER が DISABLE になり、Snowflake の自動の更新は動かず、dbt の実行が更新する。target_lag を書けば、Snowflake が自動で更新する²⁸。Snowflake には、dbt のプロジェクトを Snowflake の中で動かし、タスクでスケジュールを組める dbt Projects on Snowflake もある²⁶。

Snowflake の Well-Architected Framework は、オペレーショナルエクセレンスの柱で、パイプラインを含むすべての構成をコードとして管理し、自動のテストで本番での不具合の再発を防ぐよう勧めている²⁹。データの取り込みは、COPY_HISTORY などのビューで、遅れと状態を見張るよう書いている²⁹。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。