Apache Beam vs Spark en 2026: Pipelines Unificados y Preguntas de Entrevista

Apache Beam y Spark representan dos enfoques fundamentalmente diferentes para el procesamiento de datos a gran escala. Beam 2.76 (agosto 2026) y Spark 4.2 (julio 2026) manejan cargas de trabajo batch y streaming, pero sus filosofías de diseño difieren: Beam abstrae el motor de ejecución mientras que Spark proporciona un runtime estrechamente integrado.

Modelo de Portabilidad de Beam vs Motor Unificado de Spark

Apache Beam separa el modelo de programación de la ejecución. Una única definición de pipeline se ejecuta en Google Cloud Dataflow, Apache Flink, Apache Spark, u otros runners sin cambios en el código. Esta abstracción proviene del SDK de Beam que genera una representación portable del pipeline que cualquier runner compatible interpreta.

Spark 4.2 adopta el enfoque opuesto. La API DataFrame, Structured Streaming y MLlib comparten el mismo optimizador Catalyst y el motor de ejecución Tungsten. Este acoplamiento estrecho permite optimizaciones como Adaptive Query Execution que ajusta los planes en tiempo de ejecución basándose en estadísticas reales de los datos.

# beam_pipeline.py
import apache_beam as beam
from apache_beam.options.pipeline_options import PipelineOptions

# El mismo código se ejecuta en Dataflow, Flink, o Spark runner
options = PipelineOptions([
    '--runner=DataflowRunner',  # Cambiar a FlinkRunner o SparkRunner
    '--project=my-project',
    '--region=us-central1',
    '--temp_location=gs://my-bucket/temp'
])

with beam.Pipeline(options=options) as pipeline:
    (pipeline
     | 'ReadEvents' >> beam.io.ReadFromPubSub(topic='projects/p/topics/events')
     | 'ParseJSON' >> beam.Map(lambda x: json.loads(x))
     | 'FilterValid' >> beam.Filter(lambda e: e.get('status') == 'valid')
     | 'WindowByMinute' >> beam.WindowInto(beam.window.FixedWindows(60))
     | 'CountPerWindow' >> beam.combiners.Count.Globally()
     | 'WriteToBQ' >> beam.io.WriteToBigQuery('project:dataset.table'))

El equivalente en Spark está directamente vinculado al runtime de Spark:

# spark_streaming.py
from pyspark.sql import SparkSession
from pyspark.sql.functions import from_json, col, window

spark = SparkSession.builder \
    .appName("EventProcessing") \
    .config("spark.sql.adaptive.enabled", "true") \
    .getOrCreate()

# Spark 4.2: Modo ANSI habilitado por defecto, verificación de tipos más estricta
events = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "broker:9092") \
    .option("subscribe", "events") \
    .load()

processed = events \
    .select(from_json(col("value").cast("string"), schema).alias("data")) \
    .filter(col("data.status") == "valid") \
    .groupBy(window(col("data.timestamp"), "1 minute")) \
    .count()

processed.writeStream \
    .format("bigquery") \
    .option("table", "project.dataset.table") \
    .outputMode("append") \
    .start()

La portabilidad de Beam permite arquitecturas cloud-agnósticas pero agrega una capa de traducción. La ejecución directa de Spark generalmente muestra menor latencia para operaciones equivalentes en el mismo hardware.

Windowing y Procesamiento Event-Time Comparados

Ambos frameworks manejan semántica event-time, pero sus APIs reflejan diferentes herencias. El modelo de windowing de Beam proviene del Dataflow Model paper (2015), tratando las windows como elementos de pipeline de primera clase. Spark adaptó su windowing para Structured Streaming, integrándolo con la API DataFrame.

Las session windows revelan mejor la diferencia. Beam trata las sesiones como una estrategia de windowing nativa:

# beam_sessions.py
from apache_beam import window

# 30 minutos de gap de sesión, acepta 1 hora de datos tardíos
windowed = (
    events
    | 'SessionWindow' >> beam.WindowInto(
        window.Sessions(30 * 60),  # 30 min de gap cierra la sesión
        trigger=beam.trigger.AfterWatermark(
            early=beam.trigger.AfterProcessingTime(60),
            late=beam.trigger.AfterCount(1)
        ),
        allowed_lateness=3600,  # Acepta datos hasta 1 hora tarde
        accumulation_mode=beam.trigger.AccumulationMode.ACCUMULATING
    )
)

Spark requiere procesamiento stateful para sesiones:

# spark_sessions.py
from pyspark.sql.streaming import GroupState, GroupStateTimeout

def update_session(key, events, state: GroupState):
    # Gestión manual de sesiones con la API de estado
    session_data = state.getOption() or {"count": 0, "start": None, "end": None}
    
    for event in events:
        ts = event.timestamp
        if session_data["end"] and (ts - session_data["end"]).seconds > 1800:
            # Gap excedió 30 min, emitir sesión anterior
            yield session_data
            session_data = {"count": 0, "start": ts, "end": ts}
        
        session_data["count"] += 1
        session_data["end"] = ts
        if not session_data["start"]:
            session_data["start"] = ts
    
    state.update(session_data)
    state.setTimeoutDuration(30 * 60 * 1000)  # 30 min timeout

# Spark 4.2 Arbitrary State API v2
result = events \
    .groupByKey(lambda e: e.user_id) \
    .flatMapGroupsWithState(
        update_session,
        outputMode="append",
        stateType=session_schema,
        timeoutConf=GroupStateTimeout.ProcessingTimeTimeout
    )

Para la preparación de entrevistas sobre estos temas, consultar el módulo de Preguntas de entrevista Apache Beam y Dataflow.

