CDC baseado em push no Unity Catalog com Zerobus Ingest e Debezium

Os dados em bancos de dados operacionais impulsionam as decisões de negócios, e boa parte dessa análise acontece no lakehouse. Levar os dados até lá é difícil quando o banco de dados fica em uma rede corporativa privada, em um ambiente controlado pelo cliente ou em uma sub-rede restrita cujas políticas de rede bloqueiam conexões de entrada de serviços externos.

Muitas equipes precisam de suas alterações do PostgreSQL no Databricks, mas a equipe responsável pelo banco de dados também quer ser dona da captura. Essa equipe executa o processo que lê o log de gravação antecipada (write-ahead log) e decide quais conexões saem da sua rede. Por outro lado, as alterações vão parar em tabelas Delta governadas nas quais pipelines e analistas podem trabalhar.

Debezium é uma ferramenta open-source comum cuja implantação completa pode ser gerenciada pelas equipes para extrair um feed de captura de dados de alteração (CDC) de um banco de dados. Ela fica próxima ao banco de dados, lê seu log de gravação antecipada e envia eventos para fora. O Zerobus Ingest é o destino, uma interface de envio (push) que grava registros diretamente nas tabelas Delta do Unity Catalog. O conector open-source Zerobus Server para o Debezium une os dois sem o uso de um cluster Kafka tradicional entre a captura e o lakehouse.

Engenheiros da NVIDIA e do Databricks se uniram para criar este conector e o enviaram para o projeto open-source Debezium. O Databricks criou o conector tipado do Zerobus Ingest. Em seguida, a NVIDIA contribuiu com o modo envelope, que traz o evento de alteração completo do Debezium, junto com as salvaguardas de entrega associadas, como chaves de idempotência e confirmação durável antes que os offsets de origem avancem. O conector Zerobus Ingest é lançado na versão 3.7 do Debezium Server.

Esta publicação aborda o que o Debezium e o Zerobus fazem, o envelope de alteração bruto que a NVIDIA contribuiu para o conector e como os eventos recebidos se tornam tabelas de estado atual ou históricas. Para um passo a passo prático, incluindo uma execução ao vivo de uma tabela PostgreSQL local para uma tabela de estado atual, consulte a postagem complementar no blog da comunidade Databricks. 

O Desafio

A replicação confiável de alterações de bancos de dados operacionais no lakehouse precisa resolver vários problemas de uma só vez:

• Capturar inserções, atualizações e exclusões de forma confiável. Uma linha que é criada, modificada e posteriormente removida deve gerar um fluxo fiel para cada evento. Isso deve incluir exclusões, que abordagens baseadas em consulta do tipo "copiar a tabela" geralmente ignoram.
• Manter as evidências necessárias para a ordenação. A lógica de downstream que reconstrói o estado atual deve aplicar alterações na ordem de origem, para replicar corretamente a tabela de origem.
• Evitar sobrecarregar o banco de dados de origem. Fazer polling no banco de dados de forma agendada (SELECT ... WHERE updated_at > ?) adiciona carga de consulta e tem baixa escalabilidade.
• Funcionar com redes privadas / controladas pelo cliente. Quando o banco de dados está atrás de um perímetro altamente restrito, sabemos que pode ser desafiador se conectar a esses sistemas e ingerir os dados.
• Evitar configurar o Kafka puramente como transporte. O Kafka é um barramento de eventos poderoso, mas operar um cluster exclusivamente para mover eventos de CDC de um banco de dados para um lakehouse representa um custo operacional significativo para equipes que não precisam dele para outros fins.
• Salvar os dados de forma que possam ser facilmente processados. O fluxo de alterações deve chegar em um formato que o lakehouse possa processar e consultar, e não em um silo que exija outra etapa de exportação.

Diante desses requisitos, precisamos começar com a arquitetura de como os dados fluiriam da origem para o destino.

Arquitetura de Destino Geral

Neste blog, vamos explorar uma arquitetura tradicional de barramento de mensagens em comparação com uma arquitetura que usa o Zerobus Ingest.

Arquitetura com um barramento de mensagens:

Em muitos ambientes corporativos, a conectividade de saída de dentro de um perímetro é muito mais fácil de permitir do que o acesso de entrada. Quando sua equipe deseja executar uma implantação do agente de extração de feed de alterações, um modelo de envio local permite que os dados fluam para fora em direção a um destino. Em uma configuração tradicional, isso seria um barramento de mensagens como o Kafka. Executar o Kafka exige recursos para planejamento de capacidade — para prever o número de brokers necessários para lidar com o pico de carga no dimensionamento físico e para estimar o número de partições no dimensionamento lógico, que os consumidores precisam para acompanhar a taxa de produção. Isso exige uma equipe dedicada com experiência na implantação e no gerenciamento desse Kafka.

