IDEA的平衡了HDFS - > HBase的地图减少工作

对于客户端，我已经从范围界定上运行AWS EC2一个Cloudera的味道Hadoop集群的短期可行性。在大多数情况下，预期结果是逻辑卷的性能大部分不可靠，这就是说，尽我所能让群集在相应情况下运行得相当好。IDEA的平衡了HDFS - > HBase的地图减少工作

昨晚我跑了他们的进口商脚本的完整测试，可以从指定HDFS路径提取数据，并将其推入HBase的。他们的数据有点不寻常，因为记录少于1KB，并且已经凝聚成9MB的压缩块。所有总共有大约500K条文本记录从gzip中提取出来，进行完整性检查，然后进入reducer阶段。

作业运行在环境预期之内（我预计溢出记录的数量），但一个非常奇怪的问题是，当作业运行时，它运行8个reducer，但2个reducer执行99％的工作，同时剩下的6人做了一小部分工作。

我迄今为止未经测试的假设是，我在作业配置中缺少一个关键的洗牌或块大小设置，导致大部分数据被推入只能由2个reducer消耗的块中。不幸的是，上次我使用Hadoop时，另一个客户端的数据集在物理托管群集中的256GB lzo文件中。

为了澄清，我的问题;有没有一种方法可以调整M/R作业，以通过降低地图的输出大小或使每个缩减器减少将要解析的数据量来实际利用更多可用的缩减器。即使比目前的2减少4个改进将是一个重大改进。

来源

2011-10-21 David

好像你在你的减速器获得的热点。这可能是因为一个特定的键很受欢迎。作为映射器输出的关键是什么？

你有几个选择这里：

尝试更减速。有时候，你在散列的随机性中会产生奇怪的文物，所以有一些素数的减速器有时会有所帮助。这可能不会解决它。
编写一个定制的分区器，更好地分配工作。
找出为什么你的一堆数据被分为两个键。有没有办法让你的钥匙更独特的分裂工作？
有什么你可以用一个组合做，以减少交通要减速机量？

来源

2011-10-21 18:58:10

我需要通过客户端的参考地图挖/减少应用程序，但我认为（希望）键控问题可能是罪魁祸首。大约需要半个小时来启动群集并让它稳定（namenode safemode等），然后再运行/测试/验证几个小时，但是如果事实证明这是真的，我将回到一个答案检查中。 – David

结束写一个快速自定义M/R来弄清楚事情。客户端的导入是使用身份缩减器（来自hbase mapreduce包的股票没有扩展名），实际上其主键只有2个值。否则，记录中所有其他值的基数都是二进制或等于总记录集。我知道这是另外一个问题，但是你知道默认的hbase导入类是否可以将不同的密钥聚合为减少任务？ – David

IDEA的平衡了HDFS - > HBase的地图减少工作

回答

相关问题