Batch vs Streaming y Triggered vs Continuous

Objetivo: saber elegir el modo de procesamiento y ejecución de cada pipeline, equilibrando latencia, complejidad y coste.

1. Son dos decisiones diferentes

Esta es la idea más importante de hoy:

• Batch vs Streaming: ¿cómo procesamos los datos?

• Triggered vs Continuous: ¿cuándo ejecutamos el pipeline y durante cuánto tiempo?

Por tanto, una Streaming Table no obliga a tener un proceso ejecutándose 24 horas al día.

Puedes consumir Kafka cada 15 minutos mediante una Streaming Table con un pipeline Triggered.

2. Ejemplo real: Kafka → Bronze

Imagina que llegan 1.000 tickets por minuto.

Opción A · Triggered

Menor coste habitual

Ejecutamos el pipeline cada 15 minutos. Consume los eventos pendientes y termina.

Opción B · Continuous

Menor latencia

El pipeline permanece ejecutándose y procesa nuevos eventos conforme están disponibles.

Con Triggered, el retraso depende de la frecuencia, el arranque y la duración de cada ejecución. Con Continuous, normalmente reducimos la latencia, pero mantenemos recursos activos.

3. El código puede ser exactamente el mismo

from pyspark import pipelines as dp

@dp.table(name="bronze_tickets")
def bronze_tickets():
    return (
        spark.readStream
        .format("kafka")
        # Configuración de conexión...
        .load()
    )

¡No hemos cambiado nada!

La elección Triggered/Continuous pertenece a la configuración y orquestación del pipeline, no a la definición de esta tabla.

Databricks actualmente recomienda usar un Continuous Job para orquestar pipelines continuos, ya que permite aprovechar opciones adicionales de rendimiento Serverless. Databricks on Google Cloud

4. ¿Cuánto cuesta cada opción?

El coste depende principalmente de:

• Tiempo de ejecución.

• DBUs consumidos.

• Tipo de compute y tarifa contratada.

• Volumen, complejidad de las transformaciones y frecuencia de actualización.

La facturación exacta varía por región, tipo de compute y contrato. Microsoft publica las tarifas de Lakeflow en su página oficial de precios de Azure Databricks . Microsoft Azure

Simulador de costes

Vamos a suponer que ambos modos cuestan 2 € por hora de compute activo, únicamente para comparar el tiempo de ejecución. No es una tarifa real de Databricks.

Conclusión: Continuous no siempre es más caro en cualquier escenario, pero suele resultar considerablemente más costoso cuando hay poca actividad y los pipelines Triggered terminan rápidamente. Databricks recomienda comenzar con Triggered salvo que haya requisitos reales de baja latencia. Databricks on AWS

5. ¿Qué elegiría para nuestra arquitectura?

Esto es un punto de partida, no una configuración definitiva.

Si el dashboard operacional necesita datos con menos de un minuto de retraso, evaluaría Continuous para esa ruta específica. No convertiría automáticamente toda la arquitectura en Continuous.

Además, hay que medir el end-to-end lag: desde que se genera el evento hasta que realmente aparece en Power BI. No basta con medir el tiempo de ingesta en Bronze.

6. Mini ejercicio

Qué debes recordar:

• readStream no significa Continuous.

• Triggered procesa los datos pendientes y termina.

• Continuous permanece activo para reducir la latencia.

• El SLA del negocio debe determinar la frecuencia de ejecución.

Próxima lección: joins, agregaciones y watermarks. Aprenderemos por qué un streaming puede necesitar mantener estado y qué ocurre con los eventos que llegan tarde.