動的テーブルの仕組み¶

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

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

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

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

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

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

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

データの依存関係を追跡してデータのリフレッシュを管理するコードの記述を望まない。
ストリームやタスクの複雑さは必要ない、または避けたい。
複数のベーステーブルのクエリ結果を具体化する必要があります。
ETL パイプラインを介してデータを変換するために、複数のテーブルを構築する必要がある。
粒度の細かいリフレッシュスケジュールのコントロールは必要なく、パイプラインのターゲットデータの鮮度を指定することを希望する。
ストアドプロシージャ、フルリフレッシュでサポートされる非決定性関数にリストされていない非決定性関数、または外部関数など、サポートされていない動的クエリ構造を使用する必要がない。または、外部テーブルである動的テーブル、ストリームまたはマテリアライズドビューのソースを使用する必要がある。

注釈

動的テーブルはストリームのソースとして使用できます。動的テーブルに基づくストリームは、併用すると他のストリームと同様に機能します。その他の情報と例については、ストリーム、タスク、マテリアライズドビューと比較した動的テーブルをご参照ください。