揭秘百度数仓融合计算引擎

2024-02-29
上海
本文字数：3463 字
阅读完需：约 11 分钟

作者 | Spark 源码践行者

导读
本文介绍了百度数仓融合计算引擎的整体设计原理、优化及实践，阐述了在互联网产品快速迭代的趋势下，基于一层数仓宽表模型的数仓模型如何做到数十秒级查询的技术方案，并从互联网业务变化特性、传统计算引擎存在的问题、融合计算引擎的原理及优缺点、引擎应用场景和效果等角度进行了较为全面的分析，最终通过引擎设计和优化实现了提升查询性能的同时节约数仓存储的目标，降低了用户的数据使用成本。

01 业务背景

1.1 数据现状和数据分析引擎的演进

1.1.1 数据现状

互联网企业往往存在多个产品线，每天源源不断产出大量数据，数仓规模达到数百 PB 以上，这些数据服务于数据分析师、业务上的产品经理、运营、数据开发人员等各角色。为了满足这些角色的各种需求，需要稳定高效的计算引擎在海量数据中快速完成分析计算。

1.1.2 数据分析引擎的演进及百度数仓引擎选型

单机分析时代（数仓 TB 级别）->

MapReduce、Hive 基于磁盘的分析时代（数仓数 PB 级别，分析耗时数十分钟）-> Spark 基于内存的分析时代（数仓数百 PB，分析耗时数十秒）

百度数仓引擎选型：对比了业界常用的 Adhoc 查询分析引擎，通过对比 Hive 生态、大规模 Join、存储引擎、列式存储、是否支持高并发以及适用场景等，如图 1：

△图 1

最终选型 Spark SQL，因为 SparkSQL 对 Hive 生态兼容好，大规模 Join 性能好，支持大宽表列存，支持 UDF 等。

1.2 当前业务特性与趋势

互联网产品快速迭代，业务发展越来越快，跨业务分析越来越多，数据驱动业务越来越重要。数仓计算任务和数据量越来越多，adhoc 场景日均参与计算的数据数十 P，ETL 场景日均数十 P，数据服务的主要群体正在从数据研发转向分析师、产品及运营人员，查询计算速度需要进一步提升，使用门槛需要进一步降低。

02 面临的问题

2.1 在数据驱动业务越来越重要的大趋势下，分析效率越来越重要

面临如下问题，如图 2、图 3：

△图 2

△图 3

2.2 思考

那么在生产实践中如何解决上述面临的问题及痛点呢，在对数仓技术深度调研和对业务线具体用户访谈后，根据调研和访谈结论，得出以下想法：

（1）引擎层面：设计融合计算引擎、使用 DataSkipping，Limit 下推、Codegen 和向量化，参数调优等方式加速数据查询，快速满足业务查询需求，助力数据驱动业务。

（2）数仓层面：数仓不分层，节约数仓整体存储，用更少的表满足业务需求，比如一个主题一张宽表，明确数据表使用方式，确保口径清晰统一，避免业务方线下拉会沟通，降低沟通成本，提高沟通效率。

03 技术方案

根据上述的想法，经过可行性分析后，提出设计开发出融合计算引擎和一层大宽表模型替代经典数仓维度模型的技术方案，来解决传统数仓 adhoc 场景查询性能低、存储大量冗余、表多且口径不清晰的问题。

3.1 融合计算引擎

融合计算引擎是一个百度自研的集常驻、查询、生产于一体的数仓融合的 SQL 计算引擎，它基于 Apache Spark 构建，具有快速、可扩展和高度可靠的特性，不仅用于在 PB 甚至 EB 级大规模数据处理和分析场景中执行 SQL 查询，也用于例行生产的 ETL 场景。

3.1.1 融合计算引擎架构

融合计算引擎架构如下：由 WebServer、Master、Worker 三部分组成。具体各部分功能见图 4：

△图 4

基于 Spark 源码二次开发的 Worker 是核心执行模块，内部 Container 常驻做到资源复用。

3.1.2 融合计算引擎性能优化

3.1.2.1 如何算的更少 DataSkipping

（1）PartitionSkipping：仅读取必要的分区，对性能提升最大

（2）Parquet 列式存储

百度数据中台线上查询特点是宽表 500~1300 列，平均查询列数 15 列以内，非常适合使用 Parquet 存储格式，优点是：

（a）同列同质数据拥有更好的编码及压缩

（b）Parquet 映射下推，通过映射下推只需要从每个 RowGroup 中读取下推的列即可，实现文件 IO 量：TB->GB 级别，如图 5：

△图 5

（3）RowGroup 级别统计过滤

