Apache Beam vs Spark 2026: Birleşik Pipeline'lar ve Mülakat Soruları

Apache Beam vs Spark, modern veri mühendisliğinde en yaygın mimari kararlardan birini temsil eder. Beam 2.76 (Ağustos 2026) ve Spark 4.2 (Temmuz 2026) hem batch hem de streaming iş yüklerini yönetir, ancak tasarım felsefeleri temelden farklıdır: Beam yürütme motorunu soyutlarken, Spark sıkı entegre bir çalışma zamanı sunar.

Beam'in Taşınabilirlik Modeli vs Spark'ın Birleşik Motoru

Apache Beam, programlama modelini yürütmeden ayırır. Tek bir pipeline tanımı, kod değişikliği olmadan Google Cloud Dataflow, Apache Flink, Apache Spark veya diğer runner'larda çalışır. Bu soyutlama, Beam SDK'nın uyumlu herhangi bir runner'ın yorumlayabileceği taşınabilir bir pipeline temsili oluşturmasından kaynaklanır.

Spark 4.2 tam tersi yaklaşımı benimser. DataFrame API, Structured Streaming ve MLlib aynı Catalyst optimizer ve Tungsten yürütme motorunu paylaşır. Bu sıkı bağlantı, gerçek veri istatistiklerine göre çalışma zamanında planları ayarlayan Adaptive Query Execution gibi optimizasyonları mümkün kılar.

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

# Aynı kod Dataflow, Flink veya Spark runner'da çalışır
options = PipelineOptions([
    '--runner=DataflowRunner',  # FlinkRunner veya SparkRunner'a geçiş yapılabilir
    '--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'))

Spark eşdeğeri doğrudan Spark çalışma zamanına bağlıdır:

# 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: ANSI modu varsayılan olarak etkin, daha katı tip denetimi
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()

Beam'in taşınabilirliği bulut bağımsız mimarilere olanak tanır ancak bir çeviri katmanı ekler. Spark'ın doğrudan yürütmesi aynı donanımda eşdeğer işlemler için genellikle daha düşük gecikme gösterir.

Pencere Oluşturma ve Olay Zamanı İşleme Karşılaştırması

Her iki framework de olay zamanı semantiğini yönetir, ancak API'leri farklı mirasları yansıtır. Beam'in pencere modeli, pencereleri birinci sınıf pipeline elemanları olarak ele alan Dataflow Model paper (2015) makalesinden gelir. Spark, pencere oluşturmayı DataFrame API ile entegre ederek Structured Streaming için uyarlamıştır.

Oturum pencereleri farkı en net şekilde ortaya koyar. Beam, oturumları yerel bir pencere stratejisi olarak ele alır:

# beam_sessions.py
from apache_beam import window

# 30 dakikalık oturum boşluğu, 1 saate kadar geç veriye izin ver
windowed = (
    events
    | 'SessionWindow' >> beam.WindowInto(
        window.Sessions(30 * 60),  # 30 dk boşluk oturumu kapatır
        trigger=beam.trigger.AfterWatermark(
            early=beam.trigger.AfterProcessingTime(60),
            late=beam.trigger.AfterCount(1)
        ),
        allowed_lateness=3600,  # 1 saate kadar geç veriyi kabul et
        accumulation_mode=beam.trigger.AccumulationMode.ACCUMULATING
    )
)

Spark, oturumlar için durum bilgili işleme gerektirir:

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

def update_session(key, events, state: GroupState):
    # State API ile manuel oturum yönetimi
    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:
            # Boşluk 30 dk'yı aştı, önceki oturumu yayınla
            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 dk 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
    )

Bu konularda mülakat hazırlığı için Apache Beam ve Dataflow mülakat soruları modülüne bakılabilir.

Performans: 2026 Benchmark Verileri

Doğrudan karşılaştırmalar dikkatli kurulum gerektirir çünkü Beam, Spark üzerinde bir runner seçeneği olarak çalışır. İlgili karşılaştırma Beam-on-Dataflow vs yerel Spark'tır.

Databricks ve Google Cloud'dan son benchmark'lar şunları göstermektedir:

Spark 4.2'nin performans artışları birçok özellikten kaynaklanır:

• Varsayılan ANSI modu: daha katı SQL semantiği hataları erkenden yakalar
• VARIANT veri tipi: yerel yarı yapılandırılmış veri işleme
• Adaptive Query Execution: çalışma zamanı plan optimizasyonu
• Java 21 desteği: sanal thread'ler ek yükü azaltır

Beam 2.76 şunlarla karşılık verir:

• Flink 2.0 runner desteği: üretim düzeyinde durum bilgili streaming
• CDC offset kalıcılığı: DebeziumIO FileSystemOffsetRetainer
• ADK entegrasyonu: Python SDK'da Google Agent Development Kit desteği

Yaygın Mülakat Soruları: Beam vs Spark

