hadoop - 对于大型Mapreduce作业，以及一些挥之不去的 reducer ，可以安全地缩小尺寸吗？

Question

克里斯·史密斯(Chris Smith)回答了这个问题，并说我可以发表。

如果您有200个节点的mapreduce作业，而只有3个运行reduce作业
留在身边，关闭除主节点以外的所有节点是否安全？
和3个正在运行的工作？
再加上少数几个坏节点需要更换的情况？

如果对这个问题的回答是"is"，那么奇怪的是，emr没有
当大多数节点不在时，它们会自动关闭
使用。

最近有一些工作大部分完成了，但有一些
减少挥之不去。我认为这使我们付出了代价，因为不使用
节点保持。

我可以想到以下这些问题:

-何时将数据复制到S3？如果没有使用某个节点
运行reduce的过程，是否仍需要将其复制到S3？在那里面
的情况下，回答我的问题是，从根本上讲，您永远都不会安全切换
离节点
-如果3个工作之一失败了怎么办？硕士/职位协调员应
将其重新分配给另一个节点。我想你只要安全就可以
跟踪出现了哪些框，而不是错误地分配给
已关闭。

Answer 1

If you have a 200-node mapreduce job, with just 3 running reduce jobs left lingering, is it safe to switch off all nodes except the master and the 3 with the running jobs? Plus maybe a handful more in case of a bad node needing replacement?

If the answer to this question is "yes" it's strange that emr doesn't automatically turn off most of the nodes nodes when they're not in use.

请记住，EMR是Hadoop上非常薄的一层。如果您要在Amazon的架构上进行分布式计算，则可以通过针对其特定需求进行自定义的功能来提高TON的效率，而这些功能根本不会真正类似于Hadoop或Map / Reduce。如果您在Hadoop上进行了大量工作，那么通常最好使用自己的集群，或者至少使用云中的专用集群(这样，数据就已经在本地磁盘上进行了分片，而输出只需要保留到本地磁盘)。 EMR的主要优点是它既快速又脏，并且可以很好地连接到AWS的其他部分(例如S3)。

Lately there's been several jobs that mostly finished, but with a few reduces lingering. I think this is costing us since the not-in-use nodes stay up.

这绝对是在花费您的钱，尤其是在运行时方面。首先，我要担心完成时间为何如此不一致。

There are these issues I can think of:

-- when does data get copied to S3? If a node is not in use in terms of running reduce, could it still be needed for copying to S3? In that case, answer to my question is you're basicaly never safe to switch off nodes

如果您指的是作业的输出，如果您将S3作为作业配置的输出路径，则来自给定任务的数据将在任务退出之前写到S3。

-- what happens if one of 3 jobs fails? Master/job coordinator should reassign it to another node. I guess you're safe as long as it can keep track of what boxes are up, and not wrongly assign to a box that has been shut off.

好吧……这要复杂得多……当为新节点分配作业时，它必须从某处提取数据。那通常是由首先生成数据的映射器生成的。如果不再存在，则可能需要重新运行 map task (或更可能是:作业将失败)。通常，映射输出上的复制因子为1，因此这是完全合理的情况。这是Hadoop作业可以让其“完成百分比”向后退的几个原因之一……映射器甚至可以从100％退回到<100％。

与此相关:可以想象，根据那些化简作业所处的阶段，它们还没有收到所有反馈给它们的 map 输出。显然，在这种情况下，杀死错误的映射器是致命的。

我认为重要的是要强调仅使脱机TaskTracker节点与运行TaskTracker + DataNode服务的节点之间的区别。如果您不仅仅使用后者，那么您将失去HDFS中的数据块，这通常对您的工作不是一件好事(除非您真的不将HDFS用于分发工作以外的任何事情)。您可以一次起飞几个节点，然后运行一个重新平衡器以“鼓励” HDFS使所有块的复制因子恢复到3。当然，这会触发网络流量和磁盘I / O，这可能会减慢剩余的任务。

tl; dr:杀死节点可能有问题。尽管您可以确信已完成的任务(将其输出写入S3)在通知JobTracker任务已完成时已完全写出其所有输出，但对于映射任务却不能这么说。移到其本地目录，然后异步将数据传输到 reducer 。即使所有映射输出都已转移到其目标Reducer，如果Reducer失败(或者推测性执行触发另一个节点上的任务分解)，您仍然需要邮寄这些其他节点，因为Hadoop可能会转向他们用于重新分配的 reducer 的输入数据。

-
克里斯

附言对于非EMR Hadoop设置来说，这实际上也可能是一个很大的痛点(与其支付比所需时间更长的节点费用，还不如说是因为节点在您可能正在做的工作时处于闲置状态，以及大量的计算时间损失由于节点故障)。通常，避免问题的技巧是:保持任务大小相当一致并保持在1-5分钟范围内，启用推测性执行(在EMR世界中，节点性能几乎是一致的，这是至关重要的)，保持复制因素远远超过给定作业的预期节点损失(取决于节点的可靠性，一旦您用一天多的时间运行超过400个节点，就开始考虑复制因子4)，并使用允许新作业的作业调度程序在旧工作仍然完成时开始(这些天通常是默认设置，但这是〜Hadoop 0.20 IIRC引入的全新事物)。我什至听说过一些疯狂的事情，例如将SSD用作贴图目录(尽管它们在所有写入操作中都可能很快耗尽，但它们的故障情况对Hadoop作业的灾难性影响较小)。