Por Andrew Tan
La costosa verdad sobre los stacks de datos modernos
Pasas suficiente tiempo cerca de equipos de plataforma de datos y escuchas la misma historia. Una empresa construye su "stack de datos moderno" — almacén de datos, capa de procesamiento, orquestador — y todo se ve limpio en el diagrama de arquitectura. Entonces la factura del almacén de datos empieza a subir. Los trabajos de ingesta fallan más a menudo de lo que nadie esperaba. Y cada vez que algo se rompe, toma medio día averiguar si el problema está en la carga, la transformación, el orquestador o el almacén de datos mismo.
En algún momento, alguien en el equipo dice en voz alta la parte que todos callan: "Creo que construimos una herramienta de integración realmente cara sin querer."
Normalmente tienen razón.
El error de categoría
Un almacén de datos es un motor de consulta y almacenamiento. Está optimizado para una sola cosa: responder preguntas analíticas rápidamente sobre grandes conjuntos de datos.
Un Data Pipeline es un tiempo de ejecución de movimiento y procesamiento. Está optimizado para algo diferente: llevar los datos de donde están a donde necesitan estar, con la forma correcta, en el momento correcto, de manera confiable.
Esos son trabajos diferentes. Pero en la última década, le hemos pedido silenciosamente al almacén de datos que hiciera ambos.
Empezó inocentemente. Los almacenes de datos mejoraron cargando datos. Luego obtuvieron procedimientos almacenados. Luego dbt convirtió SQL en una capa de procesamiento. Luego los orquestadores comenzaron a disparar consultas del almacén de datos para mover datos entre tablas. Y antes de que alguien lo nombrara, el almacén de datos se había convertido en la capa de integración predeterminada.
El resultado es predecible. El almacén de datos es excelente en analítica. Es mediocre en integración. Y cuando lo obligas a hacer integración a escala, lo pagas con tres monedas: costo, confiabilidad y fragilidad arquitectónica.
Qué sale mal cuando el almacén de datos se convierte en el Data Pipeline
La factura de computación se vuelve una sorpresa
La computación del almacén de datos está precificada para consultas analíticas. Los analistas ejecutan algunas consultas grandes, esperan los resultados y van a tomar decisiones. La computación es intermitente y a ritmo humano.
Las cargas de trabajo de integración no se ven así. Se ejecutan continuamente o en horarios ajustados. Mueven millones de filas. Ejecutan las mismas conversiones una y otra vez. No se detienen para que los humanos lean paneles.
Cuando ejecutas este tipo de carga de trabajo dentro de un almacén de datos, el medidor gira de manera diferente. Es común que una sincronización "simple" por hora consuma más créditos que toda la carga de trabajo analítica. No porque el almacén de datos sea malo, sino porque es el motor equivocado para el trabajo.
Las fallas se vuelven opacas
Un Data Pipeline tiene un trabajo claro: tomar datos de A, transformarlos, entregarlos en B. Cuando falla, quieres saber qué paso falló y por qué.
Cuando el almacén de datos es el Data Pipeline, la falla se distribuye entre capas. ¿La carga fue lenta porque el almacén de datos estaba sobrecargado? ¿El orquestador perdió su conexión? ¿La consulta de transformación alcanzó un tiempo de espera? ¿Los datos están mal por la fuente, la conversión o un cambio en el plan de ejecución del almacén de datos?
La depuración se convierte en arqueología. Excavas en el historial de consultas, los registros del orquestador y las métricas del almacén de datos, intentando reconstruir lo que realmente sucedió. Las herramientas están todas ahí. La claridad no.
La latencia es lo que el almacén de datos decida
Si tu Data Pipeline es una serie de consultas del almacén de datos, tu latencia está limitada por la programación del almacén. Una consulta espera en una cola. Se compila. Se ejecuta. Tal vez sea interrumpida. Tal vez escale. Tal vez no.
Para analítica por lotes, esto está bien. A nadie le importa si un informe nocturno termina a las 3 AM o a las 3:15 AM.
Para casos de uso operacionales, no está bien. Detección de fraude, actualizaciones de inventario, paneles orientados al cliente — estos necesitan minutos o segundos, no el tiempo de cola del almacén de datos. Cuando el almacén de datos es tu Data Pipeline, heredas su ritmo. Y su ritmo está diseñado para analistas, no para operaciones.
El bloqueo se profundiza
Cuanta más lógica de integración vive dentro del almacén de datos, más difícil se vuelve salir. Tus reescrituras están en dialectos SQL específicos del almacén. Tu orquestación está atada a sesiones del almacén. Tus reglas de calidad de datos se ejecutan como consultas del almacén. Incluso tu visibilidad de costos está moldeada por el almacén.
Esto no es una conspiración. Es simplemente lo que sucede cuando una herramienta se vuelve responsable de demasiados trabajos. El costo de migración crece hasta que se siente más fácil quedarse infeliz que irse.
Cómo se ve una separación limpia
La solución no es desechar el almacén de datos. El almacén de datos es bueno en lo que hace. La solución es dejar que haga lo que hace y dejar de pedirle que lo haga todo.
En la práctica, eso suele significar dos plataformas, no una:
Tiempo de ejecución de integración y orquestación
Aquí es donde los datos se mueven, se transforman, se validan y se enrutan a los consumidores correctos. También programa Data Pipelines, reintenta fallas, impone dependencias y dispara trabajo posterior — tanto dentro de la plataforma como en sistemas externos. Se ejecuta en un motor diseñado para flujo de datos continuo, no para latencia de consulta.
Almacén de datos
Aquí es donde los datos se almacenan y consultan. Recibe datos limpios y listos para consultar desde la capa de integración. No se preocupa por cómo llegaron los datos ahí, cuándo llega la siguiente carga o qué hacer si un trabajo falla. Solo responde preguntas.
Lógicamente, aún puedes pensar en integración y orquestación como preocupaciones separadas. Operativamente, a menudo pertenecen al mismo tiempo de ejecución. Un Data Pipeline que puede mover datos pero no programarse a sí mismo, reintentarse a sí mismo o disparar el siguiente paso es solo medio útil. Las mejores plataformas combinan ambos.
Cuando estas preocupaciones se separan del almacén de datos, cada herramienta se vuelve más simple. La capa de integración está optimizada para throughput y confiabilidad. El orquestador está optimizado para gestión de dependencias y recuperación de fallas. El almacén de datos está optimizado para rendimiento de consultas.
Lo más importante es que los problemas se mantienen en su carril. Cuando la ingesta falla, miras el tiempo de ejecución de integración. Cuando un informe está mal, miras el almacén de datos. Cuando un trabajo no se ejecuta, miras al orquestador — que, en una configuración limpia, es parte del mismo tiempo de ejecución que mueve los datos.
Cuando el almacén-como-Data-Pipeline realmente está bien
No quiero exagerar esto. Para algunos equipos, el patrón de almacén-como-Data-Pipeline funciona bien.
Si eres pequeño, tus volúmenes de datos son bajos, tu transformación es simple y tus requisitos de latencia son "mañana está bien", entonces mantener todo en un solo lugar es un compromiso razonable. La simplicidad operativa vale más que la pureza arquitectónica.
Los problemas comienzan cuando el patrón sigue escalando más allá de su límite natural. Un equipo que lo supera usualmente lo sabe. Las facturas se vuelven extrañas. Las fallas se vuelven misteriosas. La idea de agregar un caso de uso en tiempo real se convierte en un proyecto de varios meses en lugar de un cambio de configuración.
La pregunta no es si el patrón es malo. La pregunta es si sigue siendo el patrón correcto para dónde estás ahora.
El camino de migración que nadie toma
La mayoría de los equipos imaginan esta separación como un proyecto de reemplazo total. No tiene que serlo.
El mejor enfoque es extraer primero la capa de movimiento. Elige una fuente de datos. En lugar de cargarla directamente en el almacén de datos y luego transformarla allí, muévela primero a través de un tiempo de ejecución de integración dedicado. Límpiala. Valídala. Luego escribe los datos limpios en el almacén de datos.
El almacén de datos no cambia mucho. Los analistas siguen consultando las mismas tablas. Pero ahora esas tablas son alimentadas por un Data Pipeline diseñado para alimentar tablas.
Una vez que se mueve una fuente, el patrón se repite. Fuente por fuente. Data Pipeline por Data Pipeline. Con el tiempo, el almacén de datos deja de ser el centro de integración y se convierte en lo que debía ser: el centro de analítica.
Los equipos que hacen esto con éxito no empiezan con el Data Pipeline más difícil. Empiezan con uno aburrido. Los Data Pipelines aburridos te enseñan el patrón sin el riesgo. Los Data Pipelines difíciles se vuelven más fáciles una vez que el patrón está establecido.
Dónde encaja layline.io
Seré directo: esta es la apuesta arquitectónica detrás de layline.io.
Construimos una plataforma de procesamiento de datos que maneja la capa de integración y orquestación — tanto por lotes como en streaming — sin hacer que el almacén de datos haga el trabajo pesado. Los Data Pipelines mueven datos, los transforman, los validan y los entregan. También se programan a sí mismos, reintentan ante fallas, imponen dependencias y disparan Workflows posteriores dentro de layline o en sistemas externos.
El almacén de datos almacena los datos y los consulta. Cada herramienta hace su propio trabajo.
Debido a que layline maneja tanto por lotes como streaming en el mismo tiempo de ejecución, no terminas con una herramienta para tus cargas por hora y otra para tus eventos en tiempo real. Mismos Workflows. Misma observabilidad. Mismo equipo. Y debido a que la orquestación está integrada, no necesitas un orquestador separado encima, coordinando entre layline y todo lo demás.
Eso no es un argumento de venta para todos. Si tu configuración de almacén-como-Data-Pipeline está funcionando y tus facturas son razonables, no nos necesitas. Pero si estás mirando una factura de almacén de datos triplicada y te preguntas cómo una sincronización "simple" se volvió tan cara, la separación que estamos describiendo probablemente es lo que realmente estás buscando.
La pregunta para hacerle a tu equipo
Elige tus tres cargas de trabajo de almacén de datos más caras. No las consultas analíticas más grandes — las que se ejecutan todo el día, moviendo y transformando datos.
Pregunta: ¿estas cargas de trabajo están respondiendo preguntas de negocio, o simplemente están dando forma a los datos para que puedan responder preguntas de negocio?
Si la respuesta es la segunda, tienes trabajo de integración ejecutándose en un motor analítico. Eso no es una falla moral. Es una arquitectura muy común. Pero también es una muy reparable.
El almacén de datos es una herramienta poderosa. Simplemente no es la única herramienta.
Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura empresarial de procesamiento de datos que maneja cargas de trabajo tanto por lotes como en tiempo real a escala.
