動的テーブルのリフレッシュの境界

動的テーブルのリフレッシュの境界を使用して、動的テーブルのパイプラインを切断してもなお、上流の結果を読み取ります。

ある動的テーブルが別の動的テーブルを参照すると、その2つは1つのパイプラインとしてまとめてリフレッシュされます。これはほとんどのシナリオで機能しますが、チームの境界を超えてデータを共有するなど、データのリフレッシュのニーズが異なるユースケースがあります。DYNAMIC_TABLE_REFRESH_BOUNDARY() の上流参照をラップすることで、2つの動的テーブルを独立した（つまり、異なるパイプラインに属している）ものとして宣言できます。スナップショットの分離は単一のパイプライン内でのみ保証されるため、リフレッシュの境界を越える動的テーブルは、互いにスナップショットの分離を提供しません。

概要

デフォルトでは、動的テーブルが別の動的テーブルから読み込むと、Snowflakeは次のようにします。

  • 単一のパイプラインの一部として両方のテーブルを一緒にリフレッシュします。

  • 下流の動的テーブルが、パイプラインのすべての上流の動的テーブルにわたって スナップショットの分離 を表示するようにリフレッシュを調整します。

  • ターゲットラグチェックなど、パイプラインレベルのルールを強制します。

一部のパイプラインでは、すべての関係で両方の動的テーブルが一緒にリフレッシュされることは望ましくありません。一般的な例を次に示します。

  • クロスチームパイプライン では、あるチームが別のチームが消費する動的テーブルを公開しますが、下流の動的テーブルは上流のパイプラインに影響を与えたり継承されたりすることはありません。

  • 増分移行 では、上流のパイプラインステップを動的テーブルに変換しますが、下流のコンシューマーがそれを使用してリフレッシュの調整を開始することは望ましくありません。

  • Dynamic-table-on-view-on-dynamic-table パターンでは、動的テーブルが別の動的テーブルをクエリするビューから読み取ります。このパターンは、ビューが DYNAMIC_TABLE_REFRESH_BOUNDARY() でラップされていない限りサポートされません。

リフレッシュの境界は、この分離を明示的にします。境界内の入力は、別のパイプラインに属するものとして扱われ、通常のテーブルのように読み込まれます。

構文

DYNAMIC_TABLE_REFRESH_BOUNDARY( <object_name> )

条件:

object_name

テーブル、ビュー、動的テーブル、または共通テーブル式（ CTE ）名。

動的テーブル定義の FROM /JOIN 句（ CTEs および UNION ブランチ内を含む）でこのキーワードを使用します。。

例

次の例では、別の動的テーブルをクエリするビューから読み取ります。リフレッシュの境界がないと、別の動的テーブルのビューから読み込む動的テーブルの作成はサポートされません。DYNAMIC_TABLE_REFRESH_BOUNDARY() でのビューのラップがこのパターンを可能にします。

CREATE DYNAMIC TABLE analytics.click_analytics_dt
  WAREHOUSE = analytics_wh
  TARGET_LAG = '5 minutes'
AS
SELECT *
FROM DYNAMIC_TABLE_REFRESH_BOUNDARY(analytics.enriched_clicks_view);

次の例では、直接参照される動的テーブルと、上流の動的テーブルがより長いスケジュールでリフレッシュされるビューを結合します。DYNAMIC_TABLE_REFRESH_BOUNDARY() でのビューのラップは、下流の動的テーブルが5分ごとにコストのかかる上流のリフレッシュをトリガーするのを防ぐと同時に、利用可能な最新バージョンを読み取ることを可能にします。スナップショットの分離は、リフレッシュの境界を越えて保証されません。

CREATE DYNAMIC TABLE data_eng.enriched_clicks_dt
  WAREHOUSE = de_wh
  TARGET_LAG = '5 minutes'
AS
SELECT
  c.*,
  p.product_name
FROM data_eng.clickstream_dt AS c
LEFT JOIN DYNAMIC_TABLE_REFRESH_BOUNDARY(product_db.active_products_view) AS p
  ON c.product_id = p.product_id;

動作

リフレッシュの境界が依存関係を変更する方法

