9. 优化
9.1 HADOOP计算框架特性
数据量大不是问题，数据倾斜是个问题。
? jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次汇总，产生十几个jobs，耗时很长。原因是map reduce作业初始化的时间是比较长的。
? sum,count,max,min等UDAF，不怕数据倾斜问题,hadoop在map端的汇总合并优化，使数据倾斜不成问题。
? count(distinct ),在数据量大的情况下，效率较低，如果是多
count(distinct )效率更低，因为count(distinct)是按group by 字段分组，按distinct字段排序，一般这种分布方式是很倾斜的，比如男uv,女uv，淘宝一天30亿的pv，如果按性别分组，分配2个reduce,每个reduce处理15亿数据。
?
9.2 优化的常用手段
? ? ? ? ?
? ? ?
好的模型设计事半功倍。
解决数据倾斜问题。 减少job数。
设置合理的map reduce的task数，能有效提升性能。(比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够)。
了解数据分布，自己动手解决数据倾斜问题是个不错的选择。set hive.groupby.skewindata=true;这是通用的算法优化，但算法优化有时不能适应特定业务背景，开发人员了解业务，了解数据，可以通过业务逻辑精确有效的解决数据倾斜问题。
数据量较大的情况下，慎用count(distinct)，count(distinct)容易产生倾斜问题。 对小文件进行合并，是行至有效的提高调度效率的方法，假如所有的作业设置合理的文件数，对云梯的整体调度效率也会产生积极的正向影响。 优化时把握整体，单个作业最优不如整体最优。
9.3 HIVE查询优化
Hive查询的优化：
一、数据量大的表和数据量小的表做关联的时候，把数据量小的表放到join前面去select。 原因是在 Join 操作的 Reduce 阶段，位于 Join 操作符左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生内存溢出错误的几率。
51
二、Join优化
Join查找操作中如果存在多个join，且所有参与join的表中其参与join的key都相同，则会将所有的join合并到一个mapred程序中。 例：
SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1) 在一个mapre程序中执行join
SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key2) 在两个mapred程序中执行join
Map join的关键在于join操作中的某个表的数据量很小 例：
SELECT /*+ MAPJOIN(b) */ a.key, a.value FROM a join b on a.key = b.key
三、用sum() group by的方式来替换count(distinct)。
四、排序优化
Order by 实现全局排序，一个reduce实现，效率低 Sort by 实现部分有序，单个reduce输出的结果是有序的，效率高，通常和DISTRIBUTE BY关键字一起使用（DISTRIBUTE BY关键字 可以指定map 到 reduce端的分发key） CLUSTER BY col1 等价于DISTRIBUTE BY col1 SORT BY col1.
五、合并小文件
文件数目过多，会给 HDFS 带来压力，并且会影响处理效率，可以通过合并 Map 和 Reduce 的结果文件来尽量消除这样的影响
hive.merge.mapfiles = true是否和并 Map 输出文件，默认为 True
hive.merge.mapredfiles = false是否合并 Reduce 输出文件，默认为 False hive.merge.size.per.task = 256*1000*1000合并文件的大小。
这里的参数没有写到上面的表格里是因为这是可以根据任务不同临时设置的，而不一定非要是全局设置。有时候全局设置了反而对大文件的操作有性能影响。 六、使用分区，RCFile，lzo，ORCFile等
Hive中的每个分区都对应hdfs上的一个目录，分区列也不是表中的一个实际的字段，而是一个或者多个伪列，在表的数据文件中实际上并不保存分区列的信息与数据。Partition关键字中排在前面的为主分区（只有一个），后面的为副分区
静态分区：静态分区在加载数据和使用时都需要在sql语句中指定 例：(stat_date='20120625',province='hunan')
动态分区：使用动态分区需要设置hive.exec.dynamic.partition参数值为true，默认值为false，在默认情况下，hive会假设主分区时静态分区，副分区使用动态分区；如果想都使用动态分区，需要设置set hive.exec.dynamic.partition.mode=nostrick，默认为strick 例：(stat_date='20120625',province)
52
七、使用外部表而尽量少用内部表，这主要从数据的安全性上考量。
9.4 全排序
Hive的排序关键字是SORT BY，它有意区别于传统数据库的ORDER BY也是为了强调两者的区别–SORT BY只能在单机范围内排序。
9.4.1 例1
set mapred.reduce.tasks=2; 原值
select cookie_id,page_id,id from c02_clickstat_fatdt1
where cookie_id
IN('1.193.131.218.1288611279693.0','1.193.148.164.1288609861509.2') 1.193.148.164.1288609861509.2
113181412886099008861288609901078194082403 684000005 1.193.148.164.1288609861509.2
127001128860563972141288609859828580660473 684000015 1.193.148.164.1288609861509.2
113181412886099165721288609915890452725326 684000018 1.193.131.218.1288611279693.0
01c183da6e4bc50712881288611540109914561053 684000114 1.193.131.218.1288611279693.0
01c183da6e4bc22412881288611414343558274174 684000118 1.193.131.218.1288611279693.0
01c183da6e4bc50712881288611511781996667988 684000121 1.193.131.218.1288611279693.0
01c183da6e4bc22412881288611523640691739999 684000126 1.193.131.218.1288611279693.0
01c183da6e4bc50712881288611540109914561053 684000128
53
hive> select cookie_id,page_id,id from c02_clickstat_fatdt1 where cookie_id
IN('1.193.131.218.1288611279693.0','1.193.148.164.1288609861509.2') SORT BY COOKIE_ID,PAGE_ID; SORT排序后的值
1.193.131.218.1288611279693.0 684000118 01c183da6e4bc22412881288611414343558274174 684000118 1.193.131.218.1288611279693.0 684000114 01c183da6e4bc50712881288611540109914561053 684000114 1.193.131.218.1288611279693.0 684000128 01c183da6e4bc50712881288611540109914561053 684000128 1.193.148.164.1288609861509.2 684000005 113181412886099008861288609901078194082403 684000005 1.193.148.164.1288609861509.2 684000018 113181412886099165721288609915890452725326 684000018 1.193.131.218.1288611279693.0 684000126 01c183da6e4bc22412881288611523640691739999 684000126 1.193.131.218.1288611279693.0 684000121 01c183da6e4bc50712881288611511781996667988 684000121 1.193.148.164.1288609861509.2 684000015 127001128860563972141288609859828580660473 684000015
select cookie_id,page_id,id from c02_clickstat_fatdt1
where cookie_id
IN('1.193.131.218.1288611279693.0','1.193.148.164.1288609861509.2') ORDER BY PAGE_ID,COOKIE_ID;
54
1.193.131.218.1288611279693.0 684000118 01c183da6e4bc22412881288611414343558274174 684000118 1.193.131.218.1288611279693.0 684000126 01c183da6e4bc22412881288611523640691739999 684000126 1.193.131.218.1288611279693.0 684000121 01c183da6e4bc50712881288611511781996667988 684000121 1.193.131.218.1288611279693.0 684000114 01c183da6e4bc50712881288611540109914561053 684000114 1.193.131.218.1288611279693.0 684000128 01c183da6e4bc50712881288611540109914561053 684000128 1.193.148.164.1288609861509.2 684000005 113181412886099008861288609901078194082403 684000005 1.193.148.164.1288609861509.2 684000018 113181412886099165721288609915890452725326 684000018 1.193.148.164.1288609861509.2 684000015 127001128860563972141288609859828580660473 684000015
可以看到SORT和ORDER排序出来的值不一样。一开始我指定了2个reduce进行数据分发(各自进行排序)。结果不一样的主要原因是上述查询没有reduce key，hive会生成随机数作为reduce key。这样的话输入记录也随机地被分发到不同reducer机器上去了。为了保证reducer之间没有重复的cookie_id记录，可以使用DISTRIBUTE BY关键字指定分发key为cookie_id。
select cookie_id,country,id,page_id,id from c02_clickstat_fatdt1 where cookie_id
IN('1.193.131.218.1288611279693.0','1.193.148.164.1288609861509.2') distribute by cookie_id SORT BY COOKIE_ID,page_id; 1.193.131.218.1288611279693.0 684000118 01c183da6e4bc22412881288611414343558274174 684000118 1.193.131.218.1288611279693.0 684000126 01c183da6e4bc22412881288611523640691739999 684000126 1.193.131.218.1288611279693.0 684000121 01c183da6e4bc50712881288611511781996667988 684000121 1.193.131.218.1288611279693.0 684000114 01c183da6e4bc50712881288611540109914561053 684000114
55
Hive用户手册)_中文版
