hive性能调优
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亿数据。
2：优化的常用手段
· 好的模型设计事半功倍。
· 解决数据倾斜问题。
· 减少job数。
· 设置合理的map reduce的task数，能有效提升性能。(比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够)。
· 了解数据分布，自己动手解决数据倾斜问题是个不错的选择。set hive.groupby.skewindata=true;这是通用的算法优化，但算法优化有时不能适应特定业务背景，开发人员了解业务，了解数据，可以通过业务逻辑精确有效的解决数据倾斜问题。
· 数据量较大的情况下，慎用count(distinct)，count(distinct)容易产生倾斜问题。
· 对小文件进行合并，是行至有效的提高调度效率的方法，假如所有的作业设置合理的文件数，对云梯的整体调度效率也会产生积极的正向影响。
· 优化时把握整体，单个作业最优不如整体最优。
3：全排序
Hive的排序关键字是SORT BY，它有意区别于传统数据库的ORDER BY也是为了强调两者的区别–SORT BY只能在单机范围内排序。
order by 以及 sort by distribute by cluster by
order by 语句 和数据库中的一样 会对结果集执行一个全局排序 但是 如果是全局排序的话 那么所有的数据 必须通过
一个reduce进行处理 就是说 用Order by 必须保证只有一个reduce 任何情况下 都不会出现多个reduce 那么 程序
运行的性能就会下降 非常容易出现数据倾斜的问题
体会一下:
set mapred.reduce.tasks = 3;
select count(*) from emp group by deptno; 用了3个reduce
select ename,sal from emp order by sal desc;
总结一下 什么情况下 我们不管如何设置reduce的个数 但他总是1
1. order by
2. 没有group by 的汇总 比如 selct max(sal) from emp; 比如 select count(1) from emp;有group by的汇总
有几个group by的列 就要有几个reduce
3.笛卡尔积
因为我们用order by只有一个reduce 非常容易出现数据倾斜 所以 如果我们添加了这个属性
set hive.mapred.mode = strict;
如果我们直接做排序 他不会让我们通过 select * from emp order by sal desc;
必须要加 Limit select * from emp order by sal desc limit
