HiveSQL技术原理、优化与面试

HiveSQL技术原理、优化与面试

Hive SQL 编译成MapReduce过程

编译 SQL 的任务是在上节中介绍的 COMPILER（编译器组件）中完成的。Hive将SQL转化为MapReduce任务，整个编译过程分为六个阶段

1、词法、语法解析: Antlr 定义 SQL 的语法规则，完成 SQL 词法，语法解析，将 SQL 转化为抽象语法树 AST Tree；

Antlr是一种语言识别的工具，可以用来构造领域语言。使用Antlr构造特定的语言只需要编写一个语法文件，定义词法和语法替换规则即可，Antlr完成了词法分析、语法分析、语义分析、中间代码生成的过程。

2、语义解析: 遍历 AST Tree，抽象出查询的基本组成单元 QueryBlock；
3、生成逻辑执行计划: 遍历 QueryBlock，翻译为执行操作树 OperatorTree；
4、优化逻辑执行计划: 逻辑层优化器进行 OperatorTree 变换，合并 Operator，达到减少 MapReduce Job，减少数据传输及 shuffle 数据量；
5、生成物理执行计划: 遍历 OperatorTree，翻译为 MapReduce 任务；
6、优化物理执行计划: 物理层优化器进行 MapReduce 任务的变换，生成最终的执行计划。

阶段一：词法、语法解析根据Antlr定义的sql语法规则，将相关sql进行词法、语法解析，转化为抽象语法树AST Tree：

 select * from dim.dim_region where dt = '2021-05-23'; 

ABSTRACT SYNTAX TREE:
TOK_QUERY
        TOK_FROM        
        TOK_TABREF
                    TOK_TABNAME
                            dim
                                dim_region
        TOK_INSERT
            TOK_DESTINATION
                TOK_DIR
                    TOK_TMP_FILE
            TOK_SELECT
                TOK_SELEXPR
                    TOK_ALLCOLREF       
    TOK_WHERE
        =
                TOK_TABLE_OR_COL
                        dt
                            '2021-05-23'

阶段二：语义解析

遍历AST Tree，抽象出查询的基本组成单元QueryBlock：

AST Tree生成后由于其复杂度依旧较高，不便于翻译为mapreduce程序，需要进行进一步抽象和结构化，形成QueryBlock。

QueryBlock是一条SQL最基本的组成单元，包括三个部分：输入源，计算过程，输出。简单来讲一个QueryBlock就是一个子查询。

QueryBlock的生成过程为一个递归过程，先序遍历 AST Tree ，遇到不同的 Token 节点(理解为特殊标记)，保存到相应的属性中。

阶段三：生成逻辑执行计划

遍历QueryBlock，翻译为执行操作树OperatorTree：Hive最终生成的MapReduce任务，Map阶段和Reduce阶段均由OperatorTree组成。

• TableScanOperator
• SelectOperator
• FilterOperator
• JoinOperator
• GroupByOperator
• ReduceSinkOperator

Operator在Map Reduce阶段之间的数据传递都是一个流式的过程。每一个Operator对一行数据完成操作后之后将数据传递给childOperator计算。

由于Join/GroupBy/OrderBy均需要在Reduce阶段完成，所以在生成相应操作的Operator之前都会先生成一个ReduceSinkOperator，将字段组合并序列化为Reduce Key/value, Partition Key。

阶段四：优化逻辑执行计划

Hive中的逻辑查询优化可以大致分为以下几类：

• 投影修剪
• 推导传递谓词
• 谓词下推
• 将Select-Select，Filter-Filter合并为单个操作
• 多路 Join
• 查询重写以适应某些列值的Join倾斜

阶段五：生成物理执行计划

• 生成物理执行计划即是将逻辑执行计划生成的OperatorTree转化为MapReduce Job的过程，主要分为下面几个阶段：
• 对输出表生成MoveTask
• 从OperatorTree的其中一个根节点向下深度优先遍历
• ReduceSinkOperator标示Map/Reduce的界限，多个Job间的界限
• 遍历其他根节点，遇过碰到JoinOperator合并MapReduceTask
• 生成StatTask更新元数据
• 剪断Map与Reduce间的Operator的关系

阶段六：优化物理执行计划

Hive中的物理优化可以大致分为以下几类：

