Gluten CH Backend 在 BIGO 的研发和应用以及 Flink native 进展

摘要：导读当大数据计算遭遇 CPU 墙，当 Java 引擎优化逼近极限，向量化执行与 Native 引擎成为行业破局的关键钥匙。作为全球音视频服务巨头，BIGO 通过深度参与开源项目 Gluten，不仅在 Spark 场景实现性能与资源利用率的双重突破，更将技术边界

导读当大数据计算遭遇 CPU 墙，当 Java 引擎优化逼近极限，向量化执行与 Native 引擎成为行业破局的关键钥匙。作为全球音视频服务巨头，BIGO 通过深度参与开源项目 Gluten，不仅在 Spark 场景实现性能与资源利用率的双重突破，更将技术边界拓展至 Flink 领域，开启了大数据计算的 “原生执行” 时代。BIGO 技术专家徐帅将全景式呈现其在 Gluten 技术栈上的全生命周期实践：从技术选型的底层逻辑，到功能补全的攻坚细节；从 Spark 大规模上线的自动化流水线，到 Flink Native 引擎的前沿探索。无论你是关注技术落地的开发者，还是寻求降本增效的企业管理者，都能从中获取可复用的工程经验与技术洞察。

今天的介绍会围绕下面六点展开：

1. 技术瓶颈下的战略选择：Gluten 为何成为破局关键？

2. BIGO 的 Gluten 攻坚：从功能补全到生产级优化

3.规模化收益：从性能提升到成本重构

4. 新战场开拓：Gluten for Flink 的挑战与规划

5. 结语：Native 执行的未来版图

6. Q&A

分享嘉宾｜徐帅 BIGO Principle Engineer

编辑整理｜李硕

内容校对｜郭慧敏

出品社区｜DataFun

技术瓶颈下的战略选择：Gluten 为何成为破局关键？

1. Spark 引擎的现实困境：从 IO 瓶颈到 CPU 饱和

Apache Spark 作为大数据领域的 “瑞士军刀”，支撑了 BIGO 日均 PB 级数据的离线处理需求。然而，随着业务扩张至 150 + 国家、4 亿月活用户，传统Spark 集群逐渐暴露两大核心问题：

CPU 资源瓶颈：万兆网络与 SSD 硬盘的普及，使计算瓶颈从 IO 转向 CPU。Spark 基于 Java 的解释执行模式，无法充分释放现代 CPU 的向量化指令能力（如 AVX/AVX2），导致集群 CPU 利用率长期维持在 80% 以上。

优化边际递减：Spark 的 Java 层优化（如 Tungsten 执行引擎、自适应查询）已趋近极限。以字符串处理为例，Java 的 String 操作相比 C++ 的原生实现，性能差距可达 3-5 倍，复杂 UDF 场景差距更显著。

2. Native 执行浪潮：向量化引擎的技术逻辑

业界逐渐认识到，突破性能天花板需从执行层重构入手。Native 执行技术通过 C++ 等原生语言构建计算引擎，绕开 JVM 限制，实现三大核心优化：

向量化执行：将单行数据处理转换为批量列操作。例如，ClickHouse 的 Vectorized 引擎可将整数求和操作的 CPU 指令数减少 90%，缓存命中率提升 3 倍以上。列存格式：基于 Arrow 内存格式的列存储，减少 CPU 缓存行颠簸（Cache Line Thrashing）。实测显示，列存相比行存的聚合操作性能提升 2-4 倍。硬件亲和性：直接利用 CPU 底层特性（如分支预测、预取指令），避免 Java 即时编译的不确定性开销。

Gluten 项目正是这一趋势的开源实践：通过插件化机制，将 Spark 的逻辑计划转换为 Native 引擎可识别的执行计划，实现 “Java 生态兼容” 与 “Native 性能” 的平衡。其核心架构包括：

Plan Conversion：将Spark 物理计划转换为 SubstrAIt 协议，适配Velox/ClickHouse 等引擎；

