Hadoop tez/蜂巢中的OOM

[经过几次回答和评论后，我根据此处获得的知识提出了一个新问题：]

我的一个查询始终失败，出现以下错误：

ERROR : Status: Failed
ERROR : Vertex failed, vertexName=Map 1, vertexId=vertex_1516602562532_3606_2_03, diagnostics=[Task failed, taskId=task_1516602562532_3606_2_03_000001, diagnostics=[TaskAttempt 0 failed, info=[Container container_e113_1516602562532_3606_01_000008 finished with diagnostics set to [Container failed, exitCode=255. Exception from container-launch.
Container id: container_e113_1516602562532_3606_01_000008
Exit code: 255
Stack trace: ExitCodeException exitCode=255: 
    at org.apache.hadoop.util.Shell.runCommand(Shell.java:933)
    at org.apache.hadoop.util.Shell.run(Shell.java:844)
    at org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:1123)
    at org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor.launchContainer(DefaultContainerExecutor.java:237)
    at org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch.call(ContainerLaunch.java:317)
    at org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch.call(ContainerLaunch.java:83)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

Container exited with a non-zero exit code 255
]], TaskAttempt 1 failed, info=[Error: Failure while running task:java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap space
    at org.apache.hadoop.hive.ql.exec.tez.TezProcessor.initializeAndRunProcessor(TezProcessor.java:173)

这里的关键字似乎是java.lang.OutOfMemoryError:java堆空间

我环顾四周，但我认为我从Tez那里了解到的一切都无助于我：

​Thread site/Thread.nodemanager.resource.memory-mb已达到最大值=>我使用了我能使用的所有内存 纱线站点/warn.scheduler.maximum-allocation-mb：与warn.nodemanager.resource.memory-mb相同 纱线站点/warn.scheduler.minimum-allocation-mb=1024 配置单元站点/hive.tez.container.size=4096纱线的倍数.scheduler.minimum-allocation-mb ​我的查询有4个映射器，3个非常快，第4个每次都会消失。以下是查询的Tez图形视图：

从该图像中：

table contact有150M行，283GB的ORC压缩数据有一个大的json字段，横向视图 表m有1M行、20MB的ORC压缩数据 表c有2k行，<1MB ORC压缩 表e有800k行，7GB ORC压缩 e与所有其他表连接在一起 e和contact是分区的，在WHERE子句中只选择了一个分区

因此，我试图增加地图的数量：

tez.grouping.max-size：默认情况下为650MB，即使我将其降低到- tez.grouping.min-size​ 16MB没有区别 tez.grouping.split-count即使增加到1000也没有什么区别 默认情况下，tez.grouping.split-wave 1.7，即使增加到5也没有区别 如果相关，以下是一些其他内存设置：

mapred站点/mapreduce.map.memory.mb=1024最小容器大小 mapred站点/mapreduce.reduce.memory.mb=2048 2*最小容器大小 mapred site/mapreduce.map.java.opts=819 0.8*最小容器大小 mapred site/mapreduce.reduce.java.opts=1638 0.8*mapreduce.reduce.memory.mb mapred站点/warn.app.mapreduce.am.resource.mb=2048 2*最小容器大小 mapred站点/warn.app.mapreduce.am.command-opts=1638 0.8*warn.app.mapreduce.am.resource.mb mapred站点/mapreduce.task.io.sort.mb=409 0.4*最小容器大小 我的理解是，tez可以将工作分成许多部分，因此需要很长时间，但最终还是完成了。​是我错了，还是我没有找到一条路

---

上下文：hdp2.6，8个数据节点，32GB内存，使用基于json的粗块横向视图通过直线运行进行查询。

问题显然是由于数据倾斜。我建议您将distributedbycol添加到selectqueryfromsource中，以便reducer具有均匀分布的数据。在下面的示例中，COL3是分布更均匀的数据，如ID列 范例

---

我也有同样的问题，增加所有的内存参数都没有帮助

然后我切换到MR，得到下面的错误

Failed with exception Number of dynamic partitions created is 2795, which is more than 1000.

---

设置了更高的值后，我返回到tez，问题就解决了。

如果您将表转换为使用ORC格式并进行Snappy压缩，该怎么办？@cricket\u 007这已经是我的表的存储方式。好的。。。没有什么能阻止您使用HiveI转换为另一种格式，我会尽快尝试，但快速问：您能解释清楚吗？很明显，数据是倾斜的，但是你怎么猜呢？只是猜测：你说：我的查询有4个映射器，3个非常快，第4个每次都会消失。。这已经是一个关于不均匀分布的数据的陈述了。@ThomasKettenbach谢谢-我在问题中添加了一个查询的图形视图。正如您所看到的，失败的地图是由于缺乏更好的措辞而导致的其他地图的组合。不确定是否可以通过这种方式看到偏斜？我第一次尝试使用distribute by也产生了同样的问题。添加distribute by.Hi@Guillaume后，我没有看到任何变化，从图中我了解到查询被转换为MAPJOIN。您可以尝试将set hive.auto.convert.join.noconditionaltask=false；，如果您可以尝试此方法，我们可以确定问题是因为您正在尝试映射连接一个非常大的数据集。

Failed with exception Number of dynamic partitions created is 2795, which is more than 1000.