Pular para o conteúdo principal
Última atualização em

Captura de dados de alterações (CDC) e Snapshots

Engenheiros de dados muitas vezes precisam replicar dados de fontes upstream do Databricks — como bancos de dados relacionais (Oracle, Postgres, SQL Server) — para o Databricks para analítica, relatórios e machine learning. À medida que os sistemas operacionais mudam, as tabelas analíticas devem permanecer sincronizadas com essas alterações.

Algumas equipes precisam refletir o estado atual de seus bancos de dados operacionais para relatórios e analítica. Outros precisam preservar um histórico completo de alterações para fins de auditabilidade, requisitos regulamentares ou analítica do cliente.

A captura de dados de alteração (CDC, na sigla em inglês) trata um banco de dados como um conjunto de alterações, em vez de um banco de dados estático completo. O diagrama a seguir mostra que, quando uma linha em uma tabela de origem que contém dados de funcionários é atualizada, ela gera um novo conjunto de linhas em um feed CDC que contém apenas as alterações. Cada linha do feed do CDC normalmente contém metadados adicionais, incluindo a operação, como UPDATE , e uma coluna que pode ser usada para ordenar deterministicamente cada linha no feed do CDC, para que você possa lidar com atualizações fora de ordem. Por exemplo, a coluna sequenceNum no diagrama a seguir determina a ordem das linhas no feed do CDC:

Visão geral da captura de dados de alterações (CDC).

O CDC permite apenas visualizar as alterações nos dados para transações mais simples ao atualizar o banco de dados em um sistema downstream. Também é possível visualizar a história do banco de dados, se isso for um requisito.

O desafio é que os sistemas de origem fornecem dados em diferentes formatos. Alguns emitem feeds de alteração que capturam alterações individuais (inserções, atualizações e exclusões). Outros apenas fornecem Snapshots periódicos de toda a tabela. Cada formato requer diferentes abordagens de processamento para manter as tabelas downstream precisas e atualizadas.

Historicamente, as equipes dependeram de MERGE INTO lógica personalizada para aplicar essas alterações — seja a partir de feeds de alterações ou comparando snapshots. Essa abordagem é complexa e propensa a erros, exigindo tabelas de preparação, funções de janela e premissas de sequenciamento que são difíceis de compreender e manter à medida que os pipelines evoluem.

Esta página descreve os dois formatos de CDC (SCD Tipo 1 e Tipo 2), o que é o CDC em detalhes, e como tirar proveito do CDC, mesmo quando os dados de origem não o suportam, usando snapshots.

Quais são os benefícios do CDC?​

A captura de dados de alterações (CDC) oferece vários benefícios em suas cargas de trabalho.

  • Os dados de alteração são geralmente menores que o conjunto de dados completo, e as alterações podem ser processadas por consultas downstream como atualizações incrementais nos dados.
  • Os dados de alteração podem ser armazenados de uma forma que permite reconstruir registros como estavam em um momento específico, oferecendo um histórico completo para auditoria, relatórios pontuais ou análise de tendências.
  • Dados de alteração permitem chaves substitutas estáveis ao longo do tempo.

Como as alterações são aplicadas: Estado atual ou histórico completo das alterações​

Dimensões que mudam lentamente (SCD) definem como as alterações a montante são aplicadas e modeladas depois que chegam às tabelas analíticas. Organizações podem usar abordagens diferentes com base em suas necessidades de dados. O SCD tipo 1 permite que você salve apenas o estado atual do dataset. SCD Tipo 2 salva o histórico completo de alterações no dataset. Esta seção descreve estes em mais detalhes.

SCD Tipo 1: estado atual apenas​

O SCD Tipo 1 sobrescreve dados antigos com dados novos sempre que ocorrem alterações, mantendo apenas a versão mais recente de cada registro. O histórico não é retido.

Utilize SCD Tipo 1 quando:

  • Basta o estado atual dos dados.
  • Deseja-se que as views materializadas a jusante sejam atualizadas incrementalmente em vez de recomputadas por completo.
  • São necessárias chaves substitutas estáveis para junções.

