Openflow Connector for Google BigQuery について

注釈

このコネクタは、 Snowflakeコネクタ規約 に従うものとします。

|BigQueryOF|はGoogle BigQueryプロジェクトをSnowflakeに接続し、スケジュールに従って選択したデータセット、テーブル、およびビューからデータを複製します。コネクタは各テーブルに対して初期のフルロードを実行し、その後、BigQueryのネイティブ変更追跡機能を使用して増分更新を行います。ビューは、トランケートしてロードする（truncate and load）戦略を使用して複製されます。

ユースケース

コネクタは、次のユースケースをサポートしています。

  • Snowflakeへの複製: 下流の分析とモデリングのために、BigQueryからSnowflakeにデータセットを継続的にミラーリングします。増分変更は、10分の遅延ウィンドウを伴うスケジュールで取り込まれます。

  • 選択的な複製: 制御しながら広範囲をカバーするために、名前または正規表現フィルターを使用して、含めるリージョン、データセット、テーブル、およびビューを定義します。

  • 移行と変更のキャプチャ: 移行のために1回限りのスナップショットロードを実行し、テーブルの同期を保つためにBigQueryの変更履歴を使用して増分同期を実行します。

  • ビューの複製: 構成可能なスケジュールで、トランケートしてロードする戦略を使用して、標準およびマテリアライズドBigQueryビューをSnowflakeに複製します。

テーブル複製のライフサイクル

テーブルの複製サイクルは、スキーマ検出とデータの初期スナップショットロードから始まります。サイクルは、データがSnowflakeにインジェストされた後、増分同期に移行します。

  1. スキーマイントロスペクション: コネクタはソーステーブルのスキーマを検出し、データ型を検証したうえで、対応する宛先スキーマとテーブルをSnowflakeに作成します。

  2. スナップショットロード: スキーマとテーブルを作成した後、コネクタはBigQueryテーブルからSnowflakeに既存データをすべてコピーします。このプロセスは、構成内のテーブルごとに順次実行されます。

  3. 増分同期: 初期ロードが完了すると、テーブルはスケジュールに基づく増分同期モードに移行します。実行ごとに、コネクタはBigQueryのCHANGES関数を使用して、前回の同期以降に発生した行レベルの変更（挿入、更新、削除）のジャーナルを読み取ります。これらの変更は取得され、Snowflakeの宛先テーブルにマージされます。

Openflow要件

最小ランタイムサイズは``Medium``である必要があります。大量のデータを複製する場合は、より大きなランタイムとマルチノードのOpenflow設定を使用してください。

制限事項

  • BigQueryは、ソースデータの取得に使用されるデータストリームが少なくとも6時間有効であることを保証します。その結果、データストリームの有効期限が切れることを防ぐために、ソーステーブルの読み取りプロセスは6時間以内に完了する必要があります。100GBを超えるデータ量のテーブルをインジェストする場合は、より大きなマルチノードランタイムを使用する必要があります。

  • BigQueryのBIGNUMERIC型は、SnowflakeのNUMBER型（38桁）よりも高い精度（最大76桁）をサポートします。コネクタは、Snowflakeの制限を超えるBIGNUMERIC列から値をインジェストできません。

  • コネクタは外部テーブルの複製をサポートしていません。

  • ビューの複製では、トランケートしてロードする（truncate and load）戦略のみを使用します。増分同期（CDC）はビューではサポートされていません。

  • 増分同期では、更新と削除を正しく処理するために主キーが必要です。主キーのないテーブルの場合、コネクタは削除をサポートせず、更新を新しい挿入として扱います。

    注釈

    主キー制約が満たされていることを確認する必要があります。主キーとしてマークされたフィールドが一意でない場合、増分モード中にデータの不整合が発生する可能性があります。

  • コネクタは、増分更新に`BigQueryのCHANGES <https://cloud.google.com/bigquery/docs/reference/standard-sql/time-series-functions#changes>`_関数を使用します。この関数は過去10分のテーブル履歴をクエリできないため、増分モードで複製されたデータはソースから最小10分のタイムラグがあります。

  • 増分同期プロセスは、BigQuery CHANGES関数のため、最大24時間のデータウィンドウに制限されています。テーブルの複製ラグがこの期間を超えると、コネクタは同期を続行するために変更ウィンドウを24時間に短縮します。この短縮により、データが失われる可能性があります。

  • コネクタは、BigQuery CHANGES関数の他のすべての制限を継承します。詳しくは、`BigQuery CHANGES関数のドキュメント<https://cloud.google.com/bigquery/docs/reference/standard-sql/time-series-functions#changes>`_を参照してください。

ビューの複製

コネクタは、BigQueryからSnowflakeへの標準ビューとマテリアライズドビューの複製をサポートします。テーブルの複製とは異なり、ビューは増分同期（CDC）をサポートしません。代わりに、コネクタは**トランケートしてロードする**（truncate and load）戦略を使用します。同期サイクルごとに、コネクタはSnowflakeの宛先テーブルのデータをソースビューの現在の内容で完全に置き換えます。

ビューの同期頻度は、**View Sync Frequency**パラメーターを使用して、テーブルの増分同期頻度とは別に構成されます。実行は重複しません。サイクルに構成された間隔よりも時間がかかる場合、次の実行は前の実行が終了するのを待ちます。

