Databricks Zerobus CDC retire Kafka du parcours tout en laissant la capture aux équipes base de données

Databricks a présenté une voie de réplication de bases de données qui contourne Kafka tout en maintenant la capture sous le contrôle de l’équipe base de données. Databricks Zerobus CDC associe Zerobus Ingest, son service d’ingestion géré, à Debezium, une plateforme open source de capture des changements de données. La capture des changements de données, ou CDC, enregistre les modifications d’une base de données afin qu’elles soient traitées ailleurs. L’intérêt réside dans un chemin plus court vers l’analytique, avec des responsabilités de fiabilité qui exigent toujours une ingénierie réfléchie.

L’architecture répond à un problème organisationnel précis : une équipe base de données peut autoriser le trafic sortant tout en refusant les connexions entrantes d’un service analytique externe. Apache Kafka, une plateforme de streaming d’événements, prend déjà en charge des architectures où la capture est contrôlée par la source. Le changement consiste ici à supprimer cette plateforme intermédiaire lorsque Databricks est la destination prévue.

Cette distinction compte pour les administrateurs de bases de données, les ingénieurs plateforme et les acheteurs de solutions analytiques qui évaluent une autre option d’ingestion. Un chemin de transport plus court peut réduire la responsabilité liée à l’infrastructure. Il ne produit pas automatiquement une réplique correcte, n’établit pas de politique de reprise et ne tranche pas quelle équipe gère une mise à jour défaillante. Ces décisions déterminent si la simplification résiste à la production.

Databricks Zerobus CDC offre aux équipes source une destination directe

Databricks a décrit l’architecture dans un article d’ingénierie publié le 5 novembre 2026. Son architecture CDC basée sur le push connecte directement Debezium Server à Unity Catalog, la couche de gouvernance de Databricks, via Zerobus Ingest. La destination stocke les événements dans des tables Delta, qui utilisent le format de stockage ouvert Delta Lake.

Selon Databricks, ses ingénieurs ont développé le sink typé, le composant qui transmet les enregistrements capturés vers la destination. NVIDIA a contribué au mode enveloppe, qui conserve l’événement de changement et les métadonnées de livraison associées. Databricks indique que le sink est livré avec Debezium Server 3.7.

Le changement concret est un chemin de livraison directe pris en charge, la capture restant dans l’environnement de l’équipe source.

Cette répartition offre aux organisations une autre manière d’attribuer les responsabilités. L’équipe base de données exécute la capture à proximité de sa base. La plateforme analytique reçoit les changements sans obliger cette équipe à adopter une plateforme événementielle intermédiaire uniquement pour le transport.

Prenons le cas illustratif d’un déploiement en entreprise avec une base de commandes hébergée dans un environnement privé. Les évaluateurs de sécurité autorisent un processus local à envoyer des données approuvées vers l’extérieur. Ils n’autorisent pas un service externe à initier des connexions à la base de données. Un processus exploité côté source correspond à cette direction d’accès, à condition que les évaluateurs approuvent la destination, l’identité et les données autorisées.

Cet exemple explique l’adéquation architecturale plutôt qu’une adoption client documentée. L’annonce établit l’intégration et son usage prévu. Elle n’établit pas que chaque réseau d’entreprise restreint puisse approuver la connexion, ni que chaque charge de travail de base de données nécessite cette conception.

Pour les acheteurs, la distinction importante est celle entre la disponibilité d’une intégration et la justification d’une migration. Une équipe disposant d’une infrastructure opérationnelle a besoin d’éléments montrant que modifier le parcours améliore son propre modèle d’exploitation. Une annonce ne peut, à elle seule, répondre à cette question.

Pour les équipes qui conçoivent un nouveau pipeline, en revanche, la décision initiale évolue. Elles peuvent déterminer si la destination a réellement besoin d’un service de transport intermédiaire. Cette question doit être abordée tôt dans la revue d’architecture, avant que les standards de déploiement ne rendent un composant particulier obligatoire en apparence.

La conséquence immédiate est plus limitée que le remplacement d’une plateforme de streaming d’entreprise. Databricks a décrit un parcours pour une tâche précise : acheminer des changements de base de données vers son environnement analytique gouverné. Son utilité dépend de la correspondance entre les besoins réels et cette tâche.

Une évaluation raisonnable commence donc par les exigences de propriété et de destination. Quelle équipe contrôle l’accès à la base de données ? Où les changements doivent-ils parvenir ? Qui a besoin d’un accès indépendant avant le traitement analytique ? Les réponses déterminent si un sink direct élimine un travail superflu ou une capacité dont quelqu’un a encore besoin.

La pression s’exerce sur les pipelines conçus pour une seule destination

Le défi le plus fort vise les infrastructures intermédiaires dont le seul objectif est de livrer les changements à Databricks.

Ce cadrage permet de garder la comparaison honnête. Kafka offre des capacités qui dépassent le simple transfert d’enregistrements vers une table analytique. Son modèle de streaming d’événements inclut le stockage durable des événements, les abonnements et le traitement. Ces capacités sont importantes lorsque plusieurs applications consomment le même flux ou nécessitent des calendriers de traitement indépendants.

