--- title: "CDCデータ転送 - 転送先 - Snowflake | TROCCO Docs" slug: "cdc-data-destination-snowflake" updated: 2026-09-10T02:12:58Z published: 2026-09-10T02:12:58Z canonical: "documents.trocco.io/cdc-data-destination-snowflake" --- > ## Documentation Index > Fetch the complete documentation index at: https://documents.trocco.io/llms.txt > Use this file to discover all available pages before exploring further. # CDCデータ転送 - 転送先 - Snowflake 本ページでは、CDCデータ転送における転送先 - Snowflakeについて説明します。 接続に関する設定については、[接続情報 - Snowflake](/docs/connection-configuration-snowflake)を参照ください。 ## データ転送の仕組み 転送先 - Snowflakeでは、以下の流れでデータを転送します。 1. スキーマ・テーブルの準備：転送先スキーマ（スキーマの自動生成オプションが有効な場合）と生ログスキーマを作成し、転送先テーブルと生ログテーブルを自動作成します。 2. 生ログテーブルへの書き込み：転送元から取得した変更データを、**Snowpipe Streaming**を利用して生ログテーブルに書き込みます。この処理ではウェアハウスを使用しません。Snowpipe Streamingについて、詳しくは[Snowflake公式ドキュメント - Snowpipe Streaming](https://docs.snowflake.com/ja/user-guide/snowpipe-streaming/data-load-snowpipe-streaming-overview)を参照ください。 3. 転送先テーブルへのマージ：転送先設定で指定したウェアハウスを利用して、生ログテーブルの未反映データを転送先テーブルに反映します。差分転送時は`MERGE`クエリ、全件転送時は`CREATE OR REPLACE TABLE`クエリを実行します。 4. 反映済みデータの記録：転送先テーブルへ反映した生ログテーブルのレコードに反映済みの印を付け、次回以降の処理対象から除外します。 ### アーキテクチャ 以下は、転送元 - MySQL・転送先 - Snowflakeにおけるアーキテクチャです。 **初回転送（全件転送）時** ![cdc-data-destination-snowflake_全件転送時のアーキテクチャ](https://cdn.document360.io/3a3bae1e-f157-487f-8798-01e9d820e760/Images/Documentation/cdc-data-destination-snowflake-2026-08-27-17-13-00.png) **差分転送時** ![cdc-data-destination-snowflake_差分転送時のアーキテクチャ](https://cdn.document360.io/3a3bae1e-f157-487f-8798-01e9d820e760/Images/Documentation/cdc-data-destination-snowflake-2026-08-27-17-14-00.png) ### マージ処理の内容 - 主キーごとに最新の変更イベントのみが転送先テーブルに反映されます。 - 転送元で削除されたレコードは、転送先テーブルからも物理的に削除されます。削除フラグ列を残す論理削除には対応していません。 - 全件転送時の`CREATE OR REPLACE TABLE`クエリには`COPY GRANTS`句が付与されます。そのため、転送先テーブルに付与した権限はテーブル再作成後も保持されます。 データ転送に伴うSnowflakeの課金対象 - 生ログテーブルへの書き込みは、Snowpipe Streaming（高パフォーマンスアーキテクチャ）としての課金対象です。詳しくは、[Snowflake公式ドキュメント - Snowpipe Streaming high-performance architecture: Understand your costs](https://docs.snowflake.com/ja/user-guide/snowpipe-streaming/snowpipe-streaming-high-performance-cost)を参照ください。 - マージ処理は、転送先設定で指定したウェアハウスの課金対象です。 - 生ログテーブルに保存されたデータは、Snowflakeのストレージ課金対象です。 QUERY_TAGによるコスト分析 CDCデータ転送がマージ処理時にSnowflakeウェアハウスで実行するクエリには、TROCCOのジョブ情報を含むJSON形式の`QUERY_TAG`が設定されます。 JSONには、`trocco_job_type`・`trocco_sync_type`・`trocco_job_id`・`trocco_executor_type`が含まれます。 `SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY`ビューの`QUERY_TAG`列を参照することで、TROCCOのジョブ単位でSnowflake側のコストを分析できます。 以下は、CDCデータ転送が実行したクエリの履歴を確認するクエリの例です。 ``` SELECT start_time, query_tag, warehouse_name, total_elapsed_time, query_text FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY WHERE TRY_PARSE_JSON(query_tag):trocco_job_type = 'cdc' ORDER BY start_time DESC; ``` ## 事前準備 ### Snowflake接続情報の作成 CDCデータ転送では、**キーペア認証**または**プログラムによるアクセストークン認証**のSnowflake接続情報にのみ対応しています。 接続情報の作成手順については、[接続情報 - Snowflake](/docs/connection-configuration-snowflake)を参照ください。 AWS PrivateLinkを利用した接続情報 AWS PrivateLinkを有効にした接続情報は利用できません。 今後の対応を検討しています。 ### 権限とロールの準備 接続情報で利用するロールに、あらかじめ以下の権限を付与する必要があります。 | 項目 | 権限 | 内容 | | --- | --- | --- | | [仮想ウェアハウス権限](https://docs.snowflake.com/ja/user-guide/security-access-control-privileges.html#virtual-warehouse-privileges) | `USAGE` | 指定したウェアハウスでマージ処理などのクエリを実行できるようにします。 | | [データベース権限](https://docs.snowflake.com/ja/user-guide/security-access-control-privileges.html#database-privileges) | `USAGE`・`CREATE SCHEMA` | 転送先のデータベースを使用できるようにします。ジョブ実行毎に生ログスキーマを作成するため、`CREATE SCHEMA` を含む権限が必要です。 | | [スキーマ権限](https://docs.snowflake.com/ja/user-guide/security-access-control-privileges.html#schema-privileges) | `USAGE`・`CREATE TABLE` | 転送先テーブルと生ログテーブルを自動作成できるようにします。 既存のスキーマを転送先スキーマ・生ログスキーマとして指定する場合に必要です。 TROCCOが自動作成したスキーマには`OWNERSHIP`が付与されるため、個別の付与は不要です。 | | [テーブル権限](https://docs.snowflake.com/ja/user-guide/security-access-control-privileges.html#table-privileges) | `OWNERSHIP` | 転送先スキーマに同名の既存テーブルがある場合に必要です。全件転送時に既存テーブルを削除・再作成するために利用します。 | #### クエリサンプル 以下の条件を例に、ロールに権限を付与するクエリサンプルをご紹介します。 実際にロールに権限を付与する場合は、適宜内容を読み替えてください。 - 作成するロール：`TROCCO_CDC_ROLE` - ロールを付与するユーザー：`TROCCO_USER` - 対象ウェアハウス：`TROCCO_WAREHOUSE` - 対象データベース：`TROCCO_DATABASE` - 対象スキーマ（転送先スキーマ）：`ANALYTICS` ``` -- ロールを作成可能なロールに切り替える USE ROLE ACCOUNTADMIN; -- ロールを新規作成する CREATE ROLE TROCCO_CDC_ROLE; -- 指定したユーザーにロールを使用可能にする GRANT ROLE TROCCO_CDC_ROLE TO USER TROCCO_USER; -- ユーザーに対し、作成したロールをデフォルトで使用するロールにする ALTER USER TROCCO_USER SET DEFAULT_ROLE = TROCCO_CDC_ROLE; -- ウェアハウスの利用権限をロールに付与する GRANT USAGE ON WAREHOUSE TROCCO_WAREHOUSE TO ROLE TROCCO_CDC_ROLE; -- データベースの利用権限をロールに付与する GRANT USAGE ON DATABASE TROCCO_DATABASE TO ROLE TROCCO_CDC_ROLE; -- スキーマの作成権限をロールに付与する GRANT CREATE SCHEMA ON DATABASE TROCCO_DATABASE TO ROLE TROCCO_CDC_ROLE; -- 既存のスキーマを転送先スキーマとして利用する場合のみ実行する GRANT USAGE ON SCHEMA TROCCO_DATABASE.ANALYTICS TO ROLE TROCCO_CDC_ROLE; GRANT CREATE TABLE ON SCHEMA TROCCO_DATABASE.ANALYTICS TO ROLE TROCCO_CDC_ROLE; ``` ## 設定項目 ### STEP1 詳細設定 | 項目 | 必須 | デフォルト値 | 内容 | | --- | --- | --- | --- | | 追加されたテーブル・カラムの追従設定 | No | カラムのみを自動追従(推奨) | 追加されたテーブル・カラムを転送先のテーブルに自動で追従するかを選択できます。詳しくは、[CDCスキーマ自動追従](/docs/cdc-schema-auto-prepagation)を参照ください。 | | バックフィル設定 | No | 有効(推奨) | テーブル・カラムの自動追従において、ジョブ実行時に追加や変更があったテーブルの全件転送を行うかどうかを設定します。詳しくは、[CDCスキーマ自動追従](/docs/cdc-schema-auto-prepagation)を参照ください。 | | テーブル連続失敗回数上限 | No | 20 | テーブルの同期が連続して失敗した際に、該当テーブルの同期を停止するまでの失敗回数を設定します。 停止した場合でも、他のテーブルの同期は継続されます。 値を空にすると上限なしとなり、エラーが発生しても同期を停止しません。詳しくは、[同期対象のテーブル例外について](/docs/cdc-data-destination-snowflake#%E5%90%8C%E6%9C%9F%E5%AF%BE%E8%B1%A1%E3%81%AE%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E4%BE%8B%E5%A4%96%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6)を参照ください。 | ### STEP1 転送先設定 | 項目 | 必須 | デフォルト値 | 内容 | | --- | --- | --- | --- | | 生ログスキーマ | Yes | 「スキーマ」名に「_raw_trocco_logs」のsuffixをつけた値 | CDCデータ転送の中間テーブル（生ログテーブル）を保存するスキーマを指定します。 生ログスキーマ名は、指定した値にかかわらず**大文字**で作成されます。 | | スキーマの自動生成オプション | Yes | 自動生成しない | 転送先のスキーマが存在しない場合に、スキーマを自動生成するかを選択します。 | 以下の設定項目については、[転送先 - Snowflake](/docs/data-destination-snowflake)の該当する項目を参照ください。 - Snowflake接続情報 - ウェアハウス - データベース - スキーマ 生ログスキーマ・生ログテーブルの取り扱い 生ログスキーマおよび生ログテーブルの内容は、CDCデータ転送設定の利用中に変更・削除しないでください。 転送データの重複・欠損が発生する可能性があります。 スキーマ名について 転送先テーブルごとに`__TROCCO_RAW_LOGS_<テーブル名>`という名前（大文字）で生ログテーブルが作成されるため、大文字小文字のみが異なる転送先テーブル名を同時に指定できません。 反映済みデータの保持 転送先テーブルへ反映済みの生ログデータは、自動では削除されません。 生ログテーブルは全件転送時に再作成されるため、そのタイミングで反映済みデータはリセットされます。 ### STEP2 スキーマ設定 | 項目 | 内容 | | --- | --- | | カラム | 転送対象のカラム選択や、転送先でのカラム名・カラム型を設定します。転送先カラム型の設定については、[転送先カラム型の設定](/docs/cdc-data-destination-snowflake#%E8%BB%A2%E9%80%81%E5%85%88%E3%82%AB%E3%83%A9%E3%83%A0%E5%9E%8B%E3%81%AE%E8%A8%AD%E5%AE%9A)を参照ください。 | ### 転送先カラム型の設定 転送先に出力する際のカラムの型を指定できます。スキーマ設定のカラム設定にて、対象カラムの**転送先カラム型**のドロップダウンから指定してください。 デフォルトでは、転送元のカラム型から自動マッピングされた型が選択されています。 出力型を変更すると、差分列に**型変更あり**バッジが表示されます。出力型を元の自動マッピング値に戻すまで、バッジは継続して表示されます。 #### 対応する型変換 選択可能な型は、転送元カラムの型ごとに以下のとおりです。Snowflakeのデータ型表記で記載しています。 | 自動マッピングされる型 | 選択可能な出力型 | | --- | --- | | `timestamp_ntz`（タイムゾーンを持たないtimestamp） | `timestamp_ntz` / `timestamp_tz` / `varchar` `timestamp_ntz`はタイムゾーンを持たないため、`timestamp_tz`へ変更した場合はUTCとして扱われます。 | | `timestamp_tz`（タイムゾーン付きtimestamp） | `timestamp_tz` / `varchar` | | `date` | `date` / `varchar` | | `time` | `time` / `varchar` | | `number`（整数型・10進数型） | `number` / `varchar` 整数型は`NUMBER(38,0)`、10進数型は`NUMBER(38,9)`として作成されます。 | | `float`（浮動小数点型） | `float` / `varchar` | | `boolean` | `boolean` / `varchar` | | `binary` | `binary` / `varchar` | 出力型が固定となる型 `varchar`と`variant`は、他の型への変更はできず固定です。 `varchar`への変換時の挙動 - タイムゾーンを持たないtimestampを`varchar`に変換した場合、エポックミリ秒（整数）の文字列として書き込まれます。 - `date`を`varchar`に変換した場合、エポック（1970-01-01）からの経過日数の文字列として書き込まれます。 - `time`を`varchar`に変換した場合、深夜0時からの経過マイクロ秒数の文字列として書き込まれます。 - 数値型を`varchar`に変換した場合は、元の値を保持したまま文字列として書き込まれます。 #### 注意事項 - 出力型変更が利用できるのは、**スキーマ設定タブで選択中のテーブル**のみです。未選択テーブルでは出力型ドロップダウンが無効化されます。 - 出力型を変更してスキーマ設定を保存する場合、**該当テーブルの全件転送（再読み込み）が必須**です。スキーマ設定の保存時に確認モーダルが表示され、保存と同時に全件転送のジョブが作成されます。Snowflake側のテーブルは一度削除され、変更後の出力型で再作成されます。 - 転送元カラムの型変更がCDCで検知された場合は、従来どおり転送先テーブルの型は自動的に追従します。 - `timestamp_ntz`型はタイムゾーン情報を持たないため、`timestamp_tz`型へ変換する際はUTCとしてキャストされます。転送元のデータベースが暗黙的にUTC以外のタイムゾーンを前提としてタイムゾーンなしの日時カラムを保持している場合、Snowflake側で意図しない時刻として扱われる可能性があります。 - タイムゾーンの変更が必要な場合は、Snowflake側の後続処理でタイムゾーン変換を適用してください。 ## 同期対象のテーブル例外について 差分転送において転送ジョブ内の一部テーブルでエラーが発生した場合、エラーが発生したテーブルのみ例外として転送をスキップできます。 エラーが発生したテーブルが存在するジョブは、ジョブ自体は成功しますが「テーブルエラーあり」と表示されます。 失敗回数が連続失敗回数上限を超えた場合、テーブルの転送はスキップされます。 ### スキップされたテーブルへの対応 スキップされたテーブルを再度転送する場合は、「全件転送（選択テーブル）」または「全件転送（全テーブル）」を実行してください。 転送先のテーブルは一度削除され再作成されます。 連続失敗回数が多い場合 差分転送に失敗するたびに未反映の生ログデータが徐々に増大するため、転送に失敗する回数が多くなると、遅延やエラーが発生する可能性があります。 テーブル連続失敗回数は原則設定することを推奨します。 全件転送時のエラー 全件転送では、いずれかのテーブルの転送に失敗した場合、ジョブ全体が失敗します。 転送元でのエラー 転送元でエラーが発生した場合は、すべてのテーブルの転送がエラーとなり、ジョブ全体が失敗します。