動的テーブルの主キーを理解する

Snowflakeは動的テーブルや動的Icebergテーブルの主キーを使用して、行レベルの変更をより効率的に追跡し、フルリフレッシュされる動的テーブルの下流の増分リフレッシュを可能にします。変更追跡列に依存する代わりに、Snowflakeは主キーを安定した行識別子として使用し、リフレッシュ間の変更の最小限のセットを計算します。

これは特に、次のシナリオで役立ちます。

  • ベーステーブルはインプレースで更新されるのではなく、 INSERT OVERWRITE によって定期的に書き換えられます。これにより、通常、Snowflakeはバージョン間で変更された内容を検出できません。

  • パイプラインは、行系統の前にある外部管理のApache Iceberg™ v2テーブルから読み取ります。

  • 一部の動的テーブルは、サポートされていない増分構築のためにフルリフレッシュモードを使用する必要がありますが、下流のテーブルは増分処理の恩恵を受けます。

動的テーブルの主キーの型

Snowflakeは、動的テーブルの2種類の主キーユースケースをサポートしています。1）行レベルの変更追跡、2）動的テーブル自体の一意のキーの導出。

主キーの行レベルの系統ベース変更追跡

ベーステーブルに RELY プロパティが設定されている主キー制約がある場合、Snowflakeはそのキーを使用して、下流の動的テーブルの行レベルの変更を追跡します。これは通常、テーブルのバージョンをまたがった変更の追跡を防ぐ INSERT OVERWRITE によってベーステーブルが定期的に書き換えられる場合に特に便利です。

信頼性の高い主キーを使用すると、Snowflakeは内部の変更追跡列に依存する代わりに、主キーの値を比較することで、リフレッシュ間で変更された行を識別します。これにより、基礎となるデータが完全に置き換えられた場合でも、増分処理が可能になります。

ベーステーブルの主キーの RELYプロパティは次のように設定します。

ALTER TABLE my_base_table ALTER CONSTRAINT my_pk_constraint RELY;

一意のキー導出

Snowflakeは、動的テーブルのクエリ定義から信頼性の高い一意のキーを自動的に取得できます。たとえば、次の SQL 構築は派生した一意のキーを生成します。

  • GROUP BY:各グループは正確に1つの出力行を生成するため、グループ化列は一意のキーを形成します。

  • QUALIFY ROW_NUMBER() = 1:フィルターはパーティションごとに正確に1行を保持するため、パーティションバイ列は一意のキーを形成します。

  • 信頼性の高いベーステーブルの主キー:ベーステーブルの主キーは、動的テーブルの一意のキーとして使用されます。

Snowflakeは、派生主キーを動的テーブルの一意の制約として登録します。これらの制約はクエリ構造に起因するため、追加の検証を行わなくても完全に信頼できます。

動的テーブルに派生主キーがあるかどうかを確認するには、次を実行します。

SHOW UNIQUE KEYS IN my_dynamic_table;

主キーを使用するタイミング

主キーは次のシナリオで役立ちます。

INSERT OVERWRITE ワークロードの変更追跡を改善する

ベーステーブルが INSERT OVERWRITE によって定期的に書き換えられる場合、Snowflakeは標準的な変更追跡列を使用して、変更内容を検出することはできません。主キーによって、Snowflakeはキー値で行を比較し、実際の変更のみを処理して、動的テーブルの完全な再計算を回避します。

フルリフレッシュ動的テーブルの下流で増分リフレッシュを有効にする

通常、増分リフレッシュモードの動的テーブルは、フルリフレッシュモードの動的テーブルの下流にあることはできません。上流のフルリフレッシュ動的テーブルにシステム派生の一意のキーがある場合、Snowflakeはフルリフレッシュ間の変更を計算でき、下流のテーブルを増分リフレッシュできるようになります。これにより、増分パイプラインの主なブロッカーが削除されます。

パイプラインで変更の伝播を低減する

主キーは、パイプラインの各ステージで値ベースの変更削減を可能にします。Snowflakeは、主キーが同一の値を持つ旧バージョンと新バージョンの両方に存在する行をフィルターすることができ、下流のテーブルに反映される変更の量を減らすことができます。

主な動作

  • 下流の増分リフレッシュのオプトイン:派生した一意のキーを持つフルリフレッシュ動的テーブルから読み取る動的テーブルで増分リフレッシュを使用するには、下流のテーブルで明示的に REFRESH_MODE = INCREMENTAL を設定する必要があります。REFRESH_MODE = AUTO の設定は FULL に解決され続けます。

  • 主キーベースの変更追跡サポートを確認する:SHOW UNIQUE KEYS IN <dt_name> を使用して動的テーブルに派生の一意のキーがあるかどうかを確認します。あるいは、 REFRESH_MODE = INCREMENTAL で下流の動的テーブルを作成し、作成が成功したかどうかを確認します。

  • マスキングポリシー:主キー列をわかりにくくするマスキングポリシーは、Snowflakeが変更追跡にこれらのキーを使用することを防ぎます。この場合、Snowflakeは標準の変更追跡列にフォールバックします。

次のステップ

例と実装のガイダンスについては、 主キーを使用して動的テーブルパイプラインを最適化する を参照してください。

CREATE DYNAMIC TABLE の完全な構文については、 CREATE DYNAMIC TABLE を参照してください。