Альтернативные движки и расширения Spark

Экосистема вокруг Spark

Apache Spark — доминирующий distributed processing engine, но он не единственный. Ряд проектов дополняют, ускоряют или заменяют Spark в определённых нишах. Разберём три категории:

1. DataFusion — Rust-based альтернатива для small-to-medium data
2. Photon — проприетарный ускоритель Spark от Databricks
3. External Shuffle Services — расширения shuffle-подсистемы Spark

DataFusion: Arrow-native query engine

Apache DataFusion — query engine написанный на Rust, работающий поверх Apache Arrow. Это не форк Spark — это совершенно другая архитектура:

Ключевые характеристики

• Rust + Arrow native: нет JVM, нет GC pauses, предсказуемая производительность
• Embedded: можно встроить как библиотеку в Rust/Python приложение
• Vectorized execution: обработка данных batch-ами в Arrow columnar format
• Extensible: custom data sources, functions, optimizers

# DataFusion через Python binding
import datafusion

ctx = datafusion.SessionContext()

# Регистрация Parquet файла как таблицы
ctx.register_parquet("events", "/data/events.parquet")

# SQL-запросы -- синтаксис аналогичен Spark SQL
result = ctx.sql("""
    SELECT city, COUNT(*) as total
    FROM events
    WHERE event_date >= '2024-01-01'
    GROUP BY city
    ORDER BY total DESC
    LIMIT 10
""")

# Результат -- Arrow RecordBatch
print(result.to_pandas())

Ballista: распределённый DataFusion

Ballista — distributed query engine поверх DataFusion. Концептуально аналогичен Spark, но на Rust + Arrow:

Spark:     JVM   + RDD/DataFrame  + Catalyst  = Distributed SQL
Ballista:  Rust  + Arrow/DataFusion + Custom   = Distributed SQL

Ballista находится в ранней стадии развития и не заменяет Spark для production big data workloads, но демонстрирует направление: native execution без JVM overhead.

Когда DataFusion vs Spark?

DataFusion — комплемент Spark для small-to-medium data и embedded сценариев, где JVM overhead неоправдан. Для TB-scale distributed processing Spark остаётся стандартом.

Photon: Databricks Vectorized Engine

Photon — проприетарный native execution engine от Databricks, написанный на C++. Он заменяет JVM-based execution для Spark SQL:

Standard Spark:
  SQL Query -> Catalyst -> Tungsten (JVM bytecode) -> CPU

Photon (Databricks):
  SQL Query -> Catalyst -> Photon (C++ native code) -> CPU

Ключевые характеристики

• Vectorized execution: обработка данных column-batch-ами (аналогично Arrow)
• Native C++: нет JVM overhead, нет GC pauses, SIMD-оптимизации
• 100% совместим с Spark SQL: тот же SQL, те же DataFrame API, без изменений кода
• Доступен только на Databricks Runtime — не open-source
• Стандартен в Databricks Runtime 16/17 (2025): Photon включён по умолчанию начиная с DBR 9.1 LTS. В DBR 16.4 поставляется Photon v2 (улучшенная SQL-производительность), в DBR 17.0 — advanced Photon optimizations и query planner improvements.

Производительность Photon

String-операции показывают наибольшее ускорение: C++ работает с UTF-8 строками нативно, в отличие от JVM, где каждая string — объект с heap allocation.

External Shuffle Services

Проблема shuffle reliability

В стандартном Spark shuffle-данные хранятся на локальном диске executor. Если executor умирает — shuffle-данные теряются, и upstream stages нужно пересчитать:

Standard shuffle:
  Executor 1 (map output) ──── dies ──── shuffle data LOST
                                          │
  Executor 3 (reduce) ◄──── needs ────── X
                                          │
                              RECOMPUTE map stage!

Spark External Shuffle Service (ESS)

ESS выносит shuffle-данные из executor в отдельный процесс на node:

# Включение External Shuffle Service
spark.shuffle.service.enabled              true

# ESS запущен как YARN auxiliary service или standalone daemon
# Shuffle-данные сохраняются даже при crash executor

Push-Based Shuffle

Spark3.5 Push-based shuffle (Spark 3.2+, production-ready в 3.5) — оптимизация, при которой mapper push-ит shuffle-блоки на reducer-ноды, вместо того чтобы reducer pull-ил их:

Преимущества push-based shuffle:

• Меньше fetch запросов: reducer читает один merged файл вместо N блоков
• Меньше мелких I/O: merge на mapper-стороне создаёт larger sequential reads
• Устойчивость: merged shuffle data на отдельном сервисе

# Включение push-based shuffle (Spark 3.2+)
spark.shuffle.push.enabled                 true
spark.shuffle.push.maxBlockSizeToPush      1m
spark.shuffle.push.maxBlockBatchSize        3m

# Требует External Shuffle Service
spark.shuffle.service.enabled              true

Custom Shuffle Implementations

Крупные компании разрабатывают собственные shuffle-системы для масштаба:

Apache Celeborn (Apache TLP с апреля 2024) — ведущий open-source remote shuffle service: push-based shuffle, поддержка Spark 2.4-4.1 и Flink, pluggable storage backends. Также см. Apache Uniffle (Apache TLP с февраля 2025) — альтернативный remote shuffle service с 3-tier storage.

Сравнение: позиционирование движков

Итоги модуля

Модуль M14 Advanced Topics дал обзор расширенной экосистемы Spark:

• Spark Connect — клиент-серверная архитектура для ресурсной изоляции и multi-tenancy
• GraphX/GraphFrames — графовые вычисления в Spark
• MLlib — распределённое машинное обучение с Pipeline API
• RAPIDS — прозрачное GPU-ускорение
• DataFusion, Photon, Celeborn — альтернативные и дополняющие технологии

Каждая из этих технологий решает конкретную задачу. Ключевой навык data engineer — понимать когда и зачем применять каждый инструмент, а не знать все API наизусть.