performance - 平衡 HDFS -> HBase mapreduce 作业的想法

Question

对于客户，我一直在研究在 AWS EC2 上运行 Cloudera 风格的 hadoop 集群的短期可行性。在大多数情况下，结果是预期的，逻辑卷的性能大多不可靠，也就是说尽我所能让集群在这种情况下运行得相当好。

昨晚我对他们的导入程序脚本进行了全面测试，以从指定的 HDFS 路径中提取数据并将其推送到 Hbase。他们的数据有些不同寻常，因为记录小于 1KB，并且被压缩到 9MB 的 gzip block 中。总共有大约 50 万条文本记录从 gzip 中提取出来，经过完整性检查，然后推送到 reducer 阶段。

作业在环境的预期范围内运行(溢出记录的数量是我预料到的)但是一个非常奇怪的问题是当作业运行时，它使用 8 个 reducer 运行，但 2 个 reducer 完成 99% 的工作，而剩下的 6 个只做一小部分工作。

我迄今为止未经检验的假设是，我在作业配置中遗漏了一个关键的混洗或 block 大小设置，这导致大部分数据被推送到只能由 2 个 reducer 使用的 block 中。不幸的是，上次我在 Hadoop 上工作时，另一个客户的数据集位于物理托管集群上的 256GB lzo 文件中。

澄清一下，我的问题；有没有一种方法可以通过降低映射的输出大小或使每个缩减器减少它将解析的数据量来调整 M/R 作业以实际利用更多可用的缩减器。即使在当前的 2 个 reducer 基础上再增加 4 个 reducer 也是一项重大改进。

Answer 1

看来您的 reducer 中出现了热点。这可能是因为某个特定的 key 非常受欢迎。作为映射器输出的键是什么？

这里有几个选项:

• 尝试更多 reducer 。有时，您会在散列的随机性中得到奇怪的伪像，因此拥有质数的 reducer 有时会有所帮助。这可能无法解决问题。
• 编写自定义分区程序以更好地分散工作。
• 弄清楚为什么您的大量数据被分为两个键。有没有办法让您的 key 更加独特以拆分工作？
• 您可以使用组合器做些什么来减少流向 reducer 的流量吗？