既然我一直遇到这个错误,如何优化这个表单的查询?或者想出更好的执行计划?如果我删除了substring子句,查询将正常工作,这表明这需要大量内存。
当作业失败时,直线输出显示堆空间。在线阅读建议我增加 export HADOOP_HEAPSIZE
但这仍然会导致错误。我尝试的另一件事是增加 hive.tez.container.size
以及 hive.tez.java.opts
(tez heap),但仍然有这个错误。在yarn日志中,可能会超出gc开销限制,这表明内存不足和/或查询计划效率极低,因为它无法收集回足够的内存。
我正在使用azure hdinsight interactive query 4.0。20个工作节点、d13v2 8核和56gb ram。
源表
create external table database.sourcetable(
a,
b,
c,
...
(183 total columns)
...
)
PARTITIONED BY (
W string,
X int,
Y string,
Z int
)
目标表
create external table database.NEWTABLE(
a,
b,
c,
...
(187 total columns)
...
W,
X,
Y,
Z
)
PARTITIONED BY (
aAAA,
bBBB
)
查询
insert overwrite table database.NEWTABLE partition(aAAA, bBBB, cCCC)
select
a,
b,
c,
...
(187 total columns)
...
W,
X,
Y,
Z,
cast(a as string) as aAAA,
from_unixtime(unix_timestamp(b,'yyMMdd'),'yyyyMMdd') as bBBB,
substring(upper(c),1,2) as cCCC
from database.sourcetable
2条答案
按热度按时间llycmphe1#
如果其他一切正常,请尝试在查询末尾添加distribute by partiton键:
因此,每个reducer只创建一个分区文件,占用的内存更少
d7v8vwbk2#
尝试对分区列进行排序:
启用时,动态分区列将被全局排序。这样我们就可以为reducer中的每个分区值只打开一个记录编写器,从而减少reducer的内存压力。
https://cwiki.apache.org/confluence/display/hive/configuration+properties