動的テーブルのターゲット・ラグの理解¶
動的なテーブルの更新は、データの ターゲット・ラグ によってトリガーされます。固定のターゲット・ラグをセットするか、動的テーブルを DOWNSTREAM にセットして、その更新タイミングをそれに依存する他の動的テーブルに依存させることができます。
動的テーブルのターゲット・ラグは、直接上流の動的テーブルではなく、グラフのルートの動的テーブルを基準として測定されます。動的テーブルに接続されているテーブルのグラフを見るには、 動的テーブルに接続されたテーブルのグラフ表示 をご参照ください。
Snowflakeは、動的テーブルの実際のラグをターゲットラグ以下に保つようにリフレッシュをスケジュールします。各リフレッシュの所要時間は、クエリ、データパターン、ウェアハウスサイズによって異なります。ターゲットラグを選択する際には、ルートへ チェーンの動的テーブル をそれぞれリフレッシュするのに必要な時間を考慮してください。そうしないと、一部のリフレッシュがスキップされ、実際のラグが大きくなる可能性があります。
注釈
ターゲットラグは保証ではありません。代わりに、Snowflakeが達成を目指すターゲットです。動的テーブルのデータは、ターゲットラグの範囲内で可能な限りリフレッシュされます。しかし、ウェアハウスのサイズ、データサイズ、クエリの複雑さ、および類似の要因などのために、ターゲットラグを超える可能性があります。
ターゲット・ラグのタイプ¶
ターゲットラグは以下のいずれかの方法で指定します。ターゲットラグは、動的テーブルのリフレッシュ頻度に反比例します。
鮮度の測定: テーブルのコンテンツがベーステーブルの更新から遅れる最大時間を定義します。
以下の例では、
my_dynamic_table
を、1時間ごとにリフレッシュし、鮮度を維持するようにセットしています。ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = '1 hour';ダウンストリーム: 他の依存関係の動的テーブルが更新されるときに、その動的テーブルがオンデマンドで更新されるように指定します。このリフレッシュは、 作成時の初期化、 手動リフレッシュ、 下流動的テーブルのスケジュール・リフレッシュ によってトリガーされます。
以下の例では、
my_dynamic_table
が、ダウンストリームの動的テーブルのターゲット・ラグに基づいてリフレッシュするようにセットされています。my_dynamic_table
に依存する動的テーブルがない場合、リフレッシュされません。ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = DOWNSTREAM;
動的テーブルの最適ターゲットラグの決定¶
設定したターゲット・ラグは、動的テーブルの スケジュール・リフレッシュ の頻度に影響します。
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
)
);
出力は、経時的なリフレッシュを反映しています。各行はリフレッシュを表します。動的テーブルが更新されるたびに新しい行が追加されます。
Snowsight にサインインします。
ナビゲーションで、 Monitoring » Dynamic Tables を選択し、 Refresh History タブを選択します。
Lag Metrics から、最大ラグタイムを確認してください。このメトリックは、各リフレッシュの実際のラグタイムに基づいています。
ターゲットラグの変更¶
以下のような理由で、動的テーブルのターゲット・ラグを調整したい場合があります。
もっと最新のデータが必要です。ターゲット・ラグを減らすことで、動的テーブルの更新頻度を高め、よりリアルタイムに近い新鮮なデータをプロバイダーが提供できるようになります。
リソースを最適化したいとします。ターゲットラグを大きくすることで、リフレッシュの頻度を減らし、コンピューティングリソースを節約することができます。これは、常時更新を必要としないワークロードや、データが頻繁に変更されないワークロードに有効です。たとえば、動的テーブルが20分ごとに更新されるが、ソース・テーブルから1時間以内であればよい場合、1時間のターゲット・ラグをセットすることでコストを削減できます。
ターゲットラグをデータパイプラインと一致させたいとします。動的テーブルが、更新間隔が長い他のテーブルに依存している場合、ターゲット・ラグを調整することで、依存関係との整合性を確保できます。
ターゲットラグを変更するには、 ALTER DYNAMIC TABLE コマンドを使用します。詳細については、 動的テーブルのウェアハウスまたはターゲット・ラグの変更 をご参照ください。
上流と下流の関係がターゲット・ラグに与える影響¶
以下の図は、中断、再開、および手動リフレッシュの操作を他の動的テーブルとの上流と下流の関係で表しています。

この図は、動的テーブルで構築されたシンプルな宣言型データパイプラインを示しています。
DT2
は、そのダイナミックテーブルに依存しているため、DT1
の ダウンストリーム として記述され、それに依存しているDT3
の アップストリーム として記述されます。DT3
は、DT2
とDT1
の両方の下流にあります。これは、DT2
に直接依存し、DT1
に間接的に依存するためです。DT1
は他の動的テーブルの直接的または間接的な上流にあります。
例: 動的テーブル・チェーンのターゲット・ラグ¶
動的テーブル (DT2
) が、別の動的テーブル (DT1
) から内容を読み込んで実体化する次の例を考えてみましょう。このシナリオでは、レポートはクエリを介して DT2
のデータを消費します。

各動的テーブルがラグをどのように指定するかによって、次のような結果が考えられます。
|
|
リフレッシュの結果 |
---|---|---|
|
|
|
|
|
このシナリオは避ける必要があります。レポートクエリはデータを受け取りません。DT1 は頻繁に更新され、 |
|
|
|
|
|
|