我有一个在 HBase 表上运行的 map reduce 作业。它在应用一些扫描过滤器并进行一些处理后扫描 Hbase 表。
这项工作需要很长时间，肯定比预期的要多得多，并且感觉性能下降是指数级的（即，前 90% 的完成速度比其余的快得多，大约 98% 之后（映射器完成），似乎像电影开场中的地狱一样陷入永恒。
从高层次来看，这种不平衡的性能应该没有理由，因为扫描中的每一行都应该表现相似，并且下游服务应该在 HBase 表的每一行中都有相似的 SLA。
如何调试和分析此作业？是否有任何可用的工具可以帮助我测量系统并查明行为不端的组件？
【问题讨论】：
有几种方法可以监控和调试此类作业。
首先是查看 RegionServers、Datanodes 和 TaskTracker 的日志并尝试查找任何错误消息。 JobTracker 还将包含每个任务的性能细分，您可以查看是否有任何任务失败或被杀死以及原因的消息。这是最简单最直接的起点
根据我的经验，使用 HBase 的缓慢 MapReduce 作业表明您所在区域的密钥分布不均匀。对于 TableInputFormats，默认拆分是每个区域一个映射器，如果您的一个区域包含您正在访问的奇数行数，或者如果特定 RegionServer 有多个区域正在被多个映射器读取，这可能会导致机器速度变慢，因为磁盘争用或网络 io。
对于调试 RegionServers，您可以查看JProfiler，HBase Wiki 中提到了他们使用的分析器。我从未使用过它，但它确实有一个 HBase 探针。通过 uptime 或 top 的标准 CPU 负载和来自 iostat 指标的 IO 等待还可以让您确定哪些机器正在减慢速度。
如果您不想运行分析工具，您可以监控 RegionServer WebUI 并查看是否有大量 RPC 请求排队或花费很长时间，这很容易可解析的 JSON 格式。这将允许您查明您的工作正在处理的特定区域的减速。
网络 IO 也可能是一个促成因素。如果您正在运行与 HBase 集群分开的 MapReduce 集群，那么所有数据都必须传送到 TaskTracker，这样可能会使您的网络饱和。可以使用标准的网络监控工具。
另一个问题可能只是扫描器本身，根据我的经验，打开缓存块通常会损害 MR 作业期间的性能。这是因为高速缓存流失率很高，因为您通常在 MR 作业期间只读取一次行。此外，附加到扫描器的过滤器是在服务器端应用的，因此如果您执行复杂的过滤可能会导致更高的延迟。
【讨论】：