Hive 的一些优化方法

雨点打透心脏的1/2处 2023-02-11 04:45 7阅读 0赞

### Hive 的一些优化方法 ###

*   *   *  Hadoop 框架计算特性
         *  常用的一些优化方法
         *   *  排序的选择

### Hadoop 框架计算特性 ###

*  1、 数据量大不是问题，数据倾斜是个问题
 *  2、 jobs 数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次汇总，产生十几个 jobs，耗时很长。原因是 map reduce 作业初始化的时间是比较长的
 *  3、 sum,count,max,min 等 UDAF，不怕数据倾斜问题， hadoop 在 map 端的汇总合并优化，使数据倾斜不成问题。
 *  4 、 count(distinct userid) ， 在数据量大的情况下， 效 率较低， 如果是多count(distinctuserid,month)效率更低，因为 count(distinct)是按 group by 字段分组，按 distinct 字段排序，一般这种分布方式是很倾斜的，比如 PV 数据，淘宝一天 30 亿的 pv，如果按性别分组，分配 2 个 reduce， 每个 reduce 期望处理 15 亿数据，但现实必定是男少女多。

### 常用的一些优化方法 ###

*  1、好的模型设计事半功倍，所以设计好模型很重要。
 *  2、解决数据倾斜问题。
 *  3、 减少 job 数。
 *  4、 设置合理的 MapReduce 的 task 数，能有效提升性能。 (比如， 10w+级别的计算，用 100个 reduce，那是相当的浪费， 1 个足够)
 *  5、了解数据分布，自己动手解决数据倾斜问题是个不错的选择。这是通用的算法优化，但算法优化有时不能适应特定业务背景，开发人员了解业务，了解数据，可以通过业务逻辑精确有效的解决数据倾斜问题。
 *  6、 数据量较大的情况下，慎用 count(distinct)， group by 容易产生倾斜问题。
 *  7、 对小文件进行合并，是行之有效的提高调度效率的方法，假如所有的作业设置合理的文件数，对集群的整体调度效率也会产生积极的正向影响。
 *  8、 优化时把握整体，单个作业最优不如整体最优。

#### 排序的选择 ####

**order by**： 全局排序，在hive中默认启动一个reducetask。  
**sort by** ： 局部排序，在每一个reducetask内部做排序。

eg:
        set reducetasks=3 
    在reducetask进行数据分配的时候，随机选择一个字段取hash值，然后 字段%3，但是这个字段是随机选取的。也就是说，假如有3行同样的数据：
        1   zs   f   23   cs   
        1   zs   f   23   cs    
        1   zs   f   23   cs  
    但它们可能分别进入 reducetask0，reducetask1，reducetask2。这样只能达到每一个reducetask内部是有序的，最终输出的数据达不到全局排序的效果。

**distribute by** 不管是 分桶 | 分组 | 分区，都是进行数据分配的。

eg： distribute by  name + sort by age
    reducetask在分配数据的时候，按照 name.hash  % 3得到不同的值进入不同的reducetask。
    这样，name相同的，一定会分到同一个reducetask中，name不同的分在不同的reducetask中。
    最终可以达到先按name进行分开数据，在相同的name中，按age顺序输出结果。

**cluster by**  
cluster by 后面只跟一个字段。  
cluster by 字段 = distribute by 字段 sort by 字段 （两个字段要统一）  
区别：

*  1）distribute by + sort by 的功能比 cluster by 要强大。cluster by 后面只能跟一个字段，而distribute by 和 sort by 后面可以跟不同的字段。
 *  2）cluster by 只能做升序排序，但distribute by 和 sort by 既可以升序也可以降序。

**总结：**能使用局部排序，就不要使用使用全局排序，因为局部排序会比全局排序效率会高很多。但局部排序注意数据倾斜。