hive sql优化（全排序，笛卡尔积，exist in，决定reducer个数，合并MapReduce）

hive 全排序 优化
分类： hive hadoop hadoop 2013-01-28 20:11 717人阅读 评论(0) 收藏 举报
hive hadoop
目录(?)[+]
使用Hive可以高效而又快速地编写复杂的MapReduce查询逻辑。但是某些情况下，因为不熟悉数据特性，或没有遵循Hive的优化约定，Hive计算任务会变得非常低效，甚至无法得到结果。一个”好”的Hive程序仍然需要对Hive运行机制有深入的了解。

有一些大家比较熟悉的优化约定包括：Join中需要将大表写在靠右的位置；尽量使用UDF而不是transfrom……诸如此类。下面讨论5个性能和逻辑相关的问题，帮助你写出更好的Hive程序。

全排序
Hive的排序关键字是SORT BY，它有意区别于传统数据库的ORDER BY也是为了强调两者的区别–SORT BY只能在单机范围内排序。考虑以下表定义：

CREATE TABLE if not exists t_order(

id int, -- 订单编号

sale_id int, -- 销售ID

customer_id int, -- 客户ID

product _id int, -- 产品ID

amount int -- 数量

) PARTITIONED BY (ds STRING);
在表中查询所有销售记录，并按照销售ID和数量排序：

set mapred.reduce.tasks=2;

Select sale_id, amount from t_order

Sort by sale_id, amount;
这一查询可能得到非期望的排序。指定的2个reducer分发到的数据可能是（各自排序）：

Reducer1：

Sale_id | amount

0 | 100

1 | 30

1 | 50

2 | 20
Reducer2：

Sale_id | amount

0 | 110

0 | 120

3 | 50

4 | 20
因为上述查询没有reduce key，hive会生成随机数