Une destination directe modifie cette relation. Elle fait de la plateforme analytique le système de réception immédiat. Cela peut convenir à un pipeline dont les exigences s’arrêtent là. Une analyse plus attentive est nécessaire lorsque d’autres équipes attendent de la couche d’ingestion qu’elle serve aussi leurs applications.

Imaginons un flux de base de données utilisé pour le reporting, l’indexation de recherche et les notifications applicatives. La décision architecturale doit tenir compte de chaque consommateur. Ne compter que le parcours de reporting sous-estimerait les responsabilités du système et ferait paraître la voie directe plus complète qu’elle ne l’est.

Considérons maintenant une autre organisation. Ses changements de base de données n’alimentent qu’une réplique analytique, et personne n’a besoin d’une couche partagée de distribution d’événements. Dans ce contexte, maintenir une plateforme intermédiaire exige une justification distincte. Une familiarité existante peut étayer cette justification, mais elle ne suffit pas à établir une nécessité.

Cela pousse les équipes plateforme à expliquer le rôle de chaque composant. La question utile devient : quelle capacité opérationnelle disparaît lorsqu’un composant disparaît ? Une réponse claire justifie son maintien. Une réponse floue identifie un candidat à la simplification.

L’annonce exerce également une pression sur les discussions d’approvisionnement fondées sur des listes de composants. Un service d’ingestion géré et une plateforme événementielle n’accomplissent pas des tâches identiques. Les comparer exige une charge de travail commune, un objectif de reprise commun et une description explicite de l’équipe qui exploite les logiciels restants.

Aucune comparaison de charge de travail vérifiée ne démontre ici des économies universelles ou de meilleures performances de bout en bout. Les acheteurs devraient éviter de transformer un diagramme plus court en conclusion financière. Les effectifs, les services existants, la gestion des incidents et le traitement en aval influencent tous le résultat.

La même retenue s’applique à l’urgence d’une migration. Un déploiement Kafka stable servant plusieurs consommateurs présente une décision différente d’un cluster proposé pour une seule destination. La voie directe est la plus convaincante lorsque le transport intermédiaire deviendrait autrement une nouvelle obligation opérationnelle.

Pour les responsables d’ingénierie, c’est l’occasion de réexaminer les frontières de responsabilité. Les administrateurs de bases de données doivent définir un comportement de capture acceptable. Les équipes plateforme doivent définir les opérations de destination. Les équipes analytiques doivent définir une fraîcheur et une exactitude acceptables. Une couche de transport plus réduite devient utile lorsque ces responsabilités restent explicites.

La question concurrentielle qui en résulte est pratique : quelle quantité d’infrastructure une organisation doit-elle exploiter pour fournir le produit de données dont elle a réellement besoin ? Databricks a renforcé sa réponse pour une charge de travail centrée sur une destination. Des besoins de streaming plus larges exigent toujours une comparaison plus étendue.

La livraison durable et la réplication correcte restent deux tâches distinctes

Le détail le plus déterminant de Databricks Zerobus CDC est la frontière d’accusé de réception. Un accusé de réception indique au producteur que la destination a accepté la responsabilité des données. Un offset source enregistre la progression de la capture, permettant au producteur de reprendre depuis une position connue.

Le sink Debezium Server documente une livraison at-least-once, ce qui signifie que les tentatives peuvent livrer un événement plus d’une fois. Il valide les enregistrements au sein d’un groupe de tables cibles et attend l’accusé de réception avant de terminer la progression source. Une défaillance ultérieure peut entraîner la relecture d’un groupe déjà accusé de réception.

Le mode enveloppe fournit une idempotency_key, un identifiant d’événement utilisé pour reconnaître une livraison répétée. Le traitement en aval doit utiliser cette identité pour éliminer les doublons. Identifier un événement répété ne permet pas d’établir quel événement distinct doit prévaloir.

La livraison durable protège la transmission ; la logique en aval doit encore établir l’état métier correct.

Une mise à jour de commande illustrative montre pourquoi cela compte. Supposons qu’un client modifie l’adresse de livraison d’une commande. La destination accepte la mise à jour, mais la capture redémarre avant que sa progression soit entièrement validée. La relecture de cette mise à jour devrait laisser la représentation analytique inchangée après le traitement des doublons.

L’ajout de chaque enregistrement reçu préserverait la livraison répétée. Cela peut constituer une preuve utile dans une collection brute d’événements. Cela devient un problème si le reporting traite chaque arrivée comme une action métier distincte. Le succès du transport et l’interprétation analytique répondent à des questions différentes.

L’ordonnancement introduit une autre distinction. Supposons qu’une commande passe de l’état en attente à approuvée, puis d’approuvée à annulée. La répétition de l’événement d’approbation ne doit pas restaurer l’état antérieur. Le pipeline a besoin d’une règle qui distingue la séquence source de l’heure d’arrivée.

