動的テーブルリフレッシュについて¶

動的テーブルのコンテンツは、特定のクエリの結果に基づいています。動的テーブルの基となるデータが変更されると、その変更を反映してテーブルが更新されます。これらの更新はリフレッシュと呼ばれます。このプロセスは自動化されており、テーブルの基礎となるクエリを分析します。次のセクションでは、動的テーブルがどのようにリフレッシュされるのか、また、動的テーブルの SELECT ステートメントによって使用されるリフレッシュの型がどのように決定されるのかを説明します。

動的テーブルの初期化¶

CREATE DYNAMIC TABLE ステートメントを使用して動的テーブルが作成されると、動的テーブルには、最初に基礎となるテーブルからのデータが入力されます。作成後、ダウンストリームラグのある動的テーブルを含め、動的テーブルは完全にリフレッシュされます。リフレッシュはスナップショットの分離を保証し、関係するすべての動的テーブルを同期させ、上流の動的テーブルのデータリフレッシュは行わずにコストを削減します。

この初期リフレッシュでは、特に広範なデータのスキャンが必要な場合に時間がかかることがあり、動的テーブルの作成時間はスキャンされたデータのサイズに依存します。進捗状況を確認するには、 information_schema.dynamic_table_refresh_history() を使用してリフレッシュ履歴をクエリし、 refresh_trigger = INITIAL のエントリを探します。

初期化に失敗した場合、テーブル作成プロセスは停止し、不正確な定義について即座にフィードバックされます。既存の動的テーブルの新バージョンの初期化中は、新バージョンが利用可能になるまで既存バージョンはアクセス可能なままであるため、新バージョンの作成に失敗しても現在のインスタンスには影響しません。

動的テーブルのリフレッシュの型¶

動的テーブルリフレッシュプロセスは、次の2つの方法のいずれかで動作します。

増分リフレッシュ: この自動化されたプロセスでは、動的テーブルのクエリを分析し、前回のリフレッシュからの変更点を計算します。そして、これらの変更をテーブルにマージします。サポートされるクエリの詳細については、増分リフレッシュをサポートするクエリの型をご参照ください。

フルリフレッシュ: 自動プロセスが増分リフレッシュを実行できない場合、フルリフレッシュを実行します。これには、動的テーブルのクエリを実行し、以前の具体化された結果を完全に置き換えることが含まれます。

クエリで使用されるコンストラクトは、増分リフレッシュが使用できるかどうかを決定します。動的テーブルを作成した後、テーブルをモニターして、そのテーブルのリフレッシュに増分リフレッシュまたはフルリフレッシュが使用されているかどうかを判断することができます。

ターゲットラグについて¶

動的テーブルのリフレッシュは、データの古さの度合い、またはラグまたはターゲットラグと一般的に呼ばれるものに基づいてトリガーされます。

ターゲットラグは2つの方法のいずれかで指定します。

鮮度の指標: テーブルのコンテンツがベーステーブルの更新から遅れる最大時間を定義します。

