データ変換へのモダンで高速なアプローチとして、何千ものお客様がダイナミックテーブルを活用しています。数分単位のエンドツーエンドのパイプラインレイテンシーと効率的な増分処理エンジンを備えたダイナミックテーブルは、自律型パイプラインへのモダンでスケーラブルなアプローチを提供します。過去1年間、Snowflakeはダイナミックテーブルをより高速で表現力豊かに改善し、すでにお使いのツールとの相互運用性を高めるためのアップデートを次々と提供してきました。
Summitでは、Wind Creek HospitalityのシニアデータエンジニアであるSergey Labetsik氏が、条件を満たしてから1分以内にゲストへ食事券を提供できた方法をデモンストレーションしました。dbtバッチジョブをダイナミックテーブルのパイプラインに移行することで、エンドツーエンドのレイテンシーを1分未満に短縮しました。これは、以前のジョブが実行されていた30分のスケジュールからの大幅な改善です。
ダイナミックテーブルの新機能と、それがパイプラインにとって重要である理由をご紹介します。
最大2.8倍高速化されたリフレッシュパフォーマンスのベンチマーク
スピードは、他のすべての基盤となるものです。2025年5月から2026年5月にかけて、最も一般的なダイナミックテーブルのパターンをベンチマークした結果、最大2.8倍高速のリフレッシュパフォーマンスが測定されました。これは、トップレベルの集計関数、QUALIFYの行/ランク = 1（SCD-1）、クラスター化操作、結合など、ダイナミックテーブルのパフォーマンスを加速するために内部で行われたアップデートを反映したものであり、すべてGen2ウェアハウスで測定されています。
これらの向上は、Gen2ウェアハウスと組み合わせたダイナミックテーブル専用に構築されたパフォーマンス最適化によるものです。増分リフレッシュは処理するデータが少なく、より早く完了するため、残りのワークロードにコンピュートを解放できます。ダイナミックテーブルのワークロードをまだGen2ウェアハウスに移行していない場合は、今がその絶好の機会です。
設計パターン：ダイナミックテーブルを使用した効果的な構築方法
基本に立ち返り、ダイナミックテーブルを使用して効率的なパイプラインを構築するためのベストプラクティスを確認します。
複数のダイナミックテーブルを連結して使用する：複雑なパイプラインを2つ以上のダイナミックテーブルのチェーンに分割し、それぞれで1つの論理ステップを処理します。多くのチームがメダリオンアーキテクチャの用語を使用しています。ブロンズ（未加工のランディング）、シルバー（TARGET_LAG = DOWNSTREAM）、ゴールド（時間ベースのラグで集計）です。ダイナミックテーブルの世界では、ブロンズレイヤーは未加工のランディングテーブルを表し、シルバーレイヤーはデータをクレンジングするダイナミックテーブル、ゴールドレイヤーはデータを強化してダウンストリームアプリケーションに提供する準備を整える場所です。
結合と集計を別々のダイナミックテーブルに分解する：最初に結合を配置し、次に集計を配置します。その後、各ステップが増分的にリフレッシュされるため、効率の向上が相乗効果を生み、管理性が向上します。
デュアルウェアハウス戦略を使用する：再初期化（フルスキャン、リソース集約型）にはINITIALIZATION_WAREHOUSEを設定し、継続的な増分リフレッシュにはより小さなウェアハウスを設定します。
本番環境ではREFRESH_MODE = AUTOを使用しない：開発環境で自動リフレッシュモードを使用し、パイプラインが増分的に実行されるか、フルリフレッシュが必要かを確認します。その後、本番環境でrefresh_modeを明示的に設定します。
新しいアップデートによるリフレッシュのさらなる高速化
QUALIFYの行/ランク = 1によるSCD-1の重複排除
ベーステーブルが追記専用のレコードを受け取るCDCパイプラインの場合、ビジネスキーごとに最新の行のみを増分的に保持するには、QUALIFY ROW_NUMBER() = 1（一般提供）を使用するのが最もクリーンな方法です。ウィンドウ関数は取り込み順序に関係なく正しい行を選択し、追加のロジックなしで順序通りでない到着を処理します。
さらに、SELECT * EXCLUDEパターンを使用すると、自動スキーマ進化も実現できます。ベーステーブルに追加または削除された列は、ダイナミックテーブルの定義を変更することなく、自動的にダウンストリームに伝播します。
SELECT * EXCLUDE _metadata_cols
FROM raw_events
QUALIFY ROW_NUMBER() OVER (
PARTITION BY id
ORDER BY updated_at DESC
) = 1プライマリキー：INSERT OVERWRITEへのスマートな対応
よくある事例をご紹介します。スマートに実行されている増分パイプラインがあるとします。その後、INSERT OVERWRITEがベーステーブルに実行され、変更追跡メタデータがリセットされます。あるいは、フルリフレッシュを必要とする複雑な集計が存在します。これにより、すべての下流テーブルがすべてを最初から再処理することになります。現在では、ベーステーブルにシンプルなPRIMARY KEY RELY制約（一般提供）を設定することで、この問題に対処できます。
ALTER TABLE dim_customers
ADD PRIMARY KEY (customer_id) RELY;これにより、Snowflakeに次のように指示できます。「変更の検出にはこのキーを信頼してください。変更追跡列には依存しないでください」
| メリット | 詳細 |
|---|---|
| パイプライン全体への伝播 | ベーステーブルで1回宣言するだけで、そのメリットはダウンストリームのすべてのダイナミックテーブルに波及。注：Primary Key RELYは遡及して適用されない。追加後、ダウンストリームのダイナミックテーブルでCREATE OR REPLACEを実行してメリットを有効にする必要がある。 |
| 派生キー | Snowflakeは、ユニークキーとなるSELECT、GROUP BY列とQUALIFY ROW_NUMBER()パーティションを自動的に読み取る。 |
| Apache Iceberg™ v2ソース | クラウドストレージ内のテーブルの更新および削除のパフォーマンスを大幅に向上させる。 |
| カスケード依存関係の解消 | FULLリフレッシュの親から読み取る場合でも、ダウンストリームのダイナミックテーブルはINCREMENTALを維持する。 |
アダプティブリフレッシュモード
プライマリキーを使用できないものの、増分パイプラインでフルで再計算する方が実際には安価になる状況が時折発生することがあります。アダプティブリフレッシュモード（パブリックプレビュー）は、このような課題を解決します。
これは、よりスマートな増分処理と言えます。Snowflakeには、その時点でより優れたコストパフォーマンスをもたらす方法に基づいて、増分処理を行うか再初期化するかをリフレッシュごとに評価するヒューリスティックが組み込まれています。
CREATE DYNAMIC TABLE my_table
REFRESH_MODE = ADAPTIVE
TARGET_LAG = '10 minutes'
WAREHOUSE = my_warehouse
AS
SELECT ... FROM source_table;アダプティブリフレッシュモードには、いくつかのガードレールが組み込まれています。高コストな関数（Cortex AI関数やユーザー定義関数など）が、予期せず再初期化されることはありません。また、ダイナミックテーブルの定義が増分リフレッシュに対応していない場合は、作成自体が事前に失敗するようになっています。これにより、実行時の予期しない動作を抑えることができます。
増分ダイナミックテーブルにおけるマスキングポリシーと行アクセスポリシー
金融サービス、ヘルスケア、またはその他の規制の厳しい産業の組織では、マスキングポリシーや行アクセスポリシーを使用していることでしょう。以前は、クエリ自体が増分処理の対象であっても、特定のポリシー関数ではフルリフレッシュが必要でした。
一般提供（近日予定）の開始時には、ダイナミックテーブルの所有者ロールに完全なデータアクセスを許可するすべての行アクセスポリシーまたはマスキングポリシーが、増分リフレッシュをサポートする予定です。これにより、不要なフルスキャンを回避できます。
表現力の向上：ダイナミックテーブルを使用したより高度なモデルの構築
凍結リージョン：変更されないデータのコスト支払いを停止
パイプラインに5年分の過去の注文データがあるとします。リフレッシュのたびに、Snowflakeは今後変更されない2020年の行を含め、そのすべてを再処理します。凍結リージョン（一般提供）を使用すると、どの行を凍結できるかを単純な述語で宣言できます。Snowflakeは、リフレッシュのたびに凍結された行をスキップします。新しいデータを含む変更可能なウィンドウのみが再計算されます。
CREATE DYNAMIC TABLE orders_enriched
FROZEN WHERE order_date < CURRENT_DATE() - 1
TARGET_LAG = '1 hour'
WAREHOUSE = my_warehouse
AS
SELECT o.*, c.region
FROM orders o
JOIN customers c ON o.customer_id = c.id;| メリット | 意味 |
|---|---|
| 変更分のみの支払い | リフレッシュのたびに凍結された行はスキップされる |
| 削除の無視 | ソース行を削除しても、凍結された出力には伝播しない |
| ディメンションの安定性 | ディメンションが変更されても、凍結された結合結果は再計算されない |
| フルリフレッシュのコスト削減 | 凍結リージョンを持つフルリフレッシュのダイナミックテーブルは、履歴データに対して増分リフレッシュのように機能する |
| クエリの進化 | クエリを進化させる際、新しい行のみが再計算される |
バックフィル：再処理なしの移行
新しいパイプラインを構築する際、すでに何年分ものクリーンな履歴データが存在する場合があります。BACKFILL FROMは、再計算を行うことなく、既存のデータを凍結リージョンに直接ゼロコピークローンします（一般提供）。
CREATE DYNAMIC TABLE new_pipeline_table
FROZEN WHERE event_date < CURRENT_DATE()
BACKFILL FROM existing_historical_table
TARGET_LAG = '1 hour'
WAREHOUSE = my_warehouse
AS
SELECT * FROM raw_events;何年分ものデータを再処理することなく、既存のパイプラインを数時間ではなく数分でダイナミックテーブルに移行できます。したがって、履歴データがある場合は、最初から凍結リージョンを使用することを強くお勧めします。また、履歴データへの変更をキャッチアップしたい、あるいは特定の行を削除するというGDPRのユースケースがあるというお客様の声も時折耳にします。これにより、再計算のコストをかけることなく、これらの凍結リージョンに対してDMLコマンドを使用し、ダイナミックテーブルを最新の状態に保つことができます。
ストレージライフサイクルポリシー：生データを期限切れにし、集計データを保持
生のイベントデータには有効期限があります。ホットなパイプラインテーブルに3年分の生ログを保持しておく必要はありません。しかし、ダウンストリームの集計を壊すことなくデータをパージすることは、それ自体がエンジニアリングプロジェクトになりかねません。
ストレージライフサイクルポリシー（一般提供）を使用すると、単一の句で保持ルールを適用できます。行はリフレッシュとは無関係に、独自のスケジュールで自動的に期限切れになります。カスタムジョブは不要です。DELETEステートメントも不要です。パージされたデータを誤って再処理するリスクもありません。
リフレッシュ境界：独立したパイプラインの実行
デフォルトでは、パイプライン内のダイナミックテーブルはスナップショット分離を共有し、すべてのリフレッシュが同期され、同じ時点から読み取られます。これは一貫性を保つうえで非常に優れています。しかし、独立性が必要になる場合もあります。
リフレッシュ境界（一般提供）を使用すると、ダイナミックテーブル → ビュー → ダイナミックテーブルのパターンを含む有向非巡回グラフ（DAG）にソフトブレークを挿入し、サブパイプラインを独自の鮮度スケジュールで運用できるようになります。
| ユースケース | メリット |
|---|---|
| 変化の遅いディメンション | 製品カタログや地理情報のルックアップが、変化の速い注文パイプラインをブロックしない |
| チーム間のパイプライン | チームAの障害がチームBに波及しない |
| データ共有 | 制御できない可能性のあるデータプロバイダーとは無関係に、独自のリフレッシュスケジュールを制御できる |
カスタム増分ダイナミックテーブル
パイプラインで、複雑なMERGEロジック、ストリームと静的テーブルの結合、論理削除、または実行アキュムレータが必要になる場合があります。標準的なSELECTベースのダイナミックテーブルでは、これを常に適切に表現できるとは限りませんが、マネージドなスケジューリング、再試行、監視は引き続き必要です。
カスタム増分ダイナミックテーブル（近日中に一般提供）により、SELECTのみの戦略から、SELECT / MERGE / INSERT戦略へと移行できます。命令型バッチ処理のパフォーマンスと制御を犠牲にすることなく、包括的な表現力を得ることができます。同時に、Snowflakeが引き続き実行（マネージドなスケジューリング、依存関係の追跡、オブザーバビリティ、レプリケーション）を制御します。
CREATE DYNAMIC TABLE order_enriched
REFRESH_MODE = INCREMENTAL
TARGET_LAG = '5 minutes'
WAREHOUSE = my_warehouse
AS
MERGE INTO order_enriched t
USING (
SELECT s.order_id, s.amount, d.region
FROM orders_stream s
JOIN dim_customers d ON s.customer_id = d.id
) src ON t.order_id = src.order_id
WHEN MATCHED THEN UPDATE SET
t.amount = src.amount, t.region = src.region
WHEN NOT MATCHED THEN INSERT
(order_id, amount, region) VALUES (src.order_id, src.amount, src.region);カスタム増分処理を備えたダイナミックテーブルは、同じパイプライン内で標準的なSELECTベースのダイナミックテーブルと組み合わせることができます。一般的なユースケースは以下のとおりです。
| パターン | CI-DTタイプ |
|---|---|
| ディメンションのルックアップと削除の伝播を伴うCDCエンリッチメント | MERGE |
| Top-Kリーダーボードの維持 | MERGE |
| 追記専用のストリームと静的テーブルの結合によるエンリッチメント | INSERT |
| タスクとストリームからの移行 | MERGEまたはINSERT |
相互運用性
ダイナミックテーブル向けのCoCoスキル
パイプラインのデバッグで、リフレッシュ履歴ログを1行ずつ読み進める必要はありません。Snowflake CoCoの新しいダイナミックテーブルスキルにより、IDE内で直接、ダイナミックテーブルの作成、最適化、監視、トラブルシューティングに関する専門的なガイダンスを得ることができます。
目標を説明し、ダイナミックテーブルについて言及すると、スキルが呼び出されます。リフレッシュの失敗、ラグのチューニング、パイプラインの設計、パフォーマンスの最適化に関するサポートを迅速に受けることができます。
Apache Icebergの互換性
ダイナミックテーブルは、パイプラインの両端でApache Icebergと包括的な互換性を備えています。
| ユースケース | ダイナミックテーブルでできること |
|---|---|
| Apache Icebergからの読み取り | 外部で管理されるIceberg v2テーブルをソースとして使用する。ここでは、PRIMARY KEY RELY制約により、更新や削除のパフォーマンスが大幅に向上する |
| Apache Icebergへの書き込み | Snowflakeマネージドの外部ストレージにIceberg形式で出力するダイナミックIcebergテーブルを作成し、Apache Spark™、Trino、その他のエンジンから直接読み取ることができるようにする。 |
オープンフォーマットの出力で、同じリフレッシュモード、同じスケジューリング、同じパイプラインセマンティクスを利用できます。
Wolt（DoorDashグループ）ではApache Icebergを標準採用しており、各ワークロードを最適なエンジンで柔軟に実行できる環境を整えています。私たちのデータレイクにおけるデータの拡充、準備、および自動リフレッシュには、SnowflakeのダイナミックIcebergテーブルを活用しています。目標とするデータの鮮度を指定してクエリを1つ定義するだけで、増分の更新やオーケストレーションはすべてSnowflakeが管理してくれます。Apache Iceberg上でダイナミックテーブルを活用することで、パイプラインの立ち上げが迅速化し、メンテナンス時間が短縮されたほか、インクリメンタルなパイプラインの運用負荷も削減されました」
—Raimund Kämmerer氏
dbtマテリアライゼーションとしてのダイナミックテーブル
継続的なリフレッシュを必要としないチームもあります。そのようなチームは、午前5時にデータが準備されている必要があったり、dbtやAirflowからパイプラインを駆動したりしています。このようなケースでは、TARGET_LAGはうまく機能しません。
新しいスケジューラー機能：
- 外部でオーケストレーションされるパイプラインのスケジューラーを無効化
- Snowflakeデータベース変更管理（DCM）プロジェクトでの同期リフレッシュのサポート
dbtとダイナミックテーブル：連携によるメリット
dbtはエンジニアリングワークフローを処理します。ダイナミックテーブルはデータの鮮度を管理します。これらを組み合わせることで、パイプラインの規律とパフォーマンスのトレードオフを解消できます。
この統合は、そのまま置き換えることが可能です：ほとんどのdbtモデルは、すでにCTASステートメントになっています。ロジックを書き換えることなく、それらをダイナミックテーブルに変換できます。完全なdbtリネージグラフ、テストスイート、ドキュメントを維持しながら、変更されていないソースを自動的にスキップする動作を利用できます：
- 既存のモデルを直接変換するためのロジックの書き換えが不要
- Snowflakeが変更されていないソースを特定し、リフレッシュを自動的にスキップする
- 完全なdbtリネージ、テスト、ドキュメントが保持される
この強力な組み合わせの詳細については、こちらのブログをご覧ください。
パイプラインにもたらす意味
これらの更新から、明確なメッセージが読み取れます。ダイナミックテーブルを使用すれば、複雑さを増すことなく、より多くの制御が可能になります。以下のことが可能になりました。
- 複雑なロジックを必要とする変換に
MERGEとINSERTを使用する - dbtとGitでダイナミックテーブルを管理する
- データレイクの相互運用性のために、結果をIceberg形式で保存する
- Cortex AI関数を使用してインラインでデータを強化する
- ローリングウィンドウのために現在時刻でフィルタリングする
- スキーマを自動的に進化させる
- パイプラインの構築とデバッグにおいてAIの支援を受ける
- Gen2ウェアハウスでリフレッシュをより高速に実行する
使用を開始する
以下を参照して新しい機能を今すぐお試しください。
すでにダイナミックテーブルを実行している場合は、ウェアハウスをGen2にアップグレードして、その違いを測定してみてください。オーケストレーションの複雑さや表現力のギャップを理由に導入を控えていた場合、そのような障壁はすでに解消されています。
将来予想に関する記述
本コンテンツには、当社の将来の製品提供に関するものを含め、将来予想に関する記述が含まれていますが、いかなる製品の提供をお約束するものでもありません。実際の成果や提供内容は異なる可能性があり、既知および未知のリスクおよび不確実性の影響を受けます。詳細については、最新の四半期報告書（10-Q）をご覧ください。
