¿Qué es la arquitectura de canalización de datos?

La arquitectura de pipeline de datos es el diseño de extremo a extremo de cómo se recopilan, procesan, almacenan y entregan los datos desde los sistemas de origen hasta las personas, aplicaciones y modelos que los utilizan. La palabra “arquitectura” se refiere al plano, no al pipeline en sí. Abarca las decisiones sobre cómo fluyen los datos, dónde se transforman y qué herramientas gestionan cada paso del camino.

Una buena arquitectura se adapta al caso de uso en lugar de elegirse de forma genérica. Un pipeline de datos creado para la detección de fraudes en tiempo real se ve muy diferente de uno que genera un informe de ventas nocturno, aunque ambos mueven datos del origen al destino. Esta página de glosario cubre las capas principales que comparten todos los pipelines, los modelos de etapas comunes, los patrones arquitectónicos principales y las mejores prácticas que mantienen la confiabilidad de los pipelines a medida que escalan.

¿Cómo funciona la arquitectura de un pipeline de datos?

Un pipeline de datos mueve los datos a través de una serie de etapas, y cada etapa tiene una tarea específica: recopilar los datos, limpiarlos, almacenarlos y hacerlos utilizables. La arquitectura es el plan de cómo se conectan esas etapas. Define qué sucede con los datos en cada paso, en qué orden y bajo qué reglas.

Las decisiones de arquitectura se sitúan en dos niveles. El diseño lógico define qué etapas existen y qué hace cada una: este es “el qué”. El diseño físico define qué herramientas e infraestructura específicas ejecutan cada etapa: este es “el cómo”. La orquestación (la programación y coordinación automática de cada paso) y el monitoreo no pertenecen a una sola etapa. Se ejecutan en todo el pipeline. Las plataformas modernas también han eliminado una antigua división. Con Lakeflow, Databricks unifica los pipelines de batch y streaming en una sola base, para que los equipos no tengan que crear y mantener dos sistemas paralelos.

Las capas principales de un pipeline de datos

Independientemente del patrón que elija un equipo, cada pipeline de datos se construye sobre las mismas cuatro capas. Cada capa responde a una pregunta diferente sobre los datos: cómo entran, cómo se vuelven útiles, dónde residen y quién los consume.

Ingesta

La ingesta extrae datos hacia el pipeline desde los sistemas de origen: bases de datos, aplicaciones, APIs, archivos en almacenamiento en la nube, flujos de eventos y sensores. La ingesta de datos se presenta en dos modalidades. La ingesta por lotes (batch) extrae datos según una programación, como cada hora o cada noche. La ingesta de streaming captura datos de forma continua a medida que ocurren los eventos. Muchos pipelines también utilizan change data capture (CDC), un método que rastrea los cambios a nivel de fila en una base de datos de origen para que el pipeline mueva solo lo nuevo o actualizado en lugar de volver a cargar todo.

Procesamiento y transformación

En esta capa es donde los datos brutos se limpian, remodelan, enriquecen y preparan para su uso. El trabajo típico incluye corregir valores faltantes, estandarizar formatos, unir conjuntos de datos y aplicar lógica de negocio, las mismas tareas que están en el corazón de ETL. El procesamiento sigue la misma división que la ingesta. El procesamiento por lotes (batch) trabaja con grandes volúmenes de datos a la vez, mientras que el procesamiento de streaming maneja los registros uno a uno o en pequeños micro-lotes (micro-batches) a medida que llegan.

Almacenamiento

El almacenamiento es donde aterrizan los datos procesados para que puedan ser consultados, analizados o enviados a los modelos. El destino suele ser un data lake, un data warehouse o un lakehouse, un único sistema que combina las ventajas de ambos. El formato importa tanto como la ubicación. Los formatos abiertos como Lakehouse Storage y Apache Iceberg permiten que múltiples herramientas lean los mismos datos sin tener que copiarlos de un sistema a otro. Delta Lake también añade características de confiabilidad como transacciones ACID (una garantía de que las escrituras se realizan por completo o fallan por completo, evitando la corrupción) y time travel (la capacidad de consultar versiones anteriores de una tabla).

Entrega y consumo

La capa final entrega los datos preparados a las personas y sistemas que los necesitan: analistas que ejecutan consultas SQL, usuarios de negocio que trabajan con tableros (dashboards), científicos de datos que entrenan modelos y aplicaciones que llaman a APIs. Los destinos van desde herramientas de BI hasta plataformas de ML y sistemas operativos, con un data warehouse que a menudo se encuentra en el centro de las cargas de trabajo analíticas. A lo largo de las cuatro capas, la orquestación y la observabilidad realizan el trabajo de conexión: programar tareas, realizar un seguimiento de la calidad de los datos y generar alertas cuando algo falla.

¿Cuántas etapas tiene un pipeline de datos? (3 frente a 4 frente a 5)

Diferentes fuentes describen que los pipelines de datos tienen tres, cuatro o cinco etapas, lo que genera mucha confusión. La realidad es más sencilla. Los tres modelos describen el mismo trabajo subyacente con diferentes niveles de detalle.

