Databricks Zerobus CDC Remove Kafka do Caminho, Mantém a Captura com as Equipes de Banco de Dados

A Databricks apresentou um caminho de replicação de banco de dados que contorna o Kafka, mantendo a captura sob o controle da equipe de banco de dados. O Databricks Zerobus CDC combina o Zerobus Ingest, seu serviço gerenciado de ingestão, com o Debezium, uma plataforma open source de captura de alterações de dados. A captura de alterações de dados, ou CDC, registra mudanças no banco de dados para processamento em outro lugar. O atrativo é uma rota mais curta para análises, com responsabilidades de confiabilidade que ainda exigem engenharia deliberada.

A arquitetura aborda um problema organizacional específico: uma equipe de banco de dados pode permitir tráfego de saída, mas recusar conexões de entrada de um serviço externo de análises. O Apache Kafka, uma plataforma de streaming de eventos, já oferece suporte a arquiteturas com captura controlada pela origem. A mudança aqui é eliminar essa plataforma intermediária quando a Databricks é o destino pretendido.

Essa distinção importa para administradores de banco de dados, engenheiros de plataforma e compradores de soluções analíticas que avaliam outra opção de ingestão. Um caminho de transporte mais curto pode reduzir a responsabilidade pela infraestrutura. Ele não produz automaticamente uma réplica correta, estabelece uma política de recuperação nem define qual equipe lida com uma atualização com falha. Essas decisões determinam se a simplificação resiste ao ambiente de produção.

Databricks Zerobus CDC Oferece às Equipes de Origem um Destino Direto

A Databricks descreveu a arquitetura em uma publicação de engenharia de 5 de novembro de 2026. Sua arquitetura de CDC baseada em push conecta o Debezium Server diretamente ao Unity Catalog, a camada de governança da Databricks, por meio do Zerobus Ingest. O destino armazena eventos em tabelas Delta, que usam o formato aberto de armazenamento Delta Lake.

Segundo a Databricks, seus engenheiros desenvolveram o sink tipado, o componente que entrega registros capturados ao destino. A NVIDIA contribuiu com o modo envelope, que preserva o evento de alteração e os metadados de entrega associados. A Databricks afirma que o sink é distribuído com o Debezium Server 3.7.

A mudança concreta é um caminho direto de entrega com suporte, mantendo a captura dentro do ambiente da equipe de origem.

Essa divisão oferece às organizações uma maneira diferente de atribuir responsabilidades. A equipe de banco de dados opera a captura perto de seu banco. A plataforma de análises recebe as alterações sem exigir que essa equipe adote uma plataforma intermediária de eventos apenas para transporte.

Considere uma implantação empresarial ilustrativa com um banco de dados de pedidos hospedado de forma privada. Revisores de segurança permitem que um processo local envie dados aprovados para fora. Eles não permitem que um serviço externo inicie conexões com o banco de dados. Um processo operado pela origem se ajusta a essa direção de acesso, desde que os revisores aprovem o destino, a identidade e os dados permitidos.

Esse exemplo explica a adequação arquitetural, e não uma adoção documentada por clientes. O anúncio estabelece a integração e seu uso pretendido. Ele não estabelece que toda rede empresarial restrita possa aprovar a conexão ou que toda carga de trabalho de banco de dados precise desse desenho.

Para compradores, a distinção importante está entre uma integração se tornar disponível e uma migração se tornar justificada. Uma equipe com infraestrutura funcional precisa de evidências de que alterar o caminho melhora seu próprio modelo operacional. Um anúncio isolado não pode responder a essa questão.

Para equipes que projetam um novo pipeline, porém, a decisão inicial muda. Elas podem avaliar se o destino precisa de um serviço intermediário de transporte. Essa pergunta deve surgir cedo na revisão de arquitetura, antes que padrões de implantação façam um determinado componente parecer obrigatório.

A consequência imediata é mais restrita do que substituir uma plataforma corporativa de streaming. A Databricks descreveu uma rota para um trabalho específico: mover alterações de banco de dados para seu ambiente analítico governado. Sua utilidade depende de quanto o requisito real corresponde a esse trabalho.

Uma avaliação sensata, portanto, começa pelos requisitos de propriedade e de destino. Qual equipe controla o acesso ao banco de dados? Para onde as alterações devem ir? Quem precisa de acesso independente antes do processamento analítico? Essas respostas determinam se um sink direto elimina trabalho desnecessário ou elimina uma capacidade de que alguém ainda precisa.

A Pressão Recai sobre Pipelines Criados para um Único Destino

O desafio mais forte visa à infraestrutura intermediária cujo único propósito é entregar alterações à Databricks.

Esse enquadramento mantém a comparação honesta. O Kafka oferece capacidades além de encaminhar registros para uma tabela analítica. Seu modelo de streaming de eventos inclui armazenamento durável de eventos, assinaturas e processamento. Essas capacidades importam quando várias aplicações consomem o mesmo fluxo ou precisam de agendas independentes de processamento.

