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

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

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

動的テーブルは、指定された ターゲット・ラグ に基づいて更新されます。これは、ベーステーブルの更新と動的テーブルのコンテンツとの間に許容される最大遅延をセットします。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 パラメーターによって制御されます。このパラメーターは、アカウントまたはウェアハウスレベルで、更新が自動的にキャンセルされるまでの最大許容期間をセットします。

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

動的テーブルは、自動、インクリメンタル、フルの3つのリフレッシュモードをサポートしています。リフレッシュモードを AUTO または明示的に設定できます。

• AUTO リフレッシュモード: AUTO パラメーターの使用時、Snowflakeは、クエリの複雑さ、サポートされる構築、演算子、関数、および予想されるパフォーマンスに基づいて、コストと時間効果が最も高いリフレッシュモードを自動的に選択します。この決定は、テーブルの作成時に一度だけ行われます。インクリメンタルリフレッシュが サポート対象外 または 非効率 の場合、Snowflakeは代わりにフルリフレッシュを選択します。

  たとえば、動的テーブルがビューを参照し、ビューの定義が非同期に変更された場合でも、リフレッシュモードは変更なしのままになります。元の決定は増分であったが、サポートされなくなった場合（たとえば、上流のビューの変更が原因で）、リフレッシュは Dynamic table can no longer be refreshed incrementally because an upstream view changed. のようなエラーで失敗します。

  リフレッシュモードを変更するには、CREATE OR REPLACE DYNAMIC TABLE コマンドを使用して動的テーブルを再作成します。

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

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

フルリフレッシュとインクリメンタルリフレッシュを使用する場合のガイダンスについては、 リフレッシュモードを選択 をご参照ください。既存の動的テーブルがどのリフレッシュモードを使用しているかを確認するには、 リフレッシュモード をご参照ください。

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

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

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

例えば、動的テーブル 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 のリフレッシュと一致するようにしてください。

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

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