Apache Beam vs Spark у 2026: Уніфіковані Pipeline та Питання на Співбесідах

Apache Beam vs Spark представляє одне з найпоширеніших архітектурних рішень у сучасній інженерії даних. Beam 2.76 (серпень 2026) та Spark 4.2 (липень 2026) обробляють як пакетні, так і потокові навантаження, але їхні філософії проектування фундаментально відрізняються: Beam абстрагує механізм виконання, тоді як Spark надає тісно інтегроване середовище виконання.

Модель Переносимості Beam vs Уніфікований Рушій Spark

Apache Beam відокремлює модель програмування від виконання. Єдине визначення pipeline працює на Google Cloud Dataflow, Apache Flink, Apache Spark або інших runner'ах без змін коду. Ця абстракція виникає завдяки тому, що Beam SDK генерує переносиме представлення pipeline, яке інтерпретує будь-який сумісний runner.

Spark 4.2 застосовує протилежний підхід. DataFrame API, Structured Streaming та MLlib спільно використовують один оптимізатор Catalyst і рушій виконання Tungsten. Це тісне поєднання уможливлює оптимізації на кшталт Adaptive Query Execution, які коригують плани під час виконання на основі фактичної статистики даних.

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

# Той самий код працює на runner'ах Dataflow, Flink або Spark
options = PipelineOptions([
    '--runner=DataflowRunner',  # Перемикання на FlinkRunner або 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'))

Еквівалент на Spark безпосередньо прив'язаний до середовища виконання 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: режим ANSI увімкнено за замовчуванням, суворіша перевірка типів
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 уможливлює хмарно-незалежні архітектури, але додає рівень трансляції. Пряме виконання Spark зазвичай демонструє нижчу затримку для еквівалентних операцій на тому ж обладнанні.

Порівняння Віконування та Обробки Часу Подій

Обидва фреймворки обробляють семантику часу подій, але їхні API відображають різну спадщину. Модель віконування Beam походить з Dataflow Model paper (2015), розглядаючи вікна як першокласні елементи pipeline. Spark адаптував своє віконування для Structured Streaming, інтегрувавши його з DataFrame API.

Сесійні вікна найяскравіше демонструють різницю. Beam розглядає сесії як нативну стратегію віконування:

# beam_sessions.py
from apache_beam import window

# 30-хвилинний проміжок сесії, допускає до 1 години запізнілих даних
windowed = (
    events
    | 'SessionWindow' >> beam.WindowInto(
        window.Sessions(30 * 60),  # 30 хв проміжку закриває сесію
        trigger=beam.trigger.AfterWatermark(
            early=beam.trigger.AfterProcessingTime(60),
            late=beam.trigger.AfterCount(1)
        ),
        allowed_lateness=3600,  # Приймати дані до 1 години запізнення
        accumulation_mode=beam.trigger.AccumulationMode.ACCUMULATING
    )
)

Spark вимагає stateful обробки для сесій:

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

def update_session(key, events, state: GroupState):
    # Ручне керування сесією через 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:
            # Проміжок перевищив 30 хв, emit попередньої сесії
            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 хв 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
    )

Для підготовки до співбесід з цих тем варто ознайомитися з модулем питань на співбесіді Apache Beam та Dataflow.

Продуктивність: Дані Бенчмарків 2026

Прямі порівняння вимагають ретельного налаштування, оскільки Beam працює поверх Spark як один із варіантів runner. Релевантне порівняння — Beam-on-Dataflow проти нативного Spark.

Останні бенчмарки від Databricks та Google Cloud показують:

Покращення продуктивності Spark 4.2 випливають з кількох функцій:

• Режим ANSI за замовчуванням: суворіша семантика SQL виявляє помилки раніше
• Тип даних VARIANT: нативна обробка напівструктурованих даних
• Adaptive Query Execution: оптимізація плану під час виконання
• Підтримка Java 21: віртуальні потоки зменшують накладні витрати

Beam 2.76 відповідає:

• Підтримка runner Flink 2.0: продакшн-рівня stateful streaming
• Персистентність CDC offset: DebeziumIO FileSystemOffsetRetainer
• Інтеграція ADK: підтримка Google Agent Development Kit у Python SDK

Поширені Питання на Співбесідах: Beam vs Spark

Технічні співбесіди на позиції інженера даних часто порівнюють ці фреймворки. Нижче наведено питання, що з'являються на співбесідах у 2026 році, з очікуваною глибиною відповіді.

П1: Коли обрати Beam замість нативного Spark?

Очікувані пункти відповіді:

• Multi-cloud або гібридні розгортання, де код pipeline має працювати без змін
• Середовища Google Cloud, де Dataflow надає керовану інфраструктуру
• Складна семантика часу подій, що вимагає сесійних вікон або власних тригерів
• Команди з наявним досвідом Beam з бекграунду Dataflow

Відповідь-червоний прапорець: "Beam завжди кращий, бо переносимий." Переносимість має свою ціну.

П2: Як абстракція runner Beam впливає на дебагінг?

Очікувані пункти відповіді:

• Stack trace посилаються як на Beam SDK, так і на реалізацію runner
• Оптимізації, специфічні для runner, можуть поводитися по-різному (checkpoints Flink vs checkpoints Spark)
• Metrics API забезпечує уніфікований моніторинг, але дашборди runner'ів показують різні деталі
• Тестування з DirectRunner перед розгортанням на продакшн runner

П3: Поясніть семантику exactly-once в обох фреймворках.

Очікувана відповідь:

# Beam: exactly-once через гарантії runner
# Dataflow забезпечує exactly-once як для джерел, так і для sink'ів
# SDK керує дедуплікацією та координацією checkpoint'ів

with beam.Pipeline() as p:
    (p
     | beam.io.ReadFromPubSub(subscription='...')  # Exactly-once читання
     | beam.Map(process)
     | beam.io.WriteToBigQuery(...)  # Exactly-once запис з retry
    )

# Spark: exactly-once через checkpointing та ідемпотентні sink'и
spark.readStream \
    .format("kafka") \
    .load() \
    .writeStream \
    .option("checkpointLocation", "/checkpoint")  # Відновлення стану
    .foreachBatch(idempotent_write)  # Дедуплікація на рівні застосунку
    .start()

Більше тем streaming для співбесід у модулі PySpark.

П4: Як мігрувати пакетне завдання Spark на Beam?

Це питання тестує розуміння обох API. Ключові пункти:

1. Відображення операцій DataFrame на PCollections та трансформації
2. Заміна spark.read відповідними I/O конекторами Beam
3. Конвертація UDF у функції beam.Map або beam.ParDo
4. Різна обробка партиціонування (Reshuffle Beam vs repartition Spark)
5. Тестування з DirectRunner перед розгортанням на продакшн runner

Вибір Правильного Інструменту: Матриця Рішень

Вибір залежить більше від організаційного контексту, ніж від технічних можливостей. Обидва фреймворки компетентно обробляють більшість завдань інженерії даних.

Для рішень щодо патернів ETL/ELT слід розглянути обсяг даних та вимоги до затримки перед вибором фреймворку.

Реальна Архітектура: Гібридний Підхід

Багато організацій використовують обидва фреймворки. Поширений патерн:

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

Beam обробляє streaming ingestion, де автомасштабування Dataflow відповідає патернам трафіку. Spark обробляє пакетні навантаження, де економіка кластера сприяє стабільним обчисленням. Обидва живлять уніфіковане сховище даних.

Ця архітектура з'являється в туторіалі Apache Spark з деталями реалізації.

Ключові Висновки для Вибору Beam vs Spark

• Beam 2.76 забезпечує переносимість runner між Dataflow, Flink 2.0 та Spark, жертвуючи частиною продуктивності заради гнучкості розгортання
• Spark 4.2 надає тіснішу інтеграцію між SQL, streaming та ML навантаженнями з функціями на кшталт типів VARIANT та Adaptive Query Execution
• Сесійні вікна та складні тригери на користь нативної моделі віконування Beam
• Продуктивність batch на еквівалентному обладнанні зазвичай на користь Spark завдяки оптимізації Catalyst/Tungsten
• Питання на співбесідах фокусуються на компромісах, а не на оголошенні одного фреймворку кращим
• Гібридні архітектури з використанням обох фреймворків поширені у продакшн середовищах
• Порівняння вартості залежить від патернів навантаження: ціни per-GB Dataflow vs provisioning кластера Spark