Columnar Shuffle：基于Celeborn 实现列存数据的分布式洗牌，减少 Row/Column 转换开销；

Fallback 机制：通过 Shim Layer 无缝回退至原生 Spark，保障业务稳定性。

1. 研发里程碑：两年磨一剑的技术落地

BIGO 的 Gluten 之旅始于 2023 年 12 月，历经三阶段攻坚：

（1）基础能力构建（2023.12-2024.6）

完成CSV/JSON 解析、复杂数据类型（Array/Map/Struct）支持，实现 Parquet/ORC 的谓词下推与列裁剪；实现 200 + 新函数扩展（覆盖 date/JSON/math 等领域）选择 ClickHouse 作为底层引擎，因其 OLAP 向量化能力与公司内部生态契合，2024 年 6 月启动灰度上线。

（2）生产级优化（2024.6-2025.2）

修复 150 + 函数 Diff（如 cast/timestamp/divide）；优化 Celeborn Shuffle 支持（1000 + 节点集群），引入多磁盘 IO、小文件合并等系统级调优。

（3）全量迁移（2025.2 至今）

5000 + 工作流、20000 + 作业完成迁移，累计提交 600+PR，贡献 9 万行代码，4 人成为社区 Committer。

2. 功能与性能优化：全链路深度改造

（1）数据处理能力扩展

格式支持：新增 bzip2 压缩格式解析，支持压缩文件切片（Split），存储成本降低 30% 的同时保持计算效率；算子扩展：支持 Expand/CollectLimit/Generate 等算子，覆盖数据宽表构建、分页聚合等复杂场景；UDF Native 化：将内部高频 UDF 从 Java 重写为 C++，避免 Fallback 导致的性能损耗，Fallback 率从 20% 降至 1% 以下。

（2）计算性能跃升

向量化解析：JSON 数据解析速度提升 50%，Array Join 场景通过哈希表向量化构建，内存访问次数减少 60%；JIT 编译优化：对字符串处理、数值计算等高频函数启用 LLVM JIT，执行速度提升 3-5 倍；公共子表达式消除（CSE）：自动识别重复计算，如用户画像作业的 CPU 耗时从 8 小时缩短至 5 小时。

（3）系统级调优

Driver 内存管理：通过共享元数据减少计划分发的内存占用，OOM 风险降低 90%；多磁盘Shuffler：支持多磁盘并行读写，Shuffle 阶段吞吐量提升 40%，缓解热点磁盘压力；EC 文件读取优化：通过 LibHDFS 支持擦除编码（EC）文件，存储成本降低 50%，读取性能提升 20%。

3. 自动化上线流水线：零风险迁移的核心保障

为确保 5000 + 工作流的无缝切换，BIGO 构建了端到端自动化验证体系：

双跑机制：通过调度平台复制作业，一份用 Gluten 执行，一份保留原生 Spark，每日对比结果一致性（基于 Delta Lake 校验）与性能指标（耗时 / 内存 / CPU）。问题闭环：若发现 Diff 或性能回退，自动触发人工介入。典型案例包括正则表达式边界处理（ClickHouse 使用 RE2 引擎，Spark 使用 Java 内置引擎）、非法日期解析差异，均通过修改 ClickHouse 内核或扩展 Gluten 适配层解决。动态监控：对上线后作业持续监控，一旦检测到逻辑修改（如 UDF 更新），自动重新触发双跑验证，避免版本迭代引入隐性问题。

生产落地成效：数据背后的业务价值

截至 2025 年 2 月，BIGO 实现全量 Spark 作业 Native 化，核心收益包括：

性能提升：作业平均运行速度提升 30%，CPU 密集型任务（如广告归因计算）提速达 50%；资源节省：内存消耗减少 50%，年硬件成本节约超 1200 万元；

1. Flink 场景的独特挑战

