Databricks Zerobus CDC elimina Kafka del recorrido y mantiene la captura en manos de los equipos de bases de datos

Databricks presentó una ruta de replicación de bases de datos que evita Kafka y mantiene la captura bajo el control del equipo de bases de datos. Databricks Zerobus CDC combina Zerobus Ingest, su servicio de ingestión gestionado, con Debezium, una plataforma de código abierto para la captura de cambios de datos. La captura de cambios de datos, o CDC, registra modificaciones en una base de datos para procesarlas en otro lugar. El atractivo es una ruta más corta hacia la analítica, con responsabilidades de fiabilidad que aún exigen una ingeniería deliberada.

La arquitectura aborda un problema organizativo concreto: un equipo de bases de datos puede permitir tráfico saliente y, al mismo tiempo, rechazar conexiones entrantes de un servicio externo de analítica. Apache Kafka, una plataforma de streaming de eventos, ya admite arquitecturas con captura controlada desde el origen. El cambio aquí consiste en eliminar esa plataforma intermedia cuando Databricks es el destino previsto.

Esta distinción importa para administradores de bases de datos, ingenieros de plataforma y compradores de soluciones analíticas que evalúan otra opción de ingestión. Una ruta de transporte más corta puede reducir la responsabilidad sobre infraestructura. No produce automáticamente una réplica correcta, no establece una política de recuperación ni determina qué equipo gestiona una actualización fallida. Esas decisiones determinan si la simplificación resiste en producción.

Databricks Zerobus CDC ofrece a los equipos de origen un destino directo

Databricks describió la arquitectura en una publicación de ingeniería del 5 de noviembre de 2026. Su arquitectura CDC basada en envío conecta Debezium Server directamente con Unity Catalog, la capa de gobernanza de Databricks, mediante Zerobus Ingest. El destino almacena eventos en tablas Delta, tablas que utilizan el formato abierto de almacenamiento Delta Lake.

Según Databricks, sus ingenieros desarrollaron el receptor tipado, el componente que entrega los registros capturados al destino. NVIDIA aportó el modo envelope, que conserva el evento de cambio y los metadatos de entrega asociados. Databricks afirma que el receptor se distribuye con Debezium Server 3.7.

El cambio concreto es una ruta compatible de entrega directa, con la captura permaneciendo dentro del entorno del equipo de origen.

Esta división ofrece a las organizaciones otra forma de asignar responsabilidades. El equipo de bases de datos opera la captura cerca de su base de datos. La plataforma analítica recibe los cambios sin exigir a ese equipo adoptar una plataforma intermedia de eventos únicamente para el transporte.

Pensemos en una implementación empresarial ilustrativa con una base de datos de pedidos alojada de forma privada. Los revisores de seguridad permiten que un proceso local envíe hacia fuera datos aprobados. No permiten que un servicio externo inicie conexiones a la base de datos. Un proceso operado desde el origen encaja con esa dirección de acceso, siempre que los revisores aprueben el destino, la identidad y los datos permitidos.

Este ejemplo explica el encaje arquitectónico, no una adopción documentada por clientes. El anuncio establece la integración y su uso previsto. No establece que todas las redes empresariales restringidas puedan aprobar la conexión ni que todas las cargas de trabajo de bases de datos necesiten este diseño.

Para los compradores, la distinción importante está entre que una integración esté disponible y que una migración esté justificada. Un equipo con infraestructura funcional necesita evidencia de que cambiar la ruta mejora su propio modelo operativo. Un anuncio por sí solo no puede responder a esa pregunta.

Sin embargo, para los equipos que diseñan una nueva canalización, cambia la decisión inicial. Pueden evaluar si el destino necesita en absoluto un servicio intermedio de transporte. Esa cuestión debe plantearse pronto en la revisión de arquitectura, antes de que los estándares de despliegue hagan que un componente concreto parezca obligatorio.

La consecuencia inmediata es más limitada que sustituir una plataforma empresarial de streaming. Databricks ha descrito una ruta para una tarea concreta: trasladar cambios de bases de datos a su entorno analítico gobernado. Su utilidad depende de cuánto coincida el requisito real con esa tarea.

Por tanto, una evaluación sensata comienza con los requisitos de propiedad y destino. ¿Qué equipo controla el acceso a la base de datos? ¿Adónde deben ir los cambios? ¿Quién necesita acceso independiente antes del procesamiento analítico? Las respuestas determinan si un receptor directo elimina trabajo innecesario o elimina una capacidad que alguien todavía necesita.

La presión recae sobre canalizaciones diseñadas para un único destino

El desafío más fuerte se dirige a la infraestructura intermedia cuyo único propósito es entregar cambios a Databricks.

Ese enfoque mantiene honesta la comparación. Kafka ofrece capacidades que van más allá de reenviar registros a una tabla analítica. Su modelo de streaming de eventos incluye almacenamiento duradero de eventos, suscripciones y procesamiento. Estas capacidades importan cuando varias aplicaciones consumen el mismo flujo o necesitan calendarios de procesamiento independientes.