C’est pourquoi les métadonnées de livraison méritent une attention particulière lors de l’approvisionnement et de la revue d’architecture. Une équipe doit savoir quelles informations survivent au transport et ce que son moteur en aval exige. Une intégration qui préserve des éléments de preuve utiles nécessite toujours un contrat de traitement qui les exploite correctement.

La frontière de défaillance façonne aussi l’enquête sur les incidents. Les opérateurs doivent pouvoir distinguer un événement en attente de livraison d’un événement en attente de traitement. Ils doivent identifier une livraison répétée sans la confondre avec une activité métier répétée. Sinon, la reprise crée de l’incertitude au moment même où les personnes ont besoin de preuves claires.

Il s’agit de critères d’acceptation pratiques, et non de raisons de rejeter la conception. Une voie directe peut être fiable lorsque ses responsabilités sont comprises. Les problèmes surviennent lorsque les équipes interprètent une garantie d’ingestion comme une garantie sur la table analytique finale.

Le test approprié est donc plus exigeant que de voir des enregistrements arriver. Interrompez la capture après une livraison réussie, redémarrez-la, puis inspectez l’état métier obtenu. Testez les mises à jour et les suppressions, ainsi que les insertions. Un pipeline inspire confiance lorsque la reprise préserve le sens, et pas seulement la connectivité.

Cette évaluation doit impliquer les personnes responsables des rapports. Les ingénieurs peuvent vérifier le traitement des événements, tandis que les analystes vérifient l’interprétation qui en résulte. L’accord entre ces perspectives établit une frontière d’acceptation plus solide que celle qu’une équipe peut fournir seule.

Un flux de changements stocké nécessite toujours un contrat analytique

Une frontière distincte existe entre le stockage durable et la disponibilité pour les requêtes. La documentation de Databricks sur l’accusé de réception de durabilité les distingue explicitement : l’accusé de réception confirme la durabilité avant que l’enregistrement ne devienne interrogeable dans la table Delta.

Cette distinction évite une erreur de mesure fréquente. Une ingestion réussie ne signifie pas nécessairement qu’un analyste peut déjà constater le changement métier correspondant. Un engagement de fraîcheur doit couvrir le parcours allant de la transaction source à la table ou au rapport réellement utilisé.

L’objectif de service pertinent mesure le moment où une information correcte devient disponible pour son utilisateur prévu.

Pour un tableau de bord opérationnel, ce point d’arrivée peut être le statut actuel d’une commande. Pour un processus d’audit, il peut s’agir d’un historique des modifications conservé. Ces produits peuvent partager les mêmes événements capturés tout en exigeant des comportements en aval et des critères d’acceptation différents.

Databricks documente le traitement AUTO CDC pour créer ces représentations. AUTO CDC est une interface de pipeline qui applique les enregistrements de changement à l’aide de clés et d’un séquençage définis. Son traitement de type 1 conserve l’état actuel ; son traitement de type 2 conserve les versions historiques.

La distinction métier mérite une attention particulière avant la mise en œuvre. Une table d’état actuel répond à la question de savoir à quoi ressemble un enregistrement maintenant. Une table d’historique permet d’interroger des états antérieurs. Le choix entre les deux détermine ce que les utilisateurs peuvent examiner après un incident ou un rapport contesté.

Prenons l’exemple d’un processus de support impliquant une commande annulée. Un agent consultant le statut actuel doit voir l’annulation correctement reflétée. Un enquêteur examinant le dossier peut également devoir comprendre l’approbation qui l’a précédée. Le produit de données doit préciser à quelle question il s’engage à répondre.

Une simple collection d’événements bruts laisse cette promesse ambiguë. Les utilisateurs pourraient interpréter des arrivées répétées comme des actions répétées ou supposer que chaque version stockée représente une transition métier distincte. Un contrat analytique documenté devrait expliquer la relation entre les événements capturés et les enregistrements publiés.

Ce contrat fournit également aux équipes une cible utile pour le rapprochement. Elles peuvent comparer l’état source à la représentation publiée de l’état actuel. Elles peuvent examiner séparément si l’historique conservé correspond à l’interprétation métier prévue. Chaque comparaison vérifie une responsabilité différente.

Le guide pratique PostgreSQL CDC de la communauté Databricks fournit un exemple technique concret. Il suit les changements PostgreSQL à travers l’ingestion jusqu’à une table d’état actuel. Le guide vérifie les insertions, les mises à jour et les suppressions, faisant de ces opérations des cas d’acceptation visibles.

Cet exemple est utile pour comprendre l’intégration. Il ne démontre pas les performances sur tous les jeux de données de production, toutes les politiques réseau ou tous les scénarios de récupération. Les équipes devraient considérer ce guide comme un point de départ reproductible et étendre ses vérifications à leurs propres conditions de défaillance.

L’implication organisationnelle est simple. La suppression d’un transport intermédiaire ne supprime pas le besoin d’un responsable du produit de données. Quelqu’un doit toujours définir l’exactitude, approuver les attentes en matière de fraîcheur et décider si l’interprétation historique répond aux besoins métier.