**Included View Names**パラメーターと**Included View Names Regex**パラメーターを使用して、複製するビューをフィルターできます。これらのフィルターは、複製用に選択されたすべてのデータセットに適用されます。

コネクタは、ビューのインジェスト中にBigQueryで一時テーブルを作成します。**Temporary Table Dataset**パラメーターを使用して、これらの一時テーブル専用のデータセットを指定します。Snowflakeは、この目的のためにインジェストされたデータセットを使用せず、一時テーブルには別のデータセットを使用することをお勧めします。

データ型マッピング

コネクタは、BigQueryデータ型を対応するSnowflakeデータ型にマップします。

BigQuery データ型

Snowflakeデータ型

BIGNUMERIC

NUMBER

NUMERIC

NUMBER

GEOGRAPHY

VARCHAR

DATETIME

TIMESTAMP_NTZ

JSON

OBJECT

STRUCT

OBJECT

RANGE

OBJECT

INTERVAL

OBJECT

TIMESTAMP

TIMESTAMP_NTZ

DATE

DATE

TIME

TIME

INT64 / INTEGER

NUMBER

FLOAT64

FLOAT

BOOL / BOOLEAN

BOOLEAN

STRING

VARCHAR

BYTES

BINARY

ARRAY

ARRAY

Google BigQueryでデータの変更を追跡する

コネクタの増分同期機能は、`BigQueryのネイティブCHANGES関数<https://cloud.google.com/bigquery/docs/reference/standard-sql/time-series-functions#changes>`_に基づいて構築されています。ソーステーブルで変更履歴を有効にすると、BigQueryはすべての行レベルの変更（挿入、更新、および削除）の内部ジャーナルを維持します。

コネクタは、構成された増分同期頻度スケジュールでこのジャーナルをクエリし、変更のフィードを取得します。コネクタは、これらの変更を同じBigQueryデータセット内のジャーナルテーブルに実体化します。このジャーナルテーブルは、一貫した命名規則に従っています: <sourceTableName>_<incremental_number>_<hash>_journal

これらのジャーナルテーブルは、複製プロセス中、コネクタによって完全に管理され、Snowflakeの最終的な宛先テーブルにデータをマージするために使用されます。

警告

ジャーナルテーブルはいかなる方法でも変更しないでください。ジャーナルテーブルを変更すると、同期プロセスが中断され、データ整合性の問題が発生する可能性があります。

マージ操作では、主キー（PK）を持つテーブルと持たないテーブルとで変更の処理が異なります。

主キーを持つテーブル

主キーを持つテーブルの場合、コネクタは次のようにデータの変更を処理します。

挿入と更新:

``INSERT``または``UPDATE``として識別された行は、対応するSnowflakeテーブルに「アップサート」されます。

削除:

データ履歴を保持するために、コネクタはソフト削除戦略を使用します。削除された行をSnowflakeから物理的に削除する代わりに、コネクタはターゲット行に対して``UPDATE``を実行し、``_SNOWFLAKE_DELETED``列を``TRUE``に設定します。

主キーのないテーブル

主キーのないテーブルの場合、コネクタは次のようにデータの変更を処理します。

挿入と更新:

``INSERT``または``UPDATE``として識別された行は同じ方法で扱われ、対応するSnowflakeテーブルに挿入されます。

削除:

サポート対象外です。

注釈

コネクタは、宛先テーブルスキーマの作成時に``_SNOWFLAKE_DELETED``（BOOLEAN）列を自動的に追加します。

構成された同期頻度スケジュールと実際の同期頻度

Incremental Sync Frequencyスケジュールは、テーブルの同期頻度を決定します。指定したスケジュールが、テーブルの同期に必要な実際の時間よりも頻繁である場合、システムは指定したスケジュールに従いません。これは、増分サイクルは順番に実行する必要があり、重複することはできないために発生します。

スキーマ進化

コネクタは、ソースBigQueryテーブルのいくつかの一般的なスキーマの変更をサポートします。次のスキーマの変更が検出され、Snowflake宛先テーブルに反映されます。

列の追加:

BigQueryに追加された新しい列は、対応するSnowflakeテーブルに自動的に追加されます。

列の削除（ソフト削除）:

BigQueryで列がドロップされた場合、コネクタはSnowflakeで「ソフト削除」を実行します。宛先テーブルからは列はドロップされません。代わりに、列名の末尾に``_SNOWFLAKE_DELETED``サフィックスを追加することで名前が変更されます。たとえば、``my_column``は``my_column_SNOWFLAKE_DELETED``になります。これにより、Snowflakeの履歴データが保持されます。

列の名前変更:

列の名前変更操作は、2段階のプロセスです。

  1. 元の列は「ソフト削除」され、``_SNOWFLAKE_DELETED``サフィックスが追加されて名前が変更されます。

  2. 新しい名前の新しい列がSnowflakeテーブルに追加されます。

主キーの変更:

主キーの追加、削除、変更がサポートされています。

データ型の変更:

既存の型を拡大する変更のみが許容されます。列の型を狭めるか、互換性のない型に変換する変更はサポートされておらず、そのテーブルの複製に失敗します。

次のステップ

コネクタの設定方法については、次のトピックをご参照ください。