動的テーブルを作成する

このトピックでは、動的テーブルを作成するためのキーの概念について概説します。

開始する前に、 動的テーブルを作成するための権限 があり、動的テーブルクエリで使用されるすべてのオブジェクトで 変更追跡 が有効になっていることを確認してください。

動的テーブルの作成にはいくつかの制限があります。包括的なリストについては、 動的テーブルの制限 をご参照ください。

変更の追跡を有効にする

増分リフレッシュモードで動的テーブルを作成する際、クエリするテーブルで変更追跡が有効になっていない場合、Snowflakeは自動的にそれらのテーブルで変更追跡を有効にしようとします。増分リフレッシュをサポートするには、動的テーブルで使用されるすべての基本オブジェクトに対して、 ゼロ以外のTime Travel保持期間 で変更追跡を有効にする必要があります。

ベースオブジェクトが変われば、動的テーブルも変わります。ベースオブジェクトを再作成する場合は、変更トラッキングを再度有効にする必要があります。

注釈

Snowflakeは、フルリフレッシュモードで作成された動的テーブルの変更追跡を自動的に有効化しようとしません。

特定のデータベースオブジェクトで変更追跡を有効にするには、そのオブジェクトで ALTER TABLE や ALTER VIEW などのコマンドを使用します。動的テーブルを作成するユーザーには、基になるすべてのオブジェクトの変更追跡を有効化する OWNERSHIP 権限が必要です。

変更追跡が有効かどうかを確認するには、基になるオブジェクトに対して SHOW VIEWS、 SHOW TABLES などのコマンドを使用し、 change_tracking 列を調べます。

動的テーブルを作成するための構文

Suppose that you want to create a dynamic table named product that contains the product_id and product_name columns from the table named staging_table, and you decide:

  • You want the data in the product table to be at most 20 minutes behind the data in staging_table.

  • リフレッシュ に必要なコンピューティングリソースには、ウェアハウス mywh を使用します。

  • リフレッシュモードが自動的に選択されるようにします。

  • 動的テーブルを作成時に同期的にリフレッシュしたいと思っています。

  • リフレッシュタイプが自動的に選択され、動的テーブルが作成時に同期的にリフレッシュされるようにします。

この動的テーブルを作成するには、次の CREATE DYNAMIC TABLE SQL ステートメントを実行します。

CREATE OR REPLACE DYNAMIC TABLE product
  TARGET_LAG = '20 minutes'
  WAREHOUSE = mywh
  REFRESH_MODE = auto
  INITIALIZE = on_create
  AS
    SELECT product_id, product_name FROM staging_table;
Copy

パラメーターの完全なリストとバリアント構文については、 CREATE DYNAMIC TABLE リファレンスをご参照ください。

動的テーブル作成のベストプラクティス

動的テーブルのパイプラインのチェーン

新しい動的テーブルを定義する場合、多くの入れ子ステートメントを持つ大きな動的テーブルを定義するのではなく、パイプラインを持つ小さな動的テーブルを使用します。

動的テーブルを設定して、他の動的テーブルをクエリできます。たとえば、データパイプラインがステージング・テーブルからデータを抽出して、さまざまなディメンジョン・テーブル (customer、 product、 date、 time など) を更新するシナリオを想像してください。さらに、パイプラインは、これらのディメンジョン・テーブルの情報に基づいて、集約された sales テーブルを更新します。ディメンジョン・テーブルからステージング・テーブルへのクエリ、および集約された sales テーブルからディメンジョン・テーブルへのクエリを構成することで、タスク・グラフに似たカスケード効果を作成できます。

この設定では、集約された sales テーブルのリフレッシュは、ディメンジョン テーブルのリフレッシュが正常に完了した後にのみ実行されます。これにより、データの一貫性が確保され、ラグターゲットが達成されます。自動化されたリフレッシュプロセスにより、ソーステーブルの変更は適切なタイミングですべての従属テーブルのリフレッシュをトリガーします。

タスクグラフと動的テーブル DAGs の比較

複雑なタスクグラフに「コントローラー」動的テーブルを使用する

多くのルートとリーフを持つ動的テーブルの複雑なグラフがあり、1つのコマンドでタスクグラフ全体に対して操作（ラグ変更、手動リフレッシュ、中断など）を実行したい場合、以下を実行します。

  1. すべての動的テーブルの TARGET_LAG の値を DOWNSTREAM に設定してください。

  2. タスクグラフのすべてのリーフから読み取る「コントローラー」動的テーブルを作成します。このコントローラーがリソースを消費しないようにするには、以下を実行します。

    CREATE DYNAMIC TABLE controller
  TARGET_LAG = <target_lag>
  WAREHOUSE = <warehouse>
  AS
    SELECT 1 A FROM <leaf1>, …, <leafN> LIMIT 0;
    Copy

  3. コントローラーを使用してグラフ全体を制御します。例:

  • タスクグラフの新しいターゲットラグを設定します。

    ALTER DYNAMIC TABLE controller SET
  TARGET_LAG = <new_target_lag>;
    Copy

  • タスクグラフを手動でリフレッシュします。

    ALTER DYNAMIC TABLE controller REFRESH;
    Copy

動的テーブルのクローンパイプラインについて

パイプラインの再初期化を避けるために、同じcloneコマンドで動的テーブルパイプラインのすべての要素をクローンします。パイプラインのすべての要素（基本テーブル、表示、動的テーブルなど）を同じスキーマまたはデータベースに統合することでこれを行うことができます。

一時動的テーブルを使用してストレージコストを削減する

一時 動的テーブルは、データ保持期間内はデータを確実に保持し、Time Travelをサポートしますが、フェイルセーフ期間を超えてデータを保持することはありません。デフォルトでは、動的テーブルデータは fail-safe ストレージに7日間保持されます。

リフレッシュスループットが高い動的テーブルでは、ストレージの消費量が大幅に増加する可能性があります。したがって、動的テーブルを一時的に使用するのは、そのデータが永続テーブルと同じレベルのデータ保護とリカバリを必要としない場合に限ります。

一時動的テーブルを作成したり、既存の動的テーブルを一時的な動的テーブルにクローンするには、 CREATE DYNAMIC TABLE ステートメントを使用します。

動的テーブル作成のトラブルシューティング

動的テーブルを作成すると、最初のリフレッシュはスケジュール (ON_SCHEDULE) または作成直後 (ON_CREATE) に行われます。初期データ入力、つまり 初期化 は、この初期リフレッシュがいつ発生するかによって決まります。例えば、 ON_CREATE の場合、上流のダイナミック・テーブルのリフレッシュをトリガーすると、初期化に時間がかかることがあります。

スキャンされるデータの量に応じて、初期化に時間がかかる場合があります。進行状況を表示するには、以下を実行します。

  1. Snowsight にサインインします。

  2. ナビゲーションメニューで Monitoring » Query History を選択します。

  3. Filters ドロップダウンで、 SQL Text フィルターに CREATE DYNAMIC TABLE と入力し、 Warehouse フィルターにウェアハウス名を入力します。

  4. SQL text で動的テーブルを含むクエリを選択し、 Query Details と Query Profile タブを使用して進行状況を追跡します。

言語: 日本語