Assim que os dados chegam ao Kafka, você tem a próxima tarefa a realizar, que é replicar esses eventos para o lakehouse. Isso pode ser feito por meio da implantação de jobs de ingestão, como com o Spark, Kafka Connector ou outras ferramentas. O resultado é uma arquitetura de dois saltos do Debezium até o lakehouse.

Arquitetura com o Zerobus Ingest:

Quando seu único destino é o lakehouse, o Zerobus permite ignorar saltos intermediários, como o barramento de mensagens. Isso simplifica sua arquitetura de ponta a ponta e elimina a necessidade de implantar e gerenciar a infraestrutura do Kafka para o trânsito de dados. Ao usar o Zerobus como um conector com o Debezium, ele continua funcionando durante seus horários de pico, sem necessidade de ajustes.

O que é o Debezium?

O Debezium é uma plataforma de captura de dados de alteração (CDC) baseada em logs e open-source. Em vez de consultar tabelas por polling, ele lê o log de transações de um banco de dados, por exemplo, o log de gravação antecipada (WAL) do PostgreSQL, o binlog do MySQL e os fluxos de alteração (change streams) do MongoDB. Em seguida, ele emite cada alteração como um evento estruturado. O projeto começou em 2015 e hoje oferece suporte a um amplo ecossistema de conectores (PostgreSQL, MySQL, SQL Server, Oracle, MongoDB e muito mais).

Cada evento de alteración carrega um envelope consistente:

• before — o estado da linha antes da alteração (null para inserções)
• after — o estado da linha após a alteração (null para exclusões)\
• op — a operação: c (criar/inserir), u (atualizar), d (excluir), r (ler/snapshot)
• source — metadados: banco de dados, esquema, tabela, número de sequência do log WAL (LSN), ID da transação, flag de snapshot
• ts_ms — carimbo de data/hora do evento

O Debezium adiciona uma carga mínima ao banco de dados principal devido ao seu monitoramento de logs (log tailing) em vez de usar polling para capturar alterações com baixa latência, além de preservar a ordem de confirmação.

Independente (Debezium Server) vs. a implantação do Kafka Connect

O Debezium possui dois modelos operacionais. Um que é executado no Kafka Connect e outro que é um "servidor independente" (stand-alone server) que pode ser configurado em computação básica.

O Debezium Server, o ambiente de execução autônomo, atua como seu agente no lado da origem que monitora os logs de transação e envia eventos de alteração diretamente para o Zerobus Ingest do Databricks, sem que um cluster Kafka atue como transporte.

A solução: Debezium + Zerobus Ingest

Portanto, identificamos o Debezium como nosso monitor de logs. Agora precisamos enviar os eventos para o Databricks.

O Zerobus Ingest é um serviço de ingestão sem servidor baseado em push que grava dados diretamente em Delta tables governadas pelo Unity Catalog, sem precisar executar um corretor de mensagens. Os produtores se conectam a um endpoint do Zerobus e transmitem registros que caem em uma Delta table de formato aberto. Ele foi construído para lidar com alta taxa de transferência e cargas de trabalho altamente concorrentes. Ao pular a etapa de um corretor de mensagens, conseguimos simplificar a arquitetura e a manutenção de ter que dimensionar e executar pipelines de ingestão para mover os dados para o lakehouse.

Combinado com o Debezium, seus pipelines de CDC ficarão mais ou menos assim:

• O Debezium observa o log do banco de dados e converte cada alteração em um evento de CDC.
• O Zerobus Ingest transporta esses eventos diretamente para o Databricks e os grava em uma Delta table — sem nenhum cluster Kafka como camada de transporte intermediária.
• O Databricks recebe o fluxo de alterações em uma Delta table e pode processá-lo em tabelas curadas downstream.

O Zerobus Ingest é apenas de inserção (append-only). Assim que os eventos de alteração chegam, o próximo passo é construir uma tabela dimensional do Tipo 1 executando um merge para obter a versão mais recente de cada combinação de chave primária fornecida.

Contribuição da NVIDIA: modo envelope

O destino Zerobus no Debezium oferece dois contratos de tabela. O modo Typed, que é o padrão, mapeia cada evento de alteração em uma tabela com as colunas próprias da origem. O modo Envelope, que foi uma contribuição da NVIDIA, grava o evento de alteração completo do Debezium em uma tabela fixa de nove colunas:

1. target_table
2. destination
3. partition
4. operation
5. idempotency_key
6. key
7. value
8. source_position
9. headers

Os registros podem ser codificados como JSON (armazenados em colunas VARIANT) ou Protobuf.