Um destino direto muda essa relação. Ele transforma a plataforma analítica no sistema receptor imediato. Isso pode se adequar a um pipeline cujos requisitos terminam ali. Merece análise mais cuidadosa quando outras equipes esperam que a camada de ingestão também atenda suas aplicações.

Imagine uma alimentação de banco de dados usada para relatórios, indexação de busca e notificações de aplicações. A decisão arquitetural deve considerar todos os consumidores. Contar apenas o caminho de relatórios subestimaria as responsabilidades do sistema e faria a rota direta parecer mais abrangente do que é.

Agora considere outra organização. Suas alterações de banco de dados alimentam apenas uma réplica analítica, e ninguém precisa de uma camada compartilhada de distribuição de eventos. Nesse cenário, manter uma plataforma intermediária exige uma justificativa separada. A familiaridade existente pode apoiar essa justificativa, mas familiaridade por si só não estabelece necessidade.

Isso pressiona equipes de plataforma a explicar a finalidade de cada componente. A pergunta útil passa a ser qual capacidade operacional desaparece quando um componente desaparece. Uma resposta clara sustenta sua manutenção. Uma resposta pouco clara identifica um candidato à simplificação.

O anúncio também pressiona conversas de compras estruturadas em torno de listas de componentes. Um serviço gerenciado de ingestão e uma plataforma de eventos não executam trabalhos idênticos. Compará-los exige uma carga de trabalho comum, um objetivo comum de recuperação e uma descrição explícita de quem opera o software restante.

Não há aqui uma comparação verificada de cargas de trabalho que estabeleça economia universal ou desempenho ponta a ponta superior. Compradores devem resistir a transformar um diagrama mais curto em uma conclusão financeira. Equipe, serviços existentes, tratamento de incidentes e processamento downstream afetam o resultado.

A mesma cautela se aplica à urgência de migração. Uma implantação estável de Kafka atendendo vários consumidores representa uma decisão diferente de um cluster proposto para atender um único destino. A rota direta apresenta seu argumento mais claro quando o transporte intermediário, de outra forma, se tornaria uma nova obrigação operacional.

Para líderes de engenharia, esta é uma oportunidade de revisar limites de responsabilidade. Administradores de banco de dados devem definir comportamentos aceitáveis de captura. Equipes de plataforma devem definir operações de destino. Equipes de análises devem definir atualização e correção aceitáveis. Uma camada de transporte menor se torna útil quando essas responsabilidades permanecem explícitas.

A questão competitiva resultante é prática: quanta infraestrutura uma organização deve operar para entregar o produto de dados de que realmente precisa? A Databricks fortaleceu sua resposta para uma carga de trabalho focada no destino. Requisitos mais amplos de streaming ainda exigem uma comparação mais ampla.

Entrega Durável e Replicação Correta Continuam Sendo Trabalhos Separados

O detalhe mais consequente no Databricks Zerobus CDC é o limite de confirmação. Uma confirmação informa ao produtor que o destino aceitou a responsabilidade pelos dados. Um offset de origem registra o progresso da captura, permitindo que o produtor retome a partir de uma posição conhecida.

O sink do Debezium Server documenta entrega pelo menos uma vez, o que significa que novas tentativas podem entregar um evento mais de uma vez. Ele valida registros dentro de um grupo de tabelas de destino e aguarda confirmação antes de concluir o progresso da origem. Uma falha posterior pode fazer com que um grupo anteriormente confirmado seja reproduzido novamente.

O modo envelope fornece uma idempotency_key, um identificador de evento usado para reconhecer entregas repetidas. O processamento downstream deve usar essa identidade para remover duplicatas. Identificar um evento repetido não estabelece qual evento distinto deve ter precedência.

A entrega durável protege a transferência; a lógica downstream ainda precisa estabelecer o estado de negócio correto.

Uma atualização ilustrativa de pedido mostra por que isso importa. Suponha que um cliente altere o endereço de entrega de um pedido. O destino aceita a atualização, mas a captura é reiniciada antes que seu progresso seja totalmente confirmado. Reproduzir essa atualização deve deixar a representação analítica inalterada após o tratamento de duplicatas.

Acrescentar cada registro recebido preservaria a entrega repetida. Isso pode ser uma evidência útil em uma coleção bruta de eventos. Torna-se um problema se os relatórios tratam cada chegada como uma ação de negócio separada. O sucesso do transporte e a interpretação analítica respondem a perguntas diferentes.

A ordenação introduz outra distinção. Suponha que um pedido mude de pendente para aprovado e depois de aprovado para cancelado. Repetir o evento de aprovação não deve restaurar o status anterior. O pipeline precisa de uma regra que diferencie a sequência de origem do momento de chegada.

