1. 背景
随着大数据分析场景对性能和稳定性的要求不断提升，Apache Spark 社区及生态项目积极探索向量化执行（Vectorized Execution）以突破传统行式处理的性能瓶颈。向量化执行通过批处理方式利用 CPU SIMD 指令、减少虚函数调用、优化内存布局等手段，显著提升查询性能。当前主流的 Spark 向量化方案包括 Gluten + ClickHouse 和 DataFusion + Blaze。本文基于实际测试与功能对比，对两种方案进行系统性评估，并提出落地建议。
2. 性能对比
表格
| 方案 | 性能提升 | 说明 |
|---|---|---|
| Gluten + ClickHouse | ≈2 倍 | 利用 ClickHouse 的列式执行引擎加速 Spark SQL 查询 |
| DataFusion + Blaze | ≈3 倍 | 基于 Apache Arrow 和 Rust 实现的高性能执行引擎，向量化效率更高 |
结论 ：在纯性能维度，Blaze 方案表现更优，尤其适用于高吞吐、低延迟的 OLAP 场景。
3. 功能支持对比
表格
| 功能 | Gluten | Blaze | 说明 |
|---|---|---|---|
| HDFS Kerberos 认证 | ❌ 不支持 | ✅ 支持 | 在安全集群环境中，Blaze 具备更强的兼容性 |
| Hudi 读写支持 | ❌ 均不支持 | ❌ 均不支持 | 两者均需额外开发适配 Hudi 的向量化读写路径 |
| 断点续传（Fault Tolerance） | ❌ 不支持 | ✅ 支持 | Blaze 支持任务失败后从检查点恢复，保障 Spark 作业可靠性 |
| Remote Shuffle | ✅（仅稳定性） | ✅（仅稳定性） | Remote Shuffle 主要用于解耦计算与存储、提升容错能力，不带来性能提升 |
关键发现：
- Blaze 在企业级特性（如 Kerberos、断点续传）上更成熟，更适合生产环境部署。
- Hudi 集成是共同短板，需团队投入资源实现谓词下推、列裁剪等优化。
4. Hudi 优化建议
尽管当前 Gluten 与 Blaze 均未原生支持 Hudi 向量化读写，但可通过以下方式提升 Hudi 表查询性能：
- 启用谓词下推（Predicate Pushdown）：将过滤条件下推至 Hudi 层，减少 I/O。
- 开启列裁剪（Column Pruning）：仅读取必要字段，降低数据扫描量。
- 使用 MOR（Merge-on-Read）表配合索引：结合 Bloom Filter 或 Record Index 加速点查。
- 规划向量化读取路径：未来可基于 Arrow 格式实现 Hudi 文件的向量化扫描器。
建议：优先在 Blaze 上实现 Hudi 向量化读取，因其性能基线更高、扩展性更强。
5. 技术选型建议
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 高性能 OLAP 查询（非安全集群） | Blaze | 性能领先 50%，支持断点续传 |
| 安全集群（Kerberos + HDFS） | Blaze | 唯一支持 Kerberos 认证的向量化方案 |
| 快速验证向量化收益 | Gluten + ClickHouse | 社区文档较丰富，集成相对简单 |
| 长期演进 & 生产稳定性 | Blaze | 架构现代（Rust + Arrow），故障恢复能力强 |