Snowflake の増分転送を設定する
このガイドでは、Snowflake から BigQuery への増分データ転送を構成する方法について説明します。増分転送では、前回の転送実行以降に変更されたデータのみを転送できるため、転送時間とコストを削減できます。
増分転送の制限事項
Snowflake の増分転送には、次の制限があります。
- upsert 書き込みモードを使用するには、主キー列を指定する必要があります。詳細については、増分転送の主キーを定義するをご覧ください。
- 主キーはソーステーブル内で一意である必要があります。重複が存在する場合、BigQuery の統合オペレーションの結果に一貫性がなく、ソースデータと一致しない可能性があります。
- 増分転送によるスキーマ変更の自動処理はサポートされていません。ソーステーブルのスキーマが変更された場合は、BigQuery テーブルのスキーマを手動で更新する必要があります。
- 増分転送は、ソースデータの変更が少数のパーティションに集中している場合に最適です。更新がソーステーブル全体に分散している場合、多くのパーティションをスキャンする必要があるため、増分転送のパフォーマンスが大幅に低下する可能性があります。データ転送間で変更される行が多い場合は、代わりに完全転送を使用することをおすすめします。
- Snowflake の一部のオペレーション(
CREATE OR REPLACE TABLEやCLONEなど)では、元のテーブル オブジェクトとそれに関連付けられた変更追跡履歴が上書きされる可能性があります。これにより、既存のデータ転送が古くなり、増分転送を再開するには新しい完全同期が必要になります。 - 増分転送は、変更の追跡のために Snowflake のデータ保持期間内に収まるように、十分な頻度で実行する必要があります。最後の転送がこの期間外に実行された場合、次の転送は完全転送になります。
データの取り込みの動作
Snowflake 転送を設定するときに、転送構成で [完全] または [増分] の書き込み設定を選択することで、BigQuery へのデータの読み込み方法を指定できます。増分転送はプレビュー版でサポートされています。
完全データ転送を構成すると、データ転送のたびに Snowflake データセットからすべてのデータが転送されます。または、増分データ転送(プレビュー版)を構成して、データ転送ごとにデータセット全体を読み込むのではなく、最後のデータ転送以降に変更されたデータのみを転送することもできます。データ転送で [増分] を選択した場合は、[追加] または [Upsert] の書き込みモードを指定して、データの増分転送中に BigQuery にデータを書き込む方法を定義する必要があります。以降のセクションでは、使用可能な書き込みモードについて説明します。
[追加] 書き込みモード
追加書き込みモードでは、宛先テーブルに新しい行のみが挿入されます。このオプションでは、既存のレコードをチェックせずに転送されたデータが厳密に追加されるため、このモードでは宛先テーブルでデータが重複する可能性があります。
追加モードを選択した場合は、ウォーターマーク列を選択する必要があります。Snowflake コネクタがソーステーブルの変更を追跡するには、ウォーターマーク列が必要です。
Snowflake の転送では、レコードの作成時にのみ更新され、その後の更新では変更されない列を選択することをおすすめします。たとえば、CREATED_AT 列です。
[Upsert] 書き込みモード
[Upsert] 書き込みモードでは、主キーを確認して、宛先テーブルの行を更新するか、新しい行を挿入します。主キーを指定すると、Snowflake コネクタは、宛先テーブルをソーステーブルと同期するために必要な変更を特定できます。データ転送中に指定された主キーが宛先 BigQuery テーブルに存在している場合、Snowflake コネクタはソーステーブルの新しいデータでその行を更新します。データ転送中に主キーが存在していない場合、Snowflake コネクタは新しい行を挿入します。
upsert モードを選択する場合は、ウォーターマーク列と主キーを選択する必要があります。
- Snowflake コネクタがソーステーブルの変更を追跡するには、ウォーターマーク列が必要です。
- 行が変更されるたびに更新されるウォーターマーク列を選択します。
UPDATED_AT列またはLAST_MODIFIED列に類似した列をおすすめします。
- 行が変更されるたびに更新されるウォーターマーク列を選択します。
主キーは、行の挿入または更新が必要かどうかを Snowflake コネクタが判断するために必要なテーブルの 1 つ以上の列です。
テーブルのすべての行で一意の null 以外の値を含む列を選択します。システムが生成した識別子、一意の参照コード(自動増分式の ID など)、不変の時間ベースのシーケンス ID を含む列をおすすめします。
データの損失や破損を防ぐため、選択する主キー列には一意の値が必要です。選択した主キー列の一意性に疑問がある場合は、代わりに [追加] 書き込みモードを使用することをおすすめします。
増分データ転送で upsert 書き込みモードを使用するには、カスタム スキーマ ファイルで主キーを定義する必要があります。
増分取り込みの動作
データソースのテーブル スキーマを変更すると、これらのテーブルからの増分データ転送は、次の方法で BigQuery に反映されます。
| データソースの変更 | 増分取り込みの動作 |
|---|---|
| 新しい列の追加 | 宛先の BigQuery テーブルに新しい列が追加されます。この列の以前のレコードはすべて null 値になります。 |
| 列の削除 | 削除された列は、宛先 BigQuery テーブルに残ります。この削除された列への新しいエントリには null 値が入力されます。 |
| 列のデータ型を変更する | このコネクタは、
ALTER COLUMN DDL ステートメントでサポートされているデータ型変換のみをサポートします。これ以外のデータ型変換を行うと、データ転送が失敗します。問題が発生した場合は、新しい転送構成を作成することをおすすめします。 |
| 列の名前を変更する | 元の列は宛先 BigQuery テーブルにそのまま残り、更新された名前の新しい列が宛先テーブルに追加されます。 |
増分転送用のカスタム スキーマ ファイル
カスタム スキーマ ファイルを使用して、増分転送の主キーを定義し、スキーマ マッピングをカスタマイズできます。カスタム スキーマ ファイルは、ソーススキーマとターゲット スキーマを記述する JSON ファイルです。
Upsert モードの増分転送では、1 つ以上の列を主キーとして指定する必要があります。これを行うには、カスタム スキーマ ファイルで PRIMARY_KEY 使用タイプを使用して列にアノテーションを付けます。
次の例は、O_ORDERKEY と O_ORDERDATE を orders テーブルの主キーとして定義するカスタム スキーマ ファイルを示しています。
{
"databases": [
{
"name": "my_db",
"originalName": "my_db",
"tables": [
{
"name": "orders",
"originalName": "orders",
"columns": [
{
"name": "O_ORDERKEY",
"originalName": "O_ORDERKEY",
"usageType": [
"PRIMARY_KEY"
]
},
{
"name": "O_ORDERDATE",
"originalName": "O_ORDERDATE",
"usageType": [
"PRIMARY_KEY"
]
}
]
}
]
}
]
}
変更の追跡を有効にする
増分 Snowflake 転送を設定する前に、次のコマンドを使用して、各ソーステーブルで変更の追跡を有効にする必要があります。
ALTER TABLE DATABASE_NAME.SCHEMA_NAME.TABLE_NAME SET CHANGE_TRACKING = TRUE;
テーブルで変更追跡が有効になっていない場合、Snowflake コネクタはデフォルトでそのテーブルの完全なデータ転送を行います。
次のステップ
Snowflake の増分転送に必要なすべての手順を構成したら、Snowflake の転送構成で増分転送を有効にできます。詳細については、Snowflake 転送を設定するをご覧ください。