尽管 Spark 场景取得成功，BIGO 的技术探索并未止步。2025 年 1 月启动的 Gluten for Flink 项目，旨在解决实时计算场景的性能与资源效率问题，但面临三大技术壁垒：

非插件化架构：Flink 内核缺乏 Spark 的插件机制，需直接修改 Planner 与执行层代码，实现算子替换（如 Filter/Aggregate）。有状态计算：需在 Velox 引擎中实现 State 接口，支持键值对存储与增量更新，同时确保 Checkpoint 的一致性与容错性。流式数据处理：流式场景要求低延迟与高吞吐的平衡，需减少 Row/Column 转换次数。

2. 技术路径与项目进展

Gluten for Flink 的架构设计遵循 “最小侵入性” 原则：

分层改造：通过 Flink Planner 拦截逻辑计划，转换为 Gluten Native 计划，调用 Velox Runtime 执行，保留 Flink Runtime 作为 Fallback；State 管理：设计基于 RocksDB 的向量化 State 存储，支持增量 Checkpoint，减少状态快照的 IO 开销；算子适配：优先支持高频算子（如 Filter/Map/Window），2025 年 4 月完成首个 POC（Filter 算子在 Velox 执行），7 月前通过 Nexmark 基准测试（覆盖 80% 查询场景）。

3. 里程碑规划

2025 年 Q2：完成基础算子（Filter/Aggregate）的 Velox 支持，启动内部流数据测试；2025 年 Q3：支持 Nexmark 全量测试，实现流式 Join 与窗口计算的向量化执行；2025 年 Q4：完成 State 管理模块开发，上线部分生产任务（如实时流量监控），目标迁移 20% 作业；2026 年：扩展至 Flink batch 模式、Flink DataStream 等场景，实现端到端列存计算。

4. 社区共建呼吁

BIGO 呼吁更多开发者参与 Gluten for Flink 建设，贡献形式包括：

代码开发：参与 State 接口实现、Window 算子向量化等核心模块；

场景验证：提供生产级流计算场景（如实时风控、日志监控），帮助覆盖边缘案例；

代码 review：参与 Gluten 社区代码 review。

从 Spark 到 Flink，BIGO 的 Gluten 实践揭示了大数据技术演进的底层逻辑：生态兼容性与性能优化的平衡。通过保留 Java 层的生态优势，同时在执行层引入 Native 技术，企业得以在不颠覆现有架构的前提下，实现计算效率的指数级提升。

未来，随着 Gluten for Flink 的落地，BIGO 将构建 “离线 + 实时” 全场景的 Native 计算体系，进一步向 AI 训练数据预处理、实时特征工程等场景延伸。这不仅是技术的胜利，更是开源社区与企业需求深度协同的典范 —— 正如徐帅在分享中所言：“Gluten 的价值不仅在于性能提升，更在于构建一个开放、可扩展的计算生态，让更多企业从中受益。”

Q1：为什么真实业务性能提升只有 30%，而官网测试显示几倍到十几倍？

实际生产环境与官网测试存在显著差异，主要原因包括：

集群负载复杂性：生产集群中多作业并行运行，资源竞争（如 CPU / 内存 / 磁盘 IO）导致排队延迟。例如，Shuffle 阶段的文件写入、HDFS 元数据操作等不可控因素，会增加端到端耗时。官网测试通常在空载或低负载环境下进行，更能体现纯计算性能。统计维度差异：官网数据：聚焦计算层优化，如向量化执行、JIT 编译等，测试场景多为单一查询（如 TPC-DS），性能提升主要反映计算效率。生产数据：统计包含作业调度、资源分配、数据倾斜等全链路耗时。例如，某作业计算时间减少 50%，但因排队等待资源，整体耗时仅下降 30%。资源节省的隐性价值：虽然端到端时间提升 30%，但资源利用率显著优化。例如，内存消耗减少 50%，同等算力下可减少 50% 节点数量，硬件成本降低近两倍，这部分收益未直接反映在时间指标中。