動的テーブル定義内の DYNAMIC_TABLE_REFRESH_BOUNDARY() で入力をラップした場合、

  • その入力は、この定義のリフレッシュ境界入力として扱われます。

  • その入力から到達可能な動的テーブルは、この定義のパイプラインには含まれません。

  • リフレッシュ時に、動的テーブルはパイプライン全体で調整されたデータタイムスタンプではなく、現在のバージョンでそれらのオブジェクトを読み取ります。

その結果、

境界を越えたカスケードリフレッシュはありません

下流の動的テーブルをリフレッシュしても、リフレッシュ境界を介してのみ到達可能な動的テーブルのリフレッシュはトリガーされません。

独立したスケジューリング

下流の動的テーブルのターゲットラグとリフレッシュのスケジューリングは、境界を越えてのみ到達可能な動的テーブルを無視します。

境界を越えるスナップショットの分離はありません

下流の動的テーブルは、リフレッシュ時に利用可能な上流データのバージョンをすべて読み取ります。境界を越えるデータは、他の上流の依存関係に適用される :ref:` スナップショットの分離 <label-dynamic_tables_refresh_boundary_snapshot_isolation>` と整列することは保証されません。

スナップショットの分離とリフレッシュの境界

単一のパイプライン（境界なし）内で、Snowflakeはそのパイプラインに参加しているすべての上流の動的テーブルの :ref:` スナップショットの分離 <label-dynamic_tables_intro_refresh_dependencies>`を保証します。

リフレッシュの境界は、境界を越える依存関係に対するこの保証を意図的に脆弱にします。

  • 境界の内側: オブジェクトは、独自のパイプラインに従ってリフレッシュおよび調整されます。

  • 境界の外側: 下流の動的テーブルは、リフレッシュ時に利用可能なバージョンをすべて読み取ります。

したがって、単一の動的テーブル定義は、両方のタイプの入力を参照できます。

  • パイプライン内のスナップショットの分離と調整されたリフレッシュに参加する、上流の動的テーブルへの**直接参照**。

  • リフレッシュ境界参照。これは、スナップショットの分離なしで、上流データの利用可能な最新バージョンを個別に読み取ります。

リフレッシュの境界は、上流と下流の動的テーブル間のスナップショットの分離を必要としない依存関係にのみ使用します。

ユースケース

クロスチームパイプラインの分離

異なるチームが論理パイプラインの異なる部分を所有する場合があります。

  • チームA: 組織全体で使用されるコア動的テーブルを公開します。

  • チームB: コア動的テーブルをチーム固有のデータと結合する下流の動的テーブルを定義します。

チームBは、チームAの出力をリフレッシュの境界でラップして、次のことができます。

  • チームAの動的テーブルを独自のパイプラインにプルすることを避ける。

  • 独自のリフレッシュスケジュールを独立させたままにする。

  • チームAの動的テーブルを外部の定期的に更新されるテーブルと同様に扱う。

動的テーブルのビューでの動的テーブルの有効化

リフレッシュの境界がないと、別の動的テーブルのビューから読み込む動的テーブルの作成はサポートされません。リフレッシュの境界を使用すると、ビューの依存関係を境界として明示的にマークできます。

CREATE VIEW v_orders AS
SELECT *
FROM orders_dt;

CREATE DYNAMIC TABLE order_summary_dt
  WAREHOUSE = analytics_wh
  TARGET_LAG = '15 minutes'
AS
SELECT
  customer_id,
  COUNT(*) AS num_orders
FROM DYNAMIC_TABLE_REFRESH_BOUNDARY(v_orders)
GROUP BY customer_id;

こちらは、 order_summary_dt です。

  • リフレッシュの境界を越えて orders_dt から読み取ります。

  • orders_dt と同じパイプラインに属していません。

  • リフレッシュ時に利用可能な orders_dt のあらゆるバージョンを読み取ります。

例: チーム所有の境界ビュー

一般的なパターンは、1つのチームが動的テーブルとその上のビューの両方を所有し、ビュー定義内にリフレッシュ境界を適用することです。他のチームは、所有チームの動的テーブルに新しい依存関係を導入することなく、そのビューを消費します。

-- Team A: owns product_catalog_dt and publishes a boundary view
CREATE DYNAMIC TABLE product.product_catalog_dt
  WAREHOUSE = product_wh
  TARGET_LAG = '1 hour'
