hadoop - 识别 map/reduce 作业瓶颈的正确方法是什么？

Question

在正常的 java 开发中，如果我想提高应用程序的性能，我通常的过程是运行带有附加分析器的程序，或者在应用程序中嵌入一组检测标记。无论哪种情况，近期目标都是确定应用程序的热点，然后能够衡量我所做的更改的效果。

当应用程序是在 hadoop 集群中运行的 map/reduce 作业时，正确的类比是什么？

当作业的运行速度似乎比您在开发沙箱中运行等效逻辑所预测的慢时，有哪些选项可用于收集性能数据？

Answer 1

Map/Reduce 框架

在 Job-Tracker 中查看职位。在这里您将看到映射器和缩减器需要多长时间。一个常见的例子是，如果您在 reducer 中做了太多工作。在这种情况下，您会注意到映射器很快就完成了，而缩减器则需要很长时间。
查看您的所有映射器是否花费相似的时间也可能很有趣。也许这项工作被一些缓慢的任务耽搁了？这可能表明集群中存在硬件缺陷(在这种情况下，推测执行可能是答案)或者工作负载分布不均不够。

操作系统

观察节点(使用像 top 这样简单的东西，或者使用诸如 munin 或 ganglia 的监控)来查看你的工作是否是 cpu bound 或 io 绑定(bind)。例如，如果你的 reduce 阶段是 io bound，你可以增加你使用的 reducer 的数量。
当您的任务使用大量内存 时，您可能会在这里检测到其他情况。如果 tasktrackers 没有足够的 RAM，增加每个节点的任务数量实际上可能会损害性能。监控系统可能会突出显示生成的交换。

单一任务

您可以单独运行 Mapper/Reducer 进行分析。在这种情况下，您可以使用您已知的所有工具。
如果您认为只有在集群中执行作业时才会出现性能问题，您可以使用 System.nanoTime() 测量代码相关部分的时间并使用 System.outs 输出一些粗略的性能数据。
当然，也可以选择将 JVM 参数添加到子 JVM 并远程连接分析器。