有人告诉我，count(distinct )可能会导致数据偏斜，因为只使用了一个reducer。
我用一个有50亿数据的表做了一个测试，有两个查询。
查询A:
select count(distinct columnA) from tableA
查询A： 查询B：
select count(columnA) from
(select columnA from tableA group by columnA) a
实际上，查询A需要1000 -1500秒，而查询B需要500 -900秒。这个结果似乎在意料之中。
但是，我意识到这两个查询都使用了 370 mappers 和 1 reducers 和他们几乎有相同的 same cumulative CPU seconds. 这意味着他们没有geneiune差异和时间差异可能造成的集群负载.
我很困惑，为什么所有的人都使用1 1减速器，我甚至尝试了 mapreduce.job.reduces 但却没有效果。另外，如果他们都使用1个减速器，为什么人们建议不要使用。count(distinct ) 而且似乎数据偏斜是无法避免的？
两个查询都使用了相同数量的映射器，这是预料之中的，而且只有一个最终的reducer，这也是预料之中的，因为你需要单个标量计数结果。同一个顶点上的多个reducer是独立运行的，是孤立的，每个reducer都会产生它自己的输出，这就是为什么最后阶段有单个reducer。不同的是在计划中。
在第一个查询执行中，单个减速器读取每个映射器的输出，并对所有数据进行独立的计数计算，它处理的数据太多。
第二个查询使用中间聚合，最终的reducer接收部分聚合的数据（上一步聚合的不同值），最终的reducer需要聚合部分结果。最终的reducer需要再次聚合部分结果以获得最终结果，它可能比第一种情况下的数据少得多。
从Hive 1.2.0开始，对count(distinct)进行了优化，你不需要重写查询。设置这个属性。hive.optimize.distinct.rewrite=true
另外还有mapper聚合（mapper也可以预聚合数据，并在他们的数据部分--split的范围内产生distinct值）设置这个属性，允许地图端聚合。hive.map.aggr=true
设置此属性，允许地图侧聚合： 解释 命令来检查执行计划的差异。