Apache Beam vs Spark em 2026: Pipelines Unificados e Perguntas de Entrevista

Apache Beam e Spark representam duas abordagens fundamentalmente diferentes para processamento de dados em larga escala. Beam 2.76 (agosto 2026) e Spark 4.2 (julho 2026) lidam com cargas de trabalho batch e streaming, mas suas filosofias de design divergem: Beam abstrai o motor de execução enquanto Spark fornece um runtime fortemente integrado.

Modelo de Portabilidade do Beam vs Motor Unificado do Spark

Apache Beam separa o modelo de programação da execução. Uma única definição de pipeline executa no Google Cloud Dataflow, Apache Flink, Apache Spark, ou outros runners sem alterações no código. Essa abstração vem do SDK do Beam que gera uma representação portável do pipeline que qualquer runner compatível interpreta.

Spark 4.2 adota a abordagem oposta. A API DataFrame, Structured Streaming e MLlib compartilham o mesmo otimizador Catalyst e o motor de execução Tungsten. Esse acoplamento forte permite otimizações como Adaptive Query Execution que ajusta os planos em tempo de execução baseado em estatísticas reais dos dados.

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

# O mesmo código executa no Dataflow, Flink, ou Spark runner
options = PipelineOptions([
    '--runner=DataflowRunner',  # Trocar para FlinkRunner ou 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'))

O equivalente Spark está diretamente vinculado ao runtime 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 padrão, verificação de tipos mais rigorosa
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()

A portabilidade do Beam permite arquiteturas cloud-agnósticas mas adiciona uma camada de tradução. A execução direta do Spark geralmente mostra menor latência para operações equivalentes no mesmo hardware.

Windowing e Processamento Event-Time Comparados

Ambos os frameworks lidam com semântica event-time, mas suas APIs refletem heranças diferentes. O modelo de windowing do Beam vem do Dataflow Model paper (2015), tratando windows como elementos de pipeline de primeira classe. Spark adaptou seu windowing para Structured Streaming, integrando-o com a API DataFrame.

As session windows revelam melhor a diferença. Beam trata as sessões como uma estratégia de windowing nativa:

# beam_sessions.py
from apache_beam import window

# 30 minutos de gap de sessão, aceita 1 hora de dados atrasados
windowed = (
    events
    | 'SessionWindow' >> beam.WindowInto(
        window.Sessions(30 * 60),  # 30 min de gap fecha a sessão
        trigger=beam.trigger.AfterWatermark(
            early=beam.trigger.AfterProcessingTime(60),
            late=beam.trigger.AfterCount(1)
        ),
        allowed_lateness=3600,  # Aceita dados até 1 hora atrasados
        accumulation_mode=beam.trigger.AccumulationMode.ACCUMULATING
    )
)

Spark requer processamento stateful para sessões:

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

def update_session(key, events, state: GroupState):
    # Gerenciamento manual de sessões com a 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 excedeu 30 min, emitir sessão 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 preparação de entrevistas sobre esses tópicos, consultar o módulo de Perguntas de entrevista Apache Beam e Dataflow.

Performance: Dados de Benchmark 2026

Comparações diretas requerem configuração cuidadosa já que Beam executa sobre Spark como uma opção de runner. A comparação relevante é Beam-on-Dataflow vs Spark nativo.

Os benchmarks recentes da Databricks e Google Cloud mostram:

Os ganhos de performance do Spark 4.2 vêm de várias funcionalidades:

• Modo ANSI por padrão: semântica SQL mais rigorosa detecta erros mais cedo
• Tipo de dados VARIANT: tratamento nativo de dados semi-estruturados
• Adaptive Query Execution: otimização do plano em tempo de execução
• Suporte Java 21: virtual threads reduzem overhead

Beam 2.76 contra-ataca com:

• Suporte Flink 2.0 runner: streaming stateful de nível produção
• Persistência de offsets CDC: DebeziumIO FileSystemOffsetRetainer
• Integração ADK: suporte do Google Agent Development Kit no SDK Python

Perguntas de Entrevista Comuns: Beam vs Spark

Entrevistas técnicas para posições de data engineering frequentemente comparam esses frameworks. Estas são as perguntas que aparecem nas entrevistas de 2026, com a profundidade de resposta esperada.

P1: Quando escolher Beam em vez de Spark nativo?

Pontos de resposta esperados:

• Deployments multi-cloud ou híbridos onde o código do pipeline deve executar sem modificações
• Ambientes Google Cloud onde Dataflow fornece infraestrutura gerenciada
• Semântica event-time complexa requerendo session windows ou triggers personalizados
• Equipes com experiência existente em Beam vinda de background em Dataflow

Resposta red flag: "Beam é sempre melhor porque é portável." A portabilidade tem custos de overhead.

P2: Como a abstração do runner do Beam afeta o debugging?

Pontos de resposta esperados:

• Stack traces referenciam tanto o SDK do Beam quanto a implementação do runner
• Otimizações específicas do runner podem se comportar diferentemente (checkpoints do Flink vs checkpoints do Spark)
• A API de Metrics fornece monitoramento unificado, mas os dashboards dos runners mostram detalhes diferentes
• Testar com DirectRunner antes de fazer deploy no runner de produção

P3: Explicar a semântica exactly-once em ambos os frameworks.

Resposta esperada:

# Beam: exactly-once via garantias do runner
# Dataflow fornece exactly-once para sources e sinks
# O SDK lida com deduplicação e coordenação de checkpoints

with beam.Pipeline() as p:
    (p
     | beam.io.ReadFromPubSub(subscription='...')  # Leitura exactly-once
     | beam.Map(process)
     | beam.io.WriteToBigQuery(...)  # Escrita exactly-once com retries
    )

# Spark: exactly-once via checkpointing e sinks idempotentes
spark.readStream \
    .format("kafka") \
    .load() \
    .writeStream \
    .option("checkpointLocation", "/checkpoint")  # Recuperação de estado
    .foreachBatch(idempotent_write)  # Deduplicação a nível de aplicação
    .start()

Para mais tópicos de entrevista sobre streaming, consultar o módulo PySpark.

P4: Como migrar um job batch Spark para Beam?

Essa pergunta testa a compreensão de ambas as APIs. Pontos-chave:

1. Mapear operações DataFrame para PCollections e transforms
2. Substituir spark.read pelos conectores I/O apropriados do Beam
3. Converter UDFs para funções beam.Map ou beam.ParDo
4. Lidar com particionamento diferentemente (Reshuffle do Beam vs repartition do Spark)
5. Testar com DirectRunner antes de fazer deploy no runner de produção

Escolhendo a Ferramenta Certa: Matriz de Decisão

A escolha depende mais do contexto organizacional do que das capacidades técnicas. Ambos os frameworks lidam com a maioria das cargas de trabalho de data engineering de forma competente.

Para decisões sobre padrões ETL/ELT, considerar o volume de dados e os requisitos de latência antes de selecionar um framework.

Arquitetura Real: Abordagem Híbrida

Muitas organizações utilizam ambos os frameworks. Um padrão comum:

[Ingestão Streaming]     [Processamento Batch]     [Treinamento ML]
        |                        |                    |
   Beam/Dataflow           Spark no Databricks    Spark MLlib
        |                        |                    |
        v                        v                    v
    BigQuery  <----- dbt -----> Delta Lake -----> Model Registry

Beam gerencia a ingestão streaming onde o autoscaling do Dataflow combina com os padrões de tráfego. Spark processa cargas de trabalho batch onde a economia de clusters favorece computação sustentada. Ambos alimentam um data warehouse unificado.

Essa arquitetura aparece no tutorial Apache Spark com detalhes de implementação.

Pontos-Chave para a Seleção Beam vs Spark

• Beam 2.76 fornece portabilidade de runners no Dataflow, Flink 2.0 e Spark, trocando performance por flexibilidade de deployment
• Spark 4.2 oferece integração mais forte entre SQL, streaming e cargas de trabalho ML com funcionalidades como tipos VARIANT e Adaptive Query Execution
• Session windows e triggers complexos favorecem o modelo de windowing nativo do Beam
• Performance batch em hardware equivalente geralmente favorece Spark graças à otimização Catalyst/Tungsten
• Perguntas de entrevista focam em trade-offs em vez de declarar um framework superior
• Arquiteturas híbridas utilizando ambos os frameworks são comuns em ambientes de produção
• A comparação de custos depende dos padrões de carga de trabalho: preços por GB do Dataflow vs provisionamento de cluster Spark