Apenas a versão mais recente dos dados está disponível em SCD1. É uma abordagem direta, que pode ser pensada como armazenando apenas a tabela final. Se um registro mudar de Owner para Manager,, somente Manager permanece na tabela:

Visão geral da captura de dados de alterações (CDC) SCD tipo 1.

SCD Tipo 2: Acompanhamento Histórico​

O SCD Tipo 2 mantém um registro histórico completo criando várias versões de dados ao longo do tempo, cada uma com registro de data/hora e metadados. As colunas __START_AT e __END_AT definem o período de validade para cada versão de um registro. Registros ativos têm __END_AT = NULL. É possível visualizar o estado do dataset como era em qualquer ponto no tempo.

Use SCD Tipo 2 quando:

  • Auditabilidade ou requisitos regulatórios exigem acompanhamento histórico.
  • A analítica do cliente exige a compreensão de como as entidades evoluíram ao longo do tempo.
  • A lógica de negócios exige relatórios pontuais.
  • É necessário analisar tendências ou comparar estados históricos.

Processamento SCD tipo 2 mantém um registro histórico de alterações de dados. Por exemplo, se um registro atualmente tem o campo de função definido como Manager, você também pode ver que a função foi previamente definida como Owner. Na imagem a seguir, foi exatamente o que aconteceu com o registro de Chris. É possível identificar o registro atual por ter um valor null para o campo end_at:

Captura de dados de alterações (CDC) SCD Tipo 2: visão geral.

O que é um feed de CDC?​

A captura de dados de alterações (CDC) é um padrão de integração de dados que captura as alterações feitas nos dados em um sistema de origem: inserções, atualizações e exclusões. Em vez de processar dataset inteiros, o CDC gera feeds que contêm apenas os registros modificados.

Por exemplo, se houver uma tabela de funcionários no Oracle com 50 linhas, e o cargo de um funcionário mudar, o feed do CDC contém um único registro UPDATE para esse funcionário. Isso permite que o Databricks processe apenas os registros alterados em vez de ler a tabela de origem inteira em cada execução.

Cada registro do CDC do banco de dados de origem inclui:

  • O tipo de operação (INSERT, UPDATE, DELETE)
  • Os valores de dados para o registro
  • Um número de sequência ou timestamp para ordenação determinística

O número de sequência garante que as chegadas tardias ou fora de ordem sejam aplicadas corretamente. Bancos de dados transacionais como SQL Server, MySQL e Oracle geram feeds de CDC nativamente. As tabelas Delta também geram seu próprio feed CDC, conhecido como Feed de Dados de Alteração (CDF), tornando o processamento de alterações de fontes Delta simples também.

O que é um Snapshot?​

Um snapshot representa o estado completo de uma tabela em um ponto específico no tempo. Ao contrário dos feeds CDC que capturam apenas as alterações, os snapshots contêm todas as linhas da tabela de origem.

As equipes nem sempre habilitam os feeds do CDC em bancos de dados operacionais por diversos motivos:

  • Custo (o CDC pode aumentar a carga nos bancos de dados de produção)
  • Preocupações de desempenho na base de dados de origem
  • Sistemas legados que não suportam CDC
  • Restrições organizacionais (as equipes que gerenciam a ingestão não são proprietárias dos bancos de dados de origem)

Quando um feed de alterações não está disponível, a ingestão baseada em snapshots é a única opção. As capturas de tela podem vir de:

  • Exportações periódicas de bancos de dados relacionais (Oracle, Postgres, SQL Server)
  • Despejos de arquivos no armazenamento em cloud de sistemas a montante
  • Tabelas Delta (cada versão da tabela é efetivamente um Snapshot)
  • OpenSharing de tenants a montante

Como os snapshots não capturam alterações em nível de registro, identificar o que mudou requer comparar os registros entre os snapshots para inferir inserções, atualizações e exclusões.

Processar automaticamente feeds de CDC​

O Databricks simplifica o processamento de CDC por meio da API AUTO CDC nos Pipelines Declarativos do Lakeflow Spark. Esta API foi projetada para processar alterações de feeds do CDC em bancos de dados de origem ou tabelas Delta com o Change Data Feed habilitado.