• 分区修剪(Partition Pruning)
• 基于分区和桶的扫描修剪(Scan pruning)
• 如果查询基于抽样，则扫描修剪
• 在某些情况下，在 map 端应用 Group By
• 在 mapper 上执行 Join优化 Union，使Union只在 map 端执行
• 在多路 Join 中，根据用户提示决定最后流哪个表
• 删除不必要的 ReduceSinkOperators
• 对于带有Limit子句的查询，减少需要为该表扫描的文件数
• 对于带有Limit子句的查询，通过限制 ReduceSinkOperator 生成的内容来限制来自 mapper 的输出
• 减少用户提交的SQL查询所需的Tez作业数量
• 如果是简单的提取查询，避免使用MapReduce作业
• 对于带有聚合的简单获取查询，执行不带 MapReduce 任务的聚合
• 重写 Group By 查询使用索引表代替原来的表
• 当表扫描之上的谓词是相等谓词且谓词中的列具有索引时，使用索引扫描

经过以上六个阶段，SQL 就被解析映射成了集群上的 MapReduce 任务。

Hive千亿级数据倾斜

数据倾斜问题剖析
数据倾斜是分布式系统不可避免的问题，因为任何分布式系统都会有几率发生数据倾斜。在map和reduce这两个阶段中，最容易出现数据倾斜的就是reduce阶段了，因为map到reduce会经过shuffle阶段，在shuffle中默认会按照key进行hash，如果相同的key过多，那么hash的结果就是大量相同的key进入到同一个reduce中，导致数据倾斜
map阶段也有可能会产生数据倾斜，因为在一个任务中，数据文件在进入map阶段之前会切分，默认是128M一个数据块，但是如果对文件使用GZIP压缩等不支持文件分割操作的压缩方式，MR任务读取压缩后的文件是，是对它切分不了的，该压缩文件只会被一个任务读取。如果说有一个超大的不可切分的压缩文件被一个map读取时，就会发生map阶段的数据倾斜。
从本质上来说，发生数据倾斜的原因有两种
1、任务中需要处理大量相同的key的数据
2、任务中读取不可分隔的大文件
数据倾斜解决方案

• 1、空值引发的数据倾斜

问题：
在实际业务中有些大量的null或者一些无意义的数据参与到计算机作业中，表中会出现大量的null值，我们在对表进行join操作时，就会有shuffle产生，就会出现所有的null值分配到一个reduce中，就会导致数据倾斜

解决方案：
第一种可以直接不让null值参于join操作，也就是说没有null就没有shuffle阶段
第二种：因为null参与shuffle时hash结果都是一样的，所以我们可以对null值进行随机赋值，这样它们的hash的记过就不一样了，就会进入到不同的reduce中了

• 2、不同的数据类型引发的数据倾斜

问题：
对于两个表join，表a中需要join的字段key为int，表b中key字段既有string类型也有int类型。当按照key进行两个表的join操作时，默认的hash操作会按int型的id进行分配，这样所有的string类型都被分配成同一个id，结果就是所有的string类型的字段进入到一个reduce中，引发数据倾斜

解决方案：
如果key字段既有string也有int类型，默认的hash会按照int类型来分配，那我们直接把int类型都转为string就好了，这样key字段都为string，hash时就可以按照string类型分配了

• 3、不可拆分大文件引发的数据倾斜

问题：
当集群的数据量增长到一定规模，有些数据需要归档或者转储，这时候往往会对数据进行压缩；当对文件使用GZIP压缩等不支持文件分割操作的压缩方式，在日后有作业涉及读取压缩后的文件时，该压缩文件只会被一个任务所读取。如果该压缩文件很大，则处理该文件的Map需要花费的时间会远多于读取普通文件的Map时间，该Map任务会成为作业运行的瓶颈。这种情况也就是Map读取文件的数据倾斜。

解决方案：
使用GZIP压缩等不支持文件分割的文件转为bzip和zip等支持文件分割的压缩方式。所以，我们在对文件进行压缩时，为避免因不可拆分大文件而引发数据读取的倾斜，在数据压缩的时候可以采用bzip2和Zip等支持文件分割的压缩算法。

• 4、数据膨胀引发的数据倾斜

在多维聚合计算时，如果进行分组聚合的字段过多

select a，b，c，count（1）from log group by a，b，c with rollup;

对于最后的with rollup关键字不知道大家用过没，with rollup是用来在分组统计数据的基础上再进行统计汇总，即用来得到group by的汇总信息。

问题：
如果上面的log表的数据量很大，并且Map端的聚合不能很好地起到数据压缩的情况下，会导致Map端产出的数据急速膨胀，这种情况容易导致作业内存溢出的异常。如果log表含有数据倾斜key，会加剧Shuffle过程的数据倾斜。

解决方案：可以拆分上面的sql，将with rollup拆分成如下几个sql：


SELECT a, b, c, COUNT(1) FROM log GROUP BY a, b, c;

SELECT a, b, NULL, COUNT(1) FROM log GROUP BY a, b;

SELECT a, NULL, NULL, COUNT(1) FROM logGROUP BY a;