由于 Parquet 文件是基于 RowGroup 的方式分块存储的，并且 Parquet Footer 中存储了每个 RowGroup 的 min/max，sum，BloomFilter 元信息等索引信息，因此可以结合谓词下推进一步过滤出必要的 RowGroup，如图 6：

△图 6

（4）Parquet ColumnIndex

在 Spark 3.2.0 之前 Parquet 的谓词下推是基于 Row group 的统计信息来的，如：最大最小值，字典信息，以及 Parquet-1.12 的 Bloom filter，在 Spark 3.2.0 之后，我们可以基于 page 级别的数据过滤（只选择需要的 page），这样能大大减少 IO，因为在 page 级别过滤的话，不需要每次都会获取整个 Row group 的数据。

另外数据分布对于 Parquet ColumnIndex 的影响较大。数据分布越紧凑，min/max 索引越精确，RowGroup Skipping 效果越好。因此我们会在 Spark 引擎数据写入 Parquet 文件之前基于指定字段做一次文件内排序，这样能将 Data Page 内的数据分布更加紧凑，最大发挥出 Parquet ColumnIndex 中 min/max 等索引的特性，实际业务落地时日增 3 千亿行的大宽表查询耗时降低 43%，Parquet Index 如图 7：

△图 7

3.1.2.2 如何算得更快

（1）ProjectLimit

Spark3.2 之前对 Select * from table Limit 1000 这种 partten 无法进行 ProjectLimit 下推，简单查询会执行非常久，通过分析物理计划，发现完全可以消除该查询物理计划中的 Exchange 节点也就是 Shuffle 阶段，优化后该类型的查询耗时从数十分钟级别降低到秒级别，性能提升百倍以上，如图 8：

△图 8

（2）CodeGen

CodeGen 通过动态生成 Java 代码、即时编译和加载，把解释执行转化为编译执行，变成机器码执行，主要针对表达式计算和全 Stage 计算做代码生成，都取得了数量级的性能提升。

具体来说，Spark Codegen 分为 Expression 级别和 WholeStage 级别，Expression 级别主要针对表达式计算做代码生成，WholeStage 级别主要针对全 Stage 计算做代码生成。

通过参数简化、函数嵌套简化、函数返回值简化，可以减少函数调用的开销，减少 CPU 计算资源的浪费和提高缓存命中率等从而加速计算，如图 9：

△图 9

在百度内部生产中，我们实现了 UDF、get_json_object、parse_url、sentences 等算子的 WSCG 性能提升 9%，如图 10：

△图 10

（3）向量化

列式存储向量化读取，减少虚函数调用，如图 11：

△图 11

百度的内部场景中我们发现有大量的 Like 和 JSON 解析操作。因此，我们引入 hyperscan 和 simdJson 使用向量化技术替换 Spark 现有的 Like 和 Json 算子，以此提升查询性能。最终融合计算引擎查询性能提升了 12%。

3.1.2.3 如何算的更稳定

Spark 有 task 级别的 retry 机制，但要保证查询又快又稳，需要避免这种 retry，于是我们根据生产中不同业务场景不同任务类型，从上百个参数中调整改良了几十个参数，主要调整的参数包括堆内内存、堆外内存、资源并发参数、shuffle 参数、推测执行参数、调度参数、序列化参数以及文件参数等。

3.1.3 融合计算引擎例行 ETL 场景

融合计算引擎天然适合 ETL 场景，因为其是基于 Spark 进行的二次开发，可支持单语句、多语句、各种复杂的 SparkSQL 等语法，如图 12：

△图 12

3.2 融合计算引擎优点及性能

（1）查询引擎和 ETL 生产引擎统一，避免不同引擎之间的语义差距，使用成本更低

在同一个数仓生产场景中，使用相同引擎，可以显著降低业务同学的使用门槛，以及数据开发人员的学习成本，使其更关注其业务逻辑，提高生产力。

（2）适合超大规模的查询和生产

面对数仓数百 PB 数据进行大规模查询计算生产，可以完美支持日增 3 千亿行的超大表进行高频查询。

（3）性能对比

Adhoc 查询场景，耗时在数十秒级别，相比于普通 Spark 性能提升 5 倍。

ETL 生产场景资源节约 20%的同时耗时相比普通 spark 性能提升 4 倍。

（4）计算引擎和数仓建模一体化

正是因为有融合计算引擎强大的计算能力，才可以完成百度数仓一层大宽表模型替代传统经典维度模型的数仓优化。融合计算引擎和一层大宽表模型整体规划，完成了百度数仓的整体降本增效，融合计算引擎推动一层大宽表替换维度模型，通过极少的冗余，做到了表更少，口径更清晰，业务使用上更方便，沟通更流畅，效率更高的同时，做到了数仓总存储下降 30% 左右，查询性能提升 300%，大大提升了业务分析和数仓生产效率。