hive中怎么实现全排序

hive中怎么实现全排序，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

全排序

hive的排序关键字是SORT BY，它有意区别于传统数据库的ORDER BY也是为了强调两者的区别–SORT BY只能在单机范围内排序。

1.1.1     例1

set mapred.reduce.tasks=2;

原值

select cookie_id,page_id,id fromc02_clickstat_fatdt1

where cookie_idIN('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

hive> select cookie_id,page_id,id fromc02_clickstat_fatdt1 where

cookie_idIN('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 fromc02_clickstat_fatdt1

where cookie_idIN('1.193.131.218.1288611279693.0','1.193.148.164.1288609861509.2')

ORDER BY PAGE_ID,COOKIE_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

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 fromc02_clickstat_fatdt1 where cookie_idIN('1.193.131.218.1288611279693.0','1.193.148.164.1288609861509.2')  distribute by cookie_id SORT BYCOOKIE_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

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

1.1.2     例2

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

使用DISTRIBUTE BY关键字指定分发key为sale_id。改造后的HQL如下：

set mapred.reduce.tasks=2;

Select sale_id, amount from t_order

Distribute by sale_id

Sort by sale_id, amount;

这样能够保证查询的销售记录集合中，销售ID对应的数量是正确排序的，但是销售ID不能正确排序，原因是hive使用hadoop默认的HashPartitioner分发数据。

这就涉及到一个全排序的问题。解决的办法无外乎两种：

1.) 不分发数据，使用单个reducer：

set mapred.reduce.tasks=1;

这一方法的缺陷在于reduce端成为了性能瓶颈，而且在数据量大的情况下一般都无法得到结果。但是实践中这仍然是最常用的方法，原因是通常排序的查询是为了得到排名靠前的若干结果，因此可以用limit子句大大减少数据量。使用limit n后，传输到reduce端（单机）的数据记录数就减少到n* （map个数）。

2.) 修改Partitioner，这种方法可以做到全排序。这里可以使用Hadoop自带的TotalOrderPartitioner（来自于Yahoo!的TeraSort项目），这是一个为了支持跨reducer分发有序数据开发的Partitioner，它需要一个SequenceFile格式的文件指定分发的数据区间。如果我们已经生成了这一文件（存储在/tmp/range_key_list，分成100个reducer），可以将上述查询改写为

set mapred.reduce.tasks=100;

set hive.mapred.partitioner=org.apache.hadoop.mapred.lib.TotalOrderPartitioner;

settotal.order.partitioner.path=/tmp/ range_key_list;

Select sale_id, amount from t_order

Cluster by sale_id

Sort by amount;

有很多种方法生成这一区间文件（例如hadoop自带的o.a.h.mapreduce.lib.partition.InputSampler工具）。这里介绍用Hive生成的方法，例如有一个按id有序的t_sale表：

CREATE TABLE if not exists t_sale (

id int,

name string,

loc string

);

则生成按sale_id分发的区间文件的方法是：

create external tablerange_keys(sale_id int)

row format serde

'org.apache.hadoop.hive.serde2.binarysortable.BinarySortableSerDe'

stored as

inputformat

'org.apache.hadoop.mapred.TextInputFormat'

outputformat

'org.apache.hadoop.hive.ql.io.HiveNullValueSequenceFileOutputFormat'

location '/tmp/range_key_list';

insert overwrite table range_keys

select distinct sale_id

from source t_salesampletable(BUCKET 100 OUT OF 100 ON rand()) s

sort by sale_id;

生成的文件（/tmp/range_key_list目录下）可以让TotalOrderPartitioner按sale_id有序地分发reduce处理的数据。区间文件需要考虑的主要问题是数据分发的均衡性，这有赖于对数据深入的理解。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注亿速云行业资讯频道，感谢您对亿速云的支持。