Q2：Gluten for Flink 的当前规划是什么？优先支持流计算还是批计算？

当前项目处于初期阶段，规划遵循 “从简到难” 原则：

2025 年重点：优先支持流计算（Streaming），聚焦无状态算子（如 Filter、Map、简单 Aggregate），2025 年 7 月前通过 Nexmark 基准测试（流计算性能测试集）。2025 年底前实现 State 状态管理与 Checkpoint 支持，目标上线部分生产任务（如实时流量监控）。批计算（Batch）支持计划：批计算场景（如 Flink SQL 离线分析）预计 2026 年启动，需解决行列转换开销、大表 Shuffle 优化等问题。当前阶段优先验证流计算的 Native 执行可行性。

Q3：Gluten 支持哪些向量化引擎？与 Presto 等引擎对比如何？

A3：

当前支持的 Backends：

ClickHouse（CH）：BIGO 内部主力引擎，适配 OLAP 场景，支持向量化 Join、Aggregate 及 Spill 到磁盘。Velox：Facebook 开源引擎，计划用于 Flink 场景，支持状态管理与流式计算。

与其他引擎的对比：

性能：向量化引擎普遍比 Java 引擎快 2-5 倍，Gluten 通过统一接口适配不同引擎，实测 CH 和 Velox 在 Spark 场景的性能接近（提升约 30-50%）。生态： Presto 更侧重 OLAP 处理，Gluten 通过插件化机制兼容多引擎，更侧重于离线数据处理。

Q4：Gluten 的部署环境有哪些？是否支持国产化系统？

A4：

操作系统支持：

主流 Linux 发行版：Ubuntu 16+/20+、CentOS 7+/8+、Rocky Linux 等。

BIGO 内部部署于 Ubuntu 16，社区反馈显示对国产化系统（如统信 UOS、麒麟 OS）兼容良好，可通过源码编译适配。

硬件与编译环境：

支持 x86_64 架构（含 AMD/Intel），ARM 架构需单独编译（社区计划 2025 年 Q4 支持）。

编译依赖 Docker 环境，可通过官方提供的 Docker 镜像快速构建，避免本地环境配置问题。

Q5：为什么选择 ClickHouse 和 Velox 作为底层引擎？两者如何选择？

A5：

ClickHouse（CH）的优势：成熟的 OLAP 能力：内置向量化引擎、列式存储，擅长复杂聚合与高吞吐查询，与 BIGO 内部数据分析场景高度契合。生态熟悉度：BIGO 已有 1000 + 节点的 CH 集群，团队对其内核调优经验丰富，便于快速落地。Velox 的优势：流式计算兼容性：作为模块化引擎，其目标是支持流批等多种计算模型，更具有开放性。社区活跃度：Velox 由 Facebook 开源，生态活跃，BIGO 与 Intel 合作开发Flink Native 功能，可快速获取技术支持。

选择建议：

离线 /批处理：如果对 CH 比较熟悉，可以优先选 CH。实时 /流式计算：目前只能选 Velox，CH 上比较难以支持状态处理。。

可根据业务需求动态切换，Gluten 通过统一 Plan Conversion 层屏蔽引擎差异。

Q6：对标阿里 Flash 等商业版引擎，Gluten 的优势是什么？

A6：

开源与免费：

Flash 是阿里商业版引擎，闭源且需付费；Gluten 是开源项目（Apache 2.0 协议），可自由修改源码，适合企业定制化需求。

多引擎兼容：

Flash 仅支持自研引擎，Gluten 支持 CH/Velox 等多引擎，避免厂商锁定。例如，BIGO 可根据场景灵活切换引擎，降低技术风险。

社区共建：

Gluten 由 Intel、Kyligence、BIGO 等多方共建，生态活跃度高，功能迭代速度快。例如，Flink Native 功能由 BIGO 与 Intel 联合开发。

Q7：如何参与 Gluten 社区贡献？非代码贡献者能做什么？