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