Use AUTO CDC quando algum destes for verdadeiro:

  • Seu sistema de origem gera um feed de dados alterados (CDF)
  • Está sendo feita a leitura de uma tabela Delta com a alteração do feed de dados ativada.
  • Você tem um fluxo de CDC de um banco de dados relacional (através de ferramentas como Debezium ou Oracle GoldenGate)

AUTO CDC manipula automaticamente os registros fora de sequência ao processar eventos na ordem definida pela coluna de sequenciamento. A coluna de sequenciamento deve ser uma representação crescente e monótona da ordem correta dos eventos, com uma atualização distinta por key em cada valor de sequenciamento. Os valores de sequenciamento NULL não são suportados. Para SCD Tipo 2, Lakeflow Spark Declarative Pipelines propaga valores de sequenciamento para as colunas __START_AT e __END_AT da tabela de destino.

Hidratação inicial: ao replicar uma tabela de banco de dados operacional existente no Databricks, você precisa primeiro carregar todos os dados históricos antes de processar as alterações contínuas. AUTO CDC oferece suporte a isso por meio de once flows , um modo que processa todos os dados disponíveis uma única vez e depois para. Após a conclusão do carregamento inicial, use um fluxo no modo triggered ou contínuo para o processamento contínuo de CDC. Isto garante uma lógica consistente para carregamentos em massa e incrementais.

Processar snapshots automaticamente​

Quando os feeds de CDC não estão disponíveis, o Databricks fornece a API AUTO CDC FROM SNAPSHOT. Esta API foi projetada para ingestão baseada em Snapshots; ela compara Snapshots consecutivos , gera um feed de alterações sintético e aplica a lógica de SCD Tipo 1 ou Tipo 2 na tabela de destino. A tabela de destino pode fornecer um feed CDC (chamado feed de dados de alterações (CDF) em tabelas Delta) do tipo SCD Tipo 1 ou Tipo 2 para consultas downstream.

AUTO CDC FROM SNAPSHOT é compatível apenas na interface de pipeline Python. Os snapshots devem ser processados em ordem crescente de versão; se um snapshot fora de ordem for detectado, ele será ignorado. Processamento a jusante, como uma view materializada que consulta a saída de um dataset AUTO CDC FROM SNAPSHOT, obtém os benefícios do CDC, como a capacidade de incrementalizar e chaves substitutas estáveis.

nota

AUTO CDC FROM SNAPSHOT não é apenas para carregamentos iniciais. É projetado para processamento contínuo quando os Snapshots forem o único formato disponível. Cada vez que um novo snapshot chega, a API o compara com o snapshot anterior para derivar alterações e um fluxo de dados de alterações.

Utilize AUTO CDC FROM SNAPSHOT quando:

  • O CDC não está ativado no banco de dados de origem
  • Você só tem acesso a Snapshots periódicos (dumps completos da tabela)
  • Para usufruir dos benefícios do CDC para processamento incremental ou para ter um histórico completo de alterações.

AUTO CDC FROM SNAPSHOT lida automaticamente com o seguinte:

  1. Compara Snapshots consecutivos para identificar registros inseridos, atualizados e excluídos.
  2. Gera um fluxo de alteração sintético com base nas diferenças entre snapshots.
  3. Aplica a mesma lógica de SCD que AUTO CDC ao compute de SCD Tipo 1 ou Tipo 2.
nota

AUTO CDC FROM SNAPSHOT Apenas registra as alterações de um Snapshot para o próximo, e não captura as alterações intermediárias. Por exemplo, se você recebe Snapshots diários e um usuário alterar seu endereço duas vezes em um dia (de A para B e, em seguida, de B para C), seu feed de alterações pode ir diretamente de A para C, porque você só recebeu Snapshots para esses momentos.

Padrões de processamento de Snapshot​

AUTO CDC FROM SNAPSHOT Suporta dois padrões para determinar versões de Snapshot.

Processamento de Snapshot usando o tempo de ingestão do pipeline

