字节跳动 SparkSQL 优化的一些建议
本帖最后由 168主编 于 2019-11-20 11:19 编辑来源：字节跳动白泉的分享作者：大数据技术与架构整理场景描述：面对大量复杂的数据分析需求，提供一套稳定、高效、便捷的企业级查询分析服务具有重大意义。本次演讲介绍了字节跳动基于SparkSQL建设大数据查询统一服务TQS（Toutiao Query Service）的一些实践以及在执行计划调优、数据读取剪枝、SQL兼容性等方面对SparkSQL引擎的一些优化。关键词：SparkSQL优化 字节跳动本文是根据来自字节跳动的分享整理而成。作者来自字节跳动数据平台查询分析团队。目标和能力为公司内部提供 Hive 、 Spark - SQL 等 OLAP 查询引擎服务支持。
[*]提供全公司大数据查询的统一服务入口，支持丰富的API接口，覆盖Adhoc、ETL等SQL查询需求
[*]支持多引擎的智能路由、参数的动态优化
[*]Spark-SQL/Hive引擎性能优化
针对SparkSQL，主要做了以下优化：1. 执行计划自动调优 • 基于AE的 ShuffledHashJoin调整 • Leftjoinbuildleftmap技术 2. 数据读取剪枝 • Parquetlocalsort • BloomFilter&BitMap • Prewhere 3. 一些其它优化执行计划调优
[*]执行计划的自动调优：
Spark Adaptive Execution （ Intel®Software）,简称SparkAE，总体思想是将sparksql生成的1个job中的所有stage单独执行，为每一个stage单独创建一个子job，子job执行完后收集该stage相关的统计信息（主要是数据量和记录数），并依据这些统计信息优化调整下游stage的执行计划。目前SparkAE主要支持的功能：（1）数据倾斜的调整（2）小task的合并（3）sortmerge-> broadcaseSpark 有3种join方式：Broadcastjoin、ShuffledHashJoin、SortMergeJoin普通leftjoin无法build 左表优化点：在AE的框架下，根据shuffle数据量大小，自动调整join执行计划：SortMergeJoin调整为 ShuffledHashJoin•扩展支持left-join时将左表build成HashMap。省去了大表join小表的情况下对shuffle数据的排序过程、join过程以HashMap完成，实现join提速。
[*]SortMergeJoin调整为ShuffledHashJoin
https://ask.qcloudimg.com/http-save/6430202/v64llwljgn.png?imageView2/2/w/1620
[*]Leftjoin build left sidemap
1、初始化表A的一个匹配记录的映射表目标：对于Left-join的情况，可以对左表进行HashMapbuild。使得小左表leftjoin大右表的情况可以进行ShuffledHashJoin调整难点：Left-join语义：左表没有join成功的key，也需要输出原理在构建左表Map的时候，额外维持一个"是否已匹配"的映射表；在和右表join结束之后，把所有没有匹配到的key，用null进行join填充。以 Aleft join B 为例：https://ask.qcloudimg.com/http-save/6430202/p25xgidlf5.png?imageView2/2/w/1620
2、join过程中，匹配到的key置为1，没有匹配到的项不变（如key3）https://ask.qcloudimg.com/http-save/6430202/7tmi5ifxre.png?imageView2/2/w/1620
3、join结束后，没有匹配到的项，生成一个补充结果集R2https://ask.qcloudimg.com/http-save/6430202/bvpxoyvhxa.png?imageView2/2/w/1620
https://ask.qcloudimg.com/http-save/6430202/sxel6ylxov.png?imageView2/2/w/1620
4.合并结果集R1和结果集R2，输出最终生成的join结果R。https://ask.qcloudimg.com/http-save/6430202/3fscsxub4g.png?imageView2/2/w/1620
优化结果
[*]约95%左右的joinSQL有被调整成ShuffledHashJoin/BroadcastJoin
[*]被优化的SQL整体速度提升20%~30%
[*]整体执行时长缩短
https://ask.qcloudimg.com/http-save/6430202/9utuk2psn0.png?imageView2/2/w/1620
基于Parquet数据读取剪枝以parquet格式数据为对象，在数据读取时进行适当的过滤剪枝，从而减少读取的数据量，加速查询速度优化点：
[*]LocalSort
[*]BoomFilter
[*]BitMap
[*]Prewhere
基于Parquet数据读取剪枝：LocalSort对parquet文件针对某个高频字段进行排序。从而实现读数据时RowGroup的过滤目标：
[*]自动选择排序字段
[*]生成文件时自动排序
https://ask.qcloudimg.com/http-save/6430202/lxzmsab0ul.png?imageView2/2/w/1620
Parquet文件读取原理： （1）每个rowgroup的元信息里，都会记录自己包含的各个列的最大值和最小值 （2）读取时如何这个值不在最大值、最小值范围内，则跳过RowGroup生成hive分区文件时，先读取metastore，获取它是否需要使用localsort，如果需要，选择它的高频列是哪个。基于Parquet数据读取剪枝：BloomFilter&BitMaphttps://ask.qcloudimg.com/http-save/6430202/8fvri75dx1.jpeg?imageView2/2/w/1620
https://ask.qcloudimg.com/http-save/6430202/y6guilj1wy.jpeg?imageView2/2/w/1620
https://ask.qcloudimg.com/http-save/6430202/gwd8wxvbv3.png?imageView2/2/w/1620
整体优化结果：
[*]命中索引平均性能提升 30%
[*]生成时间增加：10%
[*]空间开销增加：5%
如何选取合适的列https://ask.qcloudimg.com/http-save/6430202/gcjge95lfi.jpeg?imageView2/2/w/1620
Local_sort &BloomFilter & BitMap 如何自动生效https://ask.qcloudimg.com/http-save/6430202/pwvc7m0sdb.png?imageView2/2/w/1620
基于Parquet数据读取剪枝：Prewhere基于列式存储各列分别存储、读取的特性•针对需要返回多列的SQL，先根据下推条件对RowId进行过滤、选取。再有跳过地读取其他列，从而减少无关IO和后续计算•谓词选择（简单、计算量小）:in,=,<>,isnull,isnotnull优化结果使得：特定SQL（Project16列，where条件 2列）SQL平均性能提升20%其他优化
[*]Hive/SparkLoad分区Move文件优化：
通过调整staging目录位置，实现在Load过程中mv文件夹，替代逐个mv文件，从而减少与NameNode的交互次数
[*]Spark生成文件合并
通过最后增加一个repartitionstage合并spark生成文件。
[*]Vcore
对于CPU使用率低的场景，通过vcore技术使得一个yarn-core可以启动多个spark-core
[*]Spark 访问hivemetastore 特定filter下推：
构造 get_partitions_by_filter实现 cast、substring等条件下推hivemetastore，从而减轻metastore返回数据量运行期调优在SQL执行前，通过统一的查询入口，对其进行基于代价的预估，选择合适的引擎和参数:1.SQL分析
[*]抽取Hiveexplain逻辑，进行SQL语法正确性检查
[*]对SQL包含的算子、输入的数据量进行标注
2.自动引擎选择/自动参数优化标注结果自动选择执行引擎：
[*]小SQL走SparkServer（省去yarn申请资源耗时）
[*]其他默认走Spark-Submit
标注结果选择不同运行参数：
[*]Executor个数/内存
[*]Overhead、堆外内存
调优后使得Adhoc30s以内SQL占比45%，Spark-Submit内存使用量平均减少20%。
页:
[1]