hadoop - 什么时候在hadoop mapreduce作业上以交互方式增加/减少节点数是一个好主意？

Question

我的直觉是增加/减少
在运行作业中交互式地处理节点数可以加快 map 处理的速度
工作，但无助于减少工作繁重的繁重工作
通过减少。

对此有一个常见问题，但并不能很好地解释

http://aws.amazon.com/elasticmapreduce/faqs/#cluster-18

Answer 1

克里斯托弗·史密斯(Christopher Smith)回答了这个问题，他允许我在这里发帖。

一如既往...“取决于”。您几乎总可以数的一件事
on:以后添加节点并不会像
从开始的节点。

创建Hadoop作业时，它会分成多个任务。这些
任务实际上是“工作的基础”。 Hadoop让您调整＃
作业创建过程中映射器和化简任务的数量，但是一旦作业完成
创建后，它是静态的。任务分配给“插槽”。传统上，
每个节点配置为具有一定数量的插槽用于映射
任务，以及用于 reduce task 的一定数量的插槽，但是您可以
调整。某些较新版本的Hadoop不需要您
将插槽指定为 map 或缩小任务。反正
JobTracker定期将任务分配给插槽。因为完成了
动态地，新节点联机可以加快处理
通过提供更多插槽来执行任务来完成工作。

这为了解添加新节点的现实性奠定了基础。
显然，有一个阿姆达尔定律的问题，即插槽数量多于
待处理任务几乎无法完成(如果您具有推测执行力
启用后，确实有一定帮助，因为Hadoop会安排相同的任务
可以在许多不同的节点上运行，以便可以将慢速节点的任务
如果有备用资源，则由更快的节点完成)。所以，如果你
没有用很多 map 或 reduce task 来定义您的工作，而是增加了更多
节点不会有太大帮助。当然，每个任务都需要一些
开销，所以您也不想发疯。这就是为什么我
建议任务大小的准则应该是“
大约需要2-5分钟才能执行”。

当然，当您动态添加节点时，它们彼此之间
缺点:他们在本地没有任何数据。显然，如果你在
EMR管道的开始，所有节点中都没有数据，因此
没关系，但是如果您有由许多工作组成的EMR管道，
通过早期的工作将其结果保存到HDFS，您将获得巨大的 yield
性能提升，因为JobTracker将偏爱整形和
分配任务，使节点具有可爱的数据局部性(这是一个
整个MapReduce设计的核心技巧以最大化性能)。上
reducer 方面，数据来自其他 map task ，因此动态
与其他节点相比，添加的节点确实没有任何缺点。

因此，原则上，实际上不太可能动态添加新节点
帮助处理从HDFS读取的IO绑定(bind) map task 。

除了...

Hadoop有多种秘诀可进行优化
性能。一旦开始将 map 输出数据传输到
映射任务完成之前/化简器开始/化简。这个
显然，对于映射器的工作而言，这是至关重要的优化
产生大量数据您可以在Hadoop开始时进行调整
转移。无论如何，这意味着新启动的节点可能是
这是不利的，因为现有节点可能已经具有
巨大的数据优势。显然，映射器的输出越多
已经传播，缺点更大。

这就是它真正起作用的方式。不过在实践中，很多Hadoop
作业使映射器以CPU密集型方式处理大量数据，
但只输出很少的数据给reducer(或者他们
可能会向 reducer 发送大量数据，但是 reducer 仍然
非常简单，因此完全不受CPU限制)。通常工作很少
(有时甚至为0)reduce任务，因此，即使有额外的节点也可以提供帮助
您已经有一个还原槽可用于每个出色的还原
任务，新节点无济于事。新节点也可以不成比例地提供帮助
显然，由于CPU限制工作，所以
做 map task 比 reduce task 更多，这是人们通常看到的地方
胜利。如果您的映射器受I / O约束，并从
网络，添加新节点显然会增加总带宽
集群，因此对它有帮助，但是如果您的映射任务受I / O约束
读取HDFS时，最好的方法是拥有更多初始节点和数据
已经遍布HDFS。 reducer 获得I / O并不少见
由于工作结构不良而束缚，在这种情况下增加了更多
节点可以提供很多帮助，因为它再次分配了带宽。

当然也有一个警告:对于非常小的集群，
reducer 可以从运行在其中的映射器读取很多数据
本地节点，添加更多节点会将更多数据转移到
停下来慢得多的网络。您也可能遇到以下情况
还原器将大部分时间都花在多路复用数据处理上
从所有发送它们的映射器发送的数据(尽管可以将其调整为
好)。

如果您要问这样的问题，我强烈建议您进行剖析
您可以使用亚马逊提供的KarmaSphere之类的产品来工作。它
可以让您更好地了解瓶颈所在以及什么
是提高性能的最佳策略。