動的なテーブルの初期化とリフレッシュの理解¶

動的テーブル初期化の理解¶

動的テーブルを作成した 場合、最初のリフレッシュは作成時に同期的に行われるか、スケジュールされた時刻に行われます。初期データ入力、つまり 初期化 は、この初期リフレッシュがいつ発生するかによって決まります。

動的テーブルは、指定された ターゲット・ラグ に基づいて更新されます。これは、ベーステーブルの更新と動的テーブルのコンテンツとの間に許容される最大遅延をセットします。 INITIALIZE = ON_CREATE (デフォルト) をセットすると、テーブルはすぐに初期化されます。 INITIALIZE = ON_SCHEDULE をセットした場合、初期化は指定したターゲットラグタイムフレーム内で行われます。

例えば、ターゲット・ラグが30分の動的テーブル、 DT1 を考えてみましょう。 DT1 の初期データ入力は次のようになります。

• DT1 が作成時に同期的にリフレッシュするようにセットされている場合 (ON_CREATE)、作成時に初期化されます。

• DT1 がスケジュール時間 (ON_SCHEDULE) にリフレッシュするようにセットされている場合、30分以内に初期化されます。

下流に依存関係があるシナリオでは、リフレッシュの動作は依存関係に依存します。たとえば、動的テーブル DT1 に ダウンストリーム のターゲット・ラグがあり、 DT1 に依存する DT2 に30分のターゲット・ラグがある場合、 DT2 がリフレッシュされたときにのみ、 DT1 がリフレッシュされます。

DT1 の場合:

• 作成時に同期的に更新するようにセットすると、すぐに初期化されます。初期化に失敗した場合は、作成プロセスが停止し、エラーに関するフィードバックが即座に提供されます。

• スケジュールされた時間にリフレッシュするようにセットされている場合、初期化は DT2 がリフレッシュする時間に依存します。

スキャンされるデータの量に応じて、初期化に時間がかかる場合があります。進捗状況については、 動的テーブル作成のトラブルシューティング を参照してください。

手動およびスケジュール更新オプションの理解¶

動的テーブルは、 ターゲットラグ によって決定されるスケジュールでリフレッシュされます。動的テーブルが読み込まれるたびに、データの鮮度はターゲット・ラグで定義された期間内になります。

ALTER DYNAMIC TABLE ... REFRESH コマンドまたは Snowsight ... を使用して、動的テーブルを手動でリフレッシュし、最新のデータを取得することができます。詳細については、 動的テーブルの手動更新 をご参照ください。

動的テーブル更新のタイムアウトは、 STATEMENT_TIMEOUT_IN_SECONDS パラメーターによって制御されます。このパラメーターは、アカウントまたはウェアハウスレベルで、更新が自動的にキャンセルされるまでの最大許容期間をセットします。

CREATE TASK my_task
  SCHEDULE = 'USING CRON <expr> <time_zone>'
  AS
    ALTER DYNAMIC TABLE my_dynamic_table REFRESH;

動的テーブルのリフレッシュモード¶

動的テーブルは、インクリメンタルとフルという2つのリフレッシュ・モードをサポートしています。リフレッシュモードは AUTO 、または明示的にセットすることができます。

• AUTO リフレッシュ・モード: AUTO パラメーターを使用すると、Snowflake はクエリの複雑さ、サポートされる構造、演算子、関数、および期待されるパフォーマンスに基づいて、最もコストと時間の効率に優れたリフレッシュモードを自動的に選択します。インクリメンタルリフレッシュがサポートされていない場合、またはパフォーマンスが低下する可能性がある場合、Snowflakeは自動的にフルリフレッシュを選択します。

• インクリメンタル・リフレッシュ・モード: このモードでは、動的テーブルのクエリを分析し、前回のリフレッシュからの変更点を計算します。そして、これらの変更をテーブルにマージします。

• フル・リフレッシュ・モード: このモードでは、動的テーブルのクエリを実行し、以前にマテリアライズされた結果を完全に置き換えます。

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

SHOW DYNAMIC TABLES;

動的テーブルが他の動的テーブルに依存する場合のデータの更新方法¶

動的テーブルのラグが時間指標としてセットされている場合、自動リフレッシュ・プロセスは、ターゲット・ラグ時間を満たすようにリフレッシュをスケジュールします。

ある動的テーブルが別の動的テーブルに依存 している場合にデータの一貫性を保つために、このプロセスはアカウント内のすべての動的テーブルを互換性のあるタイミングでリフレッシュします。リフレッシュの頻度が低いタイミングは、リフレッシュの頻度が高いタイミングと一致します。リフレッシュに時間がかかりすぎる場合、スケジューラーはリフレッシュをスキップして最新の状態に保とうとするかもしれません。ただし、スナップショットの分離は維持されます。

例えば、動的テーブル DT1 のターゲット・ラグは2分で、動的テーブル DT2 、ターゲット・ラグは1分であるとします。このプロセスでは、 DT1 は96秒ごとに、 DT2 は48秒ごとにリフレッシュされるべきだと判断されるかもしれません。その結果、このプロセスは以下のスケジュールを適用する可能性があります。

つまり、互いに依存する一連の動的テーブルをクエリするときは、いつでも、これらのテーブルにまたがるデータの同じ「スナップショット」をクエリしていることになります。

動的テーブルのターゲットラグは、それが依存する動的テーブルのターゲットラグよりも短くはできないことに注意してください。たとえば、次の場合を考慮します。

• DT1 は動的テーブル DT2 および DT3 をクエリします。

• DT2 のターゲット・ラグは5分。

• DT3 のターゲット・ラグは1分。

つまり、 DT1 のターゲット・ラグタイムは5分より短くてはなりません（つまり、 DT2 と DT3 のラグタイムの長い方より短くてはなりません）。

DT1 のラグを5分にセットすると、このプロセスでは、これらの目標でリフレッシュスケジュールが設定されます。

• DT3 をタイムラグが1分未満になるように十分な頻度で更新してください。

• DT1、 DT2 を一緒にリフレッシュし、タイムラグが5分以内になるように十分な頻度でリフレッシュしてください。

• スナップショットの分離を確実にするため、 DT1 と DT2 のリフレッシュが DT3 のリフレッシュと一致するようにしてください。

ベーステーブルの列に対する変更の影響について¶

動的テーブルに関連付けられた基になるオブジェクトが変更されると、以下の動作が適用されます。

動的テーブルリフレッシュのベストプラクティス¶