Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Processamento de captura de dados de alterações (CDC)
Esta página explica a captura de dados de alterações (CDC) no Google Cloud Cortex Framework
no BigQuery. O BigQuery foi concebido para armazenar e analisar novos dados de forma eficiente.
Processo de CDC
Quando os dados são alterados no sistema de dados de origem (como o SAP), o BigQuery não modifica os registos existentes. Em alternativa, as informações atualizadas são adicionadas como um novo registo. Para evitar duplicados, tem de aplicar uma operação de união posteriormente. Este processo é denominado tratamento de captura de dados de alterações (CDC).
A base de dados para SAP inclui a opção de criar scripts para o Cloud Composer ou o Apache Airflow para unir
ou upsert os novos registos resultantes das atualizações e manter apenas a versão mais recente num novo conjunto de dados. Para que estes scripts funcionem, as tabelas têm de ter alguns campos específicos:
operation_flag: este indicador indica ao script se um registo foi inserido, atualizado ou eliminado.recordstamp: esta data/hora ajuda a identificar a versão mais recente de um registo. Esta flag indica se o registo é:
- Inserido (I)
- Atualizado (U)
- Eliminado (D)
Ao usar o processamento de CDC, pode garantir que os seus dados do BigQuery
refletem com precisão o estado mais recente do seu sistema de origem.
Isto elimina as entradas duplicadas e oferece uma base fiável para a análise de dados.
Estrutura do conjunto de dados
Para todas as origens de dados suportadas, os dados dos sistemas a montante são primeiro replicados
num conjunto de dados do BigQuery (source ou replicated dataset)
e os resultados atualizados ou unidos são inseridos noutro conjunto de dados
(conjunto de dados de CDC). As vistas de relatórios selecionam dados do conjunto de dados da CDC para garantir que as ferramentas e as aplicações de relatórios têm sempre a versão mais recente de uma tabela.
O fluxo seguinte mostra como o processamento de CDC para SAP, dependente do operational_flag e do recordstamp.
Figura 1. Exemplo de processamento de CDC para SAP.
O fluxo seguinte representa a integração das APIs em dados não processados e
processamento de CDC para o Salesforce, dependente dos campos Id e SystemModStamp
produzidos pelas APIs Salesforce.
Figura 2. Integração de APIs
em dados não processados e processamento de CDC para o Salesforce.
Algumas ferramentas de replicação podem unir ou inserir os registos quando os inserem no BigQuery, pelo que a geração destes scripts é opcional. Neste caso, a configuração só tem um conjunto de dados. O conjunto de dados de relatórios obtém registos atualizados para relatórios
desse conjunto de dados.
Exceto em caso de indicação contrária, o conteúdo desta página é licenciado de acordo com a Licença de atribuição 4.0 do Creative Commons, e as amostras de código são licenciadas de acordo com a Licença Apache 2.0. Para mais detalhes, consulte as políticas do site do Google Developers. Java é uma marca registrada da Oracle e/ou afiliadas.
Última atualização 2025-08-21 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]
