本文主要是介绍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会生成随机数
这篇关于hive sql优化（全排序，笛卡尔积，exist in，决定reducer个数，合并MapReduce）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
