如果您有一个200节点的mapreduce作业，只剩下3个正在运行的reduce作业，那么关闭除主节点和3个正在运行的作业之外的所有节点是否安全？如果坏节点需要更换，还可以再加一把？
如果这个问题的答案是“是”，那么奇怪的是，当大多数节点不在使用时，emr不会自动关闭它们。
请记住，emr是hadoop上非常薄的一层。如果您在amazon的结构上进行分布式计算，那么您可以更高效地使用一些针对特定需求定制的东西，而这些东西根本不像hadoop或map/reduce。如果您正在使用hadoop做大量繁重的工作，那么您最好使用自己的集群，或者至少使用云中的专用集群（这样数据就已经在本地磁盘上切片，输出只需要持久化到本地磁盘）。emr的主要优点是它快速而脏，可以很好地与aws的其他部分（如s3）相连接。
最近有好几项工作基本完成了，但仍有一些工作没有完成。我认为这是我们的成本，因为没有使用的节点保持不变。
它无疑会让你付出代价，特别是在运行时间方面。我首先要关心的是为什么完成时间如此不统一。
我能想到这些问题：
--数据何时复制到s3？如果一个节点在运行reduce时没有被使用，那么复制到s3还需要它吗？在这种情况下，我的问题的答案是你基本上永远不会安全关闭节点
如果引用的是作业的输出，如果将s3作为作业配置的输出路径，则给定任务的数据将在任务退出之前写入s3。
--如果三个作业中有一个失败了怎么办？主/作业协调员应将其重新分配给另一个节点。我想你是安全的，只要它能跟踪什么盒子在上面，而不是错误地分配给一个已经关闭的盒子。
好。。。比这复杂一点。。。当新节点被分配任务时，它必须从某处提取数据。它通常来自于最初生成数据的Map绘制者。如果它们不再存在，则可能需要重新运行map任务（或者更可能：作业将失败）。通常，map输出上的复制因子是1，因此这是一个完全合理的场景。这是为什么hadoop作业可以使其“%complete”倒退的几个原因之一。。。Map绘制者甚至可以从100%返回到<100%。
与此相关：可以想象的是，根据减速器作业所处的阶段，它们尚未接收到所有提供给它们的map输出。显然，在这种情况下，杀死错误的Map绘制者是致命的。
我认为强调仅使用tasktracker节点离线与运行tasktracker+datanode服务的节点离线之间的区别是很重要的。如果你使用了超过两个后者，你会在hdfs中丢失块，这对你的工作来说通常不是一件好事（除非你真的不使用hdfs来分配你的工作）。您可以一次去掉几个节点，然后运行一个重新平衡程序来“鼓励”hdfs将所有块的复制因子恢复到3。当然，这会触发网络流量和磁盘i/o，这可能会降低剩余任务的速度。
热释光；dr:杀死节点可能会有问题。虽然您可以确信一个已完成的任务（将其输出写入s3）在jobtracker收到任务已完成的通知时已经完全写出了其所有输出，但对于map任务却不能这样说，map任务会写出其本地目录并将数据异步传输到reducer。即使所有的map输出都被传输到了它们的目标reducer，如果reducer失败（或者推测性执行触发了另一个节点上任务的旋转），那么mail确实需要这些其他节点，因为hadoop可能会向它们请求重新分配reducer的输入数据。
--克里斯
p、 对于非emr hadoop设置来说，这实际上也是一个很大的痛点（与其为超过需要的时间的节点付费，不如说是当节点有工作要做时，节点处于空闲状态，还有由于节点故障造成的大量计算时间损失）。作为一般规则，避免问题的技巧是：保持任务大小相当一致，并且在1-5分钟的范围内，启用推测性执行（在节点性能不一致的emr世界中，这一点非常重要），保持复制因子远高于给定作业的预期节点损失（取决于节点可靠性，一旦一天作业运行超过400个节点，就开始考虑复制因子为4），使用一个作业调度程序，允许新的作业启动，而旧的作业仍在完成（现在这通常是默认的，但它是一个全新的东西引入~hadoop0.20iirc）。我甚至听说过一些疯狂的事情，比如使用ssd来Mapdir（虽然它们在所有的写操作中都会很快耗尽，但对于hadoop作业来说，它们的失败场景往往不会那么灾难性）。