时间比较赶，简单记录下：
问题描述：一开始我一个拉链表查一条数据，select *from chain_table_name where id='XXX'
最后出现： map 99%，Reduce 0%，就不再执行了，也咩有结果。
解决方案：
set hive.map.aggr = true;
select *from chain_table_name where id='XXX';
这就解决了。
总结:搜了下 ，这就是数据倾斜。
链接：
hive数据倾斜
hive数据倾斜原因分析及解决方案
http://www.aboutyun.com/thread-8296-1-1.html
Hive 数据倾斜总结
http://www.aboutyun.com/thread-8241-1-1.html
hive卡住不动，并非数据倾斜，这个是什么原因
http://www.aboutyun.com/thread-10037-1-1.html
4总结----先保留链接一部分内容
使map的输出数据更均匀的分布到reduce中去，是我们的最终目标。由于Hash算法的局限性，按key Hash会或多或少的造成数据倾斜。大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的。在此给出较为通用的步骤：
1、采样log表，哪些user_id比较倾斜，得到一个结果表tmp1。由于对计算框架来说，所有的数据过来，他都是不知道数据分布情况的，所以采样是并不可少的。
2、数据的分布符合社会学统计规则，贫富不均。倾斜的key不会太多，就像一个社会的富人不多，奇特的人不多一样。所以tmp1记录数会很少。把tmp1和users做map join生成tmp2,把tmp2读到distribute file cache。这是一个map过程。
3、map读入users和log，假如记录来自log,则检查user_id是否在tmp2里，如果是，输出到本地文件a,否则生成<user_id,value>的key,value对，假如记录来自member,生成<user_id,value>的key,value对，进入reduce阶段。
4、最终把a文件，把Stage3 reduce阶段输出的文件合并起写到hdfs。
如果确认业务需要这样倾斜的逻辑，考虑以下的优化方案：
1、对于join，在判断小表不大于1G的情况下，使用map join
2、对于group by或distinct，设定 hive.groupby.skewindata=true
3、尽量使用上述的SQL语句调节进行优化