Kyligence-刘文政-Gluten 给 Spark 提速2倍：背景、原理和实践

项目背景：由刘文政高级软件架构师参与设计研发，专注OLAP领域，拥有OLAP生态、应用及内核研发经验，并持有多项OLAP相关专利。
项目现状：兼容Spark，采用NativeExecutionEngine，性能至少提升2倍，为商业化产品，非开源。
技术参考：Databricks在SIGMOD论文中公开了其设计思想（https://people.eecs.berkeley.edu/matei/papers/2022/sigmod_photon.pdf）。
社区参与：已有10+公司参与（包括Intel、Kyligence、BIGO、Meituan、Aliyun、Netease等），80+贡献者，计划贡献至Apache基金会。
性能表现：总体速度提升2.12倍，最高提升3.48倍，Q21部分算子未支持，不参与比较。

核心机制：Gluten仅作为SparkPlugin存在，将SparkPlan转换为NativeEnginePlan，实现统一内存管理、列式Shuffle。
兼容性：通过Shim层兼容不同版本Spark，Fallback机制允许原生Spark执行，并上报NativeExecution统计信息。
内存管理：集成SparkOff-heapMemoryManagement，采用MemoryPool机制减少malloc次数，内存申请上报TaskMemoryManager，Executor内存不足时触发Spill。
Shuffle优化：采用Hash-based Shuffle、Native Partitioner、Reducer零拷贝，优化小数据量Shuffle及小文件数量。
HDD集群方案：提供Remove Shuffle Service方案。
Fallback机制：NativeEngine不支持的算子回退至Spark计算，列式数据转化成SparkUnsafeRow参与计算，完成后转化回NativeEngineColumnarBatch，相邻Fallback算子合并。

应用环境：底层查询引擎为Spark，数据格式包含CSV/Parquet等，存储在S3，查询对象包含物化视图表和原始表，部署在AWS上。
实践挑战：
- 实验室效果如何保证生产上有效果？
- 数据准确性如何保证？
- 替换后性能提升幅度多大？
- 生产环境无访问权限如何排查问题？
解决方案：
- 在QA环境充分演练部署架构、数据对比和性能对比。
- 白天复制保存流量，夜间回放，不影响生产使用。
- 自动化性能对比、数据对比，每日日报总结，研发无法登录生产环境。
问题及解决：
- SQLHint部分失效、Decimal精度问题、Crossjoin内存占用过多、CSV文件解析规则未对齐、Fallback算子导致查询更慢。
- 问题解决后，性能达标，总体提升2倍，准备上线。
上线后问题：
- On-Heap内存使用正常，Off-Heap存在内存泄漏，持续运行3天后查询失败。
- 通过Native Engine MemoryProfile、malloc主要分布、Caller method定位，最终定位为NativeEngine中Substrait使用后未及时释放。
经验总结：
- TPCH/TPCDS验证不足，建议从非核心关键场景开始替换。
- 替换前需充分验证性能和准确性。
- 需具备定位和解决问题的能力。
- 积极参与社区沟通。