Un destino directo cambia esa relación. Convierte a la plataforma analítica en el sistema receptor inmediato. Esto puede encajar en una canalización cuyos requisitos terminan ahí. Merece un análisis más detallado cuando otros equipos esperan que la capa de ingestión también atienda sus aplicaciones.

Imaginemos una alimentación de base de datos utilizada para informes, indexación de búsquedas y notificaciones de aplicaciones. La decisión arquitectónica debe considerar a cada consumidor. Contabilizar únicamente la ruta de informes subestimaría las responsabilidades del sistema y haría que la ruta directa pareciera más completa de lo que es.

Consideremos ahora otra organización. Sus cambios de base de datos alimentan únicamente una réplica analítica y nadie necesita una capa compartida de distribución de eventos. En ese contexto, mantener una plataforma intermedia exige una justificación independiente. La familiaridad existente puede respaldar esa justificación, pero la familiaridad por sí sola no demuestra necesidad.

Esto presiona a los equipos de plataforma para que expliquen el propósito de cada componente. La pregunta útil pasa a ser qué capacidad operativa desaparece cuando desaparece un componente. Una respuesta clara respalda conservarlo. Una respuesta poco clara identifica un candidato para la simplificación.

El anuncio también presiona las conversaciones de compras basadas en listas de componentes. Un servicio de ingestión gestionado y una plataforma de eventos no realizan trabajos idénticos. Compararlos requiere una carga de trabajo común, un objetivo de recuperación común y una explicación explícita de quién opera el software restante.

No existe aquí una comparación verificada de cargas de trabajo que establezca ahorros universales o un rendimiento superior de extremo a extremo. Los compradores deberían evitar convertir un diagrama más corto en una conclusión financiera. La dotación de personal, los servicios existentes, la gestión de incidentes y el procesamiento posterior influyen en el resultado.

La misma prudencia se aplica a la urgencia de migrar. Un despliegue estable de Kafka que atiende a varios consumidores presenta una decisión distinta a la de un clúster propuesto que atiende a un único destino. La ruta directa tiene su argumento más claro cuando el transporte intermedio, de otro modo, se convertiría en una nueva obligación operativa.

Para los líderes de ingeniería, esta es una oportunidad de revisar los límites de responsabilidad. Los administradores de bases de datos deben definir un comportamiento de captura aceptable. Los equipos de plataforma deben definir las operaciones del destino. Los equipos de analítica deben definir una frescura y corrección aceptables. Una capa de transporte más pequeña resulta útil cuando estas responsabilidades permanecen explícitas.

La cuestión competitiva resultante es práctica: ¿cuánta infraestructura debe operar una organización para entregar el producto de datos que realmente necesita? Databricks ha reforzado su respuesta para una carga de trabajo centrada en el destino. Los requisitos de streaming más amplios siguen exigiendo una comparación más amplia.

La entrega duradera y la replicación correcta siguen siendo tareas distintas

El detalle más importante de Databricks Zerobus CDC es el límite del acuse de recibo. Un acuse de recibo indica al productor que el destino ha aceptado la responsabilidad de los datos. Un offset de origen registra el progreso de captura, lo que permite al productor reanudar desde una posición conocida.

El receptor de Debezium Server documenta una entrega de al menos una vez, lo que significa que los reintentos pueden entregar un evento más de una vez. Valida los registros dentro de un grupo de tablas de destino y espera el acuse de recibo antes de completar el progreso del origen. Un fallo posterior puede provocar que se reproduzca un grupo previamente confirmado.

El modo envelope proporciona una idempotency_key, un identificador de evento utilizado para reconocer entregas repetidas. El procesamiento posterior debe utilizar esa identidad para eliminar duplicados. Identificar un evento repetido no determina cuál de dos eventos distintos debe tener prioridad.

La entrega duradera protege la transferencia; la lógica posterior aún debe establecer el estado empresarial correcto.

Una actualización ilustrativa de un pedido muestra por qué esto importa. Supongamos que un cliente cambia la dirección de entrega de un pedido. El destino acepta la actualización, pero la captura se reinicia antes de que su progreso se confirme por completo. La reproducción de esa actualización debería dejar sin cambios la representación analítica tras el tratamiento de duplicados.

Añadir cada registro recibido conservaría la entrega repetida. Eso puede ser evidencia útil en una colección de eventos sin procesar. Se convierte en un problema si los informes tratan cada llegada como una acción empresarial independiente. El éxito del transporte y la interpretación analítica responden a preguntas distintas.

El orden introduce otra distinción. Supongamos que un pedido cambia de pendiente a aprobado y después de aprobado a cancelado. Repetir el evento de aprobación no debe restaurar el estado anterior. La canalización necesita una regla que distinga la secuencia de origen del momento de llegada.

