Shuffle阶段持续时间过长Hadoop

Question

我有一个MR工作，其中洗牌阶段持续时间太长。

起初我认为这是因为我从Mapper发出大量数据（大约5GB）。然后我通过添加一个Combiner修复了这个问题，从而向Reducer发送了更少的数据。在那之后，洗牌时间没有缩短，正如我想的那样。

我的下一个想法是通过组合Mapper本身来消除Combiner。我从here获得了这个想法，它说数据需要序列化/反序列化才能使用Combiner。不幸的是，洗牌阶段仍然是一样的。

我唯一想到的可能是因为我使用的是单个Reducer。但这不应该是一个例子，因为我在使用Combiner或在Mapper中组合时不会发出大量数据。

以下是我的统计数据：

以下是我的Hadoop（YARN）工作的所有计数器：

我还应该补充说，这是在4台机器的小型集群上运行。每个都有8GB的RAM（保留2GB），虚拟核心数为12（保留2个）。

这些是虚拟机。起初他们都在一个单位，但后来我把他们分成两个单位2-2。所以他们最初共享硬盘，现在每个磁盘有两台机器。它们之间是一个千兆网络。

以下是更多统计数据：

占用整个内存

在作业运行时CPU始终处于压力之下（图片显示连续两次运行相同作业的CPU）

我的问题是 - 为什么洗牌时间如此之大以及如何解决？即使我大大减少了Mapper发出的数据量，我也不明白为什么没有加速？

Answer 1

很少有观察结果：

1. 对于30分钟的作业，GC时间太长（尝试重复使用对象而不是为map（）/ Reduce（）方法中的每个调用创建一个新对象）
2. 平均地图时间是TOOOOO hight，16分钟你在你的地图做什么？
3. YARN内存为99％，这表示您在HDP群集上运行的服务太多而RAM并不足以支持这些服务。
4. 请增加YAN容器内存，请至少提供1 GB。
5. 这看起来像是GC +过度调度的群集问题