以问题作为引导，进行Hive知识梳理，可以复习知识时，可以快速抓住要点

提交一条SQL到Hive后，Hive的执行流程是怎么样的？

Sql的执行的一个示意图如下

根据这个示意图，我们来描述一下一条SQL在Hive中的执行流程

1.首先向hive提交一条SQL后，这条SQL会被提交给了解析器Parser

2.解析器Parser根据SQL将其解析，生成抽象语法树(AST)，并与元数据库交互，根据元数据信息生成逻辑执行计划

3.逻辑执行计划再到优化器Optimizer，优化器对逻辑执行计划进行优化，然后再根据优化后的逻辑执行计划最终生成物理执行计划

4.根据物理执行计划生成执行任务，将执行任务交给执行引擎Execution Engine，进行执行，执行完成生成执行结果

SQL的解析和优化是如何进行的？

SQL的解析主要是解析器进行的，解析器在解析SQL时会将一个SQL解析成多个Operator，Operator是Hive解析之后最小单元，每个Operator在最后的执行阶段是与一个MapReduce任务对应的

SQL的优化执行优化是优化器Optimizer才进行的，优化器会对解析器解析出来的Operator进行优化，最基本的优化就是Operator的执行顺序，然后进行其他优化

常见的三种类型的优化器如下：

• RBO(Rule-Based Optimizer)：基于规则的优化器

RBO是根据已经制定好的优化规则，对关系表达式进行转换，最终生成一个最优的执行计划。它是一个经验式的优化方法，优化规则都是事先定义好的，只需要将Sql按照优化规则的顺序套用就可以，一旦满足某个规则就对该SQL进行对应优化，这种方式有一个弊端，就是会导致同样的一条SQL无论他读取的表中数据是什么样的，它最终得到的执行计划都是一样的，没有办法针对性的达到最佳效果

• CBO(Cost-Based Optimizer)：基于代价的优化器

CBO是根据优化规则，对关系表达式进行转换生成多个执行计划，最终根据要查询的数据表的统计信息和代价模型，计算每个执行计划的执行代价，从中挑选出执行代价最小的执行计划作为最终的执行计划。相对于RBO来说CBO是更加优秀的，RBO只认规则，对数据不敏感，在实际过程当中数据的量级是会严重的影响SQL的性能，而CBO就较好的解决了这种问题，虽然是相同的SQL也会因为数据表的不同根据代价模型计算的代价采用不同的执行计划

Hive使用的是CBO，在生产执行计划的时候Hive需要与元数据服务MetaStore进行交互，获取数据表的详情，基于数据表的详情和代价模型对SQL进行优化

• 动态CBO：在执行计划生成的过程中动态优化的方式

动态CBO是在CBO的基础上进行的改进，静态CBO的在优化执行计划时所依据的统计信息是静态的也就是事先统计好的，随着数据的快速变化，静态的统计信息没有办法提供准确的思考，所以在进行执行优化的时候使用动态的统计才可以得到最优的执行计划

Hive的存储模型都有哪些，分别有什么作用？

hive中主要有四种表：内部表，外部表，分区表，分桶表

其中内部表和外部表都是基本表，不同点就是数据的位置，内部表的数据文件归hive管理，在Hive中进行表的删除时内部表的数据会被一并删除。而外部表的数据文件则不受Hive直接管理，它的数据文件是挂载在外部表上，当外部表删除时，其所对应的数据文件不会被删除。

分区表是指按照数据表的某列或者某些列分为多个分区，分区在形式上可以理解为目录，分区表即对表中的数据进行分区存储，相对于普通表分区表在通过where字句查询时，可以根据分区字段避免全表扫描的情况，可以通过合适的索引来扫描表中的一小部分，提高查询性能，创建分区表的时候我们需要指定分区字段，建表后在HDFS表目录下会生成一个使用分区字段名称作为目录名称的目录，如果有多级分区，子级分区的目录就是父分区目录的子目录。

分桶是更加细粒度的数据划分，Hive采用某一列进行分桶，采用对列值Hash将其与桶的个数进行求余的方式来确定数据所属的桶，分桶可以获得更高的查询的数据效率，使取样更加高效

什么是数据倾斜，如何解决数据倾斜？

数据倾斜可以简答的理解为大量相同的Key被partition分配到一个相同的分区里面，造成部分分区数据量非常大，使得部分节点要承受巨大的计算压力，而其他节点计算完毕之后也需要等到这个节点计算完成，拖累了整体计算进度，使效率变得低下

hive中数据倾斜原因:

• key分布不均匀，业务数据本身就有数据倾斜特性

• 数据文件大小不均匀，小文件特别多，map阶段读入数据时，导致读取到大文件map操作处理的数据特别多，读取到小文件的map操作读取的数据特别少

• 建表时考虑不周全，数据分区倾斜

• 查询SQL语句本身就有数据倾斜问题，大小表join

解决数据倾斜

• 调整Hive参数，比如hive.map.aggr、hive.groupby.skewindata，在map端进行聚合操作，相当于combine；
  mapred.max.split.size，每个map可以处理的最大文件大小，可调大该值来减少map数，解决由于小文件过多导致每个map读取的数据量不均匀的倾斜

• 调整SQL语句：

join方式，小表join大表时，可以将小表直接加载在内存中再去扫描大表  
空值造成的数据倾斜，将空值的key变为一个字符串加上随机数，使其分散  
不同数据类型关联产生的数据倾斜，将其先转换成统一数据类型，再进行关联

hive在查询时有哪些优化项？

Hive作为一个大数据处理工具，它其实不怕数据多，而是怕数据倾斜，导致效率低下，所以在使用中我们也尽量遵守一些简单规则，可以更高效的使用它

• 列裁剪，指定要具体查询的列，少用 select *

• 善于用分区键进行检索，过滤不需要的数据

• 用小表join大表，多使用map join减少reduce中的shuffle操作

• 对hive中的小文件合并，降低NameNode压力的同时，也会减少Map阶段map操作的数量

个人公众号【爱做梦的锤子】，全网同id，个站 http://te-amo.site，欢迎关注，里面会分享更多有用知识

觉得不错就点个赞叭QAQ