Saltar a contenido

Streaming: Flink vs Spark Structured Streaming

Flink es el motor de stream processing de facto en 2026. Confluent migró de ksqlDB a Flink. Características:

  • Exactly-once semantics con checkpointing a object storage.
  • True streaming (no micro-batch).
  • Windowing avanzado: tumbling, sliding, session, custom triggers.
  • State management con RocksDB local + checkpoints remotos.
  • SQL API estable; PyFlink para Python.

Casos donde Flink gana: - SLA <30s end-to-end. - Necesidad de exactly-once estricto. - Lookups con tablas dimensionales (temporal joins con Iceberg). - Agregaciones con ventanas complejas.

Spark Structured Streaming

Útil cuando ya existe Spark batch en el equipo y la latencia tolerada es 1-10min. Características:

  • Micro-batch (configurable processingTime o continuous).
  • DataFrame API consistente con batch.
  • Integración nativa con Iceberg/Delta.
  • Re-usa el mismo cluster que ETL batch.

Casos donde Spark Streaming gana: - Latencia 1-10min suficiente. - Equipo ya skilled en Spark. - Workload mixto batch + stream sobre mismo cluster.

Cuándo migrar a streaming

No migrar pipelines a streaming "porque sí". Reglas: 1. SLA <5min lo justifica. 2. Use case real: fraud detection, alertas operativas, personalización en sesión. 3. Equipo con capacidad de operar streaming en prod (24/7 oncall).