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

点击蓝字，关注我们

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

全文4003字，预计阅读时间11分钟

1.1.1 数据现状

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

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

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

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

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

△图1

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

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

△图2

△图3

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

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

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

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

3.1.1融合计算引擎架构

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

△图4

3.1.2 融合计算引擎性能优化

3.1.2.1 如何算的更少DataSkipping

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

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

△图5

（3）RowGroup级别统计过滤

△图6

△图7

3.1.2.2 如何算得更快

△图8

△图9

△图10

△图11

3.1.2.3 如何算的更稳定

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

△图12

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

（1）融合计算引擎和宽表建模更适合面向快速迭代的数据驱动型业务，能够极大的提升业务效率。

（2）基于当前的业务实践，引擎和宽表在存储和查询性能方面相比于传统数仓更优。

（3）在业务效率提升的同时，查询越来越多，计算量越来越大，引擎压力有所提升，宽表的建设在数据生产和维护成本有所提升，整体挑战越来越大，还需结合引擎技术和实际场景进一步优化探索。