Hive优化--关键参数及HQL案例

 

1.      关键参数及HQL案例

1.1.    当输入数据量较大时减小Map处理的最大数据量

已知表midsrc有1.5亿条记录,如下:

分别设置map处理最大数据量为1024000000、512000000、256000000、128000000观察以下语句的执行情况。

统计信息如下:

Map处理的最大数据量

Mapper数

执行时长(秒)

1024000000

5

117.098

512000000

9

67.62

256000000

17

52.739

128000000

33

49.971

    可以看到:随着map处理最大数据量变小,map数逐渐增大,整体效率提升。在最大数据量从256000000到128000000时,差别已经不大了。

 

1.2.    当大量重复数据做去重时减少Reduce数量

已知文本表hugest有9.5亿条记录,如下:

使用Hive默认参数执行以下语句查询不重复的记录。

共启动105个mapper,110个reducer,耗时137.394秒。

最终发现仅有三条不重复记录,由于map端已聚合,可推测reducer只要一个就够了,会大大减少reduce阶段耗时。

设置以下参数后再次执行语句。

共启动105个mapper,1个reducer,耗时98.524秒,效果明显。

 

1.3.    当大量匹配记录做关联时增加Reduce数量

已知表dynhuge和dynhuge1有784万条记录,使用Hive默认参数执行以下语句关联两表并将数据导入表tmp。

    共启动2个mapper,1个reducer,耗时10个小时左右。

    观察发现由于两表关联字段seq存在很多相同值,关联产生巨大的数据,一个reducer处理起来非常慢,按照当前集群和租户的能力,最大可启动56个container,因此考虑设置reducer个数为50。

设置以下参数后再次执行语句。

共启动2个mapper,50个reducer,耗时16分钟,效果明显。

 

1.4.    当出现Join倾斜时打开Join倾斜优化开关

表skewtable有392329条记录,表unskewtable有129927条记录。

使用Hive默认参数执行以下语句:

启动一个MR,耗时215.742秒,同时主要耗费在reduce阶段。

经统计,发现表skewtable有记录A的数量131650,表unskewtable有记录A的数量449,可知两表关联将会出现一定的数据倾斜。

设置join倾斜优化开关,再次执行如下:

    启动了两个MR,总耗时157.494秒,单独启动一个MR处理了倾斜数据后,效率提升了。

 

1.5.    Join和Group By的字段一致时打开相关性优化开关

表log有305872条记录,表logcopy有295825条记录。

使用Hive默认参数执行以下语句:

启动了两个MR,总耗时64.59秒

由于join的字段和group by字段均为key,可以利用相关性优化,减少MR个数从而提高运行速度。

设置以下参数后,再次执行:

只启动一个MR,总耗时32.678秒。

 

1.6.    Join字段和参与Join的子查询的Group By的字段一致时打开相关性优化开关

表log有305872条记录,表logcopy有295825条记录。

使用Hive默认参数执行以下语句:

启动了三个MR,总耗时98.714秒。

由于子查询的group by字段和join字段一致,可以利用相关性优化,减少MR个数从而提高运行速度。

设置以下参数后,再次执行:

只启动一个MR,耗时33.855秒,效果明显。

 

1.7.    Count(Distinct)优化

ORC表orctbl有78914976条记录,表大小1.6G。

使用Hive默认参数执行以下语句:

由于是全聚合,只启动一个MR,总耗时295.997秒。

    优化后可以将reduce数增大(测试集群可启动的container数为51),执行如下:

启动了两个MR,总耗时198.123秒。

 

1.8.    使用Mutiple Insert优化

表src有500条记录。

分别执行插入操作,第一个插入操作如下:

第一个插入操作耗时30.536秒。

第二个插入操作如下:

第二个插入操作总耗时26.257秒。

两个SQL分别启动两个MR,共耗时56.793秒。

优化如下:

只启动一个MR,耗时27.187秒,效果提升明显。

 

1.9.    当大量表参与Join时改用MR

如下场景,需要将用户信息表USER与INDICT_1、INDICT_2、INDICT_3、INDICT_4、INDICT_5等一定数量的指标表进行关联,目标是汇总用户的所有指标到一个新的用户指标表,一方面SQL比较冗长,另一方面由于多次join性能较低。同时后续还需要加入更多同类型的指标表参与连接,届时还需要修改SQL才能完成相应功能。

   了解业务需求后,考虑使用直接编写MR实现,MAP的输入为用户信息表USER及所有指标表的目录下的文件,MAP输出为用户ID、指标值,REDUCE输入为用户ID、指标值序列,REDUCE输出为用户ID和按顺序排列的指标值,落地成结果文件。MR程序能做到指标可配置(可配置文件目录名与指标名的映射),扩展性好(不断新增指标只需改配置文件,无须修改代码/SQL),效率更高(一个MR完成指标汇总的所有功能)。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值