データベース・コネクタの概念¶

コネクタコンポーネント¶

Snowflake Databaseコネクタは、MarketplaceからSnowflakeアカウントにインストールされるSnowflake Native Appと、オンプレミスまたはクラウドのインフラストラクチャ内で実行される Agent アプリケーションで構成されます。

• Agent はソースデータベースに直接接続し、レプリケート対象として選択したテーブルの更新を追跡し、変更をSnowflakeアカウントにアップロードします。Agentは、Snowflakeおよびデータソースに接続するために1回限りの構成を必要とし、その後は新しいバージョンがリリースされたときにのみアップグレードします。それ以外は、Native Appを介して完全に制御および構成されます。

• Native Apps は、データのレプリケートプロセスを制御します。どのテーブルを追跡し、変更を受信し、それを宛先データベースにマージするかをAgentに指示します。インタラクションのほとんどは、Native Appで実行されます。新しいバージョンが利用可能になると、自動的にアップグレードされます。

Agentがローカルで実行されるこのモデルは、外部からの接続が閉ざされたネットワーク内のソースデータベースに、コネクタが安全にアクセスできるようにするために必要です。

1つのAgentインスタンスは常に1つのNative Appインスタンスに接続し、1つのNative Appは常に1つのAgentで動作します。切断されたネットワークからソースデータベースをレプリケートするなど、複数のAgentインスタンスを実行する必要がある場合は、Native Appの複数のインスタンスをインストールして構成する必要があります。サポートが必要な場合は、 Snowflakeサポートにお問い合わせください。

内部的には、コネクタは非同期のイベント駆動型のコマンド交換に依存しています。Native AppもAgentと通信して調整する必要があります。このため、コマンドの実行とそのコマンドの効果の確認の間に遅延が発生する場合があります。

データソース、テーブル、ジャーナル、宛先¶

コネクタを介したデータフローについて説明する場合、次のステージを区別します。

データソース

コネクタがレプリケートするテーブルを保持するデータベース。データベースエンジンに応じて、これはデータベース サーバー 全体、またはサーバー 内部 でホストされているデータベースの1つになります。

Agentがすべてのデータソースに直接接続できる限り、単一のコネクタインスタンスで複数のデータソースからレプリケートできます。

ソーステーブル

ソースデータベース内の特定のテーブル。コネクタによって変更が追跡され、その変更がSnowflakeにレプリケートされます。各データソースには、同じコネクタインスタンスによって同時にレプリケートされる複数のソーステーブルが含まれる場合があります。

データソース内のソーステーブルの直接の親は、Snowflake内の対応する宛先テーブルのスキーマになります。

ジャーナル

コネクタのNative Appによって所有および管理されるSnowflakeテーブル。ソーステーブルに適用されたすべての変更（挿入、更新、削除）を受け取って保存します。これはソーステーブルのデータの事実上の変更ログであり、その構造はデータベースエンジンが通常どのように変更をレプリカにブロードキャストするかを反映しています。

すべてのソーステーブルには、個別のジャーナルテーブルがあります。

宛先テーブル

コネクタがデータをレプリケートするアカウント内のSnowflakeテーブル。ソーステーブルごとに個別の宛先テーブルがあります。列名はソーステーブル内の名前を反映し、その型はソース列に対応するSnowflake型になります。

各宛先テーブルには、レプリケーション情報を含む列（_SNOWFLAKE_INSERTED_AT、 _SNOWFLAKE_UPDATED_AT、 _SNOWFLAKE_DELETED）も含まれており、指定された行の元の挿入、最終更新、削除のタイムスタンプをそれぞれ保持します。

宛先テーブルでは、ストリームを作成できるように変更追跡が事前に有効になっています。コネクタのNative Appは、 OWNERSHIP の付与をテーブル上に維持します。

スナップショットロードと増分ロード¶

新しく追加されたテーブルからのデータのレプリケートは、 スナップショットロード から始まります。Agentは、ソーステーブルに対して、単一の SELECT <列> ステートメントを実行し、すべての記録をSnowflakeの中間テーブルにストリーミングし、その後それらを宛先テーブルにコピーします。この操作はソースデータベースで大量のリソースを消費する可能性があり、大きなテーブルの場合は通常長い時間がかかります。最初の記録が宛先テーブルに表示されるまで待つ必要がある場合があります。

次のシナリオでは、スナップショットロードを繰り返して、以前にレプリケートされたデータを置き換え、ソーステーブルを宛先と同期することもできます。

