hadoop - 在Hadoop Emr上使用Hadoop来处理> 10TB的输入是否可行？

Question

大型mapreduce工作(加入14
输入目录，总共加起来大约14TB的输入)失败。不
我们只能不能做我们的工作。当我们刚刚做 map 是猫/减少是
猫，我们什至无法完成。复制它似乎停滞了
数据。

我们的猜测是我们正在饱和hadoop-on-emr的容量
由aws提供。不确定我们是否饱和网络或磁盘
空间，还是什么。我们会收到这样的错误

“减少>复制(438094 of 436094，速度为0.10 MB / s)”

在hadoop控制面板上。它只是卡在那里，从未完成
复制。另一个理论是hadoop的离线分类发生在
与复制同时进行，这在某种程度上是一个瓶颈。我们已经尝试过
更多化简器，更多节点，不同大小的各种排列
工作箱，但不知何故我们找不到组合
起作用了。

由于我们迫切需要完成此任务，因此我们正在解决
这是将数据划分为较小的作业。也就是说，每14个
输入年份将被分割，然后我们将加入分区。

有没有人有使用aws托管的hadoop来处理这种规模或更大规模的工作的经验，如果是这样，您能否就仅获得cat map / cat reduce的成功提供建议？像节点数，节点大小和配置选项一样？

否则，我想我们正在达到emr的局限性。

Answer 1

克里斯·史密斯(Chris Smith)回答了这个问题，并说我可以将其发布到SO。他的回答:

因此，输入数据的大小本身并不是对EMR的限制。还有很多其他因素。

也就是说，吸收10TB的数据是一项艰巨的任务。仅仅读取那么多数据是非常残酷的，然后就需要进行存储/分类。

第一个问题是:约束因素是什么？您是否看到网络带宽已用尽？您是否看到CPU已满？磁盘I / O或iops？这些在数据节点上的外观如何？那么JobTracker和NameNodes呢(在剩余的剩余时间里将它们最大化)是不寻常的
集群很好)？如果以上都不是，则可能是Hadoop资源已被耗尽，需要进行不同的配置。

由于您没有提到争用的任何特定方面，超出了它处于哪个阶段，这使我怀疑您没有太多衡量下面发生的情况的方式。通常，在调整一项重要工作之前，您需要多次“测量然后调整”。

根据一般经验，长时间处于“减少/复制”阶段非常有力地表明“您做错了”。通常，问题是您陷入了排序/溢出/合并过程，节点以某种方式使磁盘IO最大化。 Hadoop具有许多调整参数，这些参数对于具有大量映射器和化简器的作业开始变得古怪，尤其是在两者之间存在很大的不平衡时。同样，Karmasphere和类似工具可以在这里为您提供很多帮助。需要调整的典型事项(我可能对某些名称有误):

正在记录。特别是，像dfs.namenode.logging.level之类的内容对于作业前的调整可能很重要。用冗长的日志记录完全有可能自杀。尽管自相矛盾，它也可能是您的救赎，所以...

map 输出大小通常是“减少/复制”问题的关键因素。尽可能考虑减少 map 输出大小的方法。它实际上应该比 map 输入大小小得多。删除还原阶段严格不需要的所有数据。考虑使用紧凑的二进制序列化格式(Java序列化会降低您的性能)，例如 Protocol Buffer 或节俭(整数数据大获成功)。考虑您的字符串在多大程度上可以用ID /枚举表示。您可以使用组合器来减少必须通过网络发送多少数据吗？如果您有多余的CPU，请使用压缩功能(从lzo或snappy开始，但是如果仍有更多CPU需要刻录，请考虑使用gzip甚至是更强大的功能)。如果您仍然在 map task 日志中看到合并步骤需要很长时间，则可以做一些调整:

io.sort.factor:可能应该更高。根据您的工作情况，您甚至可能遭受过多的映射器的困扰。 io.sort.mb:与io.sort.factor密切相关，但有所不同。如果您开始在节点上看到很多磁盘I / O压力，我会解决这个问题。这会消耗内存，因此此参数涉及实际折衷。

