Diagrama de arquitectura de pipeline de datos: CDC, streaming y un almacén de datos

Los pipelines de datos fallan en silencio. Un panel muestra las cifras de ayer, una columna cambia de tipo en el origen y un job descarta filas sin dar error, o un slot de replicación del que nadie se acuerda retiene el registro de escritura anticipada en la base de producción hasta llenar el disco. Cada uno de estos casos es un salto o un contrato que nadie dibujó.

Un diagrama de arquitectura de pipeline de datos muestra de dónde vienen los datos, cómo se mueven, dónde se guardan en cada etapa, quién los transforma y cuándo, y cómo sabe cualquiera que están frescos y son correctos. Este artículo construye uno para una configuración habitual, la captura de datos de cambios (CDC) desde PostgreSQL a través de Kafka hacia un lake y un almacén de datos, y explica qué etiquetar en cada salto.

Extracciones por lotes, CDC o eventos

Hay tres formas habituales de sacar datos de una base operativa:

La captura de datos de cambios (CDC) basada en el log es popular para analítica porque no requiere cambios en la aplicación, ve los borrados y añade poca carga de consultas. Sus costes son operativos, y tienen su sitio en el diagrama.

Cómo funciona el CDC basado en el log con PostgreSQL

PostgreSQL expone los cambios mediante la decodificación lógica, que convierte el registro de escritura anticipada (WAL) en un flujo de cambios de filas. Necesita wal_level = logical, un plugin de salida y un slot de replicación. El conector de PostgreSQL de Debezium usa el plugin estándar pgoutput, incluido en PostgreSQL 10 y versiones posteriores. En el primer arranque toma una instantánea coherente de las tablas y después transmite cada inserción, actualización y borrado confirmados, por defecto a un topic de Kafka por tabla, llamado topicPrefix.schemaName.tableName.

El slot de replicación es la parte que muerde. La documentación de PostgreSQL explica que un slot impide eliminar el WAL que su consumidor aún necesita, incluso cuando no hay nada conectado. Si el conector se detiene un fin de semana, el WAL sigue creciendo en el primario. El parámetro max_slot_wal_keep_size limita cuánto WAL pueden retener los slots; su valor por defecto, -1, significa sin límite. Un límite protege la base de datos a costa de invalidar el slot, lo que implica una nueva instantánea. En cualquier caso, monitoriza el retraso del slot y dibuja el slot en el diagrama.

Las capas del lake y el almacén

Una vez que los cambios están en Kafka, un sink los escribe en el almacenamiento y las transformaciones los hacen útiles. Databricks popularizó la arquitectura medallón para nombrar las etapas:

• Bronze guarda los datos en bruto tal como llegaron, con metadatos de carga, para que puedas reprocesar sin volver a leer el origen.
• Silver guarda registros limpios, deduplicados y armonizados: una fila actual por pedido, tipos y claves coherentes.
• Gold guarda tablas de negocio y agregados que leen los paneles y los modelos.

Dónde vive cada capa es una decisión de diseño: almacenamiento de objetos con un formato de tabla abierto como Apache Iceberg, o el propio almacén de datos. Dibuja dónde vive de verdad, porque eso decide el coste, el control de acceso y quién puede consultarla.

Orquestación y contratos

Las transformaciones de bronze a gold se ejecutan según una programación o cuando llegan datos nuevos, gestionadas por un orquestador como Airflow o Dagster, a menudo con modelos SQL en dbt. Dos cosas marcan la diferencia entre un pipeline y un pasivo:

• Contratos. Los esquemas de los eventos de cambio se registran en un registro de esquemas con reglas de compatibilidad, de modo que un cambio incompatible en la tabla de origen falla de forma ruidosa en el productor en lugar de fallar en silencio en un informe.
• Comprobaciones. Después de cada paso se ejecutan comprobaciones de frescura, recuento de filas, unicidad y nulos, y un fallo avisa al responsable antes de que el panel muestre datos erróneos.

El ejemplo: una tienda online

La base PostgreSQL de la tienda guarda pedidos, pagos y clientes. Debezium se ejecuta en Kafka Connect, lee el WAL mediante un slot de replicación y publica shop.public.orders, shop.public.payments y shop.public.customers. Un conector sink añade los eventos de cambio a tablas bronze. Cada 15 minutos, el orquestador ejecuta modelos dbt que construyen silver y gold, y después las comprobaciones de datos. Los paneles leen gold.