Veri mühendisliği pozisyonları için teknik mülakatlar bu framework'leri sıklıkla karşılaştırır. Aşağıda 2026 mülakatlarında çıkan sorular ve beklenen cevap derinliği yer almaktadır.

S1: Yerel Spark yerine Beam'i ne zaman tercih edersiniz?

Beklenen cevap noktaları:

• Pipeline kodunun değişiklik olmadan çalışması gereken çoklu bulut veya hibrit dağıtımlar
• Dataflow'un yönetilen altyapı sağladığı Google Cloud ortamları
• Oturum pencereleri veya özel tetikleyiciler gerektiren karmaşık olay zamanı semantiği
• Dataflow geçmişinden mevcut Beam deneyimine sahip ekipler

Kırmızı bayrak cevabı: "Beam her zaman daha iyidir çünkü taşınabilir." Taşınabilirliğin maliyetleri vardır.

S2: Beam'in runner soyutlaması hata ayıklamayı nasıl etkiler?

Beklenen cevap noktaları:

• Stack trace'ler hem Beam SDK hem de runner uygulamasına referans verir
• Runner'a özgü optimizasyonlar farklı davranabilir (Flink checkpoint'leri vs Spark checkpoint'leri)
• Metrics API birleşik izleme sağlar, ancak runner dashboard'ları farklı detaylar gösterir
• Üretim runner'ına dağıtmadan önce DirectRunner ile test etme

S3: Her iki framework'te exactly-once semantiğini açıklayın.

Beklenen cevap:

# Beam: runner garantileri aracılığıyla exactly-once
# Dataflow hem kaynaklar hem de sink'ler için exactly-once sağlar
# SDK, tekilleştirme ve checkpoint koordinasyonunu yönetir

with beam.Pipeline() as p:
    (p
     | beam.io.ReadFromPubSub(subscription='...')  # Exactly-once okuma
     | beam.Map(process)
     | beam.io.WriteToBigQuery(...)  # Yeniden denemelerle exactly-once yazma
    )

# Spark: checkpoint ve idempotent sink'ler aracılığıyla exactly-once
spark.readStream \
    .format("kafka") \
    .load() \
    .writeStream \
    .option("checkpointLocation", "/checkpoint")  # Durum kurtarma
    .foreachBatch(idempotent_write)  # Uygulama düzeyinde tekilleştirme
    .start()

Daha fazla streaming mülakat konusu için PySpark modülüne bakılabilir.

S4: Bir Spark batch işini Beam'e nasıl taşırsınız?

Bu soru her iki API'nin anlaşılmasını test eder. Temel noktalar:

1. DataFrame işlemlerini PCollection'lar ve dönüşümlerle eşleştirme
2. spark.read'i uygun Beam I/O konektörleriyle değiştirme
3. UDF'leri beam.Map veya beam.ParDo fonksiyonlarına dönüştürme
4. Bölümlemeyi farklı şekilde yönetme (Beam'in Reshuffle'ı vs Spark'ın repartition'ı)
5. Üretim runner'ına dağıtmadan önce DirectRunner ile test etme

Doğru Aracı Seçme: Karar Matrisi

Seçim, teknik yeteneklerden çok organizasyonel bağlama bağlıdır. Her iki framework de çoğu veri mühendisliği iş yükünü yetkin bir şekilde yönetir.

ETL/ELT desen kararları için, framework seçiminden önce veri hacmi ve gecikme gereksinimleri değerlendirilmelidir.

Gerçek Dünya Mimarisi: Hibrit Yaklaşım

Birçok organizasyon her iki framework'ü de kullanır. Yaygın bir desen:

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

Beam, Dataflow'un otomatik ölçeklendirmesinin trafik desenlerine uyum sağladığı streaming alımını yönetir. Spark, küme ekonomisinin sürekli hesaplamayı desteklediği batch iş yüklerini işler. Her ikisi de birleşik bir veri ambarını besler.

Bu mimari, uygulama detaylarıyla birlikte Apache Spark eğitiminde yer almaktadır.

Beam vs Spark Seçimi için Temel Çıkarımlar

• Beam 2.76, Dataflow, Flink 2.0 ve Spark arasında runner taşınabilirliği sağlar ve dağıtım esnekliği için bir miktar performanstan ödün verir
• Spark 4.2, VARIANT tipleri ve Adaptive Query Execution gibi özelliklerle SQL, streaming ve ML iş yükleri arasında daha sıkı entegrasyon sunar
• Oturum pencereleri ve karmaşık tetikleyiciler Beam'in yerel pencere modelini destekler
• Eşdeğer donanımda batch performansı genellikle Catalyst/Tungsten optimizasyonu nedeniyle Spark'ı destekler
• Mülakat soruları, bir framework'ü üstün ilan etmek yerine ödünleşimlere odaklanır
• Her iki framework'ü kullanan hibrit mimariler üretim ortamlarında yaygındır
• Maliyet karşılaştırması iş yükü desenlerine bağlıdır: Dataflow'un GB başına fiyatlandırması vs Spark küme sağlama