作者 | 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 原生利用开发新范式