为什么投机执行对 Giraph 没有意义？答案

【问题标题】：Why is Speculative execution doesn't make sense for Giraph?为什么投机执行对 Giraph 没有意义？
【发布时间】：2014-10-27 08:12:41
【问题描述】：

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

其实我很好奇；当工作中的一个工人变慢时，其他工人只会等待它。后来我在GiraphJob.java找到了这样的东西：

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

有人知道为什么 Giraph 中没有启用推测执行吗？

谢谢

【问题讨论】：

标签： java apache hadoop giraph

【解决方案1】：

首先让我们回想一下什么是推测执行。引用自Yahoo's Hadoop tutorial：

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

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

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

【讨论】：

这是有道理的，在 BSP 的旧文献中（尤其是工作窃取），建议使用投机执行。为什么？因为一个落后的任务可以完全延迟整个超级步（计算回滚也是如此）。这是 Giraph 消息传递模型的限制，仅此而已。
我只是想确定一下。在这种情况下，迭代计算的意思是：Giraph 必须迭代地处理它的每个顶点。因此，如果在 Giraph 中启用了推测执行，那么它将违反 Giraph 的规则，处理不按顺序的事情。正确的？如果启用推测执行会发生什么？会不会造成不一致？
@Vincentius：我不确定我是否正确。但请注意，Giraph 不是迭代地处理顶点，而是它的算法步骤。对于这些步骤中的每一个，图中的每个节点（简单地说）都会分析它的传入消息。这是对每个节点异步并行完成的。启用推测执行根本没有意义，因为 Giraph 无法使用它。