El número de etapas es una elección de nomenclatura. El trabajo que realiza el pipeline es el mismo.

Patrones comunes de arquitectura de pipelines de datos

Los patrones arquitectónicos son los diseños establecidos entre los que eligen los equipos al construir pipelines. El adecuado depende de los requisitos de latencia, el volumen de datos y cómo se utilizarán los datos en las etapas posteriores (downstream).

Arquitectura por lotes (batch)

La arquitectura por lotes (batch) procesa datos en bloques programados: cada hora, cada noche o cada semana. Se adapta a la generación de informes, análisis históricos, datos de entrenamiento de ML y cualquier caso de uso donde se acepten retrasos de minutos u horas. Los pipelines de batch son más sencillos de construir, más económicos de ejecutar y más fáciles de depurar que sus equivalentes de streaming. La desventaja es la frescura de los datos. Cuando las decisiones dependen de lo que sucedió hace segundos, el procesamiento por lotes no puede mantener el ritmo.

Arquitectura de streaming

La arquitectura de streaming procesa datos de forma continua, registro por registro, a medida que se generan. Sirve para casos de uso donde importa una respuesta de menos de un minuto: detección de fraudes, personalización en tiempo real y monitoreo de IoT. La desventaja es el costo. Los pipelines de streaming suelen costar más de ejecutar y operar que los de batch porque requieren una infraestructura siempre activa.

Arquitectura Lambda

La arquitectura Lambda ejecuta dos rutas paralelas. Una ruta de batch ofrece datos históricos precisos, una ruta de streaming ofrece datos rápidos y frescos, y una capa de entrega combina los resultados. El diseño funciona, pero conlleva una desventaja muy conocida. Mantener dos pipelines significa duplicar código, duplicar lógica y duplicar la carga operativa.

Arquitectura Kappa

La arquitectura Kappa simplifica la arquitectura Lambda al utilizar un único pipeline de streaming para todo. Cuando se necesita un análisis histórico, el flujo se vuelve a reproducir desde el principio. Kappa se adapta a los equipos que desean una frescura de nivel de streaming sin el costo de mantener dos sistemas paralelos.

Arquitectura de medallón (patrón lakehouse)

La arquitectura de medallón es un patrón popular en las plataformas lakehouse que organiza los datos en tres niveles de calidad: Bronce (datos brutos, tal como se ingieren), Plata (limpios y adaptados) y Oro (curados, listos para el negocio). Como señala la documentación de Databricks, "la arquitectura de medallón utiliza tres capas: bronce, plata y oro, cada una con un propósito distinto en el pipeline". Cada nivel puede ejecutarse como su propio pipeline, lo que facilita la programación, el monitoreo y la resolución de problemas porque los inconvenientes quedan aislados en una sola capa.

ETL frente a ELT: cómo el orden de transformación define la arquitectura

ETL y ELT se diferencian en el momento en que se transforman los datos. ETL (extraer, transformar, cargar) transforma los datos antes de cargarlos en el almacenamiento. ELT (extraer, cargar, transformar) carga primero los datos brutos y los transforma dentro del destino. Las plataformas en la nube modernas como Databricks, Snowflake y BigQuery han convertido a ELT en el patrón dominante porque el almacenamiento y el cómputo en la nube son ahora lo suficientemente económicos y elásticos como para transformar los datos en el lugar. Para una comparación más detallada, consulte ETL frente a ELT.

¿Es ETL lo mismo que un pipeline de datos?

No. ETL es un tipo de pipeline de datos, pero no todos los pipelines de datos son ETL. Un pipeline de datos es la categoría general: cualquier sistema que mueve datos de un lugar a otro. ETL es un enfoque específico dentro de esa categoría, definido por la transformación de los datos antes de que lleguen al almacenamiento. Los pipelines también pueden ser ELT, de streaming, de solo replicación (mover datos sin ninguna transformación) o ETL inverso (enviar datos del data warehouse de vuelta a los sistemas operativos).

Buenas prácticas para la arquitectura de pipelines de datos

Estos 10 principios de diseño diferencian a los pipelines que escalan de los que se rompen.

