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

> Порівняння Apache Beam 2.76 та Spark 4.2 для data pipeline. Переносимість, продуктивність, питання на співбесідах та вибір правильного фреймворку.

- Published: 2026-09-10
- Updated: 2026-09-10
- Author: Anthony Fillion-Maillet
- Reading time: 5 min

---

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

> **Швидка Рамка Прийняття Рішень**
>
> Оберіть Beam, коли важлива переносимість між runner'ами (Dataflow, Flink, Spark) або при використанні Google Cloud Dataflow. Оберіть Spark при самостійному керуванні кластером, використанні Databricks або потребі ML-інтеграції з MLlib.

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

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

Spark 4.2 застосовує протилежний підхід. DataFrame API, Structured Streaming та MLlib спільно використовують один оптимізатор Catalyst і рушій виконання Tungsten. Це тісне поєднання уможливлює оптимізації на кшталт [Adaptive Query Execution](https://spark.apache.org/docs/latest/sql-performance-tuning.html), які коригують плани під час виконання на основі фактичної статистики даних.

```python
# 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:

```python
# 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](https://research.google/pubs/pub43864/) (2015), розглядаючи вікна як першокласні елементи pipeline. Spark адаптував своє віконування для Structured Streaming, інтегрувавши його з DataFrame API.

| Функція | Beam 2.76 | Spark 4.2 |
|---------|-----------|----------|
| Фіксовані вікна | `FixedWindows(duration)` | `window(col, duration)` |
| Ковзні вікна | `SlidingWindows(size, period)` | `window(col, size, period)` |
| Сесійні вікна | `Sessions(gap)` | Не нативно (використовуйте `flatMapGroupsWithState`) |
| Власні вікна | Підклас `WindowFn` | Обмежено |
| Обробка запізнілих даних | Вбудовані тригери | Затримки watermark |
| Дозволена затримка | Конфігурація per-вікно | Глобальний watermark |

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

```python
# 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 обробки для сесій:

```python
# 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](/technologies/data-engineering/interview-questions/apache-beam-dataflow).

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

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

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

| Навантаження | Spark 4.2 (Databricks) | Beam 2.76 (Dataflow) | Примітки |
|----------|------------------------|---------------------|-------|
| Batch ETL (1TB Parquet) | 4.2 хв | 5.1 хв | Перевага рушія Photon у Spark |
| Streaming (100K подій/сек) | 45мс p99 затримка | 120мс p99 затримка | Накладні витрати автомасштабування Dataflow |
| Exactly-once запис у sink | Нативно | Нативно | Обидва підтримують з 2024 |
| Вартість (стабільне навантаження) | $0.12/ГБ оброблено | $0.08/ГБ оброблено | Ціни Dataflow Flex |

Покращення продуктивності 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 в обох фреймворках.**

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

```python
# 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](/technologies/data-engineering/interview-questions/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

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

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

| Фактор | На користь Beam | На користь Spark |
|--------|-------------|-------------|
| Хмарний провайдер | Google Cloud | AWS EMR, Databricks, on-prem |
| Досвід команди | Наявний досвід Dataflow | Наявні навички Spark/PySpark |
| ML інтеграція | Обмежена (окремі інструменти) | MLlib, Spark ML |
| Інтерактивний аналіз | Не призначений для цього | Spark SQL, notebooks |
| Сесійні вікна | Нативна підтримка | Ручне керування станом |
| Модель витрат | Pay-per-use (Dataflow) | Provisioning кластера |
| Vendor lock-in | Нижчий (багато runner'ів) | Вищий (код специфічний для Spark) |

Для [рішень щодо патернів ETL/ELT](/technologies/data-engineering/interview-questions/etl-elt-patterns) слід розглянути обсяг даних та вимоги до затримки перед вибором фреймворку.

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

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

```
[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](/blog/data-engineering/apache-spark-pyspark-data-pipelines-tutorial) з деталями реалізації.

## Ключові Висновки для Вибору 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

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/uk/blog/data-engineering/apache-beam-vs-spark-2026-unified-pipelines-interview-questions