É por isso que os metadados de entrega merecem atenção durante a aquisição e a revisão de arquitetura. Uma equipe precisa saber quais informações sobrevivem ao transporte e o que seu mecanismo downstream exige. Uma integração que preserva evidências úteis ainda precisa de um contrato de processamento que as consuma corretamente.

O limite de falha também molda a investigação de incidentes. Os operadores devem conseguir distinguir um evento aguardando entrega de um evento aguardando processamento. Devem identificar a entrega repetida sem confundi-la com atividade de negócio repetida. Caso contrário, a recuperação cria incerteza justamente quando as pessoas precisam de evidências claras.

Esses são critérios práticos de aceitação, e não razões para rejeitar o desenho. Uma rota direta pode ser confiável quando suas responsabilidades são compreendidas. Os problemas surgem quando as equipes interpretam uma garantia de ingestão como uma garantia sobre a tabela analítica final.

O teste adequado, portanto, é mais exigente do que ver registros chegando. Interrompa a captura após a entrega bem-sucedida, reinicie-a e inspecione o estado de negócio resultante. Teste atualizações e exclusões, além de inserções. Um pipeline conquista confiança quando a recuperação preserva significado, e não apenas conectividade.

Essa avaliação deve envolver as pessoas responsáveis pelos relatórios. Engenheiros podem verificar o tratamento de eventos, enquanto analistas verificam a interpretação resultante. O acordo entre essas perspectivas estabelece um limite de aceitação mais forte do que qualquer uma das equipes pode oferecer isoladamente.

Um Fluxo de Alterações Armazenado Ainda Precisa de um Contrato Analítico

Existe um limite separado entre armazenamento durável e disponibilidade para consulta. A documentação de confirmação de durabilidade da Databricks os distingue explicitamente: a confirmação valida a durabilidade antes que o registro se torne consultável na tabela Delta.

Essa distinção evita um erro comum de medição. Uma ingestão bem-sucedida não significa necessariamente que um analista já consiga ver a mudança correspondente no negócio. Um compromisso de atualização deve abranger o caminho desde a transação de origem até a tabela ou o relatório que as pessoas realmente usam.

O objetivo de serviço útil mede quando informações corretas se tornam disponíveis para o consumidor a que se destinam.

Para um dashboard operacional, esse ponto final pode ser o status atual do pedido. Para um fluxo de auditoria, pode ser um histórico preservado de alterações. Esses produtos podem compartilhar eventos capturados, mas exigir comportamentos posteriores e verificações de aceitação diferentes.

A Databricks documenta o processamento AUTO CDC para criar essas representações. AUTO CDC é uma interface de pipeline que aplica registros de alterações usando chaves e sequenciamento definidos. Seu processamento Tipo 1 mantém o estado atual; o processamento Tipo 2 mantém versões históricas.

A distinção de negócio merece atenção antes da implementação. Uma tabela de estado atual responde como um registro se apresenta agora. Uma tabela de histórico dá suporte a perguntas sobre estados anteriores. Escolher entre elas afeta o que os usuários podem investigar após um incidente ou um relatório contestado.

Considere um fluxo ilustrativo de suporte envolvendo um pedido cancelado. Um agente que consulta o status atual precisa que o cancelamento esteja refletido corretamente. Um investigador que analisa o caso também pode precisar compreender a aprovação anterior. O produto de dados deve identificar qual pergunta promete responder.

Uma coleção bruta de eventos, por si só, deixa essa promessa pouco clara. Os usuários podem interpretar chegadas repetidas como ações repetidas ou presumir que cada versão armazenada representa uma transição distinta de negócio. Um contrato analítico documentado deve explicar a relação entre eventos capturados e registros publicados.

Esse contrato também oferece às equipes um alvo útil para reconciliação. Elas podem comparar o estado de origem com a representação publicada do estado atual. Também podem examinar separadamente se o histórico retido corresponde à interpretação de negócio pretendida. Cada comparação testa uma responsabilidade diferente.

O guia da comunidade Databricks sobre PostgreSQL CDC fornece um exemplo técnico concreto. Ele acompanha alterações do PostgreSQL durante a ingestão até uma tabela de estado atual. O guia verifica inserções, atualizações e exclusões, tornando essas operações casos de aceitação visíveis.

Esse exemplo é útil para compreender a integração. Ele não estabelece desempenho em todos os conjuntos de dados de produção, políticas de rede ou cenários de recuperação. As equipes devem tratar um guia como um ponto de partida reproduzível e ampliar suas verificações em torno das próprias condições de falha.

A implicação organizacional é direta. Remover o transporte intermediário não elimina a necessidade de um responsável pelo produto de dados. Alguém ainda define a correção, aprova as expectativas de atualização e decide se a interpretação histórica atende às necessidades do negócio.