動的テーブルのターゲット・ラグの理解¶

ターゲット・ラグのタイプ¶

次のいずれかの方法でターゲットラグを指定します。ターゲットラグは、動的テーブルのリフレッシュ頻度に反比例します。

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

   以下の例では、 my_dynamic_table を、1時間ごとにリフレッシュし、鮮度を維持するようにセットしています。

   ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = '1 hour';
   

   Copy

2. 下流 ：下流テーブル（このテーブルに依存するテーブル）がリフレッシュされる時に、動的テーブルがオンデマンドでリフレッシュされるように指定します。この更新は下流テーブルの 作成時の初期化 、 手動リフレッシュ または スケジュールされた更新 によってトリガーされます。

   refresh_mode が downstream に設定されているとき、動的テーブルのリフレッシュスケジュールは、その下流の依存関係の最も要求の厳しい（短い）ラグによって駆動されます。たとえば、ある下流の依存テーブルが10分以上経過していないデータを必要とし、別の下流の依存テーブルが1時間以上経過していないデータを必要とする場合、この動的テーブルのリフレッシュスケジュールは10分ごとになります。これが下流の依存関係の最小のラグであるためです。

   以下の例では、 my_dynamic_table が、ダウンストリームの動的テーブルのターゲット・ラグに基づいてリフレッシュするようにセットされています。my_dynamic_table に依存する動的テーブルがない場合、リフレッシュされません。

   ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = DOWNSTREAM;
   

   Copy

   下流ターゲットラグの例については、 例：動的テーブルチェーンのターゲットラグ をご参照ください。

Snowflakeがリフレッシュをスケジュールする方法¶

Snowflakeでは、リフレッシュが完了するまでの時間を確保するため、リフレッシュのスケジュールをターゲットラグより少し早めに設定しています。たとえば、ターゲットラグを5分に設定した場合、テーブルは5分ごとよりも頻繁にリフレッシュされる可能性があります。実際のリフレッシュ間隔は、指定されたラグよりも短くなる場合が多いです。

ワークロードに合わせてターゲットラグを調整する際のガイダンスについては、 動的テーブルのウェアハウスまたはターゲット・ラグの変更 をご参照ください。ターゲットラグの最適化については、 適切なターゲットラグの特定 をご参照ください。

上流と下流の関係がターゲット・ラグに与える影響¶

以下の図は、中断、再開、および手動リフレッシュの操作を他の動的テーブルとの上流と下流の関係で表しています。

この図は、動的テーブルで構築されたシンプルな宣言型データパイプラインを示しています。

• DT2 は、そのダイナミックテーブルに依存しているため、 DT1 の ダウンストリーム として記述され、それに依存している DT3 の アップストリーム として記述されます。

• DT3 は、 DT2 と DT1 の両方の下流にあります。これは、 DT2 に直接依存し、 DT1 に間接的に依存するためです。

• DT1 は他の動的テーブルの直接的または間接的な上流にあります。

例：動的テーブルチェーンのターゲットラグ¶

動的テーブル (DT2) が、別の動的テーブル (DT1) から内容を読み込んで実体化する次の例を考えてみましょう。このシナリオでは、レポートはクエリを介して DT2 のデータを消費します。

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