共计 3957 个字符，预计需要花费 10 分钟才能阅读完成。
作者 | Spark 源码践行者
导读
本文介绍了百度数仓交融计算引擎的整体设计原理、优化及实际，论述了在互联网产品疾速迭代的趋势下，基于一层数仓宽表模型的数仓模型如何做到数十秒级查问的技术计划，并从互联网业务变动个性、传统计算引擎存在的问题、交融计算引擎的原理及优缺点、引擎利用场景和成果等角度进行了较为全面的剖析，最终通过引擎设计和优化实现了晋升查问性能的同时节约数仓存储的指标，升高了用户的数据应用老本。
全文 4003 字，预计浏览工夫 11 分钟
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%，大大晋升了业务剖析和数仓生产效率。
04 总结
（1）交融计算引擎和宽表建模更适宜面向疾速迭代的数据驱动型业务，可能极大的晋升业务效率。
（2）基于以后的业务实际，引擎和宽表在存储和查问性能方面相比于传统数仓更优。
（3）在业务效率晋升的同时，查问越来越多，计算量越来越大，引擎压力有所晋升，宽表的建设在数据生产和保护老本有所晋升，整体挑战越来越大，还需联合引擎技术和理论场景进一步优化摸索。
——————————END——————————
举荐浏览
教不会你算我输系列 | 手把手教你 HarmonyOS 利用开发
漫谈数据分布可视化剖析
云上业务一键性能调优，应用程序性能诊断工具 Btune 上线
数据库运维工作量间接缩小 50%，基于大模型构建智能问答零碎的技术分享
百度智能云千帆 AppBuilder 构建 AI 原生利用开发新范式