AS
SELECT *
FROM product.raw_products;

CREATE VIEW product.active_products_public_v AS
SELECT * FROM DYNAMIC_TABLE_REFRESH_BOUNDARY(product.product_catalog_dt)
WHERE is_active = TRUE;

-- Team B: consumes Team A's view in their own dynamic table
CREATE DYNAMIC TABLE analytics.active_product_clicks_dt
  WAREHOUSE = analytics_wh
  TARGET_LAG = '5 minutes'
AS
SELECT
  c.*,
  p.product_name
FROM analytics.clickstream_dt AS c
JOIN product.active_products_public_v AS p
  ON c.product_id = p.product_id;

このパターンでは、

  • チームAは、 product.active_products_public_v 内部の product_catalog_dt をラップすることでリフレッシュの境界を制御します。

  • チームBとその他のチームは、公開されたビューのみを参照する独自の動的テーブルを定義します。

  • これらの下流の動的テーブルは、独自のパイプラインに product_catalog_dt を追加しません。 product_catalog_dt は、ビューを通してデータが表示されていても、パイプラインの外部に残ります。

動的テーブルへの増分移行

既存のパイプラインのステップを動的テーブルに移行する場合、下流のコンシューマーには次のことを望まない場合があります。

  • 新しい動的テーブルのリフレッシュのトリガーを開始する。

  • 新しいターゲットラグ要件を継承する。

新しい動的テーブル（またはその上のビュー）をリフレッシュの境界でラップすると、下流の動的テーブルは同じパイプラインに追加されることなく、その動的テーブルを消費できるようになります。

ターゲットラグ

リフレッシュの境界は、ターゲットラグの強制方法にも影響します。

上流の動的テーブルのターゲットラグは、同じパイプライン内の下流の動的テーブルのターゲットラグと同じか、短くする必要があります。DYNAMIC_TABLE_REFRESH_BOUNDARY() を通して参照される動的テーブルは同じパイプラインに属していないため、このルールは境界を越えて適用されません。

リフレッシュ境界内の上流の動的テーブルは、独自のターゲットラグとスケジューリングの動作を維持します。境界を越えて下流の選択によって強化または緩和されません。

制限と制約

リフレッシュの境界は、いくつかの重要なルールの対象となります。

リフレッシュ境界の内側と外側の両方で同じ動的テーブルを使用することは許可されていません

単一の定義内の同じ上流の動的テーブルへの参照はすべて、定義内に直接存在するか、 DYNAMIC_TABLE_REFRESH_BOUNDARY() でラップされている必要があります。この両方を混在させると、異なるバージョンで同じ動的テーブルを読み込むことができるようになります。Snowflakeはこれらの定義をブロックし、説明エラーを返します。

サポートされていない境界ターゲット

DYNAMIC_TABLE_REFRESH_BOUNDARY() は名前付きオブジェクト（テーブル、ビュー、動的テーブル、または CTE ）をラップする必要があります。次はラップできません。

  • インラインサブクエリ。

  • テーブル関数または UDTFs 。

  • 任意の TABLE(...) 呼び出し。

動的テーブルの外部での効果

通常の SELECT クエリで DYNAMIC_TABLE_REFRESH_BOUNDARY() を呼び出すことはできますが、動的テーブル定義の外部では操作は行われません。

ベストプラクティス

動的テーブルパイプラインでリフレッシュの境界を使用する場合:

次の場合にリフレッシュの境界を使用します。

  • パイプラインに参加せずに、別のチームの動的テーブルを消費することを望む場合。

  • 特定の上流依存関係からのスナップショットの分離が必要ない場合。

  • 動的テーブルが別の動的テーブルを参照するビューに依存する場合。このパターンは、ビューまたは上流の動的テーブルのいずれかが DYNAMIC_TABLE_REFRESH_BOUNDARY() でラップされている場合にのみサポートされます。

次の場合はリフレッシュの境界を回避します。

  • その依存関係全体でスナップショットの分離が必要な場合。

  • 下流のリフレッシュによって上流の動的テーブルと連携し、必要に応じてカスケードをリフレッシュしたい場合。

  • パイプライン全体にわたるグローバルなターゲットラグの関係に依存する場合。