Hadoop 配置单元中分区列上Group By的性能

我有一个4列的表，其中col4作为配置单元中的分区列。这是一个巨大的表，每5小时插入约9M行。我有一个限制，我不能更改此表的设计，因为它也用于其他报告

CREATE EXTERNAL TABLE testdb.table1(col1 string, col2 int, col3 int)
PARTITIONED BY (col4 string)
ROW FORMAT DELIMITED
STORED AS TEXTFILE
LOCATION '/path/to/input/';

对于其中一个用例，我尝试创建一个查找表，以标识col4中每个值的一些数据点，如

select col1, col4 from testdb.table1 group by col1, col4;

问题：

在分区列上执行GROUPBY操作会影响性能吗？在这种情况下是Col4

当我在col4上进行分组时，它仍然是一个完整的表扫描吗

使用最小的全表扫描在分区列上创建查找的最佳方法是什么

我偶然发现了这个，但它是给黑斑羚的。我不确定Impala和Hive是否在内部使用相同的MR引擎进行数据处理。因此，将此作为一个新问题发布

打开映射器端聚合以获得最佳性能：

设置hive.map.aggr=true

并将性能与分区列和非分区列进行比较。在分区列的情况下，数据已经部分分组（文件属于单个分区），地图端聚合将执行得更快一些，因为映射程序将每个创建更少的组，并且将更少的数据传递给还原程序。换句话说，执行聚合所需的所有记录都在单个分区内，每个文件只包含一个组（如果按非分区列分组，则也包含少数组）。但是过度分区可能会导致文件过多和性能下降

如果查询需要完全扫描，为什么不应该是完全扫描？是的，它肯定是完全扫描的，因为您没有WHERE子句，并且选择了not only partition列

全表扫描意味着没有分区修剪。在分区列上添加WHERE条件以限制分区。如果在查询中只使用分区列，从技术上讲，它只能使用元数据，但这种情况很少见，并且与您的查询不同

如果在WHERE子句中使用partition，则可以从分区中获得最大的好处

在加载压缩文件和ORC表时使用分区和DISTRIBUTE+SORT，可以显著减少压缩文件的大小（2倍甚至更多），但我从未注意到它带来了显著的性能提升。
感谢您的详细解释。我已经在为我的查询使用hive.map.aggr=true。此外，im还增加了还原器的数量。您能否解释一下“执行聚合所需的所有记录都在单个分区内，每个文件只包含一个组（如果按非分区列分组，则也包含少量组）。”@underwood这意味着映射程序将处理相同的组，并生成更小大小的部分预聚合数据，这些数据将更快地复制到还原程序中，处理也更快。@leftjoin我目前正在检查与“分组方式”一起使用的分区的性能优势，您声明：
对于分区列，数据已经部分分组（文件属于单个分区）
——但是“属于单个分区”并不意味着属于同一节点，因为分区只是一个虚拟HDFS文件夹。同一分区内的文件可能分散在集群中。那么，聚合一个分区有什么好处呢？啊，我想我已经开始理解它了。在上面的
col1、col4
示例中，映射器已经知道
col4
在其块中只有一个值，因此如果我们使用聚合，那么映射器只需为
col1
查找不同的值，并将它们与
col4
的单个值组合。在非分区表中，映射器必须找到
col1
和
col4
的不同值。因此，分区数据上的聚合速度更快，为还原程序生成的输入量更少。