• サポートされていないデータ型、サイズ、コネクタのバグ、またはその他の問題により、テーブルのレプリケーションが永久に失敗した場合。

• レプリケーションが一時停止され、再開された後、ソースデータベースの変更ログに、テーブルが最後にレプリケートされたとき以降のエントリが含まれなくなった場合。

最初のスナップショットが完了すると、テーブルのレプリケーションは 増分ロード に変わります。Agentはソースデータベースの変更ログを追跡し、これらの変更を対応するジャーナルテーブルにストリーミングし、そこから後で宛先テーブルにマージします。この読み込み、ストリーミング、マージのサイクルは、継続的に実行することも、スケジュールに従って実行することもできます。これらのモードの詳細については、 次のステップ および 次のステップ をご参照ください。

テーブルレプリケーションのライフサイクル¶

新しく追加されたソーステーブルのレプリケーションサイクルは、 スキーマイントロスペクション から始まります。ここでコネクタはソーステーブルの列、その名前、タイプを検出し、Snowflakeとコネクタの制限に対してそれらを検証します。検証に失敗するとこのステージは失敗し、サイクルが完了します。スキーマイントロスペクションが正常に完了すると、コネクタは空の宛先テーブルを作成します。

2つ目のステージは スナップショットロード で、コネクタはソーステーブルで使用可能なすべてのデータを宛先テーブルにコピーします。このステージで障害が発生するとサイクルも終了し、それ以上のデータはレプリケートされなくなります。正常に完了すると、ソーステーブルのデータセット全体が宛先テーブルで使用できるようになります。

最後に、テーブルは 増分ロード に移動し、コネクタはソーステーブルの変更を追跡し続け、それを宛先テーブルにコピーします。これは、テーブルがレプリケーションから削除されるまで続きます。このステージで失敗すると、問題が解決されるまで、ソーステーブルのレプリケーションが永久に停止します。

テーブルが現在どのレプリケーションフェーズにあるかを判断する方法については、 Snowflake Connector for MySQL のモニター および Snowflake Connector for PostgreSQL のモニター をご参照ください。

ソースから宛先へのデータフロー¶

コネクタは、スナップショットロードまたは増分ロードのどちらを実行しているかに応じて、ソーステーブルから宛先に異なる方法でデータを移動します。詳細については、 スナップショットロードと増分ロード をご参照ください。

継続的なレプリケーションとスケジュールされたレプリケーション¶

新しく追加されたデータソースのデフォルトのレプリケーションモードは 継続的 です。このモードでは、コネクタはデータの変更をできるだけ迅速にレプリケートすることを目的としています。これは、頻繁に変更されるデータソースに最適なモードであり、そのデータを低レイテンシでSnowflakeで使用できるようにする必要があります。

データソースを変更して、 スケジュール モードでレプリケートできます。このモードでは、データは固定スケジュールに従ってソーステーブルから宛先テーブルにバッチでコピーされます。これは、変更頻度が低いデータソースや、クレジット消費を削減する必要があり、Snowflakeで低レイテンシでデータを使用できるようにする必要がない場合に最適なモードです。

継続的なレプリケーションを実行している場合、増分ロードは「完了」として報告されることはありません。スケジュールモードでは、データのバッチごとに宛先テーブルにマージされた後に増分ロードが完了したと報告されます。スケジュールモードの「バッチ」は、前回のスケジュールされた実行から次のスケジュールされた実行が開始されるまでのすべての変更ログエントリで構成されます。

ウェアハウスのタイプ¶

コネクタの運用には、次の2つのウェアハウスが必要です。

• Operational Warehouse （Ops Warehouseとも呼ばれる）は、コネクタのコマンドと制御操作を実行するために使用されます。このウェアハウスは設定ウィザードによって自動的に作成され、最適なサイズは XS です。

• Compute Warehouse は、ジャーナルから宛先テーブルにデータを移動するマージタスクを実行するために使用されます。このウェアハウスは、設定ウィザードで作成することも、手動で作成することもできます。最適なサイズとタイプは、レプリケーションの規模に応じて異なります。

上記の区別は、大量のデータを移動するクエリと一緒にキューに入れられることなく、運用クエリがタイムリーに実行されるようにするために必要です。これは、Operational Warehouseをコネクタインスタンス間で 再利用できない こと、およびアカウント内の他のワークロードと共有してはならないことも意味します。

Compute Warehouseは、他のコネクタインスタンスやワークロードと 共有できます 。ただし、このウェアハウスを共有すると、宛先テーブルにデータが表示されるまでに遅延が生じる可能性があることに注意してください。