楽々データパイプライン：Snowflake 動的テーブルで変換をシンプルに

snowflake Dynamic table

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
;

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を含むデータベース、スキーマ、ウェアハウスに対する USAGE 権限
- クエリ対象のDynamic Tableに対する SELECT 権限
変更する為に
- Dynamic Tableに対する OPERATE 権限
Dynamic Tableのメタデータを見る為に
- Dynamic Tableに対する MONITOR 権限
  注記: OPERATE 権限ではメタデータの監視が許可されますが、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がその実装を処理します	命令型アプローチ: データを段階的に変換する方法を定義します。
動的同期: ベース/ソーステーブルのデータが変更されると同期が行われます。	データを変換するコードを実行するスケジュールを定義します。(タスクのスケジュール設定)
ストアドプロシージャやそのタスクを使用できない	ストアドプロシージャやその他のタスクを使用できます。

Cherry Peeked

Search This Blog