Cómo leerlo:

• Fila superior, la captura. Los cambios salen de PostgreSQL por el slot de replicación, se convierten en eventos de cambio en Debezium, que registra sus esquemas, y viajan por un topic de Kafka por tabla hasta el conector sink.
• Fila inferior, el almacenamiento, de derecha a izquierda. El sink añade los cambios en bruto a bronze. Las transformaciones los fusionan en silver y agregan silver en gold, que consultan los paneles.
• Debajo, el control. El orquestador ejecuta las transformaciones y las comprobaciones; una comprobación fallida lanza una alerta.
• El bloque Markdown enumera las reglas operativas del slot y de los cambios de esquema.

Qué etiquetar

• El slot y su límite en la primera conexión, y a quién se avisa cuando se retrasa.
• Los nombres de los topics o una regla de nombres, para que un consumidor sepa a qué suscribirse.
• Las programaciones y los objetivos de frescura en las conexiones de transformación, como "cada 15 min, con menos de 30 min de antigüedad".
• La retención por capa. Bronze suele guardar el historial más largo; es tu búfer de reproducción.
• Los responsables de cada capa y de cada comprobación.
• Los datos personales. Marca dónde se guardan y dónde se enmascaran o se descartan; consulta el diagrama de mapeo de datos para el RGPD.

Errores comunes

• Una sola flecha de la base de datos al almacén. Oculta el slot, los esquemas y cada punto donde los datos pueden perderse o retrasarse.
• Consultas analíticas sobre el primario. Las extracciones por lotes contra el primario de producción compiten con el tráfico de los clientes; usa CDC o una réplica, y dibuja cuál.
• Sin camino de reproducción. Si no se conserva bronze, un error en una transformación obliga a volver a leer el origen.
• Tablas en bruto como interfaz pública. Los consumidores que leen eventos de cambio de tablas internas se rompen cuando cambia el esquema. Para los eventos dirigidos a otros equipos, publica eventos diseñados para ellos; el diagrama de arquitectura orientada a eventos cubre ese lado.
• Comprobaciones que solo registran. Una prueba que falla sin avisar a nadie es un comentario.

Para el lado de la base de datos del mismo sistema, consulta el diagrama de replicación de bases de datos y el ejemplo de diagrama ER.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Del pack Datos, añade un nodo Postgres para la base de origen y un nodo Kafka para los topics.
3. Añade nodos Contenedor del pack Modelo C4 para Debezium, el registro de esquemas, el conector sink y los paneles.
4. Añade un Marco del pack Básico llamado Lake and warehouse, con dos nodos Almacén de objetos del pack Datos para bronze y silver y un Almacén de datos para gold.
5. Del pack DevOps, añade una Canalización para el orquestador y una Alerta para las comprobaciones de datos. Dibuja discontinuas las conexiones de control.
6. Añade un bloque Markdown del pack Básico con las reglas del slot y de los esquemas.

El ejemplo usa 13 nodos de diagrama, dentro del plan Free. Si tienes el esquema de origen en SQL, la herramienta PostgreSQL a diagrama ER dibuja las tablas que hay detrás de los topics.

Preguntas frecuentes

¿Es mejor CDC que las extracciones por lotes? En frescura, borrados y carga sobre el origen, normalmente sí. Los lotes son más sencillos de operar y bastan cuando unas horas de retraso son aceptables y las filas nunca se borran físicamente.

¿Necesito Kafka para hacer CDC? Debezium suele ejecutarse sobre Kafka Connect, y Kafka te da reproducción y muchos consumidores. Existen otras configuraciones; dibuja el transporte que de verdad usas y su retención.

¿Cómo gestiono los cambios de esquema? Registra los esquemas con reglas de compatibilidad, añade columnas en lugar de cambiarlas y haz que los modelos posteriores toleren columnas nuevas. Dibuja el registro, porque ahí vive el contrato.

¿Dónde deben ejecutarse las comprobaciones de calidad de datos? Después de cada capa, como parte de la ejecución orquestada, con alertas al responsable. Las comprobaciones de frescura sobre gold detectan la mayoría de los fallos silenciosos.

¿Cómo mantengo actualizado el diagrama del pipeline? Cámbialo en la misma pull request que la configuración del conector y del orquestador; consulta diagramas de arquitectura que no se quedan obsoletos.

Empieza gratis — un puesto, sin tarjeta de crédito.