動的テーブルを変更または最初に定義するときに、 TARGET_LAG = { num { seconds | ... | days } パラメーターを使用して指定されます。

DOWNSTREAM: 動的テーブルに依存する他の動的テーブルのリフレッシュが必要な場合に、動的テーブルをオンデマンドでリフレッシュすることを指定します。更新は、上流のデータベースオブジェクトから推測されます。下流の動的テーブルは、上流のコンシューマーがリクエストした場合にのみ更新されます。

動的テーブル1（DT1）に基づいて動的テーブル2（DT2）が定義されている場合を考えてみましょう。DT2は、 DT1 から読み取り、そのコンテンツを具体化する必要があります。さらに、レポートはクエリを介して DT2 データを消費します。

Simple example of two dynamic tables, DT2 which is defined based on DT1.

各動的テーブルがラグをどのように指定するかによって、次のような結果が考えられます。

動的テーブル1（DT1）	動的テーブル2（DT2）	リフレッシュの結果
`TARGET_LAG = DOWNSTREAM`	`TARGET_LAG = 10minutes`	DT2 は最大10分ごとに更新されます。DT1 は、ラグを DT2 から取得するか推測し、 DT2 が更新をリクエストするたびに更新されます。
`TARGET_LAG = 10minutes`	`TARGET_LAG = DOWNSTREAM`	このシナリオは避ける必要があります。レポートクエリはデータを受け取りません。DT2 上には DT が構築されていないため、 DT2 はリフレッシュされません。さらに、 DT1 は頻繁にリフレッシュされます。
`TARGET_LAG = 5minutes`	`TARGET_LAG = 10minutes`	DT2 は、最大5分前の DT1 からのデータで約10分ごとに更新されます。
`TARGET_LAG = DOWNSTREAM`	`TARGET_LAG = DOWNSTREAM`	DT1 に定義されたラグを持つ下流の子がないため、 DT2 は定期的にはリフレッシュされません。

増分リフレッシュをサポートするクエリの型¶

次のテーブルでは、現在増分リフレッシュをサポートしている式、キーワード、句について説明します。

注釈

クエリが増分リフレッシュに対応していない式を使用している場合、自動リフレッシュプロセスでは代わりにフルリフレッシュが使用されます。どのリフレッシュモードが使用されるかの判断については、増分リフレッシュまたはフルリフレッシュのいずれが使用されているかの判断をご参照ください。

キーワード/句	増分リフレッシュのサポート
WITH	サブクエリで増分リフレッシュをサポートする機能を使用する共通テーブル式（CTE）。
SELECT 内の式	決定論的組み込み関数や不変ユーザー定義関数を使用した式を含む式。
FROM	ソーステーブル、ビュー、およびその他の動的テーブル。
OVER	すべてのウィンドウ関数。
WHERE	SELECT で有効な式と同じ式のフィルター。
JOIN （およびテーブルを結合するための他の式）	動的テーブルは現在、増分リフレッシュのための内部結合、外部結合、クロス結合のみをサポートしています。注釈増分リフレッシュを使用するには、他の型の結合を使用する動的テーブルを再作成する必要があります。動的テーブルを再作成する必要があるかどうかを判断するには、以下の手順のいずれかを使用して、動的テーブルがフルリフレッシュを使用しているかどうかを確認します。 SHOW DYNAMIC TABLES コマンドを実行し、テーブルの `REFRESH_MODE` 列が `FULL` かどうかを確認します。 Snowsightの動的テーブルの詳細ページで、 Full Refresh がページの一番上に表示されているかどうかを確認します。結合するテーブルはいくつでも指定できます。結合内にあるすべてのテーブルの更新はクエリの結果に反映されます。
UNION ALL	動的テーブルは、 UNION ALL をサポートします。
GROUP BY	動的テーブルは、 GROUP BY をサポートします。

重要

増分リフレッシュの動的テーブルにより使用中の不変 UDF を置き換えると、 UDF を使用する動的テーブルで未定義の動作が発生します。

現在、増分リフレッシュでは、以下のコンストラクトとクエリの型はサポートされていません。クエリでこれらを指定した場合、自動リフレッシュプロセスは、フルリフレッシュ（コストが高くなる可能性があります）を使用してテーブルをリフレッシュします。

LATERAL 結合
FROM 句外のサブクエリ（例: WHERE EXISTS）
VOLATILE ユーザー定義関数

動的テーブルが他の動的テーブルに依存している場合のデータのリフレッシュ方法¶

動的テーブルのラグが時間の尺度として指定されている場合、自動リフレッシュプロセスは、動的テーブルのターゲットラグタイムに基づいて、リフレッシュのスケジュールを決定します。このプロセスは、各テーブルのターゲットラグタイムに最適なスケジュールを選択します。

注釈

ターゲットラグは保証ではありません。代わりに、Snowflakeが達成を目指すターゲットです。動的テーブルのデータは、ターゲットラグの範囲内で可能な限りリフレッシュされます。しかし、ウェアハウスのサイズ、データサイズ、クエリの複雑さ、および類似の要因などのために、ターゲットラグを超える可能性があります。

ある動的テーブルが別の動的テーブルに依存している場合にデータの一貫性を保つために、このプロセスはアカウント内のすべての動的テーブルを互換性のあるタイミングでリフレッシュします。リフレッシュの頻度が低いタイミングは、リフレッシュの頻度が高いタイミングと一致します。

たとえば、動的テーブルAのターゲットラグが2分で、ターゲットラグが1分の動的テーブルBをクエリするとします。このプロセスでは、Aは96秒ごと、Bは48秒ごとにリフレッシュする必要があると判断される可能性があります。その結果、このプロセスは以下のスケジュールを適用する可能性があります。

特定の時点	リフレッシュされる動的テーブル
2022-12-01 00:00:00	A, B
2022-12-01 00:00:48	B
2022-12-01 00:01:36	A, B
2022-12-01 00:02:24	B

つまり、互いに依存する一連の動的テーブルをクエリするときは、いつでも、これらのテーブルにまたがるデータの同じ「スナップショット」をクエリしていることになります。

動的テーブルのターゲットラグは、それが依存する動的テーブルのターゲットラグよりも短くはできないことに注意してください。たとえば、次の場合を考慮します。

動的テーブルAが動的テーブルBとCをクエリします。
動的テーブルBのターゲットラグは5分です。
動的テーブルCのターゲットラグは1分です。

つまり、Aのターゲットラグタイムは5分より短くすることはできません（つまり、BとCのラグタイムの長い方より短くすることはできません）。

Aのラグを5分に設定した場合、プロセスは以下の目標があるリフレッシュスケジュールを設定します。

ラグが1分以下になるよう、Cを頻繁にリフレッシュします。
AとBを一緒にリフレッシュし、ラグが5分以下になるように十分な頻度でリフレッシュします。
スナップショットの分離を確実にするために、AとBのリフレッシュがCのリフレッシュと一致するようにします。

注: リフレッシュに時間がかかりすぎる場合、スケジューラーはリフレッシュをスキップして最新の状態に保とうとすることがあります。ただし、スナップショットの分離は維持されます。