SELECT NULL, NULL, NULL, COUNT(1) FROM log;

在Hive中可以通过参数 hive.new.job.grouping.set.cardinality 配置的方式自动控制作业的拆解，该参数默认值是30。表示针对grouping sets/rollups/cubes这类多维聚合的操作，如果最后拆解的键组合大于该值，会启用新的任务去处理大于该值之外的组合。如果在处理数据时，某个分组聚合的列有较大的倾斜，可以适当调小该值。

• 5、表连接时引发的数据倾斜

问题：
两表进行普通的repartition join时，如果表连接的键存在倾斜，那么在 Shuffle 阶段必然会引起数据倾斜

解决方案：通常做法是将倾斜的数据存到分布式缓存中，分发到各个 Map任务所在节点。在Map阶段完成join操作，即MapJoin，这避免了 Shuffle，从而避免了数据倾斜。MapJoin是Hive的一种优化操作，其适用于小表JOIN大表的场景，由于表的JOIN操作是在Map端且在内存进行的，所以其并不需要启动Reduce任务也就不需要经过shuffle阶段，从而能在一定程度上节省资源提高JOIN效率。在Hive 0.11版本之前，如果想在Map阶段完成join操作，必须使用MAPJOIN来标记显示地启动该优化操作，由于其需要将小表加载进内存所以要注意小表的大小。

如将a表放到Map端内存中执行，在Hive 0.11版本之前需要这样写：

select /* +mapjoin(a) */ a.id , a.name, b.age from a join b on a.id = b.id;

在Hive 0.11版本及之后，Hive默认启动该优化，也就是不在需要显示的使用MAPJOIN标记，其会在必要的时候触发该优化操作将普通JOIN转换成MapJoin，可以通过以下两个属性来设置该优化的触发时机：

hive.auto.convert.join=true 默认值为true，自动开启MAPJOIN优化。

hive.mapjoin.smalltable.filesize=2500000 默认值为2500000(25M)，通过配置该属性来确定使用该优化的表的大小，如果表的大小小于此值就会被加载进内存中。注意：使用默认启动该优化的方式如果出现莫名其妙的BUG(比如MAPJOIN并不起作用)，就将以下两个属性置为fase手动使用MAPJOIN标记来启动该优化:

hive.auto.convert.join=false (关闭自动MAPJOIN转换操作)

hive.ignore.mapjoin.hint=false (不忽略MAPJOIN标记)

再提一句：将表放到Map端内存时，如果节点的内存很大，但还是出现内存溢出的情况，我们可以通过这个参数 mapreduce.map.memory.mb 调节Map端内存的大小。

HIVE底层执行架构

在 Hive 这一侧，总共有五个组件：

• UI：用户界面。可看作我们提交SQL语句的命令行界面。
• DRIVER：驱动程序。接收查询的组件。该组件实现了会话句柄的概念。
• COMPILER：编译器。负责将 SQL 转化为平台可执行的执行计划。对不同的查询块和查询表达式进行语义分析，并最终借助表和从 metastore 查找的分区元数据来生成执行计划.
• METASTORE：元数据库。存储 Hive 中各种表和分区的所有结构信息。
• EXECUTION ENGINE：执行引擎。负责提交 COMPILER 阶段编译好的执行计划到不同的平台上。

上图的基本流程是：

步骤1：UI 调用 DRIVER 的接口；

步骤2：DRIVER 为查询创建会话句柄，并将查询发送到 COMPILER(编译器)生成执行计划；

步骤3和4：编译器从元数据存储中获取本次查询所需要的元数据，该元数据用于对查询树中的表达式进行类型检查，以及基于查询谓词修建分区；

步骤5：编译器生成的计划是分阶段的DAG，每个阶段要么是 map/reduce 作业，要么是一个元数据或者HDFS上的操作。将生成的计划发给 DRIVER。

如果是 map/reduce 作业，该计划包括 map operator trees 和一个 reduce operator tree，执行引擎将会把这些作业发送给 MapReduce ：

步骤6、6.1、6.2和6.3：执行引擎将这些阶段提交给适当的组件。在每个 task(mapper/reducer) 中，从HDFS文件中读取与表或中间输出相关联的数据，并通过相关算子树传递这些数据。最终这些数据通过序列化器写入到一个临时HDFS文件中（如果不需要 reduce 阶段，则在 map 中操作）。临时文件用于向计划中后面的 map/reduce 阶段提供数据。

步骤7、8和9：最终的临时文件将移动到表的位置，确保不读取脏数据(文件重命名在HDFS中是原子操作)。对于用户的查询，临时文件的内容由执行引擎直接从HDFS读取，然后通过Driver发送到UI。