Por Andrew Tan
La ejecución programada que solía ser suficiente
Durante la mayor parte de la última década, el workflow de analítica se veía así:
Extraer datos de tus fuentes. Cargarlos en un almacén. Escribir modelos SQL en dbt. Programarlos para que se ejecuten cada pocas horas. Construir dashboards encima. Cuando el negocio pregunta por qué los números parecen incorrectos, revisas la insignia de frescura y descubres que el trabajo falló hace seis horas.
No era perfecto, pero era predecible. El contrato entre analítica e ingeniería era claro: los modelos se construyen en el almacén, en un horario, en SQL. dbt hizo que ese contrato fuera elegante. Modelos controlados por versiones, pruebas automatizadas, gráficos de dependencias, documentación generada a partir del código. Para la analítica por lotes, fue un verdadero avance.
Luego, el negocio comenzó a pedir datos más frescos. No frescos al día siguiente. No frescos cada hora. Frescos impulsados por eventos. El tipo de frescura donde un cliente actualiza su perfil y el motor de recomendaciones lo sabe antes de que se vaya.
Y de repente, la ejecución programada no es suficiente.
Por qué el éxito de dbt creó una brecha en el tiempo de ejecución
La idea central de dbt fue separar la lógica del modelo de la infraestructura de ejecución. Escribes el SQL. dbt maneja el DAG, las pruebas, la documentación, la estrategia de materialización. El cómputo real se ejecuta donde lo indiques: Snowflake, BigQuery, Redshift, Databricks. A dbt no le importa. Es un compilador y orquestador para modelos SQL, no un tiempo de ejecución.
Esa separación fue genial para cargas de trabajo por lotes. Significaba que los ingenieros de analítica podían poseer la lógica de modelado sin gestionar clústeres, estrategias de particionamiento o ajustes de memoria. El almacén se encargaba de todo eso. El ingeniero de analítica se centraba en la semántica: qué significa este modelo, cómo se prueba, quién depende de él.
Pero esa separación asume algo importante: que la capa de ejecución puede manejar la carga de trabajo que le estás lanzando. Y para trabajos por lotes programados contra un almacén moderno, eso es cierto. Para procesamiento en tiempo real contra datos streaming, no lo es.
La brecha no está en el SQL. El SQL de dbt sigue siendo SQL. La brecha está en todo lo que sucede entre el evento y el resultado del modelo:
- SLA de frescura. Un modelo de dbt que se ejecuta cada quince minutos sigue estando quince minutos atrasado. En un contexto de streaming, quince minutos es un trabajo por lotes disfrazado.
- Eventos desordenados. Los datos transmitidos llegan tarde, duplicados o fuera de secuencia. Un modelo SQL que asume entrada ordenada produce resultados incorrectos sin advertencia.
- Operaciones con estado. Funciones de ventana, sessionización, deduplicación: todas necesitan mantener el estado a través de eventos. Las estrategias de materialización de dbt (tabla, incremental, efímero) no fueron diseñadas para la gestión de estado en tiempo de evento.
- Uniones operativas. Unir un flujo de órdenes a una tabla de dimensión que cambia lentamente en tiempo real es un problema diferente a unir dos tablas de almacén en
customer_id. La dimensión podría cambiar a mitad de consulta. El flujo no espera.
Estos no son casos extremos. Son las características definitorias del procesamiento de streams. Y dbt, por diseño, delega todos ellos a la capa de ejecución.
Lo que realmente están vendiendo los proveedores
Si has asistido a una conferencia de datos en el último año, has visto el cambio de marketing. Confluent está impulsando el modelado nativo de dbt en Flink. Fivetran lanzó dbt Wizard con generación de modelos asistida por IA. Snowflake anunció Tablas Dinámicas, BigQuery tiene Vistas Materializadas, Databricks está apostando por Delta Live Tables.
El mensaje es consistente: puedes mantener tu workflow de dbt y simplemente... hacerlo en tiempo real. El SQL sigue siendo el mismo. El DAG sigue siendo el mismo. Lo único que cambia es la velocidad.
Esto es aproximadamente medio cierto.
Sí, puedes ejecutar SQL en datos streaming. Flink SQL, Spark Structured Streaming y una lista creciente de procesadores de streams admiten sintaxis SQL que parece familiar. Sí, puedes controlar versiones de esos archivos SQL y construir DAGs. Algunas herramientas incluso admiten pruebas y documentación al estilo dbt.
Lo que no te dicen es que la otra mitad del problema —la mitad del tiempo de ejecución— no desaparece. Solo cambia de forma.
Cuando te mueves de lotes programados a streaming continuo, heredas un nuevo conjunto de preocupaciones que dbt nunca tuvo que resolver:
| Suposición de lotes | Realidad de streaming |
|---|---|
| Los datos están completos cuando comienza el trabajo | Los datos nunca están completos; las llegadas tardías son normales |
| Las fallas se detectan al final de la ejecución | Las fallas deben detectarse y manejarse por evento |
| Los cambios de esquema ocurren entre ejecuciones | Los cambios de esquema ocurren en medio del stream |
| Reprocesar significa volver a ejecutar un trabajo | Reprocesar significa rebobinar un stream y reproducir |
| El costo es proporcional al volumen de datos | El costo es proporcional al tiempo de actividad de la infraestructura |
El SQL podría parecer el mismo. Pero el sistema que lo ejecuta está resolviendo un conjunto de problemas completamente diferente.
La pregunta de propiedad que nadie quiere responder
Aquí es donde se vuelve organizacional. dbt creó un límite claro: los ingenieros de analítica poseen los modelos, los ingenieros de plataforma poseen el almacén. Cuando un modelo falla, generalmente es un problema de SQL o un problema de calidad de datos. Cuando el almacén es lento, es un problema de plataforma. La separación de preocupaciones se mapeó perfectamente a una separación de equipos.
El streaming rompe ese límite.
Cuando una pipeline en tiempo real falla, ¿es un problema de SQL o un problema de infraestructura? Si los eventos llegan fuera de orden, ¿el ingeniero de analítica reescribe la lógica de ventana, o el ingeniero de plataforma reconfigura la configuración de watermark del procesador de streams? Si un evento que llega tarde corrompe una vista materializada, ¿quién lo arregla: la persona que escribió el SQL o la persona que gestiona el checkpointing?
He visto equipos manejar esto de tres maneras, y solo una de ellas funciona:
Opción 1: Los ingenieros de analítica aprenden procesamiento de streams. Se vuelven expertos en checkpointing, backpressure, tiempo de evento vs. tiempo de procesamiento, y semántica exactamente una vez. Esto funciona para equipos pequeños con personas senior. No escala.
Opción 2: Los ingenieros de plataforma poseen todo lo que está aguas abajo de Kafka. Los ingenieros de analítica escriben especificaciones SQL, y el equipo de plataforma las implementa en Flink o Spark. Esto preserva la separación pero crea una capa de traducción. Las especificaciones SQL son ambiguas sobre el comportamiento en tiempo de evento. El equipo de plataforma hace suposiciones. Esas suposiciones se convierten en errores seis meses después.
Opción 3: Separar la lógica de modelado de la responsabilidad del tiempo de ejecución. Los ingenieros de analítica poseen lo que significa el modelo: la lógica de negocio, las pruebas, la semántica. Los ingenieros de plataforma poseen cómo se ejecuta: el motor de ejecución, el backend de estado, la recuperación de fallos. Ambas partes acuerdan un contrato: el modelo espera entrada ordenada dentro de una tardanza limitada, y el tiempo de ejecución garantiza ese contrato o muestra un error claro.
Esta tercera opción es más difícil de configurar. Requiere que ambos equipos acuerden interfaces y modos de fallo de antemano. Pero es la única que escala sin convertir a tus ingenieros de analítica en especialistas en sistemas distribuidos o a tu equipo de plataforma en lectores de mentes.
Lo que realmente requiere "dbt en tiempo real"
Si tu equipo está serio sobre mover modelos al estilo dbt a pipelines en tiempo real, esto es lo que realmente necesitas, no lo que está en la presentación de marketing:
Un tiempo de ejecución que entienda el tiempo de evento. No solo el tiempo de procesamiento. El diferencia entre "cuándo llegó esto" y "cuándo sucedió esto" es la diferencia entre resultados correctos y resultados sutilmente incorrectos que se ven bien en un dashboard.
Gestión de estado explícita. Ventanas, deduplicación y sessionización requieren estado. Ese estado necesita ser checkpointed, recuperable y consultable para depuración. Si no puedes inspeccionar lo que el sistema pensó a las 2:47 PM el martes pasado, no puedes depurar un incidente de producción.
Evolución de esquema con dientes. Agregar una columna es fácil. Manejar un cambio de tipo, un renombramiento o un cambio semántico en el significado de una columna es difícil. Tu pipeline necesita detectar estos cambios, decidir si son seguros, y adaptarse o detenerse con un error claro.
Reproducción y backfill como operaciones de primera clase. En lotes, reprocesar es volver a ejecutar un trabajo. En streaming, es rebobinar un log y reproducir eventos a través de la misma lógica. Si tu pipeline en tiempo real no puede reproducir exactamente, no puedes recuperarte de errores, no puedes probar cambios contra datos históricos, y no puedes demostrar cumplimiento.
Visibilidad de costos por carga de trabajo. Los costos por lotes son fáciles de razonar: este trabajo procesó esta cantidad de datos y tomó este tiempo. Los costos de streaming son continuos: el trabajo siempre está en ejecución, siempre consumiendo recursos, y el costo no se correlaciona claramente con la salida del negocio. Necesitas telemetría que conecte el gasto de infraestructura con el comportamiento de la pipeline.
Ninguna de estas son características de SQL. Son características de tiempo de ejecución. Y son la diferencia entre una demo que se ejecuta durante diez minutos y un sistema que se ejecuta durante diez meses.
La propuesta honesta
dbt cambió cómo trabajan los equipos de analítica. Trajo prácticas de ingeniería de software —control de versiones, pruebas, documentación— a una disciplina que las necesitaba urgentemente. Esa contribución es real y duradera.
Pero dbt fue construido para un mundo donde los datos se mueven en lotes, los almacenes son el centro de gravedad, y "fresco" significa "actualizado esta hora". La industria se está moviendo hacia un mundo donde los datos se mueven continuamente, los modelos se aplican en vuelo, y "fresco" significa "actualizado este milisegundo".
Eso no hace que dbt sea obsoleto. Hace que dbt sea incompleto para un conjunto creciente de casos de uso.
Los proveedores que venden "dbt en tiempo real" están respondiendo a una demanda real. Pero lo que están vendiendo es generalmente una interfaz SQL en un procesador de streams, no una solución a los problemas de tiempo de ejecución que introduce el procesamiento de streams. El SQL es la parte fácil. La gestión de estado, la recuperación de fallos, la evolución de esquemas y la observabilidad operativa son las partes difíciles. Y esas partes difíciles no desaparecen solo porque el SQL parece familiar.
Si estás evaluando una de estas herramientas, no preguntes "¿Puede ejecutar mis modelos dbt más rápido?" Pregunta "¿Qué pasa cuando un nodo se reinicia a mitad de ventana?" "¿Cómo reproduzco los datos del martes pasado a través de un modelo que cambié ayer?" "¿Qué hace el sistema cuando el esquema cambia a las 2 AM?"
Las respuestas a esas preguntas te dirán si estás comprando una herramienta de lotes más rápida o un tiempo de ejecución de streaming real.
Dónde encajamos nosotros
En layline.io, construimos un tiempo de ejecución que maneja tanto lotes como streaming en la misma pipeline. No dos sistemas separados con un barniz SQL sobre cada uno. Un sistema donde el mismo equipo puede construir cargas programadas de almacén y procesamiento de eventos en tiempo real sin cambiar de herramientas, contextos o modelos mentales.
Los ingenieros de analítica mantienen la propiedad de la semántica del modelo. El equipo de plataforma mantiene la propiedad de la infraestructura de ejecución. Pero ambas partes trabajan en el mismo entorno, con la misma observabilidad y las mismas garantías alrededor de la reproducción, recuperación de estado y evolución de esquemas.
dbt enseñó a la industria que la lógica de modelado merece rigor. Estamos construyendo sobre esa idea —y agregando el rigor de tiempo de ejecución que los datos en tiempo real demandan.
Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura de procesamiento de datos empresarial que maneja tanto cargas de trabajo por lotes como en tiempo real a escala.
