Сравнение и выбор движка

Зачем сравнивать

Мы разобрали три подхода к нативному ускорению Spark: DataFusion Comet (L02), Gluten с Velox и ClickHouse бэкендами (L03), и Photon (М14/L06). Каждый имеет свои tradeoffs: производительность, сложность настройки, лицензия, operator coverage, ecosystem support. Этот урок даёт decision framework для production-выбора.

Техническое сравнение

Decision flowchart

Используйте этот flowchart для быстрого определения подходящего движка:

Вы на Databricks?

• Да → Photon — built-in, zero config, лучшая интеграция
• Нет → open-source deployment, ответьте на следующий блок:

Что важнее всего в open-source сценарии?

• Простейшая настройка → Comet (single JAR, Rust safety, 97% test compat)
• Максимальная производительность → Gluten + Velox (3.3× TPC-H, ByteDance-proven)
• Есть ClickHouse-экспертиза → Gluten + ClickHouse backend
• Не уверены → начните с Comet (lower risk), оцените Gluten позже

Ключевое правило: если сомневаетесь — начните с Comet. Более простой deployment, более высокая тест-совместимость, меньше risk. Если Comet не даёт достаточного ускорения для вашего workload — evaluate Gluten + Velox.

Когда НЕ использовать нативные движки

Нативные движки — не silver bullet. В следующих случаях vanilla Spark может быть лучшим выбором:

UDF-heavy workloads

Все пользовательские UDF (Python, Java, Scala) выполняются на JVM. Ни Comet, ни Gluten не могут ускорить arbitrary user code. Если ваш pipeline на 70%+ состоит из UDF-вычислений — нативные движки дадут минимальный эффект.

Рекомендация: перепишите UDF на built-in functions (М06) или pandas UDF через Arrow (М11).

Complex window functions

Window functions с нестандартными frame specifications часто не поддерживаются нативно. Каждый unsupported window operator вызывает C2R/R2C overhead.

High fallback rate (>30%)

Если более 30% операторов вашего workload не поддерживаются нативным бэкендом, суммарный overhead C2R/R2C конвертаций может превысить ускорение. Правило: fallback rate <10% — отлично, 10—30% — допустимо, >30% — нативный движок скорее всего вреден.

Short-lived jobs

Для короткоживущих jobs (секунды) overhead загрузки нативных библиотек, JNI initialization и off-heap allocation может превысить выигрыш от нативного исполнения. Нативные движки наиболее эффективны на long-running batch workloads (минуты—часы).

Spark Structured Streaming

Поддержка streaming в Comet и Gluten — ограничена. Comet фокусируется на batch SQL; Gluten имеет частичную streaming поддержку. Для production streaming workloads vanilla Spark остаётся наиболее надёжным выбором.

Стратегия миграции в production

Переход на нативные движки — не мгновенный процесс. Рекомендуемая 5-фазная стратегия:

Phase 1: Диагностика

Включите fallback диагностику без изменения production workloads:

# Comet — включить объяснение причин fallback
spark.comet.explainFallback.enabled=true
spark.comet.debug.enabled=true

# Gluten — включить логирование unsupported operators
spark.gluten.sql.debug=true
# Проверить physical plan на наличие ColumnarToRow узлов:
# spark.sql("EXPLAIN FORMATTED SELECT ...").show(truncate=False)

Phase 2: Измерение fallback rate

Для каждого production query измерьте fallback rate. Цель: <10% fallback для максимального ускорения.

Phase 3: A/B тестирование

Запустите тот же workload с нативным движком и без него. Сравните:

• Wall-clock time (end-to-end)
• Resource usage (CPU, memory, off-heap)
• Cost per query (cloud billing)

Пример A/B конфигурации для benchmarking:

# Baseline — vanilla Spark
spark-submit \
  --name "benchmark-vanilla" \
  --conf spark.eventLog.enabled=true \
  --conf spark.eventLog.dir=hdfs:///spark-events/vanilla \
  benchmark_query.py