O Snapshot é lido no momento da execução do pipeline, e o horário de ingestão é usado como a versão do Snapshot. Um novo Snapshot é incorporado a cada atualização do pipeline. Quando um pipeline é executado em modo contínuo, vários snapshots são ingeridos com base na configuração do intervalo de disparo do fluxo.

Use esse padrão quando os snapshots chegarem regularmente e em ordem, e você puder confiar no carimbo de data/hora da execução do pipeline para o versionamento.

Processamento de Snapshot usando funções de versão

É fornecida uma função que especifica qual versão do Snapshot processar no momento da execução do pipeline. A função retorna uma tupla: (DataFrame, version_number). A API processa os Snapshots na ordem definida pelos números de versão. Se um Snapshot fora de ordem for detectado, o Snapshot é ignorado.

Usar este padrão quando:

  • Vários Snapshots podem chegar ao mesmo tempo e necessitam de processamento sequencial.
  • Os Snapshots podem chegar fora de ordem.
  • É necessário ter controle explícito sobre a ordenação de Snapshot.

Capacidades adicionais do CDC​

Alterar as operações nos alvos AUTO CDC​

Diferentemente das tabelas de transmissão padrão, as tabelas do Unity Catalog que são destinos AUTO CDC oferecem suporte a INSERT, UPDATE, DELETE e MERGE instruções mesmo enquanto o pipeline está em execução. Para obter detalhes e limitações, consulte Adicionar, alterar ou excluir dados em uma tabela de transmissão de destino.

Lendo feeds de alterações de dados de destinos AUTO CDC​

AUTO CDC Tabelas de transmissão de destino podem emitir sua própria Alteração do Feed de Dados (CDF), permitindo que pipelines downstream consumam alterações a partir da saída AUTO CDC. Para obter detalhes, consulte Ler um feed de dados alterados de uma tabela de destino AUTO CDC.

Métricas e monitoramento​

AUTO CDC captura automaticamente num_upserted_rows e num_deleted_rows métricas em cada execução do pipeline. Para obter detalhes, consulte Tópicos Avançados de AUTO CDC.

Acompanhamento de subconjuntos de colunas para SCD Tipo 2​

Por padrão, SCD tipo 2 cria uma nova versão sempre que há uma alteração em qualquer valor de coluna. AUTO CDC permite especificar quais colunas rastrear para história, para que as alterações em colunas não rastreadas atualizem a versão atual no local, em vez de criar um novo registro de história. Isso reduz os custos de armazenamento e a complexidade das consultas, enquanto preserva o histórico para atributos críticos. Para um exemplo, veja Rastrear um subconjunto de colunas com SCD tipo 2.

Recomendações​

Utilize a captura de dados de alterações (CDC) quando se deseja trabalhar apenas com as alterações em seus dados, por exemplo, para permitir que views materializadas a jusante sejam atualizadas incrementalmente. Também use o CDC quando se deseja manter um histórico das alterações nos seus dados, por exemplo, para saber quem tinha qual função em um determinado momento.

Use as APIs AUTO CDC quando for necessário replicar dados upstream para o Databricks e mantê-los sincronizados com as alterações na origem. A API adequada depende de como o seu sistema de origem expõe as alterações:

  • Use AUTO CDC quando sua origem emite um feed de alterações — por exemplo, um banco de dados relacional com o CDC habilitado (via ferramentas como Debezium ou Oracle GoldenGate), uma tabela Delta com o Change Data Feed habilitado, ou qualquer origem que produz uma transmissão de inserções, atualizações e exclusões com uma coluna de sequenciamento.
  • Use AUTO CDC FROM SNAPSHOT quando sua origem não oferecer suporte a CDC e fornecer apenas dumps periódicos de tabela completa. Esta API infere alterações ao comparar snapshots consecutivos e gera um feed de alterações sintético, para que se obtenham os mesmos benefícios de processamento de SCD, mesmo sem um feed de CDC nativo.

Em ambos os casos, escolha o SCD tipo 1 se precisar apenas do estado atual de cada registro, ou o SCD tipo 2 se precisar preservar um histórico completo de alterações para auditoria, relatórios pontuais ou análise de tendências.

Passos seguintes​

Nesta página