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

動的なテーブルの更新は、データのターゲット・ラグによってトリガーされます。固定のターゲット・ラグをセットするか、動的テーブルを DOWNSTREAM にセットして、その更新タイミングをそれに依存する他の動的テーブルに依存させることができます。

動的テーブルのターゲット・ラグは、直接上流の動的テーブルではなく、グラフのルートの動的テーブルを基準として測定されます。動的テーブルに接続されているテーブルのグラフを見るには、動的テーブルに接続されたテーブルのグラフ表示をご参照ください。

Snowflakeは、動的テーブルの実際のラグをターゲットラグ以下に保つようにリフレッシュをスケジュールします。各リフレッシュの所要時間は、クエリ、データパターン、ウェアハウスサイズによって異なります。ターゲットラグを選択する際には、ルートへチェーンの動的テーブルをそれぞれリフレッシュするのに必要な時間を考慮してください。そうしないと、一部のリフレッシュがスキップされ、実際のラグが大きくなる可能性があります。

注釈

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

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

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

鮮度の測定: テーブルのコンテンツがベーステーブルの更新から遅れる最大時間を定義します。
以下の例では、 my_dynamic_table を、1時間ごとにリフレッシュし、鮮度を維持するようにセットしています。
ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = '1 hour';
Copy
ダウンストリーム: 他の依存関係の動的テーブルが更新されるときに、その動的テーブルがオンデマンドで更新されるように指定します。このリフレッシュは、作成時の初期化、手動リフレッシュ、下流動的テーブルのスケジュール・リフレッシュによってトリガーされます。

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

動的テーブルの最適ターゲットラグの決定¶

設定したターゲット・ラグは、動的テーブルのスケジュール・リフレッシュの頻度に影響します。

Snowflakeでは、リフレッシュが完了するまでの時間を確保するため、リフレッシュのスケジュールを少し早めに設定しています。たとえば、ターゲット・ラグを5分にセットしても、テーブルが正確に5分ごとに更新されるわけではありません。実際の更新間隔は、指定されたラグよりも短くなる可能性があります。5分間のリフレッシュをより安定させたい場合は、ターゲットラグを少し大きくすることを検討してください。

INFORMATION_SCHEMA または Snowsight の DYNAMIC_TABLE_REFRESH_HISTORY テーブル関数を使用して、要件に応じた最適なターゲットタイムラグを決定できます。例えば、リフレッシュ期間やスキップされたリフレッシュを含むリフレッシュの詳細を分析し、十分な情報に基づいた意思決定を行うことができます。

動的テーブル・リフレッシュの監視とトラブルシューティングの情報については、動的テーブルをモニターするおよび動的テーブルのリフレッシュに関する一般的な問題の診断を参照してください。

DYNAMIC_TABLE_REFRESH_HISTORY 関数は、リフレッシュにかかった時間やスキップされたリフレッシュなど、動的テーブルの各リフレッシュに関する情報を返します。

SELECT
    name
FROM
  TABLE (
    INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY (
      NAME_PREFIX => 'MYDB.MYSCHEMA.', ERROR_ONLY => TRUE
    )
  );

Copy

出力は、経時的なリフレッシュを反映しています。各行はリフレッシュを表します。動的テーブルが更新されるたびに新しい行が追加されます。

ターゲットラグの変更¶

以下のような理由で、動的テーブルのターゲット・ラグを調整したい場合があります。

もっと最新のデータが必要です。ターゲット・ラグを減らすことで、動的テーブルの更新頻度を高め、よりリアルタイムに近い新鮮なデータをプロバイダーが提供できるようになります。
リソースを最適化したいとします。ターゲットラグを大きくすることで、リフレッシュの頻度を減らし、コンピューティングリソースを節約することができます。これは、常時更新を必要としないワークロードや、データが頻繁に変更されないワークロードに有効です。たとえば、動的テーブルが20分ごとに更新されるが、ソース・テーブルから1時間以内であればよい場合、1時間のターゲット・ラグをセットすることでコストを削減できます。
ターゲットラグをデータパイプラインと一致させたいとします。動的テーブルが、更新間隔が長い他のテーブルに依存している場合、ターゲット・ラグを調整することで、依存関係との整合性を確保できます。

ターゲットラグを変更するには、 ALTER DYNAMIC TABLE コマンドを使用します。詳細については、動的テーブルのウェアハウスまたはターゲット・ラグの変更をご参照ください。

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

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

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

DT2 は、そのダイナミックテーブルに依存しているため、 DT1 の ダウンストリーム として記述され、それに依存している DT3 の アップストリーム として記述されます。
DT3 は、 DT2 と DT1 の両方の下流にあります。これは、 DT2 に直接依存し、 DT1 に間接的に依存するためです。
DT1 は他の動的テーブルの直接的または間接的な上流にあります。

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

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

2つの動的テーブルの簡単な例: DT2 は DT1 に基づいて定義されています。

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

`DT1`	`DT2`	リフレッシュの結果
`TARGET_LAG = DOWNSTREAM`	`TARGET_LAG = 10minutes`	`DT2` は少なくとも毎10分ごとに更新されます。 `DT1` はラグを `DT2` から推測し、 `DT2` が更新を要求するたびに更新されます。
`TARGET_LAG = 10minutes`	`TARGET_LAG = DOWNSTREAM`	このシナリオは避ける必要があります。レポートクエリはデータを受け取りません。DT1 は頻繁に更新され、 `DT2` は更新されません。なぜなら、 `DT2` をベースとするダイナミックテーブルがないからです。
`TARGET_LAG = 5minutes`	`TARGET_LAG = 10minutes`	`DT2` は、最大5分前の `DT1` からのデータで約10分ごとに更新されます。
`TARGET_LAG = DOWNSTREAM`	`TARGET_LAG = DOWNSTREAM`	`DT1` も `DT2` も、どちらもダウンストリームラグがあるため、定期的にリフレッシュされることはありません。また、ラグが定義されたダウンストリームコンシューマーもありません。