O modo envelope mantém as evidências necessárias para o processamento downstream. O source_position carrega a partição e o deslocamento de origem, incluindo o LSN do PostgreSQL. idempotency_key é uma identidade SHA-256 de cada evento, derivada de seu destino, partição, chave, operação e posição de origem, para que um evento reenviado receba a mesma chave. A chave identifica os eventos; ela não os ordena nem faz a desduplicação da tabela sozinha. 

Se um grupo posterior falhar, um grupo durável anterior poderá ser entregue novamente, portanto, a entrega é de pelo menos uma vez (at-least-once) e as duplicatas são tratadas downstream com idempotency_key. O modo envelope também filtra por destino e operação, e rejeita um registro grande demais antes da ingestão para que seu deslocamento nunca seja confirmado.

Modelagem de dados no Databricks

Assim que os eventos de CDC chegam ao Delta, um fluxo comum no estilo medalhão transforma o feed bruto de alterações em algo que analistas e aplicativos podem usar:

• Bronze: Os eventos de alteração brutos, conforme recebidos. No modo de envelope, isso representa uma linha por evento, carregando sua operação, imagens de linha antes/depois, posição de origem (LSN) e idempotency_key.
• Silver: Registros de alteração analisados, desduplicados por idempotency_key e ordenados por posição de origem. Uma representação utilizable dos dados de origem, com inserções/atualizações/exclusões interpretadas para reconstruir o estado atual.
• Gold: Os dados operacionais são transformados com dados de negócios para relatórios, como finanças, métricas de desempenho, etc.

Vale a pena mencionar brevemente duas formas de estruturar o feed de alterações:

• Tipo-1 (estado atual): compacta o log de alterações para que cada chave reflita seu valor mais recente — uma réplica do estado atual da tabela de origem.
• Tipo-2 (histórico): preserva cada versão ao longo do tempo, para que você possa consultar os dados como eles apareciam em qualquer momento.

O blog complementar de instruções na Databricks Community percorre isso de ponta a ponta com uma tabela PostgreSQL local. Ele configura o Debezium Server com o coletor Zerobus, verifica uma inserção, atualização e exclusão na tabela de envelope e, em seguida, cria a tabela do Tipo-1 (estado atual) com o AUTO CDC, ordenando as alterações pelo LSN de origem.

Conclusão

A escolha da arquitetura CDC correta depende em última análise das restrições de rede, preferências operacionais e infraestrutura existente da sua organização. 

Ao combinar o Debezium Server com o Zerobus Ingest, você pode implantar uma arquitetura de push local que faz streaming de alterações diretamente para tabelas Delta, sem precisar do Kafka como um transporte de mensagens intermediário ou depender de áreas de estágio (staging) no armazenamento de objetos em nuvem, simplificando o caminho de ingestão de ponta a ponta.

Isso mantém a captura do PostgreSQL sob o controle da equipe que gerencia o banco de dados, enquanto os dados chegam ao Unity Catalog. 

Primeiros passos

Para criar esse pipeline por conta própria, siga o guia passo a passo na Databricks Community. Ele executa alterações do PostgreSQL por meio do Debezium Server e do Zerobus Ingest em uma tabela do Unity Catalog e, em seguida, cria uma tabela de estado atual com o AUTO CDC. Para configurar o Zerobus Ingest e conhecer suas outras interfaces de ingestão, consulte a documentação do Zerobus Ingest.

Perguntas frequentes (FAQs)

O que é o sink do Debezium Zerobus Ingest?

É um sink no Debezium Server (o runtime independente do Debezium) que envia eventos de alteração diretamente para o Zerobus Ingest. O Zerobus Ingest os grava em tabelas Delta governadas pelo Unity Catalog, portanto, nenhum cluster Kafka fica entre a captura e o lakehouse. A NVIDIA e a Databricks colaboraram nessa contribuição de código aberto.

O que é o modo envelope?

O modo envelope grava cada evento de alteração completo do Debezium em uma tabela fixa de nove colunas, em vez de mapeá-lo para as próprias colunas da origem. A NVIDIA contribuiu com esse recurso para o sink. Ele preserva a operação, a chave, o valor, a posição de origem e uma chave de idempotência para processamento posterior. O modo tipado é o padrão.

O sink entrega cada alteração exatamente uma vez?

Não, a entrega é do tipo pelo menos uma vez (at-least-once). Se um grupo posterior de registros falhar, um grupo durável anterior poderá ser entregue novamente. Cada evento carrega uma idempotency_key, permitindo que você faça a desduplicação posteriormente com base nela.

Como transformar o feed de alterações em uma tabela de estado atual?

Use o AUTO CDC para criar uma tabela do Tipo 1 que mantenha a versão mais recente de cada chave. Ordene as alterações com base no LSN de origem para que sejam aplicadas na ordem correta da origem. Se preferir manter todas as versões ao longo do tempo, crie uma tabela do Tipo 2.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original