大数据面试必问Hive排序只用过order by?看看需知的这几种排序

我们经常有这样的需求，比如按照用户、访问时间进行排序，以便对排序后的数据进行一些计算，比如计算一个sessionID,计算页面访问的停留时间等。那在排序这个问题上如果只知道使用order by ，那在遇到大数据量时肯定会遇到问题。这篇文章我们就来看看hive排序的几种方式。

我们以查询测试表 webpv 为例， 有时间分区dt，三个主要字段：uid,pa,vdt,分别代表 ：用户ID,访问URL,访问时间

一、 order by

全局排序，因此，最终输出的reducer只有一个，默认设置了hive.exec.reducers.max=1。当数据量比较大时，会比较耗时。默认为asc。

select user_id,url,visit_time -- 用户ID,访问URL,访问时间

from webpv

where dt='2018-12-18'

order by visit_time

加上explain后查看执行计划，生成了两个Stage，第一个Stage为Mapreduce，第二个Stage为 Fetch Operator 获取数据。

在执行打印的日志中我们可以看到，只有一个reducers。

Hadoop job information for Stage-1: number of mappers: 3; number of reducers: 1

二、 sort by

在官方文档上有这么一句：Hive uses the columns in SORT BY to sort the rows before feeding the rows to a reducer

也就是说，sort by是在数据进入到reducer前，按照指定的字段对数据进行排序，所以sort by 排序不影响reducer数量。保证了在每个reducer里的是有序的，因此是局部有序。将order by visit_time，改为sort by user_id后，执行日志中可以看到：

Hadoop job information for Stage-1: number of mappers: 3; number of reducers: 5

可以看到有5个reducers,在每个reducers里会对user_id进行排序。如果将执行结果写入到hdfs中，可以看到会生成5个数据文件，每个文件中的uid是有序的。大家可能会有一个疑问，为什么会有3个mapper，而有5个reducers呢？后面我们会写篇文章进行分析。

值的注意的是，如果我们想查询排序后limit N获取前N行。当使用order by 时数据量太大导致执行时间太长，可以使用 sort by user_id limit N，查看执行计划，我们会发现，它首先执行MapReduce任务，在reducer阶段，对每个reducer的数据的user_id进行排序，排序后返回N条记录，发送到下个stage。这个stage再对M个reducer的M*N条记录收集后，再次进行排序以获取Top N条数据，最后在Fetch Operator的stage将结果返回。

三、 distribute by

按照指定字段，将相同值的数据分发一个reducer里，比如我们在语句后使用distribute by user_id,那么相同用户的访问数据，就会被发送到相同的reducer中。他可以结合sort by，比 如我们想按照每个用户进行的访问时间进行排序，正常我们会使用 order by user_id,visit_time，我们可以用 distribute by user_id sort by user_id asc,visit_time asc， distribute by user_id 保证了相同用户的访问数据会在一个reducer里处理，sort by user_id asc,visit_time asc 保证了在一个reducer里，数据会按照user_id ,visit_time 这两个字段进行排序。

四、 Cluster By

他其实就是distribute by和sort by组合使用，但是，他不能指定排序方式是asc和desc。

也就是说：cluster by user_id 等价于 distribute by user_id sort by user_id