hadoop - 如何在 HBase 上配置 map reduce jobs

Question

我有一个在 HBase 表上运行的 map reduce 作业。它在应用一些扫描过滤器并进行一些处理后扫描 Hbase 表。

这项工作花费了很长时间，绝对比预期的要长得多，并且感觉性能下降是指数级的(即，前 90% 的完成速度比其余的快得多，大约 98%(映射器完成)之后，看起来像像电影开始时的 hell 边缘一样陷入永恒。

从高层来看，这种不均衡的性能应该没有任何理由，因为扫描中的每一行都应该有类似的行为，并且下游服务应该在 HBase 表的每一行都有类似的 SLA。

如何调试和分析此作业？是否有任何可用的工具可以帮助我对系统进行计量并查明行为异常的组件？

Answer 1

有多种方法可以监控和调试此类作业。

首先是查看 RegionServers、Datanodes 和 TaskTrackers 的日志，并尝试查找任何错误消息。 JobTracker 还将包含每个任务的性能明细，您可以查看是否有任何任务失败或被终止以及原因消息。这是最简单最直接的起点

根据我的经验，使用 HBase 的缓慢 MapReduce 作业表明您所在地区的 key 分布不均匀。对于 TableInputFormats，默认拆分是每个区域一个映射器，如果您的一个区域包含您正在访问的行数不均匀，或者如果特定 RegionServer 有多个区域被多个映射器读取，这可能会导致机器速度变慢，因为磁盘争用或网络 io。

要调试 RegionServers，您可以查看 JProfiler HBase Wiki 中提到了这一点作为他们使用的分析器。我从来没有用过它，但它确实有一个 HBase 探测。通过 uptime 或 top 的标准 CPU 负载和来自 iostat 指标的 IO 等待还可以让您确定哪些机器正在减慢速度。

如果您不想运行分析工具，您可以监控 RegionServer WebUI 并查看您是否有很多 RPC 请求在排队，或者它们是否需要很长时间，这是一个很容易获得的方法可解析的 JSON 格式。这将使您能够查明作业正在处理的特定区域的减速。

网络 IO 也可能是一个促成因素。如果您正在运行一个独立于 HBase 集群的 MapReduce 集群，那么所有数据都必须传送到 TaskTracker，因此这可能会使您的网络饱和。可以使用标准网络监控工具。

另一个问题可能只是与扫描器本身有关，根据我的经验，打开缓存 block 通常会损害 MR 作业期间的性能。这是因为缓存流失率很高，因为您通常在 MR 作业期间只读取一次行。此外，附加到扫描器的过滤器应用于服务器端，因此如果您进行复杂的过滤，可能会导致更高的延迟。