我有一个impala内部表，它在一些列上进行了分区，我想在一些字段（包括分区列）上执行group by，基本上我的查询如下所示：
select market, col1, count(1) from mytable group by market, col1“市场”是划分栏。
然后我得到“超出内存限制”，但是如果我发出这样的查询：
select market, col1, count(1) from mytable where market='US' group by market, col1然后我得到了没有记忆问题的结果。
所以在我看来，在impala中，当分区列位于'where'子句中时，分区修剪确实会发生，但当它们位于'groupby'中时，分区修剪就不起作用了，对吗？如果我的假设是正确的，那么我会感到震惊，因为分区列上的groupby只是为hdfs子目录运行groupby。
以下是我运行第一个查询时impala配置文件消息的开头：
Estimated Per-Host Requirements: Memory=7.59TB VCores=2
F02:PLAN FRAGMENT [UNPARTITIONED] 04:EXCHANGE [UNPARTITIONED]
hosts=39 per-host-mem=unavailable
tuple-ids=1 row-size=133B cardinality=28530506252
F01:PLAN FRAGMENT [HASH(market,col1)] DATASTREAM SINK [FRAGMENT=F02, EXCHANGE=04, UNPARTITIONED] 03:AGGREGATE [FINALIZE] | output: count:merge(1) | group by: market, col1 | hosts=39 per-host-mem=3.80TB | tuple-ids=1 row-size=133B cardinality=28530506252 | 02:EXCHANGE [HASH(market,col1)]
hosts=39 per-host-mem=0B
tuple-ids=1 row-size=133B cardinality=28530506252
F00:PLAN FRAGMENT [RANDOM] DATASTREAM SINK [FRAGMENT=F01, EXCHANGE=02, HASH(market,col1)] 01:AGGREGATE | output: count(1) | group by: market, col1 | hosts=39 per-host-mem=3.80TB | tuple-ids=1 row-size=133B cardinality=28530506252 | 00:SCAN HDFS [mytable, RANDOM]
partitions=5057/5057 files=5397 size=207.71GB
table stats: 28530506252 rows total
column stats: all
hosts=39 per-host-mem=384.00MB
tuple-ids=0 row-size=125B cardinality=28530506252
1条答案
按热度按时间tcomlyy61#
它不会发生，因为使用
WHERE实际上，您限制了impala必须对其执行操作的组的数量。在cloudera官方文档中，您可以发现：
group by位于唯一或高基数列上。impala为group by查询中的每个不同值分配一些处理程序结构。拥有数百万个不同的分组值可能会超过内存限制。
事实上，这段文档被放在了“什么是内存最密集的操作”一节中。
在这一点上，我认为您可以与管理员交谈，并要求改进节点上的内存（但老实说，我不知道如何检查哪些节点的内存不足，以便执行该操作），或者您可以尝试编写一个更智能的查询，可以使用外部表或视图。