動的テーブルリフレッシュについて¶
動的テーブルのコンテンツは、特定のクエリの結果に基づいています。動的テーブルの基となるデータが変更されると、その変更を反映してテーブルが更新されます。これらの更新は リフレッシュ と呼ばれます。このプロセスは自動化されており、テーブルの基礎となるクエリを分析します。
動的テーブルリフレッシュのタイムアウトは STATEMENT_TIMEOUT_IN_SECONDS パラメーターによって決定され、アカウントまたはウェアハウスが自動的にキャンセルされるまでの最大期間を定義します。
以下のセクションでは、動的テーブルリフレッシュについて詳しく説明します。
動的テーブルのリフレッシュの型¶
動的テーブルリフレッシュプロセスは、次の2つの方法のいずれかで動作します。
増分リフレッシュ: この自動化されたプロセスでは、動的テーブルのクエリを分析し、前回のリフレッシュからの変更点を計算します。そして、これらの変更をテーブルにマージします。サポートされるクエリの詳細については、 増分リフレッシュでサポートされるクエリ をご参照ください。
フルリフレッシュ: 自動プロセスが増分リフレッシュを実行できない場合、フルリフレッシュを実行します。これには、動的テーブルのクエリを実行し、以前の具体化された結果を完全に置き換えることが含まれます。
クエリで使用されるコンストラクトは、増分リフレッシュが使用できるかどうかを決定します。動的テーブルを作成した後、 テーブルをモニター して、そのテーブルのリフレッシュに増分リフレッシュまたはフルリフレッシュが使用されているかどうかを判断することができます。
ターゲットラグについて¶
動的テーブルのリフレッシュは、データの古さの度合い、または ラグ または ターゲットラグ と一般的に呼ばれるものに基づいてトリガーされます。
ターゲットラグは2つの方法のいずれかで指定します。
鮮度の指標: テーブルのコンテンツがベーステーブルの更新から遅れる最大時間を定義します。
動的テーブルを変更または最初に定義するときに、
TARGET_LAG = { num { seconds | ... | days }パラメーターを使用して指定されます。DOWNSTREAM: 動的テーブルに依存する他の動的テーブルのリフレッシュが必要な場合に、動的テーブルをオンデマンドでリフレッシュすることを指定します。更新は、上流のデータベースオブジェクトから 推測 されます。下流の動的テーブルは、上流のコンシューマーがリクエストした場合にのみ更新されます。
動的テーブル1（DT1）に基づいて動的テーブル2（DT2）が定義されている場合を考えてみましょう。DT2は、 DT1 から読み取り、そのコンテンツを具体化する必要があります。さらに、レポートはクエリを介して DT2 データを消費します。
各動的テーブルがラグをどのように指定するかによって、次のような結果が考えられます。
動的テーブル1（DT1） |
動的テーブル2（DT2） |
リフレッシュの結果 |
|---|---|---|
|
|
DT2 は最大10分ごとに更新されます。DT1 は、ラグを DT2 から取得するか 推測 し、 DT2 が更新をリクエストするたびに更新されます。 |
|
|
このシナリオは避ける必要があります。レポートクエリはデータを受け取りません。DT2 上には DT が構築されていないため、 DT2 はリフレッシュされません。さらに、 DT1 は頻繁にリフレッシュされます。 |
|
|
DT2 は、最大5分前の DT1 からのデータで約10分ごとに更新されます。 |
|
|
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 は増分リフレッシュではサポートされていません。
フルリフレッシュでサポートされる非決定性関数¶
動的テーブルでは、以下の非決定性関数がサポートされています。これらの関数はフルリフレッシュでのみサポートされていることに注意してください。増分リフレッシュでサポートされない内容のリストについては、 増分リフレッシュのサポートに関する制限 をご参照ください。
動的テーブルが他の動的テーブルに依存している場合のデータのリフレッシュ方法¶
動的テーブルのラグが時間の尺度として指定されている場合、自動リフレッシュプロセスは、動的テーブルのターゲットラグタイムに基づいて、リフレッシュのスケジュールを決定します。このプロセスは、各テーブルのターゲットラグタイムに最適なスケジュールを選択します。
注釈
ターゲットラグは保証ではありません。代わりに、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のリフレッシュと一致するようにします。
注: リフレッシュに時間がかかりすぎる場合、スケジューラーはリフレッシュをスキップして最新の状態に保とうとすることがあります。ただし、スナップショットの分離は維持されます。