Comet vs альтернативы

Comet — не единственный проект, ускоряющий Spark через нативное исполнение. Gluten (на базе Meta Velox) и Databricks Photon решают ту же задачу, но с другой архитектурой. Разберём различия, критерии выбора и будущие направления.

Ландшафт Spark-ускорителей

Три проекта заменяют JVM execution engine Spark на нативный код:

Gluten + Velox

Gluten (Apache Incubator) — фреймворк для подключения нативных execution engine к Spark. По умолчанию использует Velox — С++ vectorized engine от Meta.

Архитектурные отличия от Comet

Substrait vs Protobuf

Gluten использует Substrait — межпроектный стандарт для описания вычислительных планов. Comet использует собственный protobuf-формат (expr.proto):

• Substrait — стандартизован, теоретически позволяет подключать разные backend-ы (Velox, DuckDB, DataFusion). На практике Gluten тесно связан с Velox
• Comet Protobuf — специализирован под DataFusion, меньше abstraction overhead, но не переносим на другие engine

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

Прямые бенчмарки между Comet и Gluten зависят от запроса:

• Scan/Filter/Project: сопоставимы — оба используют нативное чтение Parquet и векторизированную фильтрацию
• Complex aggregation/join: Velox имеет более зрелую adaptive execution; Comet использует стандартные DataFusion join-алгоритмы
• Shuffle: Comet columnar shuffle (Arrow IPC) vs Velox serialization — зависит от payload

Databricks Photon

Photon — проприетарный нативный execution engine, встроенный в Databricks Runtime:

• Не доступен вне Databricks — нельзя использовать с open-source Spark
• Глубокая интеграция — Photon знает о Delta Lake internals, Databricks caching, adaptive query execution
• Automatic fallback — бесшовный fallback на JVM для неподдерживаемых операций
• Production-ready — используется в Databricks с 2021 года

Когда выбрать Photon

Если ваша инфраструктура уже на Databricks — Photon включается одним параметром (spark.databricks.photon.enabled=true). Нет причин использовать Comet или Gluten в Databricks-окружении.

LakeSail Sail: drop-in Spark replacement

Sail (LakeSail) — главный 2026 drop-in Spark replacement, написанный на Rust и построенный поверх DataFusion. В отличие от Comet, который встраивается в JVM-процесс Spark как plugin, Sail — самостоятельная распределённая система, реализующая Spark Connect-протокол и PySpark API целиком на Rust. По публичным замерам LakeSail заявляет 4–8x throughput vs Spark и сокращение инфраструктурных затрат до 94%.

Архитектурное различие: Comet vs Sail

Когда выбрать Comet

• Уже есть production Spark cluster, миграция на новый runtime неприемлема
• Нужна полная совместимость с существующим Spark-стеком (UDF на Scala/Java, custom Spark plugins)
• Команда готова поддерживать JVM и Rust одновременно
• Acceleration важнее, чем избавление от JVM

Когда выбрать Sail

• Можно перейти на Spark Connect-клиенты (PySpark, Spark SQL через gRPC)
• Цель — полный отказ от JVM (operational simplicity, memory safety, нет GC pauses)
• Греинфилд-проект или готовность к серьёзной миграции
• Spark API нужен, но Spark JVM-инфраструктура — нет

Полное side-by-side сравнение Comet vs Sail

Критерии выбора

Когда выбрать Comet

• Вы используете open-source Spark (не Databricks)
• Вы уже инвестировали в DataFusion экосистему
• Вам нужен простой деплой без C++ зависимостей
• Parquet — основной формат хранения
• Вы хотите контролировать execution engine и контрибьютить upstream

Когда выбрать Gluten + Velox

• Вам нужна максимальная поддержка сложных выражений (Velox покрывает больше SQL)
• Вы работаете с нестандартными форматами (ORC через Velox)
• Команда готова к более сложной сборке и деплою

Когда выбрать Photon

• Инфраструктура на Databricks
• Нужна максимальная совместимость и стабильность
• Budget позволяет проприетарное решение

Вклад в Comet

Comet — активно развивающийся проект Apache с хорошими точками входа для контрибьюторов:

Области для вклада

1. Добавление поддержки выражений — самый частый тип контрибьюции:

   • Реализовать CometExpressionSerde для неподдерживаемого Spark-выражения
   • Добавить protobuf-сообщение в expr.proto
   • Написать Rust-маппинг в PhysicalPlanner

2. Расширение покрытия типов данных — добавить поддержку CalendarIntervalType, YearMonthIntervalType

3. Улучшение Iceberg-интеграции — расширение native_iceberg_compat (time travel, partition transforms)

4. Бенчмарки и документация — запуск TPC-DS, сравнительные отчёты

Архитектура для контрибьюции

apache/datafusion-comet/
├── common/           # Общие утилиты
├── spark/            # Scala-код: CometPlugin, CometExecRule, CometScanRule
├── native/           # Rust-код: PhysicalPlanner, serde, execution
│   └── core/
│       ├── src/
│       │   ├── execution/    # Нативные execution nodes
│       │   ├── parquet/      # Parquet reader
│       │   └── planner.rs    # PhysicalPlanner
│       └── Cargo.toml
└── proto/            # Protobuf definitions (expr.proto)

Пример: принятие решения

Допустим, ваша компания использует open-source Spark 3.5 на EMR / Dataproc / on-premise. Аналитические запросы по TPC-H-подобным нагрузкам занимают 40% бюджета вычислений. Варианты:

Comet даёт лучшее соотношение «усилие → результат» для начала. Если покрытие выражений недостаточно — можно контрибьютить или перейти на Gluten.

Будущие направления

Comet roadmap

• Spark 4.0 полная поддержка — адаптация к ANSI mode по умолчанию, новые типы данных
• Расширение покрытия выражений — каждый релиз добавляет 10-20 выражений
• Нативный Iceberg scan — расширение native_iceberg_compat до production-ready
• Улучшение shuffle — адаптивное переключение между columnar и row-based shuffle в зависимости от payload
• Partial replacement — экспериментальная работа над per-operator fallback вместо all-or-nothing (пока не реализовано)

Comet в контексте DataFusion

Comet демонстрирует паттерн использования DataFusion как embedded library (разобранный в модуле 05 — Паттерны расширяемости):

• DataFusion предоставляет execution primitives (FilterExec, ProjectionExec, HashJoinExec)
• Comet транслирует внешние планы (Spark) в эти примитивы
• Аналогичный паттерн используют InfluxDB IOx (InfluxQL → DataFusion) и GreptimeDB (PromQL → DataFusion)

В следующем модуле мы рассмотрим альтернативный подход — распределённое исполнение через Ballista и DataFusion Ray, где DataFusion работает не как embedded engine, а как ядро распределённой системы.

Итоги

• Три Spark-ускорителя: Comet (DataFusion, Rust), Gluten+Velox (C++), Photon (проприетарный, Databricks)
• Comet vs Gluten: Protobuf vs Substrait, Arrow vs Velox vectors, один JAR vs C++ зависимости
• Photon — только в Databricks, максимальная совместимость и стабильность
• Comet выбирают для: open-source Spark + DataFusion экосистема + простой деплой
• Контрибьюция: добавление выражений (CometExpressionSerde + protobuf + PhysicalPlanner)
• Roadmap: расширение покрытия выражений, Spark 4.0, нативный Iceberg, улучшение shuffle