Apache Beam vs Spark 2026: Perbandingan Pipeline Terpadu dan Pertanyaan Interview

Apache Beam dan Spark merupakan dua framework pemrosesan data terpopuler di tahun 2026. Beam 2.76 (Agustus 2026) dan Spark 4.2 (Juli 2026) sama-sama menangani workload batch dan streaming, namun filosofi desainnya berbeda secara fundamental. Beam mengabstraksi execution engine, sementara Spark menyediakan runtime yang terintegrasi erat.

Model Portabilitas Beam vs Engine Terpadu Spark

Apache Beam memisahkan model pemrograman dari eksekusi. Definisi pipeline tunggal dapat berjalan di Google Cloud Dataflow, Apache Flink, Apache Spark, atau runner lainnya tanpa perubahan kode. Abstraksi ini berasal dari Beam SDK yang menghasilkan representasi pipeline portabel yang dapat diinterpretasi oleh runner yang kompatibel.

Spark 4.2 mengambil pendekatan sebaliknya. DataFrame API, Structured Streaming, dan MLlib berbagi Catalyst optimizer dan Tungsten execution engine yang sama. Integrasi ketat ini memungkinkan optimasi seperti Adaptive Query Execution yang menyesuaikan rencana eksekusi saat runtime berdasarkan statistik data aktual.

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

# Kode yang sama berjalan di Dataflow, Flink, atau Spark runner
options = PipelineOptions([
    '--runner=DataflowRunner',  # Ganti ke FlinkRunner atau 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'))

Equivalen Spark terikat langsung ke 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: Mode ANSI diaktifkan secara default, type checking lebih ketat
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()

Portabilitas Beam memungkinkan arsitektur cloud-agnostic tetapi menambahkan translation layer. Eksekusi langsung Spark biasanya menunjukkan latensi lebih rendah untuk operasi setara pada hardware yang sama.

Perbandingan Windowing dan Pemrosesan Event-Time

Kedua framework menangani semantik event-time, tetapi API mereka mencerminkan warisan yang berbeda. Model windowing Beam berasal dari Dataflow Model paper (2015), memperlakukan window sebagai elemen pipeline kelas satu. Spark mengadaptasi windowing untuk Structured Streaming, mengintegrasikannya dengan DataFrame API.

Session windows paling jelas menunjukkan perbedaan. Beam memperlakukan session sebagai strategi windowing native:

# beam_sessions.py
from apache_beam import window

# 30 menit session gap, terima data terlambat hingga 1 jam
windowed = (
    events
    | 'SessionWindow' >> beam.WindowInto(
        window.Sessions(30 * 60),  # Gap 30 menit menutup session
        trigger=beam.trigger.AfterWatermark(
            early=beam.trigger.AfterProcessingTime(60),
            late=beam.trigger.AfterCount(1)
        ),
        allowed_lateness=3600,  # Terima data hingga 1 jam terlambat
        accumulation_mode=beam.trigger.AccumulationMode.ACCUMULATING
    )
)

Spark memerlukan pemrosesan stateful untuk session:

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

def update_session(key, events, state: GroupState):
    # Manajemen session manual dengan state API
    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 melebihi 30 menit, emit session sebelumnya
            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)  # Timeout 30 menit

# 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
    )

Untuk persiapan interview tentang topik ini, lihat modul pertanyaan interview Apache Beam dan Dataflow.

Performa: Data Benchmark 2026

Perbandingan langsung memerlukan setup yang cermat karena Beam berjalan di atas Spark sebagai salah satu opsi runner. Perbandingan yang relevan adalah Beam-on-Dataflow vs native Spark.

Benchmark terbaru dari Databricks dan Google Cloud menunjukkan:

Peningkatan performa Spark 4.2 berasal dari beberapa fitur:

• Mode ANSI default: semantik SQL lebih ketat menangkap error lebih awal
• Tipe data VARIANT: penanganan data semi-terstruktur native
• Adaptive Query Execution: optimasi rencana saat runtime
• Dukungan Java 21: virtual threads mengurangi overhead

Beam 2.76 menawarkan:

• Dukungan Flink 2.0 runner: stateful streaming production-grade
• CDC offset persistence: DebeziumIO FileSystemOffsetRetainer
• Integrasi ADK: dukungan Google Agent Development Kit di Python SDK

Pertanyaan Interview Umum: Beam vs Spark

Interview teknis untuk posisi data engineering sering membandingkan kedua framework ini. Berikut pertanyaan yang muncul di interview 2026, dengan kedalaman jawaban yang diharapkan.

