Organízate con las colecciones
Guarda y clasifica el contenido según tus preferencias.
Procesamiento de captura de datos de cambios (CDC)
En esta página se explica cómo usar la captura de datos de cambios (CDC) en Google Cloud Cortex Framework en BigQuery. BigQuery se ha diseñado para almacenar y analizar datos nuevos de forma eficiente.
Proceso de CDC
Cuando los datos cambian en tu sistema de datos de origen (como SAP), BigQuery no modifica los registros. En su lugar, la información actualizada se añade como un nuevo registro. Para evitar duplicados, debe aplicarse una operación de combinación después. Este proceso se denomina procesamiento de captura de datos de cambios (CDC).
Data Foundation for SAP incluye la opción de crear secuencias de comandos para Cloud Composer o Apache Airflow con el fin de combinar o upsert los nuevos registros resultantes de las actualizaciones y conservar solo la versión más reciente en un nuevo conjunto de datos. Para que estas secuencias de comandos funcionen, las tablas deben tener algunos campos específicos:
operation_flag: esta marca indica a la secuencia de comandos si se ha insertado, actualizado o eliminado un registro.recordstamp: esta marca de tiempo ayuda a identificar la versión más reciente de un registro. Esta marca indica si el registro es:
- Insertada (I)
- Actualizado (U)
- Eliminado (E)
Al utilizar el procesamiento de CDC, puedes asegurarte de que tus datos de BigQuery reflejen con precisión el estado más reciente de tu sistema de origen.
De esta forma, se eliminan las entradas duplicadas y se proporciona una base fiable para el análisis de datos.
Estructura del conjunto de datos
En todas las fuentes de datos admitidas, los datos de los sistemas de origen se replican primero en un conjunto de datos de BigQuery (source o replicated dataset) y los resultados actualizados o combinados se insertan en otro conjunto de datos (conjunto de datos de CDC). Las vistas de informes seleccionan datos del conjunto de datos del CDC para asegurarse de que las herramientas y aplicaciones de informes siempre tengan la versión más reciente de una tabla.
En el siguiente flujo se muestra cómo se procesa el CDC de SAP, que depende de operational_flag y recordstamp.
Imagen 1. Ejemplo de procesamiento de CDC para SAP.
En el siguiente diagrama se muestra la integración de las APIs en los datos sin procesar y el procesamiento de CDC de Salesforce, que depende de los campos Id y SystemModStamp que producen las APIs de Salesforce.
Imagen 2. Integración de APIs
en datos sin procesar y procesamiento de CDC para Salesforce.
Algunas herramientas de replicación pueden combinar o insertar los registros cuando se insertan en BigQuery, por lo que la generación de estas secuencias de comandos es opcional. En este caso, la configuración solo tiene un conjunto de datos. El conjunto de datos de informes obtiene los registros actualizados para generar informes a partir de ese conjunto de datos.
A menos que se indique lo contrario, el contenido de esta página está sujeto a la licencia Reconocimiento 4.0 de Creative Commons y las muestras de código están sujetas a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio web de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-08-21 (UTC).
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-08-21 (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."]]