1. Separa la ingesta de la transformación. Mantén la llegada de datos brutos y la limpieza de datos en etapas diferentes para que los problemas de una no afecten en cascada a la otra.
2. Diseña pensando en la idempotencia. Debe ser seguro volver a ejecutar un pipeline sin crear registros duplicados ni corromper los resultados. Esto es fundamental para gestionar fallos y backfills.
3. Integra controles de calidad de datos. Los controles estrictos de calidad de datos validan el esquema, los rangos de valores, los recuentos de nulos y la frescura en cada etapa, y fallan de forma evidente cuando algo va mal en lugar de permitir que los datos erróneos fluyan río abajo.
4. Planifica para el schema drift. Los sistemas de origen cambian. Los pipelines deben detectar cuándo se añaden, eliminan o renombran columnas y gestionar el cambio de forma fluida en lugar de romperse.
5. Usa formatos de almacenamiento abiertos. Formatos como Delta Lake y Apache Iceberg evitan la dependencia de un proveedor (lock-in) y permiten que múltiples herramientas lean los mismos datos sin necesidad de realizar copias.
6. Desacopla las capas del pipeline. Dividir los niveles de la arquitectura medallón (Bronze, Silver y Gold) en pipelines separados facilita la programación, el monitoreo y la resolución de problemas de cada uno de forma independiente.
7. Controla las versiones de todo. Almacena el código y la configuración del pipeline en Git para que los cambios se revisen, sean trazables y reversibles.
8. Trata la gobernanza como una prioridad de primer nivel. Aplica permisos consistentes, seguimiento de linaje y controles de auditoría en cada etapa con una herramienta como Unity Catalog, en lugar de añadirlos a la fuerza al final.
9. Dimensiona adecuadamente el streaming frente al procesamiento por lotes (batch). Usa streaming solo donde la frescura de los datos sea realmente importante, y opta por batch por defecto en todo lo demás para controlar los costes.
10. Monitorea de extremo a extremo. Realiza un seguimiento de la frescura, el volumen y la calidad de los datos, así como de los tiempos de ejecución del pipeline, para detectar los problemas antes de que los usuarios finales los noten.

Por qué es importante la arquitectura de los pipelines de datos

La arquitectura de los pipelines determina si los equipos pueden confiar en sus datos, si las decisiones se basan en información fresca y si los proyectos de AI y ML pasan del prototipo a la producción. Es la diferencia entre una plataforma de datos que acumula valor y otra que genera tickets de soporte.

Una arquitectura frágil genera costes reales: dashboards desactualizados, métricas contradictorias, despliegues de ML fallidos e ingenieros que pasan más tiempo apagando fuegos que construyendo. El enfoque de lakehouse moderno aborda la causa raíz. Al unificar batch y streaming, analítica y AI, y gobernanza en una sola plataforma como la plataforma Databricks, los equipos eliminan las transferencias frágiles entre sistemas que hacen que las arquitecturas tradicionales se rompan.

Arquitectura de pipelines de datos en Databricks

Databricks ofrece cada capa de la arquitectura de pipelines en una sola plataforma. Lakeflow Connect gestiona la ingesta desde bases de datos, aplicaciones SaaS, fuentes de archivos y flujos de eventos. Lakeflow Spark Declarative Pipelines crea pipelines ETL de batch y streaming con controles de calidad de datos integrados, y Lakeflow Jobs orquesta y programa las ejecuciones de los pipelines en toda la plataforma. Por debajo, Delta Lake proporciona el formato de almacenamiento abierto junto con características de confiabilidad como transacciones ACID y time travel, mientras que Unity Catalog aplica gobernanza, linaje y control de acceso en cada etapa.

Dado que los pipelines de batch y streaming se ejecutan en el mismo motor y escriben en el mismo almacenamiento, los equipos no necesitan mantener sistemas paralelos de estilo Lambda. Una sola definición de pipeline puede servir tanto para el informe nocturno como para el dashboard en tiempo real.

Preguntas frecuentes

¿Qué es la arquitectura de pipelines de datos en pocas palabras?

Es el plan sobre cómo los datos van desde donde se crean hasta donde resultan útiles. El plan abarca cómo se recopilan los datos, cómo se limpian y preparan, dónde se almacenan y cómo se entregan a las personas y aplicaciones que los necesitan.

¿Cuál es la diferencia entre la arquitectura Lambda y la Kappa?

Lambda ejecuta dos pipelines paralelos, uno de batch y otro de streaming, y combina sus resultados en una capa de servicio (serving layer). Kappa utiliza un único pipeline de streaming para todo y vuelve a reproducir el flujo cuando se necesita un análisis histórico. Kappa es más sencillo de operar, mientras que Lambda persiste en entornos donde las rutas de batch y streaming evolucionaron por separado.

¿Cuándo se deben usar pipelines de batch frente a los de streaming?

Usa streaming cuando el valor de los datos disminuya en cuestión de segundos o minutos, como en la detección de fraudes, la personalización en tiempo real o el monitoreo de equipos. Usa batch para todo lo demás, incluidos los informes, el análisis histórico y los datos de entrenamiento de ML. Batch es más sencillo y económico, por lo que es la opción predeterminada más sensata hasta que un caso de uso demuestre que necesita datos en tiempo real.

¿Cuál es la diferencia entre la arquitectura de pipeline lógica y física?

La arquitectura lógica define las etapas de un pipeline y lo que hace cada una, independientemente de cualquier herramienta. La arquitectura física mapea esas etapas en tecnologías e infraestructura específicas. Los equipos suelen definir primero el diseño lógico y luego eligen las plataformas que lo implementan.

Adapta tu arquitectura al trabajo

La arquitectura de pipelines de datos es el diseño detrás de cómo se mueven los datos y cómo se vuelven útiles. La arquitectura adecuada es aquella que equilibra la frescura, el coste y la confiabilidad para el trabajo específico en cuestión, ya sea un informe de ventas nocturno o una verificación de fraude que se ejecuta en milisegundos.

Descubre cómo Databricks unifica los pipelines de batch y streaming, el almacenamiento y la gobernanza en una sola plataforma.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original