コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
変更データ キャプチャ（CDC）処理
このページでは、BigQuery の Google Cloud Cortex Framework 内の変更データ キャプチャ（CDC）について説明します。BigQuery は、新しいデータを効率的に保存して分析するように設計されています。
CDC プロセス
ソースデータ システム（SAP など）でデータが変更されても、BigQuery は既存のレコードを変更しません。代わりに、更新された情報は新しいレコードとして追加されます。重複を回避するには、後で結合オペレーションを適用する必要があります。このプロセスは、変更データ キャプチャ（CDC）処理と呼ばれます。
Data Foundation for SAP には、更新の結果として生成された新しいレコードを統合または upsert して、新しいデータセットに最新バージョンのみを保持する Cloud Composer または Apache Airflow のスクリプトを作成するオプションが含まれています。これらのスクリプトを機能させるには、テーブルに特定のフィールドが必要です。
operation_flag: このフラグは、レコードが挿入、更新、削除されたかどうかをスクリプトに伝えます。recordstamp: このタイムスタンプは、レコードの最新バージョンを特定するのに役立ちます。このフラグは、レコードが次のいずれかであることを示します。
CDC 処理を利用することで、BigQuery データにソースシステムの最新の状態が正確に反映されるようにできます。これにより、重複エントリが排除され、データ分析の信頼できる基盤が確立されます。
データセットの構造
サポートされているすべてのデータソースで、アップストリーム システムのデータはまず BigQuery データセット（source または replicated dataset）に複製され、更新または統合された結果が別のデータセット（CDC データセット）に挿入されます。レポートビューは CDC データセットからデータを選択し、レポートツールとアプリケーションに常に最新バージョンのテーブルが提供されるようにします。
次のフロー図は、operational_flag と recordstamp に応じて SAP の CDC 処理がどのように行われるかを示しています。
図 1SAP の CDC 処理の例。次のフロー図は、Salesforce API によって生成された Id フィールドと SystemModStamp フィールドに応じて、API から Salesforce の元データと CDC 処理への統合を示しています。
図 2API から Salesforce の元データと CDC 処理への統合。一部のレプリケーション ツールでは、BigQuery にレコードを挿入するときにレコードを統合またはアップサートできるため、これらのスクリプトの生成は任意です。この場合、設定にはデータセットが 1 つだけあります。レポート データセットは、そのデータセットからレポート用に更新されたレコードを取得します。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-09-04 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[[["\u003cp\u003eChange Data Capture (CDC) in Google Cloud Cortex Framework for BigQuery adds updated information as new records instead of modifying existing ones.\u003c/p\u003e\n"],["\u003cp\u003eA merge or upsert operation is required after CDC to avoid duplicates and keep only the latest version of each record in a new dataset.\u003c/p\u003e\n"],["\u003cp\u003eThe process relies on \u003ccode\u003eoperation_flag\u003c/code\u003e and \u003ccode\u003erecordstamp\u003c/code\u003e fields to identify whether a record was inserted, updated, or deleted, and to track the most recent version.\u003c/p\u003e\n"],["\u003cp\u003eData is replicated into a \u003ccode\u003esource\u003c/code\u003e dataset, and the merged results are inserted into a separate CDC dataset, ensuring reporting tools always use the latest data version.\u003c/p\u003e\n"],["\u003cp\u003eSome replication tools can merge or upsert records during insertion into BigQuery, making the creation of CDC scripts optional, and allowing a single dataset approach.\u003c/p\u003e\n"]]],[],null,["# Change Data Capture (CDC) processing\n====================================\n\nThis page guides you through Change Data Capture (CDC) within Google Cloud Cortex Framework\nin BigQuery. BigQuery is designed for efficiently\nstoring and analyzing new data.\n\nCDC process\n-----------\n\nWhen data changes in your source data system\n(like SAP), BigQuery doesn't modify existing records. Instead,\nthe updated information is added as a new record. To avoid duplicates, a\nmerge operation needs to be applied afterwards. This process is\ncalled [Change Data Capture (CDC) processing](/bigquery/docs/migration/database-replication-to-bigquery-using-change-data-capture).\n\nThe Data Foundation for SAP includes the option to create scripts for\nCloud Composer or Apache Airflow to [merge](/bigquery/docs/reference/standard-sql/dml-syntax#merge_statement)\nor `upsert` the new records resulting from updates and only keep the\nlatest version in a new dataset. For these scripts to work the tables\nneed to have some specific fields:\n\n- `operation_flag`: This flag tells the script whether a record was inserted, updated, or deleted.\n- `recordstamp`: This timestamp helps identify the most recent version of a record. This flag indicates whether the record is:\n - Inserted (I)\n - Updated (U)\n - Deleted (D)\n\nBy utilizing CDC processing, you can ensure that your BigQuery\ndata accurately reflects the latest state of your source system.\nThis eliminates duplicate entries and provides a reliable foundation for\nyour data analysis.\n\nDataset structure\n-----------------\n\nFor all supported data sources, data from upstream systems are first replicated\ninto a BigQuery dataset (`source` or `replicated dataset`),\nand the updated or merged results are inserted into another dataset\n(CDC dataset). The reporting views select data from the CDC dataset,\nto ensure the reporting tools and applications always have the latest version\nof a table.\n\nThe following flow shows how the CDC processing for SAP, dependent on\nthe `operational_flag` and `recordstamp`.\n\n**Figure 1**. CDC processing example for SAP.\n\nThe following flow depicts the integration from APIs into Raw data and\nCDC processing for Salesforce, dependent on the `Id` and `SystemModStamp`\nfields produced by Salesforce APIs.\n\n**Figure 2**. Integration from APIs into Raw data and CDC processing for Salesforce.\n\nSome replication tools can merge or upsert the records when\ninserting them into BigQuery, so the generation of these\nscripts is optional. In this case, the setup only has a single\ndataset. The reporting dataset fetches updated records for reporting\nfrom that dataset."]]
