2

最近我正在运行一些基准测试来了解 Giraph 中的故障转移机制。

其实我很好奇;当工作中的一个工人变慢时,其他工人只会等待它。后来我在GiraphJob.java

// Speculative execution doesn't make sense for Giraph
giraphConfiguration.setBoolean("mapred.map.tasks.speculative.execution", false);

有谁知道为什么 Giraph 中没有启用推测执行?

谢谢

4

1 回答 1

1

首先让我们想起什么是投机执行。引自Yahoo 的 Hadoop 教程

推测执行:Hadoop 系统的一个问题是,通过将任务划分到多个节点上,一些速度较慢的节点可能会限制程序其余部分的速率。例如,如果一个节点有一个慢速磁盘控制器,那么它读取其输入的速度可能仅为所有其他节点的 10%。所以当 99 个 map 任务已经完成时,系统还在等待最后一个 map 任务签入,这比其他所有节点花费的时间要长得多。通过强制任务彼此隔离运行,单个任务不知道它们的输入来自哪里。任务信任 Hadoop 平台来提供适当的输入。因此,相同的输入可以并行处理多次,以利用机器能力的差异。由于工作中的大部分任务即将结束,Hadoop 平台将在没有其他工作要执行的几个节点上安排剩余任务的冗余副本。这个过程被称为推测执行。当任务完成时,他们会向 JobTracker 宣布这一事实。无论哪个任务副本首先完成,都将成为最终副本。如果其他副本是推测性地执行,Hadoop 会告诉 TaskTracker 放弃任务并丢弃它们的输出。然后,Reducers 首先从成功完成的 Mapper 接收输入。默认情况下启用推测执行。您可以通过将 mapred.map.tasks.speculative.execution 和 mapred.reduce.tasks.speculative.execution JobConf 选项分别设置为 false 来禁用映射器和化简器的推测执行 他们向 JobTracker 宣布这一事实。无论哪个任务副本首先完成,都将成为最终副本。如果其他副本是推测性地执行,Hadoop 会告诉 TaskTracker 放弃任务并丢弃它们的输出。然后,Reducers 首先从成功完成的 Mapper 接收输入。默认情况下启用推测执行。您可以通过将 mapred.map.tasks.speculative.execution 和 mapred.reduce.tasks.speculative.execution JobConf 选项分别设置为 false 来禁用映射器和化简器的推测执行 他们向 JobTracker 宣布这一事实。无论哪个任务副本首先完成,都将成为最终副本。如果其他副本是推测性地执行,Hadoop 会告诉 TaskTracker 放弃任务并丢弃它们的输出。然后,Reducers 首先从成功完成的 Mapper 接收输入。默认情况下启用推测执行。您可以通过将 mapred.map.tasks.speculative.execution 和 mapred.reduce.tasks.speculative.execution JobConf 选项分别设置为 false 来禁用映射器和化简器的推测执行 然后,Reducers 首先从成功完成的 Mapper 接收输入。默认情况下启用推测执行。您可以通过将 mapred.map.tasks.speculative.execution 和 mapred.reduce.tasks.speculative.execution JobConf 选项分别设置为 false 来禁用映射器和化简器的推测执行 然后,Reducers 首先从成功完成的 Mapper 接收输入。默认情况下启用推测执行。您可以通过将 mapred.map.tasks.speculative.execution 和 mapred.reduce.tasks.speculative.execution JobConf 选项分别设置为 false 来禁用映射器和化简器的推测执行

如果 Giraph 正确,他们不会使用推测性执行,因为他们使用自己的迭代计算范式,但它不适合。这种范式的灵感来自 google 的 pregel,它提供了更多以图形节点为中心的数据视图。此外,容错是通过检查点创建的,这意味着每次迭代(也称为超级步)计算每个图节点的所有传入消息,然后将消息分布在节点之间。

简单地说 MapReduce 并没有以其原始方式使用,因此 giraph 的推测执行没有意义。

于 2014-10-27T10:33:08.470 回答