# Test — Comet native execution
spark-submit \
  --name "benchmark-comet" \
  --jars comet-spark-spark3.5_2.12-0.12.0.jar \
  --conf spark.plugins=org.apache.spark.CometPlugin \
  --conf spark.comet.enabled=true \
  --conf spark.comet.exec.enabled=true \
  --conf spark.comet.exec.shuffle.enabled=true \
  --conf spark.memory.offHeap.enabled=true \
  --conf spark.memory.offHeap.size=8g \
  --conf spark.eventLog.enabled=true \
  --conf spark.eventLog.dir=hdfs:///spark-events/comet \
  benchmark_query.py

Не сравнивайте только время — нативные движки потребляют off-heap память, что увеличивает memory footprint executor.

Phase 4: Production rollout

Постепенный rollout с мониторингом:

• Начните с одного workload (lowest risk)
• Мониторьте memory pressure (off-heap usage via Spark Metrics)
• Имейте rollback plan: отключение plugin JAR возвращает vanilla Spark

Prometheus metrics для мониторинга нативного исполнения:

# Включить Spark metrics sink для Prometheus
spark.metrics.conf.*.sink.prometheus.class=\
  org.apache.spark.metrics.sink.PrometheusSink
spark.metrics.conf.executor.source.jvm.class=\
  org.apache.spark.metrics.source.JvmSource

# Ключевые метрики для нативных движков:
# - jvm.heap.used / jvm.heap.max — JVM overhead (должен снижаться)
# - executor.memoryUsed — off-heap usage (будет расти)
# - executor.shuffleWriteTime — shuffle time (должен снижаться)
# - stage.executorRunTime — total execution time

Phase 5: Tuning

Тонкая настройка engine-specific конфигурации:

# Comet: замена SortMergeJoin на hash join
spark.comet.exec.replaceSortMergeJoin=true

# Gluten: batch size tuning
spark.gluten.sql.columnar.batchSize=4096

# Gluten: Velox cache
spark.gluten.sql.columnar.backend.velox.memCacheSize=8g

Production checklist

Cross-references

Этот модуль (М15) связан с несколькими другими модулями курса:

• М14/L06 (Альтернативные движки и расширения Spark) — awareness-level обзор DataFusion standalone, Photon и ESS. М15 даёт deep-dive в Spark-native plugins
• М14/L05 (NVIDIA RAPIDS) — GPU-ускорение. RAPIDS — комплементарная технология, не конкурирующая с CPU-native движками (Comet/Gluten). В некоторых deployment-ах RAPIDS + Gluten могут сосуществовать
• М02 (Catalyst Optimizer) — Catalyst генерирует физический план, который перехватывают Comet и Gluten. Понимание Catalyst pipeline — prerequisite для понимания нативного ускорения
• М11 (Apache Arrow) — Arrow columnar format — общий субстрат для всех нативных движков. Comet возвращает Arrow RecordBatch, Gluten возвращает ArrowColumnarBatch
• М16 (External Shuffle Service) — Celeborn, Uniffle. Deep-dive в remote shuffle архитектуры, которые интегрируются с Gluten

Итоги модуля

Модуль М15 «Альтернативные движки исполнения» охватил:

1. L01: Основы нативного исполнения — JVM limitations, Arrow как субстрат, Velox и DataFusion как standalone engines
2. L02: Apache DataFusion Comet — Rust/DataFusion Spark plugin, 2.2—2.4x ускорение, 97% тест-совместимость
3. L03: Apache Gluten — middleware с Velox и ClickHouse бэкендами, 3.34x ускорение, Substrait трансляция
4. L04: Сравнение и decision framework — comparison matrix, migration strategy, production checklist

Ключевой вывод: нативные движки — мощный инструмент ускорения Spark без изменения кода. Но успех зависит от правильного выбора (Comet vs Gluten vs Photon), измерения fallback rate и постепенной миграции с мониторингом. Не существует универсального «лучшего движка» — есть лучший движок для вашего конкретного workload.