《细细品味hadoop_hadoop集群(第14期副刊)_hive性能优化》由会员分享，可在线阅读，更多相关《细细品味hadoop_hadoop集群(第14期副刊)_hive性能优化（22页珍藏版）》请在金锄头文库上搜索。
1、 细细品味 Hadoop Hadoop 集群 （第集群 （第 14 期期副刊副刊） 精 华 集 锦 csAxp 虾皮工作室 http:/ 2013 年 7 月 10 日 创建时间：2012/3/29 修改时间：2012/3/29 修改次数：0 Hadoop 集群（第集群（第 14 期副刊）期副刊） Hive 性能优化 1、性能低下根源、性能低下根源 Hive 性能优化时，把 HiveQL 当做 Map/Reduce 程序来读，即从 Map/Reduce 的运行角 度来考虑优化性能， 从更底层思考如何优化运算性能， 而不仅仅局限于逻辑代码的替换层面。 RAC（Real Application C
2、luster）真正应用集群真正应用集群就像一辆机动灵活的小货车，响应快， Hadoop 就像吞吐量巨大的轮船，启动开销大，如果每次只做小数量的输入输出，利用率将 会很低。所以用好 Hadoop 的首要任务首要任务是增大增大每次任务每次任务所搭载的数据量数据量。 Hadoop 的核心能力核心能力是 pariton 和 sort，因而这也是优化的根本优化的根本。 观察 Hadoop 处理数据处理数据的过程，有几个显著的特征特征： 数据数据的大规模大规模并不是不是负载重点负载重点，造成运行压力过大是因为运行数据运行数据的倾斜倾斜。 jobs 数数比较多比较多的作业运行效率运行效率相对比较低比较低，比
3、如即使有几百行的表，如果多次关 联多次汇总，产生十几个 jobs，将会须要 30 分钟以上的时间且大部分时间被用于 作业分配，初始化和数据输出。Map/Reduce 作业初始化作业初始化的时间时间是比较耗费时间比较耗费时间资 源的一个部分。 在使用 sum，count，max，min 等函数时，Hadoop Map 端对表中数据的汇总去重汇总去重， 能有效有效的解决数据倾斜解决数据倾斜问题。 count（distinct）效率效率较低较低，因为容易产生容易产生数据倾斜数据倾斜问题，如果是多 count（distinct） 效率更低。 数据倾斜数据倾斜是导致效率大幅降低效率大幅降低的主要原因主要
4、原因，可以采用多一次多一次 Map/Reduce 的方法， 避免倾斜。 结论结论：避实就虚，用 job 数的增加，输入量的增加，占用更多存储空间，充分利用空闲 CPU 等各种方法，分解数据倾斜造成的负担。 2、从配置角度优化、从配置角度优化 Hive 系统内部已针对不同的查询预设定了优化方法，用户可以通过调整配置进行控制， 以下举例介绍部分优化的策略以及优化控制选项。 2.1 列裁剪列裁剪 Hive 在读数据读数据的时候，可以只读只读取查询中所需要用到所需要用到的列列，而忽略其它列。 例如，若有以下查询： Select a,b From Q Where e对， ， 。河北工业大学软件工程与理论
5、实验室 整理：虾皮 6创建时间：2012/3/29 修改时间：2012/3/29 修改次数：0 所以商品表的 HDFS 读取只会是一次。 3.5 解决解决Hive对对union all优化的短板优化的短板 Hive 对 union all 的优化的特性：对 union all 优化只局限于非嵌套查询。 消灭子查询内的消灭子查询内的 group by 示例 1：子查询内有 group by Select * From (Select * From t1 Group By c1,c2,c3 Union All Select * From t2 Group By c1,c2,c3)t3 Group
6、By c1,c2,c3 从业务逻辑上说，子查询内的 group by 怎么都看显得多余（功能上的多余，除非有 count(distinct)） ，如果不是因为 Hive Bug 或者性能上的考量（曾经出现如果不执行子查询 group by，数据得不到正确的结果的 Hive Bug） 。所以这个 Hive 按经验转换成如下所示： Select * From (Select * From t1 Union All Select * From t2)t3 Group By c1,c2,c3 调优结果调优结果：经过测试，并未出现 union all 的 Hive Bug，数据是一致的。MapReduc
7、e 的 作业数由 3 减少到 1。 t1 相当于一个目录，t2 相当于一个目录，对 Map/Reduce 程序来说，t1，t2 可以作为 Map/Reduce 作业的 mutli inputs。这可以通过一个 Map/Reduce 来解决这个问题。Hadoop 的 计算框架，不怕不怕数据多数据多，就怕就怕作业数多作业数多。 但如果换成是其他计算平台如 Oracle，那就不一定了，因为把大的输入拆成两个输入， 分别排序汇总后 merge（假如两个子排序是并行的话） ，是有可能性能更优的（比如希尔排 序比冒泡排序的性能更优） 。 消灭子查询内的 count(distinct)，max，min。 S
8、elect * From (Select * From t1 Union All Select c1,c2,c3 count(disintct c4) From t2 Group By c1,c2,c3) t3 Group By c1,c2,c3; 由于子查询里头有 count(distinct)操作，直接去 group by 将达不到业务目标。这时采用 临时表消灭 count(distinct)作业不但能解决倾斜问题，还能有效减少 jobs。 Insert t4 Select c1,c2,c3,c4 From t2 Group By c1,c2,c3; Select c1,c2,c3,sum
9、(income),sum(uv) From (Select c1,c2,c3,income,0 as uv From t1 Union All Select c1,c2,c3,0 as income,1 as uv From t2) t3 Group By c1,c2,c3; 河北工业大学软件工程与理论实验室 整理：虾皮 7创建时间：2012/3/29 修改时间：2012/3/29 修改次数：0 job 数是 2，减少一半，而且两次 Map/Reduce 比 count(distinct)效率更高。 调优结果调优结果：千万级别的类目表，member 表，与 10 亿级得商品表关联。原先 196
10、3S 的 任务经过调整，1152S 即完成。 消灭子查询内的消灭子查询内的 join Select * From (Select * From t1 Uion All Select * From t4 Union All Select * From t2 Join t3 On t2.id=t3.id) x Group By c1,c2; 上面代码运行会有 5 个 jobs。加入先 join 生存临时表的话 t5，然后 union all，会变成 2 个 jobs。 Insert OverWrite Table t5 Select * From t2 Join t3 On t2.id=t3.id
11、; Select * From (t1 Union All t4 Union All t5); 调优结果调优结果：针对千万级别的广告位表，由原先 5 个 Job 共 15 分钟，分解为 2 个 Job 一 个 8-10 分钟，一个 3 分钟。 3.6 利用利用group by替代替代count(distinct)达到优化效果达到优化效果 计算 uv 的时候，经常会用到 count(distinct)，但在数据比较倾斜的时候 count(distinct) 会比较慢。这时可以尝试用 group by 改写代码计算 uv。 原有代码原有代码 Insert OverWrite Table s_dw_
12、tanx_adzone_uv Partition (ds=20120329) Select 20120329 As thedate,adzoneid,count(distinct acookie) As uv From s_ods_log_tanx_pv t Where t.ds=20120329 Group By adzoneid 进度结果表进度结果表 A 时钟时钟 Map 进度进度 Reduce 进度进度 12:17:43,940 Map=100% Reduce=99% 12:18:20,305 Map=100% Reduce=100% 12:19:22,727 Map=100% Redu
13、ce=100% 12:20:23,061 Map=100% Reduce=100% 12:21:23,757 Map=100% Reduce=100% 12:22:24,448 Map=100% Reduce=100% 12:23:25,482 Map=100% Reduce=100% 从表 A 可以看出数据倾斜的比较厉害。总共耗时 689S，最后 100%这里花了 300S。 group by 改写代码改写代码 河北工业大学软件工程与理论实验室 整理：虾皮 8创建时间：2012/3/29 修改时间：2012/3/29 修改次数：0 Insert OverWrite Table s_dw_ta
14、nx_adzone_uv Partition(ds=20120329) Select 20120329 As thedate,adzoneid,count(1) As uv From s_ods_log_tanx_pv Where ds=20120329 Group By adzoneid,acookie) t Group By adzoneid; 进度结果表进度结果表 B 时钟时钟 Map 进度进度 Reduce 进度进度 12:19:59,457 Map=100% Reduce=94% 12:20:19,092 Map=100% Reduce=97% 12:20:36,883 Map=10
15、0% Reduce=98% 12:20:56:002 Map=100% Reduce=100% 从表 B 看出， 总耗时 483 秒， 虽然 jobs 比原来多个一个， 但任务执行时间反而少了 206S， 性能提升近 30%。 麻烦的地方在于需要改写代码逻辑，工作量会上去。修改如下所示。 Set hive.groupby.skewindata=true; Insert OverWrite Table s_dw_tanx_adzone_uv Partition(ds=20120329) Select 20120329 As thedate,adzoneid,count(distinct acookie) As uv From s_ods_log_tanx_pv t Where t.ds=20120329 Group By adzoneid 采用“hive.groupby.skewindata=true” ，Hive 会自动多做一次 Map/Reduce 以解决数据 倾斜的情况。性能会比“group by 改写代码”要慢点，而且 jobs 会原有程序的 2 倍。 好处在于不用改写代码。 这个优化的主要思路是：对于数据量比较大，可能产生倾斜的数据采用“group by 改写 代码”的方式会比较好些。性能相对比较稳定，不会因为数据倾斜导致性能问题。 采用“set hi
