Apache Gluten

Что такое Gluten

Apache Gluten — middleware-плагин для Spark, который «склеивает» (от англ. glue) Spark с нативными execution engines. В отличие от Comet, который привязан к DataFusion, Gluten — middle-layer, позволяющий подключать разные бэкенды: Meta Velox (C++) или ClickHouse (C++).

Gluten был инициирован Intel и Kyligence в 2022 году как наследник проекта Intel Gazelle (retired). 5 марта 2026 года Gluten graduated как Apache Top-Level Project (TLP) — голосование: 10 binding +1, 4 non-binding +1, 0 против. Это сигнал production-readiness: ByteDance, Intel, Kyligence, Alibaba Cloud, Microsoft уже используют Gluten на EB-масштабе.

Spark3.2 Velox бэкенд поддерживает Spark 3.2+. Spark3.3 ClickHouse бэкенд поддерживает Spark 3.3+. Spark 4.0 совместимость — в разработке.

Архитектура

Архитектурно Gluten занимает уникальную позицию: это не execution engine, а middleware между Spark и нативным бэкендом. Spark генерирует физический план через Catalyst (М02), а Gluten перехватывает его и транслирует в формат, понятный нативному движку.

Pipeline трансляции

Spark PhysicalPlan
  -> GlutenPlugin (SparkPlugin API)
    -> Validation: проверка поддержки каждого оператора (planning time!)
    -> Substrait plan conversion (cross-language specification)
    -> JNI call -> native backend
      -> Velox (C++, libvelox.so)  OR  ClickHouse (C++, libch.so)
    -> ArrowColumnarBatch returned to Spark
  -> Unsupported operators: C2R -> JVM execution -> R2C (overhead!)

Ключевое отличие от Comet: Gluten валидирует план на этапе планирования (planning time), а не во время исполнения. Каждый оператор проверяется до начала выполнения — это позволяет заранее определить, какие части плана будут исполнены нативно, а какие fallback на JVM.

Substrait: универсальная спецификация планов

Gluten транслирует Spark physical plan в Substrait — стандартизированную cross-language спецификацию для обмена query plans между системами. Substrait определяет общий формат для описания relational operators (Scan, Filter, Project, Join, Aggregate), который понимают разные execution engines.

Это архитектурное решение отличает Gluten от Comet: Comet использует проприетарный Protocol Buffer формат, привязанный к DataFusion. Substrait потенциально позволяет Gluten подключать любой бэкенд, реализующий Substrait consumer interface.

Velox бэкенд (Meta)

Meta Velox — C++ vectorized execution engine с наследием Presto. Velox разработан в Meta совместно с IBM, Intel, ByteDance и Microsoft.

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

• Arrow-compatible columnar memory с Dictionary, Constant и RLE encodings — компактное представление данных
• Lazy materialization — данные не копируются, пока реально не нужны, что снижает memory footprint
• Vectorized batch processing — обработка данных column-batch-ами с SIMD-оптимизациями
• Полный набор операторов: scans, writes, projections, filtering, grouping, ordering, shuffle/exchange, hash/merge/nested loop joins, unnest

Velox — основной бэкенд Gluten. Большинство production deployment-ов (ByteDance, Intel, BIGO, Meituan) используют именно Velox. Причины: более широкое operator coverage, активное развитие Meta-инженерами, Presto heritage для аналитических запросов.

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

• Аналитические workloads: scan-heavy, aggregation, join-intensive queries
• Требуется максимальная производительность на TPC-H/TPC-DS бенчмарках
• Нет привязки к ClickHouse экосистеме
• Нужна широкая community поддержка (Meta, Intel, ByteDance контрибьюторы)

ClickHouse бэкенд (Kyligence)

ClickHouse бэкенд использует нативный движок ClickHouse (libch.so) для исполнения Spark-планов. Этот бэкенд инициирован Kyligence — компанией, специализирующейся на OLAP-решениях.

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

• ClickHouse SQL heritage — другой SQL-диалект по сравнению с Velox (Presto SQL). Это влияет на маппинг операторов и поведение edge cases
• Сильная сторона — компрессия: ClickHouse исторически оптимизирован для сжатия данных, что полезно для storage-heavy workloads
• Специфичные aggregate functions: некоторые агрегатные функции, специфичные для ClickHouse, не имеют прямых аналогов в Velox
• Другой профиль operator coverage: набор поддерживаемых Spark-операторов отличается от Velox

Когда выбирать ClickHouse бэкенд

• Команда имеет экспертизу в ClickHouse (проще дебажить нативные ошибки)
• Workload использует специфичные ClickHouse aggregate functions
• Сильное сжатие данных критично для ваших storage costs
• Уже есть ClickHouse инфраструктура и мониторинг

Конфигурация: Velox vs ClickHouse

Обе конфигурации имеют общую часть (GlutenPlugin, ColumnarShuffleManager, offHeap), но различаются JAR-файлами и backend-specific параметрами.

Velox бэкенд

spark-submit \
  --jars gluten-velox-bundle-spark3.5_2.12-1.3.0.jar \
  --conf spark.driver.extraClassPath=gluten-velox-bundle-spark3.5_2.12-1.3.0.jar \
  --conf spark.executor.extraClassPath=gluten-velox-bundle-spark3.5_2.12-1.3.0.jar \
  --conf spark.plugins=org.apache.gluten.GlutenPlugin \
  --conf spark.shuffle.manager=org.apache.spark.shuffle.sort.ColumnarShuffleManager \
  --conf spark.memory.offHeap.enabled=true \
  --conf spark.memory.offHeap.size=20g \
  --conf spark.gluten.enabled=true \
  --conf spark.gluten.sql.columnar.batchSize=2048 \
  --conf spark.gluten.sql.columnar.backend.velox.memCacheSize=4g \
  your_spark_app.py

