動的テーブルを作成する¶

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

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

Some limitations apply to creating dynamic tables. For a complete list, see 動的テーブルの制限.

注釈

インクリメンタルリフレッシュで効率的に機能するクエリを書くためのガイダンスについては、インクリメンタルリフレッシュ向けにクエリを最適化するをご参照ください。

変更の追跡を有効にする¶

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

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

注釈

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

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

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

サポートされるベースオブジェクト¶

動的テーブルは以下のベースオブジェクトをサポートします。

テーブル
Snowflake管理 Apache Iceberg™ テーブル
外部管理 Apache Iceberg™ テーブル

例: 単純な動的テーブルを作成する¶

staging_table という名前のテーブルから product_id 列と product_name 列を含む動的テーブルを作成し、次を決定するとします。

作成した動的テーブル内のデータは、staging_table のデータより最大で20分の遅延に設定します。
mywh リフレッシュ :ref:`<label-dynamic_tables_intro_refresh_modes> に必要なコンピューティングリソースには、ウェアハウス ` を使用します。
リフレッシュモードが自動的に選択されるようにします。
- Snowflake recommends using the automatic refresh mode only during development. For more information, see リフレッシュモードを選択.
動的テーブルを作成時に同期的にリフレッシュしたいと思っています。
リフレッシュタイプが自動的に選択され、動的テーブルが作成時に同期的にリフレッシュされるようにします。

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

CREATE OR REPLACE DYNAMIC TABLE my_dynamic_table
  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 リファレンスをご参照ください。

Snowflake管理または外部管理の Apache Iceberg™ テーブルから読み込む動的テーブルを作成する¶

Icebergテーブルから動的テーブルを作成するのは、通常のテーブルから動的テーブルを作成するのと似ています。Snowflake管理テーブルまたは外部カタログ管理テーブルをベースオブジェクトとして使用し、通常のテーブルの場合と同様に :doc:`/sql-reference/sql/create-dynamic-table`SQL ステートメントを実行します。

Snowflakeが管理するIcebergテーブルをベーステーブルとして読み込む動的テーブルは、Snowflakeが管理するIcebergテーブルのデータをパイプラインに操作させたい場合や、他のエンジンで書き込まれたIcebergテーブルをパイプラインに操作させたい場合に便利です。外部エンジンは、Snowflake管理のIcebergテーブルに書き込めません。Snowflakeでは読み取り/書き込み、外部エンジンでは読み取り専用であることにご注意ください。

AWS GlueやApache Sparkなどのエンジンによって記述された外部（非Snowflake）カタログが管理するIcebergテーブルから読み込む動的テーブルは、外部データレイクからのデータを処理するのに役立ちます。外部で管理されたデータの上に動的テーブルを作成し、データを複製したり取り込んだりすることなく、Snowflakeで継続的に処理することができます。

Icebergテーブルを使用する際の制限と考慮事項¶

通常の動的テーブルおよび動的Icebergテーブルのすべての制限は引き続き適用されます。

その他の情報は次のとおりです。

Icebergベーステーブルのすべての制限が適用されます。詳細については、考慮事項と制約をご参照ください。
Snowflakeネイティブテーブル、Snowflake管理Icebergテーブル、外部管理Icebergテーブルから読み込む動的テーブルを作成できます。
動的テーブルは、行レベルで変更を追跡する他のベーステーブルとは異なり、外部で管理されるIcebergベーステーブルの変更をファイルレベルで追跡します。外部で管理されるIcebergテーブルに対する頻繁なコピーオンライト操作（更新や削除など）は、増分リフレッシュのパフォーマンスに影響を与える可能性があります。

Create dynamic tables with immutability and backfill¶

不変性制約により、動的テーブルの一部を静的としてマークできます。IMMUTABLE WHERE 句を定義するとき、Snowflakeはリフレッシュ中にそれらの行をスキップします。これにより、大量の履歴データを含むテーブルのパフォーマンスが向上します。

バックフィルは、既存のデータを計算せずに動的テーブルにコピーできるようにすることで、不変性制約を拡張します。この操作により、将来の更新のためのカスタム更新クエリを定義している間、履歴データをすぐに利用できるようにします。

詳細と例については、不変性制約の使用をご参照ください。

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

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

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

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

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

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

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

すべての動的テーブルの TARGET_LAG の値を DOWNSTREAM に設定してください。
Create a “controller” dynamic table that reads from all of the leaves in your task graph.
- リーフ動的テーブルはタスクグラフのノードで、下流の依存関係はありません。他の動的テーブルはそこから読み込むことがないため、他の動的テーブルの依存関係にはありません。
- <leaf1> 、 <leaf2>...、 <leafN> を実際のリーフ動的テーブル名に置き換えます。
- このコントローラーがリソースを消費しないようにするには、 LIMIT 0 でデカルト結合を作成します。
CREATE DYNAMIC TABLE controller TARGET_LAG = <target_lag> WAREHOUSE = <warehouse> AS SELECT 1 A FROM <leaf1>, …, <leafN> LIMIT 0;
Copy
コントローラーを使用してグラフ全体を制御します。例:

タスクグラフの新しいターゲットラグを設定します。
ALTER DYNAMIC TABLE controller SET
  TARGET_LAG = <new_target_lag>;
Copy
タスクグラフを手動でリフレッシュします。
ALTER DYNAMIC TABLE controller REFRESH;
Copy

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

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

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

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

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

動的テーブルを作成すると、初期リフレッシュはスケジュール（ON_SCHEDULE）または作成時すぐに（ON_CREATE）発生します。初期データ入力、つまり初期化は、この初期リフレッシュがいつ発生するかによって決まります。たとえば ON_CREATE では、初期化が上流の動的テーブルのリフレッシュをトリガーする場合、初期化に時間がかかる可能性があります。

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

Snowsight にサインインします。
ナビゲーションメニューで Monitoring » Query History を選択します。
Filters ドロップダウンで、 SQL Text フィルターに CREATE DYNAMIC TABLE と入力し、 Warehouse フィルターにウェアハウス名を入力します。
SQL text で動的テーブルを含むクエリを選択し、 Query Details と Query Profile タブを使用して進行状況を追跡します。