mapred.job.reuse.jvm.num.tasks:仅当您的任务变得非常小时，但如果任务确实很小，则值得提高mapred.reduce.parallel.copies:如果您的CPU不受限制，那么您可能想要增加这个数字。您可能最终需要调整其他数字以平衡情况。

io.sort.record.percent:由于工作规模，该百分比是最不可能完全脱离标准的。通常，如果这是错误的，那是因为您拥有很大或很小的记录。您想要达到的黄金分割率是“16 /(16 +每条记录的字节数)”。

很难强调早期残酷的溢出对节点性能的影响。如果溢出，则意味着数据将被写出，然后再次读取，然后再次写出。在每个节点上。因此，如果您错了，添加更多节点无济于事(实际上可以做到这一点)
更差)。您想查看一份工作溢出了多少记录以及输出了多少张 map 记录。理想情况下，这些数字应相同。现在，如果您必须溢出，那么就必须溢出(尽管，这通常表示您做错了事)，但是每条记录仅溢出一次到磁盘的作业只会压碎其他记录。

reducer 方面可能存在类似的问题。看一下合并阶段的计数器。理想情况下，您希望溢出的记录为0或至少<= reducer 输入记录的数量。如果更高...这就是为什么您会遇到性能问题(严重的是，这可能是
绝对残酷)。请注意各种reducer溢出设置:mapred.job.shuffle.input.buffer.percent，mapred.job.shuffle.merge.percent，mapred.inmem.merge.threshold，io.sort.factor。 mapred.inmem.merge.threshold通常是大功告成的。前两个通常也搞砸了，但这更多地取决于工作的性质，而不是取决于工作规模。

dfs.namenode.handler.count:如果要在HDFS中生成很多小文件，则肯定要提高

dfs.mapred.job.tracker.handler.count:看看有多少个任务可以使一个想法更高。如果您要创建在数百个节点上运行的数千个小任务，那么您将无法满足于10

dfs.datanode.handler.count:这与parallel.copies标志并驾齐驱。这总是使我陷入麻烦，因为我的第一个直觉是将其提高得很高，然后我在其他地方造成了日志阻塞。 ;-)无论如何，如果您考虑与多少个reducer交谈的 map 绘制者，合理地提升这一点可能是有意义的。

tasktracker.http.threads:如果您被限制在reduce-copy中，则此问题不太可能出现。无论如何，它更接近应有的位置。 mapred.local.dir:这是我经常不得不在非EMR群集上进行调整的一项，以用于具有大量 map 输出的作业。您实际上可以成为磁盘绑定(bind)和磁盘空间绑定(bind)的对象，因此我发现将路径更改为以逗号分隔的目录列表(每个驱动器一个)很有帮助。当然，使用EMR没有意义，但是仍然指出如何真正快速地耗尽磁盘空间。

mapred.local.dir.minspacestart:您可能没有意识到，但是您的 map 输出空间可能不足。调整此值以确保在开始工作之前，每个任务在系统上都有足够的剩余空间可以真正节省您的培根。

请记住，Hadoop实际上是为每个主轴具有2个内核的系统(这是摩尔定律之前的几次迭代)而设计的，所有输入和输出都保留在HDFS内(这允许输入和输出的大量捷径)，1GigE每8核1个端口，而交换矩阵中的瓶颈很少。 EMR不会给您那样的东西。亚马逊试图提供一些不错的默认设置来进行调整，但是很难为每个人通用地解决该问题。 EMR的优势之一是您倾向于在每个节点上获得大量RAM，因此您应该花一些时间来确保最佳使用RAM以最大程度地减少磁盘I / O。 Hadoop对于那些使用映射器消耗大量原始数据但吐出相对较少数据的工作也确实很有帮助。每个作业中生成的所有数据都有大量的分布式排序，默认情况下，Hadoop会尝试执行此操作，同时保留大量RAM和磁盘空间用于任务。已经对数据进行了存储/分类实际上可以将大量工作从化简器推入映射器，从而避免大量开销。很有可能，这就是您的问题所在。