TL;DR: Dynamic Tablesは、同期機能が組み込まれたテーブルです。Dynamic Tableの定義では、同期元テーブル、同期するデータ、同期頻度を定義します。その後、Snowflakeがデータ同期プロセスを自動的に処理します。
Dynamic Tableは、信頼性が高く自動化された方法でデータを変換するために使用されます。
ソース テーブルを定義し、同期するデータを選択するための SQL クエリを記述し、同期の頻度を設定します。残りの作業は Snowflake が行います。Dynamic Tableの基になる基礎データが変更されると、テーブルが更新されてその変更が反映されます。これらの更新は自動化されており、「更新」と呼ばれます。
Dynamic Tableのソースは複数のテーブル、さらには別のDynamic Tableにすることもできます。
Dynamic Tableの主な利点:
-
宣言型プログラミング (Declarative programming): 宣言型 SQL を使用して終了状態を定義し、Snowflake にパイプライン管理を処理させることができます。
-
簡単に切り替え可能:
ALTER DYNAMIC TABLEコマンドで、バッチからストリーミングにシームレスに移行できます。パイプラインでデータを更新する頻度を制御できるため、コストとデータの鮮度のバランスをとることができます。
注記: Dynamic Tableの内容はクエリに基づいており、DML 操作を使用して変更することはできません。
Dynamic Table の仕組みを解き明かす
Dynamic Tableは、変更を検知するためにベース テーブルの変更追跡に依存します。ベース テーブルで変更追跡がまだ有効になっていない場合、Snowflake は自動的に変更追跡を有効にしようとします。Dynamic Tableを作成するユーザーは、すべての基礎となるオブジェクト/テーブルで変更追跡を有効にするために、OWNERSHIP 権限を持っている必要があります。
変更の追跡 (Change tracking)
テーブルで変更の追跡を有効にするかどうかを指定します。テーブルで変更の追跡が有効になります。この設定により、ソース テーブルに非表示の列のペアが追加され、列に変更追跡メタデータが格納され始めます。これらの列は少量のストレージを消費します。
変更追跡メタデータは、SELECT ステートメントの CHANGES 句を使用するか、テーブル上で 1 つ以上のストリームを作成してクエリすることによってクエリできます。
変更追跡は、テーブルの作成時またはAlter tableコマンドを使用して有効にすることができます。:
CREATE OR REPLACE products
...
CHANGE_TRACKING = TRUE
;
or
ALTER TABLE products SET CHANGE_TRACKING = TRUE;
基本テーブルで変更追跡が有効になっているかどうかを確認するには、基本オブジェクトに対して SHOW VIEWS、SHOW TABLES などのコマンドを使用し、change_tracking 列を調べます。
ソース テーブルとDynamic Table間のデータの同期は、次の 2 つの方法のいずれかで実行されます:
- 増分リフレッシュ (Incremental refresh): この自動プロセスは、Dynamic Tableのクエリを分析し、最後の更新 (同期) 以降の変更を計算します。次に、これらの変更をテーブルにマージします。
- 完全リフレッシュ (Full refresh): 自動プロセスが増分更新を実行できない場合は、データを完全に置き換える完全更新を実行します。
注記: Dynamic Tableの更新モードは作成時に決定され、その後は変更できません。
ターゲット ラグ:
ソース テーブルが変更されるとすぐに (1 分以内に) データを同期するか、ソース テーブルが変更されてから特定の時間後にデータを同期するかを定義できます。これは「ターゲット ラグ」と呼ばれます。ターゲット ラグ は、Dynamic Tableの内容がベース テーブルの更新から遅れる最大時間です。ターゲット ラグを設定することで、コスト効率を最適化できます。たとえば、ターゲット ラグを 2 時間に設定すると、最初の 30 分で 10 行の新しい行がベース テーブルに挿入され、その後さらに 30 行が挿入されます。この方法では、データが変更されるたびに同期プロセスを 2 回実行する代わりに、最初の変更から 2 時間以内に同期プロセスを 1 回だけ実行します。注: これは Cron スケジュールとは異なります。この 2 時間のラグ時間は、2 時間ごとに同期が行われることを意味するのではなく、最初の変更から 2 時間以内に同期が行われることを意味します。
以下の例では、注文のDynamic Tableの更新遅延を2時間に設定します:
ALTER DYNAMIC TABLE orders SET TARGET_LAG = '2 hour';
注記:
ストリームとタスクを使用してデータ変換パイプラインを設定することは可能ですが、Dynamic Tableの設定はストリームとタスクを使用するよりもはるかに簡単です。
Dynamic tableの作成
CREATE OR REPLACE DYNAMIC TABLE order
TARGET_LAG = '30 minutes'
WAREHOUSE = warehouse_xl
REFRESH_MODE = INCREMENTAL
AS
SELECT order_id, order_source
FROM staging_table
WHERE order_origin = 'America';
Dynamic tablesのパフォーマンス
Dynamic Tableは意図的にシンプルに設計されており、作成、使用、管理が簡単です。
注記:
クエリを実行すると、Dynamic Tableは通常の Snowflake テーブルと同様に動作します。
クエリが複雑になるほど、時間とリソースが増えます。
アクセス制御
Dynamic Tableへのフルアクセス（作成、使用、変更、監視など）を行うには、OWNERSHIPロールまたは使用ケースに基づく特定の権限が必要です:
-
作成する為に
- Dynamic Tableを作成する予定のスキーマに対する
CREATE DYNAMIC TABLE権限 - 新しいDynamic Tableに対してクエリを実行する予定の既存のテーブルとビューに対する
SELECT権限 - 新しいDynamic Tableに使用する予定のデータベース、スキーマ、ウェアハウスに対する
USAGE権限
- Dynamic Tableを作成する予定のスキーマに対する
-
クエリーの為に
- Dynamic Tableを含むデータベース、スキーマ、ウェアハウスに対する
USAGE権限 - クエリ対象のDynamic Tableに対する
SELECT権限
- Dynamic Tableを含むデータベース、スキーマ、ウェアハウスに対する
-
変更する為に
- Dynamic Tableに対する
OPERATE権限
- Dynamic Tableに対する
-
Dynamic Tableのメタデータを見る為に
- Dynamic Tableに対する
MONITOR権限
注記:OPERATE権限ではメタデータの監視が許可されますが、Dynamic Tableの変更も許可されます。
- Dynamic Tableに対する
注記:
Dynamic Tableに対する OWNERSHIP 権限を持つユーザーのみが、そのDynamic Tableを削除できます。
コスト
計算コスト
Dynamic Tableに関連するコンピューティング コストには、仮想ウェアハウスとクラウド サービス コンピューティングの 2 つがあります。
-
仮想ウェアハウス:
Dynamic Tableを更新するには、仮想ウェアハウスが必要です。つまり、スケジュールされた更新と手動更新の両方を含め、初期化および更新時にベース オブジェクトに対してクエリを実行します。これらの操作では、クレジットを消費するコンピューティング リソースが使用されます。 -
クラウド サービス コンピューティング:
Dynamic Tableでは、基盤となる基本オブジェクトの変更と仮想ウェアハウスを呼び出す必要があるかどうかを識別するために、クラウド サービスのコンピューティングも必要です。変更が識別されない場合、更新する新しいデータがないため、仮想ウェアハウスのクレジットは消費されません。
注記:
Dynamic Table クエリでベース オブジェクトの変更がフィルター処理される場合もあります。変更が where/having 句を通過していないためDynamic Tableは更新されませんが、変更が適用可能かどうかを判断するためにDynamic Tableが更新されるため、仮想ウェアハウス クレジットが消費されます。
ストレージコスト
Dynamic Tableには、マテリアライズされた結果を保存するためのストレージが必要です。通常のテーブルと同様に、タイムトラベル、フェイルセーフ ストレージ、クローン機能には追加のストレージ コストが発生する可能性があります。
制限事項
- Dynamic Tableの内容はクエリに基づいており、DML 操作を使用して変更することはできません。
- Dynamic Tableからデータを切り捨てることはできません.
- Dynamic Tableは、入力テーブルの
MAX_DATA_EXTENSION_TIME_IN_DAYS期間内に更新されない場合、古くなる可能性があります。古くなったDynamic Tableは、更新を再開するために再作成する必要があります。
Dynamic Table vs Streams and Tasks
ストリームとタスクを使用してデータ変換パイプラインを設定することは可能ですが、Dynamic Tableの設定はストリームとタスクを使用する場合に比べてはるかに簡単です。
| Dynamic Table | Stream & Task |
|---|---|
| 宣言型アプローチ: 望む最終結果を定義し、Snowflakeがその実装を処理します | 命令型アプローチ: データを段階的に変換する方法を定義します。 |
| 動的同期: ベース/ソース テーブルのデータが変更されると同期が行われます。 | データを変換するコードを実行するスケジュールを定義します。(タスクのスケジュール設定) |
| ストアドプロシージャやそのタスクを使用できない | ストアド プロシージャやその他のタスクを使用できます。 |
Comments
Post a Comment