Hive 的一些优化方法

最新推荐文章于 2021-02-23 16:42:09 发布

IT小鸟鸟

最新推荐文章于 2021-02-23 16:42:09 发布

阅读量302

点赞数

分类专栏： hive 文章标签： mapreduce hive 大数据

本文链接：https://blog.csdn.net/u013111855/article/details/106266965

版权

hive 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

Hive 的一些优化方法

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 既可以升序也可以降序。

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