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

動的テーブルのコンテンツは、特定のクエリの結果に基づいています。動的テーブルの基となるデータが変更されると、その変更を反映してテーブルが更新されます。これらの更新はリフレッシュと呼ばれます。このプロセスは自動化されており、テーブルの基礎となるクエリを分析します。

動的テーブルリフレッシュのタイムアウトは STATEMENT_TIMEOUT_IN_SECONDS パラメーターによって決定され、アカウントまたはウェアハウスが自動的にキャンセルされるまでの最大期間を定義します。

以下のセクションでは、動的テーブルリフレッシュについて詳しく説明します。

Dynamic table initialization
Dynamic table refresh types
ターゲットラグについて
増分リフレッシュでサポートされるクエリ
動的テーブルが他の動的テーブルに依存している場合のデータのリフレッシュ方法

Dynamic table refresh types¶

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

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

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

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

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

Dynamic table refresh is triggered based on how out of date the data might be, or what is commonly referred to as lag or target lag.

Target lag is specified in one of two ways:

Measure of freshness: Defines the maximum amount of time that the dynamic table's content should lag behind updates to the base tables.

Specified using the TARGET_LAG = { num { seconds | ... | days } parameter when altering or originally defining a dynamic table.

DOWNSTREAM: Specifies that the dynamic table should be refreshed on demand when other dynamic tables that depend on it need to refresh. Updates are inferred from upstream database objects. Downstream dynamic tables are only updated when required by upstream consumers.

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

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

動的テーブル1（DT1）	動的テーブル2（DT2）	リフレッシュの結果
`TARGET_LAG = DOWNSTREAM`	`TARGET_LAG = 10minutes`	DT2 is updated at most every 10 minutes. DT1 gets, or infers, its lag from DT2 and is updated every time DT2 requires updates.
`TARGET_LAG = 10minutes`	`TARGET_LAG = DOWNSTREAM`	This scenario should be avoided. The report query will not receive any data. DT2 is not refreshed as no DT is built on top of DT2. Furthermore, DT1 will be frequently refreshed.
`TARGET_LAG = 5minutes`	`TARGET_LAG = 10minutes`	DT2 is updated approximately every 10 minutes with data from DT1 that is at most 5 minutes old.
`TARGET_LAG = DOWNSTREAM`	`TARGET_LAG = DOWNSTREAM`	DT1 に定義されたラグを持つ下流の子がないため、 DT2 は定期的にはリフレッシュされません。

増分リフレッシュでサポートされるクエリ¶

次のテーブルでは、現在増分リフレッシュをサポートしている式、キーワード、句について説明します。増分リフレッシュをサポートしないクエリのリストについては、増分リフレッシュのサポートの制限をご参照ください。

キーワード/句	増分リフレッシュのサポート
WITH	サブクエリで増分リフレッシュをサポートする機能を使用する共通テーブル式（CTE）。
SELECT 内の式	決定論的組み込み関数や不変ユーザー定義関数を使用した式を含む式。
FROM	ソーステーブル、ビュー、およびその他の動的テーブル。FROM 句外のサブクエリ（例: WHERE EXISTS）はサポートされていません。
OVER	すべてのウィンドウ関数。
WHERE/HAVING/QUALIFY	SELECT で有効な式と同じ式のフィルター。
JOIN （およびテーブルを結合するための他の式）	増分リフレッシュでサポートされる結合型には、内部結合、外部等価結合、クロス結合があります。結合するテーブルはいくつでも指定でき、結合内にあるすべてのテーブルの更新はクエリの結果に反映されます。
UNION ALL	動的テーブルは、 UNION ALL をサポートします。
GROUP BY	動的テーブルは、 GROUP BY をサポートします。

重要

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

増分リフレッシュを使用する動的テーブルで使用中の IMMUTABLE ユーザー定義関数（UDF）を置き換えると、そのテーブルで未定義の動作が発生します。VOLATILE UDFs は増分リフレッシュではサポートされていません。

フルリフレッシュでサポートされる非決定性関数¶

動的テーブルでは、以下の非決定性関数がサポートされています。これらの関数はフルリフレッシュでのみサポートされていることに注意してください。増分リフレッシュでサポートされない内容のリストについては、増分リフレッシュのサポートに関する制限をご参照ください。

VOLATILE ユーザー定義関数
シーケンス関数（例: SEQ1、 SEQ2）
以下のコンテキスト機能:
以下の日時関数（それぞれのエイリアスと合わせて）:

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

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

注釈

ターゲットラグは保証ではありません。代わりに、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のリフレッシュと一致するようにします。

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