Por eso los metadatos de entrega merecen atención durante las revisiones de compras y arquitectura. Un equipo necesita saber qué información sobrevive al transporte y qué requiere su motor posterior. Una integración que conserva evidencia útil aún necesita un contrato de procesamiento que la consuma correctamente.

El límite de fallo también da forma a la investigación de incidentes. Los operadores deberían poder distinguir un evento pendiente de entrega de un evento pendiente de procesamiento. Deberían identificar entregas repetidas sin confundirlas con actividad empresarial repetida. De lo contrario, la recuperación crea incertidumbre precisamente cuando las personas necesitan evidencia clara.

Estos son criterios prácticos de aceptación, no motivos para rechazar el diseño. Una ruta directa puede ser fiable cuando se comprenden sus responsabilidades. Los problemas surgen cuando los equipos interpretan una garantía de ingestión como una garantía sobre la tabla analítica final.

Por tanto, la prueba adecuada es más exigente que comprobar que llegan registros. Interrumpa la captura después de una entrega satisfactoria, reiníciela e inspeccione el estado empresarial resultante. Ejercite actualizaciones y eliminaciones, además de inserciones. Una canalización se gana la confianza cuando la recuperación preserva el significado, no solo la conectividad.

Esta evaluación debería involucrar a las personas responsables de los informes. Los ingenieros pueden verificar el manejo de eventos mientras que los analistas verifican la interpretación resultante. El acuerdo entre esas perspectivas establece un límite de aceptación más sólido del que cualquiera de los equipos puede proporcionar por sí solo.

Un flujo de cambios almacenado todavía necesita un contrato analítico

Existe un límite independiente entre el almacenamiento duradero y la disponibilidad para consultas. La documentación de acuses de recibo de durabilidad de Databricks los distingue explícitamente: el acuse de recibo confirma la durabilidad antes de que el registro pueda consultarse en la tabla Delta.

Esa distinción evita un error de medición común. Una ingesta exitosa no significa necesariamente que un analista ya pueda ver el cambio empresarial correspondiente. Un compromiso de actualización debe cubrir el recorrido desde la transacción de origen hasta la tabla o el informe que las personas realmente utilizan.

El objetivo de servicio útil mide cuándo la información correcta queda disponible para su consumidor previsto.

Para un panel operativo, ese punto final podría ser el estado actual de un pedido. Para un flujo de auditoría, podría ser un historial preservado de los cambios. Estos productos pueden compartir eventos capturados y, aun así, requerir comportamientos posteriores y comprobaciones de aceptación diferentes.

Databricks documenta el procesamiento AUTO CDC para crear esas representaciones. AUTO CDC es una interfaz de canalización que aplica registros de cambios mediante claves y secuenciación definidas. Su procesamiento de Tipo 1 conserva el estado actual; el de Tipo 2 conserva versiones históricas.

La distinción empresarial merece atención antes de la implementación. Una tabla de estado actual responde cómo se ve un registro ahora. Una tabla histórica permite responder preguntas sobre estados anteriores. Elegir entre ellas afecta lo que los usuarios pueden investigar después de un incidente o de un informe cuestionado.

Considere un flujo de soporte ilustrativo que involucra un pedido cancelado. Un agente que consulta el estado actual necesita que la cancelación se refleje correctamente. Un investigador que revisa el caso también podría necesitar comprender la aprobación previa. El producto de datos debe identificar qué pregunta promete responder.

Una colección de eventos sin procesar, por sí sola, deja esa promesa poco clara. Los usuarios podrían interpretar llegadas repetidas como acciones repetidas o asumir que cada versión almacenada representa una transición empresarial distinta. Un contrato analítico documentado debe explicar la relación entre los eventos capturados y los registros publicados.

Este contrato también ofrece a los equipos un objetivo útil de conciliación. Pueden comparar el estado de origen con la representación publicada del estado actual. Por separado, pueden revisar si el historial conservado coincide con la interpretación empresarial prevista. Cada comparación pone a prueba una responsabilidad diferente.

El recorrido de PostgreSQL CDC de la comunidad de Databricks ofrece un ejemplo técnico concreto. Sigue los cambios de PostgreSQL durante la ingesta y hasta una tabla de estado actual. El recorrido verifica inserciones, actualizaciones y eliminaciones, haciendo de esas operaciones casos de aceptación visibles.

Ese ejemplo es útil para comprender la integración. No establece el rendimiento para todos los conjuntos de datos de producción, políticas de red o escenarios de recuperación. Los equipos deben tratar un recorrido como un punto de partida reproducible y ampliar sus comprobaciones en torno a sus propias condiciones de fallo.

La implicación organizativa es clara. Eliminar el transporte intermedio no elimina la necesidad de un responsable del producto de datos. Alguien sigue definiendo la corrección, aprobando las expectativas de actualización y decidiendo si la interpretación histórica satisface las necesidades empresariales.