動的テーブル¶

一例¶

ロードされた JSON データのスケジュールに従った変換 の例では、ストリームとタスクを使用して、2つのターゲットテーブル（name および visits）に新しいデータを変換して挿入し、データをランディングテーブル（raw）にストリームしています。

次の例は、動的テーブルを使用して同じ変換を実行する方法を示しています。

-- Create a landing table to store
-- raw JSON data.
CREATE OR REPLACE TABLE raw
  (var VARIANT);

-- Create a stream to capture inserts
-- to the landing table.
CREATE OR REPLACE STREAM rawstream1
  ON TABLE raw;

-- Create a table that stores the names
-- of office visitors from the raw data.
CREATE OR REPLACE TABLE names
  (id INT,
   first_name STRING,
   last_name STRING);

-- Create a task that inserts new name
-- records from the rawstream1 stream
-- into the names table.
-- Execute the task every minute when
-- the stream contains records.
CREATE OR REPLACE TASK raw_to_names
  WAREHOUSE = mywh
  SCHEDULE = '1 minute'
  WHEN
    SYSTEM$STREAM_HAS_DATA('rawstream1')
  AS
    MERGE INTO names n
      USING (
        SELECT var:id id, var:fname fname,
        var:lname lname FROM rawstream1
      ) r1 ON n.id = TO_NUMBER(r1.id)
      WHEN MATCHED AND metadata$action = 'DELETE' THEN
        DELETE
      WHEN MATCHED AND metadata$action = 'INSERT' THEN
        UPDATE SET n.first_name = r1.fname, n.last_name = r1.lname
      WHEN NOT MATCHED AND metadata$action = 'INSERT' THEN
        INSERT (id, first_name, last_name)
          VALUES (r1.id, r1.fname, r1.lname);

-- Create a landing table to store
-- raw JSON data.
CREATE OR REPLACE TABLE raw
  (var VARIANT);

-- Create a dynamic table containing the
-- names of office visitors from
-- the raw data.
-- Try to keep the data up to date within
-- 1 minute of real time.
CREATE OR REPLACE DYNAMIC TABLE names
  TARGET_LAG = '1 minute'
  WAREHOUSE = mywh
  AS
    SELECT var:id::int id, var:fname::string first_name,
    var:lname::string last_name FROM raw;

この例が示すように、動的テーブルを作成する際には、表示する結果のクエリを指定します。データの増分リフレッシュでは、変更を追跡するストリームを作成し、それらの変更を調べてターゲットテーブルに変更を適用するタスクを記述する必要はありません。自動リフレッシュプロセスは、指定したクエリに基づいて代わりこれを実行します。

動的テーブルを使用する場合¶

パイプラインでデータを変換する方法はいくつかあります（例: ストリームやタスク、 CTAS、独自のカスタムソリューション）。動的テーブルは、データを変換するための1つのオプションです。

動的テーブルは次のような場合に最適です。

• データの依存関係を追跡してデータのリフレッシュを管理するコードの記述を望まない。

• ストリームやタスクの複雑さは必要ない、または避けたい。

• 複数のベーステーブルのクエリ結果を具体化する必要があります。

• ETL パイプラインを介してデータを変換するために、複数のテーブルを構築する必要がある。

• 粒度の細かいリフレッシュスケジュールのコントロールは必要なく、パイプラインのターゲットデータの鮮度を指定することを希望する。

• ストアドプロシージャ、 フルリフレッシュでサポートされる非決定性関数 にリスト されていない 非決定性関数、または 外部関数 など、サポートされていない動的クエリ構造を使用する必要がない。または、外部テーブルである動的テーブル、ストリームまたはマテリアライズドビューのソースを使用する必要がある。

動的テーブルの仕組み¶

動的テーブルを作成する場合は、1つ以上のベースオブジェクトまたは動的テーブルからデータを変換するために使用するクエリを指定します。自動リフレッシュプロセスは、このクエリを定期的に実行し、ベースオブジェクトに加えられた変更を使用して動的テーブルをリフレッシュします。

この自動プロセスは、ベースオブジェクトに加えられた変更を計算し、その変更を動的テーブルにマージします。この作業を実行するために、プロセスは、動的テーブルに関連付けられたコンピューティングリソースを使用します。リソースの詳細については、 動的テーブルのコストについて をご参照ください。

動的テーブルの作成時に、データのターゲット「鮮度」を指定します（ターゲット ラグ）。たとえば、基本テーブルの更新から最大でも5分遅れまでにデータを更新するように指定できます。このターゲット鮮度に基づいて、自動プロセスは動的テーブルのデータがこのターゲット内（つまり、ベーステーブルのリフレッシュから5分以内）にリフレッシュされるようにリフレッシュを設定します。

データの鮮度がそれほど重要ではない場合は、ターゲット鮮度時間を長く指定してコストを削減することができます。たとえば、ターゲットテーブルのデータがベーステーブルの更新から最大1時間遅れていればよい場合は、1時間（5分の代わりに）のターゲット鮮度を指定してコストを削減できます。

動的テーブルのパイプラインのチェーンについて¶

動的テーブルを設定して、他の動的テーブルをクエリできます。

たとえば、データパイプラインがステージングテーブルからデータを取得し、顧客、製品、および日時のデータについて、 ディメンションテーブル を更新するとします。パイプラインは、ディメンションテーブルに基づいて、集計した販売データを含むテーブルも更新します。

ディメンジョンテーブルは、ステージングテーブルにクエリする動的テーブルとして設定できます。次に、ディメンジョンテーブルにクエリを発行する動的テーブルとして、売上集計テーブルを設定できます。

これはタスクグラフの定義と似ています。タスクグラフでは、売上集計テーブルを更新するタスクは、ディメンションテーブルを更新するタスクがエラーなしで完了した場合にのみ実行されます。

動的テーブルが別の動的テーブルをクエリする場合、自動リフレッシュプロセスは、それぞれのラグターゲットが満たされ、データが一貫していることを保証するために、適切なタイミングで依存するすべての動的テーブルをリフレッシュします。

動的テーブルおよびTime Travel¶

Snowflake Time Travelでは、定義された期間内の任意の時点で履歴データ（つまり、変更または削除されたデータ）にアクセスできます。Time Travelは動的テーブルでも従来のテーブルのときと同じように動作します。

詳細については、 Snowflake Time TravelおよびFail-safe をご参照ください。

動的テーブルと複製¶

動的テーブルの複製をサポートすることで、プライマリデータベースからセカンダリデータベースにデータをコピーし、障害復旧やデータ共有を実行できます。これは、障害復旧のためのフェールオーバー準備戦略としても、読み取り専用の目的でデプロイメント間でデータを共有する手段としても機能します。

複製された動的テーブルは、動的テーブルを含むプライマリデータベースが複製グループに複製されているか、フェールオーバーグループに複製されているかによって動作が異なります。詳細については、 複製と動的テーブル をご参照ください。