Streaming SQL es SQL que se ejecuta de forma continua sobre datos en movimiento. En lugar de consultar una tabla una sola vez y devolver un resultado fijo, una consulta de streaming SQL se suscribe a un flujo de eventos, como Kafka topics, registros de cambios de bases de datos o datos de sensores, y actualiza su resultado cada vez que llegan datos nuevos. La consulta sigue ejecutándose hasta que la detienes.
Para los equipos de datos, esto cambia quién puede construir pipelines en tiempo real. Filtrar, combinar y agregar eventos en vivo solía implicar escribir código Java o Scala sobre un framework de stream processing. Con streaming SQL, un analista o ingeniero de datos que ya conoce SQL puede expresar la misma lógica de forma declarativa, y el motor se encarga por debajo del estado, el orden y la tolerancia a fallos.
Una consulta SQL tradicional trabaja con datos acotados. La base de datos lee las filas que existen en el momento de la consulta, calcula una respuesta y se detiene. Una consulta de streaming SQL trabaja con datos no acotados: la entrada nunca termina, por lo que la consulta nunca "finaliza". Produce resultados de forma continua y los revisa a medida que llegan más eventos.
También lo encontrarás con el nombre de SQL stream processing, y la idea es anterior a la mayoría de las herramientas que la utilizan hoy. Productos pioneros como StreamSQL de StreamBase ampliaron SQL para flujos de eventos, y motores modernos como Apache Flink, ksqlDB y Spark Structured Streaming convirtieron este enfoque en algo habitual. En todos ellos, el objetivo es el mismo: ofrecer a los desarrolladores el modelo SQL que ya conocen para el stream processing en lugar de una nueva API de programación.
Streaming SQL no es un estándar de lenguaje independiente. Cada motor implementa su propio dialecto sobre SQL estándar y añade construcciones para el tiempo, las ventanas y la salida continua. Las ideas fundamentales son coherentes entre motores, por lo que conviene entender los conceptos antes de elegir una herramienta.
La idea central es que un flujo y una tabla son dos vistas de los mismos datos. Apache Flink lo denomina tabla dinámica: una tabla cuyo contenido cambia con el tiempo a medida que llegan eventos. Una consulta continua lee de una o varias tablas dinámicas y produce otra tabla dinámica como salida, que el motor mantiene actualizada de forma incremental en lugar de recalcularla desde cero.
Esa salida puede escribirse en otro Kafka topic, en una base de datos o en un data lake, o mantenerse como una vista materializada que las aplicaciones consultan directamente. Las streaming databases construyen todo su producto en torno a este último patrón: defines una vista materializada en SQL y la base de datos la mantiene actualizada a medida que cambian los flujos subyacentes.
Muchas preguntas sobre datos en streaming solo tienen sentido dentro de un intervalo de tiempo, como "ingresos por tienda en los últimos cinco minutos". Las ventanas dividen un flujo no acotado en grupos finitos sobre los que puede operar una agregación. La mayoría de los motores admiten tres tipos:
Los eventos no siempre llegan en el orden en que ocurrieron. Una aplicación móvil puede almacenar eventos en búfer sin conexión, y los retrasos de red pueden alterar el orden de los mensajes. Por eso, los motores de streaming SQL distinguen el event time, cuándo ocurrió algo, del processing time, cuándo lo vio el motor.
Para decidir cuándo una ventana está completa, los motores utilizan watermarks. Un watermark es una señal que indica que el event time ha avanzado hasta un punto determinado, por lo que no se esperan eventos anteriores. Tú defines cuánto retraso se tolera, por ejemplo 10 segundos, y el motor cierra las ventanas y emite resultados cuando el watermark supera ese punto. Este equilibrio entre latencia y completitud es una de las decisiones de diseño más importantes en cualquier pipeline de streaming SQL.
Las agregaciones, la deduplicación y los joins requieren que el motor recuerde eventos anteriores. Esa memoria se denomina estado, y el motor la almacena y genera checkpoints para que un fallo no provoque la pérdida de resultados. Los joins son donde más importa el estado: combinar un flujo de pagos con una tabla de perfiles de clientes es sencillo, mientras que combinar dos flujos no acotados requiere un límite temporal, o el estado crecería indefinidamente.
La sintaxis resulta familiar, pero el modelo de ejecución es diferente. La siguiente tabla resume las principales diferencias.
| SQL estándar | Streaming SQL | |
|---|---|---|
| Modelo de datos | Tablas acotadas en reposo | Flujos no acotados en movimiento |
| Duración de la consulta | Se ejecuta una vez y se detiene | Se ejecuta de forma continua hasta que se detiene |
| Resultados | Un conjunto de resultados fijo | Una tabla actualizada de forma continua o un flujo de cambios |
| Semántica temporal | Normalmente no está integrada | Event time, processing time y watermarks |
| Estado | Gestionado por el almacenamiento de la base de datos | Gestionado por el motor, con checkpoints para la recuperación |
| Uso habitual | Informes, análisis ad hoc, transacciones | Pipelines en tiempo real, alertas, métricas en vivo |
La consecuencia práctica es que streaming SQL recompensa pensar de forma explícita en el tiempo y el estado. Una consulta que resulta económica en una base de datos batch, como un GROUP BY no acotado sobre una clave de alta cardinalidad, puede acumular un estado de gran tamaño en un motor de streaming.
El siguiente ejemplo utiliza Flink SQL para leer eventos de pedidos desde un Kafka topic y calcular los ingresos por tienda en tumbling windows de cinco minutos.
CREATE TABLE orders (
order_id STRING,
store_id STRING,
amount DECIMAL(10, 2),
order_time TIMESTAMP(3),
WATERMARK FOR order_time AS order_time - INTERVAL '10' SECOND
) WITH (
'connector' = 'kafka',
'topic' = 'orders',
'properties.bootstrap.servers' = 'broker:9092',
'format' = 'json',
'scan.startup.mode' = 'earliest-offset'
);
SELECT window_start, window_end, store_id, SUM(amount) AS revenue
FROM TABLE(
TUMBLE(TABLE orders, DESCRIPTOR(order_time), INTERVAL '5' MINUTES))
GROUP BY window_start, window_end, store_id;La sentencia CREATE TABLE no copia ningún dato. Asigna el Kafka topic a una tabla dinámica e indica a Flink que order_time es la columna de event time. La cláusula WATERMARK tolera eventos que llegan con hasta 10 segundos de retraso antes de que se cierre una ventana.
La sentencia SELECT aplica una función de tumbling window sobre esa tabla y agrupa por ventana y tienda. Cada cinco minutos de event time, emite una fila por tienda con los ingresos de esa ventana. En producción, lo habitual es escribir este resultado en otro topic o en una tabla de base de datos con una sentencia INSERT INTO para que los sistemas posteriores puedan utilizarlo.
La elección de un motor de streaming SQL depende de los requisitos de latencia, el tamaño del estado, las plataformas que ya utilizas y si quieres servir los resultados de las consultas directamente a las aplicaciones.
| Motor | Modelo de procesamiento | Gestión del estado | Opciones gestionadas | Mejor encaje |
|---|---|---|---|---|
| Flink SQL | Streaming evento a evento | Estado de gran tamaño con checkpoints | Confluent Cloud for Apache Flink, Amazon Managed Service for Apache Flink y otros | Pipelines complejos y con estado a escala |
| ksqlDB | Evento a evento sobre Kafka Streams | Estado local respaldado por changelog topics de Kafka | Confluent Cloud | Equipos que solo necesitan transformaciones de Kafka a Kafka |
| Spark Structured Streaming | Micro-batch por defecto | State store por consulta | Databricks, servicios de Spark en la nube | Equipos que ya utilizan Spark y un lakehouse |
| Streaming databases (RisingWave, Materialize) | Vistas materializadas mantenidas de forma incremental | Gestionado por la base de datos | Servicios en la nube del proveedor | Servir resultados de consultas actualizados a aplicaciones y dashboards |
Flink SQL es la opción habitual para streaming SQL de propósito general, y el stream processing gestionado de Confluent se centra en él. ksqlDB sigue siendo una opción sencilla para equipos que trabajan íntegramente en Kafka. Spark Structured Streaming se adapta a organizaciones que quieren un único motor para batch y streaming, con una latencia del orden de segundos en lugar de milisegundos. Las streaming databases sacrifican parte de la flexibilidad de procesamiento a cambio de la comodidad de consultar los resultados mediante una interfaz compatible con PostgreSQL.
Los bancos y proveedores de pagos utilizan streaming SQL para comparar cada transacción con la actividad reciente de la misma tarjeta o cuenta. Una agregación por ventanas puede detectar un número inusual de transacciones en un periodo corto, y un join con datos de referencia puede verificar el riesgo del comercio antes de que se complete el pago.
Los retailers y fabricantes mantienen vistas en vivo de los niveles de stock, los pedidos pendientes y el estado de las máquinas. En lugar de esperar a un proceso batch nocturno, los equipos de operaciones ven los cambios en cuestión de segundos, y las alertas se activan cuando una métrica supera un umbral.
Change data capture transmite cada inserción, actualización y eliminación de las bases de datos operativas. Streaming SQL puede limpiar, enmascarar y combinar esos cambios en tránsito antes de que lleguen a un data warehouse o lakehouse, lo que mantiene actualizadas las copias analíticas sin añadir carga a los sistemas de origen.
Los agentes de IA y los modelos de machine learning son tan buenos como los datos con los que trabajan. Streaming SQL puede calcular features, como el gasto de un cliente en la última hora, y mantenerlas actualizadas, de modo que los modelos y agentes trabajen con lo que está ocurriendo ahora y no con la foto de ayer. El streamhouse sobre IBM Confluent de Mimacom aplica esta idea a los datos en vivo para agentes de IA.
Para la capa analítica que se sitúa sobre estos pipelines, consulta nuestra guía sobre streaming analytics.
Streaming SQL cubre una gran parte de las cargas de trabajo en tiempo real, pero no todas. La lógica de eventos compleja, como la detección de patrones en varios pasos con reglas personalizadas, puede resultar difícil de expresar en SQL, y algunos equipos trasladan esa lógica a la DataStream API o al código de la aplicación. Un estado de gran tamaño, como los joins sobre meses de historial, requiere un diseño cuidadoso para mantener bajo control la memoria, el tamaño de los checkpoints y el coste.
Operar consultas continuas también es diferente de generar informes. Una consulta que se ejecuta durante meses necesita monitorización, control de versiones y un plan para cambiar su lógica sin perder el estado. Los dialectos difieren entre motores, por lo que migrar un pipeline de ksqlDB a Flink SQL implica reescribir las consultas, no copiarlas. Los equipos que quieren evitar el código por completo pueden considerar el no-code stream processing, que construye jobs de Flink mediante un lienzo visual.
Mimacom trabaja con Confluent desde 2017 y es partner de formación de Confluent desde 2021. Tras la adquisición de Confluent por parte de IBM, trabajamos como partner de IBM, diseñando y operando plataformas de event streaming y pipelines de Flink SQL sobre IBM Confluent para empresas de banca, seguros, industria y retail.
Empezamos por el caso de uso, no por el motor. Nuestros arquitectos evalúan tus requisitos de latencia, estado y gobierno, recomiendan el enfoque de streaming SQL adecuado y, después, construyen y operan los pipelines junto a tu equipo. Descubre más sobre nuestros servicios de consultoría de Confluent o descarga el whitepaper The Data Streaming Foundation for AI.
SQL estándar se diseñó para tablas acotadas, por lo que no incluye de forma nativa el concepto de flujos no acotados, event time ni watermarks. Los motores de streaming como Flink SQL, ksqlDB y Spark Structured Streaming amplían SQL con estos conceptos, de modo que puedes escribir sentencias SELECT, JOIN y GROUP BY conocidas que se ejecutan de forma continua sobre flujos.
Una streaming database es una base de datos que ingiere flujos y mantiene vistas materializadas actualizadas de forma incremental a medida que llegan nuevos eventos. RisingWave y Materialize son dos ejemplos. A diferencia de un motor de stream processing que escribe los resultados en otros sistemas, una streaming database también sirve esos resultados directamente, de modo que las aplicaciones pueden consultarlos con clientes SQL estándar.
No, streaming SQL complementa las bases de datos OLTP en lugar de sustituirlas. Los sistemas transaccionales gestionan lecturas y escrituras individuales con consistencia estricta, mientras que streaming SQL procesa el flujo de cambios que esos sistemas generan. Un patrón habitual es capturar los cambios de la base de datos OLTP con change data capture y procesarlos con streaming SQL en etapas posteriores.
Streaming SQL lleva el lenguaje de datos más conocido a los pipelines en tiempo real. Una vez que tu equipo entiende las consultas continuas, las ventanas, los watermarks y el estado, elegir entre Flink SQL, ksqlDB, Spark y las streaming databases pasa a ser una cuestión de encaje, no de aprender un nuevo paradigma. Empieza con un caso de uso de alto valor, diseña pensando en el tiempo y el estado desde el principio y amplía a partir de ahí.
Habla con el equipo de data streaming de Mimacom sobre el motor y la arquitectura adecuados para tu caso de uso.
Descubre nuestros servicios de consultoría de Confluent | Contacta con nosotros