P1: Kapan memilih Beam dibanding native Spark?

Poin jawaban yang diharapkan:

• Deployment multi-cloud atau hybrid dimana kode pipeline harus berjalan tanpa perubahan
• Lingkungan Google Cloud dimana Dataflow menyediakan infrastruktur terkelola
• Semantik event-time kompleks yang membutuhkan session windows atau custom triggers
• Tim dengan expertise Beam dari latar belakang Dataflow

Jawaban red flag: "Beam selalu lebih baik karena portabel." Portabilitas memiliki overhead biaya.

P2: Bagaimana abstraksi runner Beam mempengaruhi debugging?

Poin jawaban yang diharapkan:

• Stack trace mereferensikan Beam SDK dan implementasi runner
• Optimasi spesifik runner mungkin berperilaku berbeda (checkpoint Flink vs checkpoint Spark)
• Metrics API menyediakan monitoring terpadu, tetapi dashboard runner menampilkan detail berbeda
• Testing dengan DirectRunner sebelum deploy ke production runner

P3: Jelaskan semantik exactly-once di kedua framework.

Jawaban yang diharapkan:

# Beam: exactly-once via jaminan runner
# Dataflow menyediakan exactly-once untuk sources dan sinks
# SDK menangani deduplikasi dan koordinasi checkpoint

with beam.Pipeline() as p:
    (p
     | beam.io.ReadFromPubSub(subscription='...')  # Read exactly-once
     | beam.Map(process)
     | beam.io.WriteToBigQuery(...)  # Write exactly-once dengan retry
    )

# Spark: exactly-once via checkpointing dan idempotent sinks
spark.readStream \
    .format("kafka") \
    .load() \
    .writeStream \
    .option("checkpointLocation", "/checkpoint")  # State recovery
    .foreachBatch(idempotent_write)  # Deduplikasi level aplikasi
    .start()

Untuk topik interview streaming lainnya, lihat modul PySpark.

P4: Bagaimana cara migrasi Spark batch job ke Beam?

Pertanyaan ini menguji pemahaman kedua API. Poin penting:

1. Map operasi DataFrame ke PCollections dan transforms
2. Ganti spark.read dengan Beam I/O connector yang sesuai
3. Konversi UDF ke fungsi beam.Map atau beam.ParDo
4. Tangani partitioning secara berbeda (Reshuffle Beam vs repartition Spark)
5. Test dengan DirectRunner sebelum deploy ke production runner

Memilih Tool yang Tepat: Matriks Keputusan

Pilihan bergantung pada konteks organisasi lebih dari kapabilitas teknis. Kedua framework menangani sebagian besar workload data engineering dengan kompeten.

Untuk keputusan pola ETL/ELT, pertimbangkan volume data dan kebutuhan latensi sebelum memilih framework.

Arsitektur Dunia Nyata: Pendekatan Hybrid

Banyak organisasi menggunakan kedua framework. Pola umum:

[Streaming Ingestion]     [Batch Processing]     [ML Training]
        |                        |                    |
   Beam/Dataflow           Spark di Databricks    Spark MLlib
        |                        |                    |
        v                        v                    v
    BigQuery  <----- dbt -----> Delta Lake -----> Model Registry

Beam menangani streaming ingestion dimana autoscaling Dataflow menyesuaikan pola traffic. Spark memproses batch workload dimana ekonomi cluster lebih menguntungkan untuk compute berkelanjutan. Keduanya mengalir ke data warehouse terpadu.

Arsitektur ini dibahas di tutorial Apache Spark dengan detail implementasi.

Kesimpulan Pemilihan Beam vs Spark

• Beam 2.76 menyediakan portabilitas runner di Dataflow, Flink 2.0, dan Spark, menukar performa untuk fleksibilitas deployment
• Spark 4.2 memberikan integrasi lebih ketat antara SQL, streaming, dan workload ML dengan fitur seperti tipe VARIANT dan Adaptive Query Execution
• Session windows dan trigger kompleks lebih cocok dengan model windowing native Beam
• Performa batch pada hardware setara biasanya lebih baik di Spark karena optimasi Catalyst/Tungsten
• Pertanyaan interview fokus pada trade-off daripada mendeklarasikan satu framework lebih superior
• Arsitektur hybrid menggunakan kedua framework umum di lingkungan produksi
• Perbandingan biaya bergantung pada pola workload: pricing per-GB Dataflow vs provisioning cluster Spark