動的テーブルリフレッシュについて¶

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

動的テーブルリフレッシュプロセスは、次の2つの方法のいずれかで動作します。

1. 増分リフレッシュ: この自動化されたプロセスでは、動的テーブルのクエリを分析し、前回のリフレッシュからの変更点を計算します。そして、これらの変更をテーブルにマージします。サポートされるクエリの詳細については、 増分リフレッシュでサポートされるクエリ をご参照ください。

2. フルリフレッシュ: 自動プロセスが増分リフレッシュを実行できない場合、フルリフレッシュを実行します。これには、動的テーブルのクエリを実行し、以前の具体化された結果を完全に置き換えることが含まれます。

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

ターゲットラグについて¶

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

動的テーブルに接続されているテーブルのグラフを見るには、 Snowsightを使用した動的テーブルグラフの調査 をご参照ください。

ターゲットラグは2つの方法のいずれかで指定します。

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

   次の例では、 product 動的テーブルを1時間ごとにリフレッシュし、鮮度を保つように設定しています。

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

   Copy

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

   以下の例では、 product は他の動的テーブルに基づいており、その下流動的テーブルのターゲットラグに基づいてリフレッシュするように設定されています。

   ALTER DYNAMIC TABLE product SET TARGET_LAG = DOWNSTREAM;
   

   Copy

ターゲットラグは、動的テーブルのリフレッシュ頻度に反比例します。

動的テーブル1（DT1）に基づいて動的テーブル2（DT2）が定義されている場合を考えてみましょう。DT2は、 DT1 から読み取り、そのコンテンツを具体化する必要があります。さらに、レポートはクエリを介して DT2 データを消費します。

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

増分リフレッシュでサポートされるクエリ¶

次のテーブルでは、現在増分リフレッシュをサポートしている式、キーワード、句について説明します。増分リフレッシュをサポートしないクエリのリストについては、 増分リフレッシュのサポートの制限 をご参照ください。

現在、横方向の結合は増分リフレッシュではサポートされていません。ただし、リフレッシュモードを INCREMENTAL に設定することで、 LATERAL を FLATTEN () と併用することができます。

例:

CREATE TABLE persons
  AS
    SELECT column1 AS id, parse_json(column2) AS entity
    FROM values
      (12712555,
      '{ name:  { first: "John", last: "Smith"},
        contact: [
        { business:[
          { type: "phone", content:"555-1234" },
          { type: "email", content:"j.smith@company.com" } ] } ] }'),
      (98127771,
      '{ name:  { first: "Jane", last: "Doe"},
        contact: [
        { business:[
          { type: "phone", content:"555-1236" },
          { type: "email", content:"j.doe@company.com" } ] } ] }') v;

CREATE DYNAMIC TABLE example
  TARGET_LAG = DOWNSTREAM
  WAREHOUSE = mywh
  REFRESH_MODE = INCREMENTAL
  AS
    SELECT p.id, f.value, f.path
    FROM persons p,
    LATERAL FLATTEN(input => p.entity) f;

演算子が増分リフレッシュする方法¶

以下のテーブルは、各演算子がどのように増分化されるのか（つまり、完全な結果の代わりに変更を生成する新しいクエリフラグメントに変換されるのか）、そのパフォーマンスとその他の考慮すべき重要な要因の概要を示しています。

CREATE DYNAMIC TABLE sums
  AS
    SELECT date_trunc(minute, ts), sum(c1) FROM table
    GROUP BY 1;

CREATE DYNAMIC TABLE intermediate
  AS
    SELECT date_trunc(minute, ts) ts_min, c1 FROM table;

CREATE DYNAMIC TABLE sums
  AS
    SELECT ts_min, sum(c1) FROM intermediate
    GROUP BY 1;

フルリフレッシュでサポートされる非決定性関数¶

動的テーブルでは、以下の非決定性関数がサポートされています。これらの関数はフルリフレッシュでのみサポートされていることに注意してください。増分リフレッシュでサポートされない内容のリストについては、 増分リフレッシュのサポートに関する制限 をご参照ください。

• VOLATILE ユーザー定義関数

• シーケンス関数 （例: SEQ1、 SEQ2）

• 以下のコンテキスト機能:

  • CURRENT_ROLE

  • CURRENT_WAREHOUSE

  • CURRENT_ACCOUNT

  • CURRENT_REGION

• 以下の日時関数（それぞれのエイリアスと合わせて）:

  • CURRENT_DATE

  • CURRENT_TIME

  • CURRENT_TIMESTAMP

動的テーブルが他の動的テーブルに依存している場合のデータのリフレッシュ方法¶

動的テーブルのラグが時間の尺度として指定されている場合、自動リフレッシュプロセスは、動的テーブルのターゲットラグタイムに基づいて、リフレッシュのスケジュールを決定します。このプロセスは、各テーブルのターゲットラグタイムに最適なスケジュールを選択します。

ある動的テーブルが別の動的テーブルに依存 している場合にデータの一貫性を保つために、このプロセスはアカウント内のすべての動的テーブルを互換性のあるタイミングでリフレッシュします。リフレッシュの頻度が低いタイミングは、リフレッシュの頻度が高いタイミングと一致します。

たとえば、動的テーブルAのターゲットラグが2分で、ターゲットラグが1分の動的テーブルBをクエリするとします。このプロセスでは、Aは96秒ごと、Bは48秒ごとにリフレッシュする必要があると判断される可能性があります。その結果、このプロセスは以下のスケジュールを適用する可能性があります。

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

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

• 動的テーブルAが動的テーブルBとCをクエリします。

• 動的テーブルBのターゲットラグは5分です。

• 動的テーブルCのターゲットラグは1分です。

つまり、Aのターゲットラグタイムは5分より短くすることはできません（つまり、BとCのラグタイムの長い方より短くすることはできません）。

Aのラグを5分に設定した場合、プロセスは以下の目標があるリフレッシュスケジュールを設定します。

• ラグが1分以下になるよう、Cを頻繁にリフレッシュします。

• AとBを一緒にリフレッシュし、ラグが5分以下になるように十分な頻度でリフレッシュします。

• スナップショットの分離を確実にするために、AとBのリフレッシュがCのリフレッシュと一致するようにします。

注: リフレッシュに時間がかかりすぎる場合、スケジューラーはリフレッシュをスキップして最新の状態に保とうとすることがあります。ただし、スナップショットの分離は維持されます。