ClickHouse бэкенд

spark-submit \
  --jars gluten-clickhouse-bundle-spark3.5_2.12-1.3.0.jar \
  --conf spark.driver.extraClassPath=gluten-clickhouse-bundle-spark3.5_2.12-1.3.0.jar \
  --conf spark.executor.extraClassPath=gluten-clickhouse-bundle-spark3.5_2.12-1.3.0.jar \
  --conf spark.plugins=org.apache.gluten.GlutenPlugin \
  --conf spark.shuffle.manager=org.apache.spark.shuffle.sort.ColumnarShuffleManager \
  --conf spark.memory.offHeap.enabled=true \
  --conf spark.memory.offHeap.size=20g \
  --conf spark.gluten.enabled=true \
  --conf spark.gluten.sql.columnar.backend.ch.runtime_config.logger.level=error \
  your_spark_app.py

Сравнение конфигурации

Обратите внимание: offHeap.enabled=true и offHeap.size — обязательные для обоих бэкендов. Без них нативный код не получит память и выполнение завершится crash или OOM.

Fallback behavior: C2R/R2C overhead

Когда Gluten встречает оператор, который нативный бэкенд не поддерживает, происходит fallback chain:

Native columnar batch (ArrowColumnarBatch)
  -> ColumnarToRow (C2R): конвертация в InternalRow
  -> JVM execution (vanilla Spark)
  -> RowToColumnar (R2C): конвертация обратно в columnar
  -> Native execution continues

Каждая C2R/R2C конвертация — это полное копирование данных между columnar и row форматами. На больших batch-ах это может занимать значительное время.

Бенчмарки (Velox бэкенд)

Официальные бенчмарки Gluten с Velox бэкендом (март 2024):

Для сравнения: Comet показывает 2.2—2.4x на TPC-H. Gluten с Velox быстрее, но требует более сложной настройки (C++ зависимости, Substrait трансляция, off-heap tuning).

Максимальное ускорение (23.45x) достигается на scan-heavy и aggregation-heavy запросах, где Velox может использовать:

• SIMD-инструкции для columnar processing
• Lazy materialization для минимизации memory footprint
• Arrow-compatible memory с Dictionary encoding для string-операций

Celeborn integration

Gluten поддерживает Apache Celeborn (0.3.x—0.5.x) как remote shuffle service — оба бэкенда (Velox и ClickHouse) совместимы.

# Celeborn integration с Gluten
spark.celeborn.client.spark.push.data.timeout=120s
spark.shuffle.manager=org.apache.spark.shuffle.sort.ColumnarShuffleManager

Remote shuffle решает проблему потери shuffle-данных при crash executor (см. М14/L06). Для shuffle-heavy workloads на крупных кластерах Celeborn + Gluten — production-рекомендация.

Production adoption

Gluten используется на production-масштабе крупнейшими технологическими компаниями:

Bolt бэкенд — ByteDance разработала собственный fork Velox (Bolt) и предложила его как дополнительный бэкенд Gluten. Это демонстрирует гибкость middleware-архитектуры: новые бэкенды можно добавлять без изменения core Gluten.

Anti-patterns

1. Не мониторить C2R/R2C fallback rate

Включение Gluten без мониторинга fallback — частая ошибка. Если >30% операторов fallback на JVM, суммарный overhead C2R/R2C может сделать запрос медленнее. Используйте Spark UI для отслеживания ColumnarToRow и RowToColumnar узлов в physical plan.

2. ClickHouse бэкенд без CH-экспертизы

ClickHouse бэкенд генерирует ClickHouse-specific error messages и stack traces. Без знания ClickHouse internals дебаггинг нативных ошибок значительно сложнее. Если команда не имеет ClickHouse-опыта — используйте Velox бэкенд.

3. Игнорирование off-heap конфигурации

Как и Comet, Gluten требует off-heap memory. Без spark.memory.offHeap.enabled=true и адекватного offHeap.size нативный бэкенд не получит память. Рекомендация: 20g+ для production workloads.

4. Ожидание одинакового speedup на всех запросах

Бенчмарк показывает 3.34x в среднем по TPC-H. Отдельные запросы варьируются от минимального ускорения до 23.45x. Scan-heavy и aggregation-heavy запросы ускоряются максимально. UDF-heavy и window-function-heavy запросы могут не получить ускорения вовсе.

Итоги

Apache Gluten — middleware-плагин, «склеивающий» Spark с нативными execution engines:

• Middleware-архитектура: не привязан к одному бэкенду — Velox (Meta, C++) или ClickHouse (Kyligence, C++)
• Substrait трансляция: стандартизированный формат для cross-language query plans
• Planning-time validation: fallback определяется до начала выполнения
• 3.34x ускорение на TPC-H (Velox бэкенд), до 23.45x на отдельных запросах
• C2R/R2C overhead: запросы с высоким fallback rate могут быть медленнее vanilla Spark
• Production adoption: ByteDance, Intel, Kyligence, Alibaba Cloud, Microsoft — EB-масштаб
• Celeborn integration: remote shuffle для обоих бэкендов

В следующем уроке мы сравним все нативные движки (Comet, Gluten, Photon, vanilla Spark) и дадим decision framework для выбора правильного движка в production.