Rendimiento: Datos de Benchmark 2026

Las comparaciones directas requieren una configuración cuidadosa ya que Beam se ejecuta sobre Spark como una opción de runner. La comparación relevante es Beam-on-Dataflow vs Spark nativo.

Los benchmarks recientes de Databricks y Google Cloud muestran:

Las mejoras de rendimiento de Spark 4.2 provienen de varias características:

• Modo ANSI por defecto: semántica SQL más estricta detecta errores antes
• Tipo de datos VARIANT: manejo nativo de datos semi-estructurados
• Adaptive Query Execution: optimización del plan en tiempo de ejecución
• Soporte Java 21: los virtual threads reducen el overhead

Beam 2.76 contrarresta con:

• Soporte Flink 2.0 runner: streaming stateful de nivel producción
• Persistencia de offsets CDC: DebeziumIO FileSystemOffsetRetainer
• Integración ADK: soporte de Google Agent Development Kit en el SDK Python

Preguntas de Entrevista Comunes: Beam vs Spark

Las entrevistas técnicas para posiciones de data engineering frecuentemente comparan estos frameworks. Estas son las preguntas que aparecen en las entrevistas de 2026, con la profundidad de respuesta esperada.

P1: ¿Cuándo elegir Beam en lugar de Spark nativo?

Puntos de respuesta esperados:

• Despliegues multi-cloud o híbridos donde el código del pipeline debe ejecutarse sin modificaciones
• Entornos Google Cloud donde Dataflow proporciona infraestructura gestionada
• Semántica event-time compleja que requiere session windows o triggers personalizados
• Equipos con experiencia existente en Beam proveniente de un background en Dataflow

Respuesta red flag: "Beam siempre es mejor porque es portable." La portabilidad tiene costos de overhead.

P2: ¿Cómo afecta la abstracción del runner de Beam al debugging?

Puntos de respuesta esperados:

• Los stack traces referencian tanto el SDK de Beam como la implementación del runner
• Las optimizaciones específicas del runner pueden comportarse diferente (checkpoints de Flink vs checkpoints de Spark)
• La API de Metrics proporciona monitoreo unificado, pero los dashboards de los runners muestran diferentes detalles
• Probar con DirectRunner antes de desplegar en el runner de producción

P3: Explicar la semántica exactly-once en ambos frameworks.

Respuesta esperada:

# Beam: exactly-once vía garantías del runner
# Dataflow proporciona exactly-once para fuentes y sinks
# El SDK maneja la deduplicación y coordinación de checkpoints

with beam.Pipeline() as p:
    (p
     | beam.io.ReadFromPubSub(subscription='...')  # Lectura exactly-once
     | beam.Map(process)
     | beam.io.WriteToBigQuery(...)  # Escritura exactly-once con reintentos
    )

# Spark: exactly-once vía checkpointing y sinks idempotentes
spark.readStream \
    .format("kafka") \
    .load() \
    .writeStream \
    .option("checkpointLocation", "/checkpoint")  # Recuperación de estado
    .foreachBatch(idempotent_write)  # Deduplicación a nivel de aplicación
    .start()

Para más temas de entrevista sobre streaming, consultar el módulo PySpark.

P4: ¿Cómo migrar un job batch de Spark a Beam?

Esta pregunta evalúa la comprensión de ambas APIs. Puntos clave:

1. Mapear operaciones DataFrame a PCollections y transforms
2. Reemplazar spark.read con los conectores I/O apropiados de Beam
3. Convertir UDFs a funciones beam.Map o beam.ParDo
4. Manejar el particionamiento diferente (Reshuffle de Beam vs repartition de Spark)
5. Probar con DirectRunner antes de desplegar en el runner de producción

Elegir la Herramienta Correcta: Matriz de Decisión

La elección depende más del contexto organizacional que de las capacidades técnicas. Ambos frameworks manejan la mayoría de las cargas de trabajo de data engineering de manera competente.

Para decisiones sobre patrones ETL/ELT, considerar el volumen de datos y los requisitos de latencia antes de seleccionar un framework.

Arquitectura Real: Enfoque Híbrido

Muchas organizaciones utilizan ambos frameworks. Un patrón común:

[Ingesta Streaming]     [Procesamiento Batch]     [Entrenamiento ML]
        |                        |                    |
   Beam/Dataflow           Spark en Databricks    Spark MLlib
        |                        |                    |
        v                        v                    v
    BigQuery  <----- dbt -----> Delta Lake -----> Model Registry

Beam maneja la ingesta streaming donde el autoscaling de Dataflow coincide con los patrones de tráfico. Spark procesa cargas de trabajo batch donde la economía de clusters favorece el cómputo sostenido. Ambos alimentan un data warehouse unificado.

Esta arquitectura aparece en el tutorial de Apache Spark con detalles de implementación.

Puntos Clave para la Selección Beam vs Spark

• Beam 2.76 proporciona portabilidad de runners en Dataflow, Flink 2.0 y Spark, intercambiando rendimiento por flexibilidad de despliegue
• Spark 4.2 ofrece integración más estrecha entre SQL, streaming y cargas de trabajo ML con características como tipos VARIANT y Adaptive Query Execution
• Las session windows y triggers complejos favorecen el modelo de windowing nativo de Beam
• El rendimiento batch en hardware equivalente generalmente favorece a Spark gracias a la optimización Catalyst/Tungsten
• Las preguntas de entrevista se centran en trade-offs en lugar de declarar un framework superior
• Las arquitecturas híbridas que utilizan ambos frameworks son comunes en entornos de producción
• La comparación de costos depende de los patrones de carga de trabajo: precios por GB de Dataflow vs aprovisionamiento de cluster Spark