是否可以使用hadoop而不是amazon emr来处理> 10TB的输入？

Question

一个大的mapreduce作业(加入14个输入目录,总共输入大约14TB)失败.我们不仅不能完成我们的工作.当我们刚刚做了地图是猫/减少是猫,我们甚至无法完成.它似乎停止复制数据.

我们的猜测是,我们正在使用aws提供的hadoop-on-emr容量饱和.不确定我们是在饱和网络,磁盘空间还是什么.我们得到这样的错误

"减少>复制(436333 of 438094,0.10 MB/s)"

在hadoop控制面板上.它只是挂在那里,从未完成副本.另一个理论是,hadoop的离线排序与复制同时发生,并且不知何故这是一个瓶颈.我们已经尝试了更多减速器,更多节点,不同大小的工作箱的各种排列,但不知何故,我们无法找到有效的组合.

由于我们迫切需要完成这项工作,因此我们正在采取一种解决方法,即将数据划分为较小的作业.也就是说,14个输入年份中的每一个都将被拆分,然后我们将加入分区.

有没有人有使用aws托管的hadoop处理这个大小或更大的工作的经验,如果是这样,你能给出建议只是让cat map/cat减少成功吗？像节点数,节点大小和配置选项一样？

否则我想我们只是达到了emr的限制.

Answer 1

克里斯史密斯回答了这个问题并说我可以把它发布到SO.他的回答是:

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

也就是说,吸入10TB的数据是一个令人兴奋的任务.只是阅读那么多数据是非常残酷的,然后你就会进行分组/排序.

第一个问题是:限制因素是什么？您是否看到网络带宽最大化？你看到CPU最大化了吗？磁盘I/O还是iops？这些如何在数据节点上看？JobTracker和NameNodes怎么样(当群集的其余部分正常时,将这些最大化并不罕见)？如果不是上述情况,可能会有一个Hadoop资源被最大化,并且需要以不同方式配置.

由于你没有提到争论的任何特定方面超出了它所处的阶段,这使我怀疑你没有太多关于下面发生的指标的方式.通常,在调整正确的大工作之前,您需要多次"测量,然后调整"迭代.

作为一般的经验法则,在"减少/复制"阶段被长时间捆绑是一个非常强烈的指标,"你做错了".通常问题是您在排序/溢出/合并过程中遇到困难,节点以某种方式最大化磁盘IO.Hadoop有许多调整参数,对于具有大量映射器和减速器的作业来说,这些参数开始变得古怪,特别是如果两者之间存在很大的不平衡.同样,Karmasphere和类似工具可以在这里为您提供很多帮助.需要调整的典型事情(我可能有一些错误的名字):

日志记录.特别是,dfs.namenode.logging.level之类的东西对于在作业之前进行调整非常重要.使用详细日志记录完全可以杀死自己.矛盾的是,它也可能是你的救赎,所以......

地图输出大小通常是"减少/复制"问题的关键因素.如果可能的话,考虑减少地图输出大小的方法.它真的应该比地图输入大小小得多.去除减少阶段不严格需要的任何数据.考虑使用紧凑的二进制序列化格式(Java序列化会破坏您的性能),如协议缓冲区或thrift(整数数据的大赢).考虑使用ID/enums表示字符串的程度.您是否可以使用Combiner来减少必须通过线路发送的数据量？如果你有备用的CPU,使用压缩(从lzo或snappy开始,但如果你还有更多的CPU要刻录,请考虑使用gzip甚至更强大的东西).如果您仍然在地图任务日志中看到合并步骤需要很长时间,那么您需要做一些调整:

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 + +每个记录的字节数)".

很难强调早期的残余溢出对节点性能的影响.如果泄漏,这意味着数据将被写出,然后再次读取,然后再次写出.在每个节点上.因此,如果你弄错了,添加更多节点并没有帮助(实际上可能会让它变得更糟).您想要查看作业溢出的记录数与输出的地图记录数.理想情况下,这些数字将是相同的.现在,如果你必须泄漏,你必须泄漏(尽管这通常表明你做错了什么),但是每个记录仅溢出到磁盘一次的工作只会粉碎其他工作.

在减速机方面可能存在类似的问题.看看合并阶段的计数器.理想情况下,您希望溢出记录为0或至少<=减速器输入记录的数量.如果它更高......这就是你遇到性能问题的原因(严重的是,这可能是非常残酷的).请注意各种reducer溢出设置:mapred.job.shuffle.input.buffer.percent,mapred.job.shuffle.merge.percent,mapred.inmem.merge.threshold,io.sort.factor.通常为大型工作获得fubar的那个是mapred.inmem.merge.threshold.前两个也经常被搞砸,但这更多地取决于工作的性质,而不是作业大小的函数.

dfs.namenode.handler.count:如果你在HDFS中生成了很多小文件,你肯定想要推高它

dfs.mapred.job.tracker.handler.count:看看你有多少任务可以获得一个想法,如果这应该更高.如果你要创建在数百个节点上运行的数千个小任务,那么你就不会满足于这个10

dfs.datanode.handler.count:这个与parallel.copies标志齐头并进.这个问题总是让我陷入困境,因为我的第一直觉是将它提升到很高的水平,然后我只是在其他地方创建了日志.;-)无论如何,如果你考虑有多少地图制作者谈论了多少减速器,那么提升它可能是有意义的.

tasktracker.http.threads:如果你陷入reduce-copy,那么这个问题不太可能成为问题.无论如何,它更接近它应该的位置.mapred.local.dir:我经常不得不在非EMR集群上调整具有大量地图输出的作业.你真的可以成为磁盘绑定和磁盘空间绑定,所以我发现将路径更改为逗号分隔的目录列表是有帮助的,每个驱动器一个.当然,使用EMR它没有意义,但仍然指出如何快速耗尽磁盘空间.

mapred.local.dir.minspacestart:您可能没有意识到这一点,但是您的地图输出可能空间不足.调整此值以确保每个任务在开始作业之前在系统上有足够的剩余空间可以真正保存您的培根.

请记住,Hadoop真的是为每个主轴有2个内核的系统设计的(这是摩尔定律的几次迭代),所有输入和输出都保留在HDFS内部(允许大量的输入和输出短路),1GigE每8个内核的端口,以及交换结构中的瓶颈很少.EMR没有给你这样的东西.亚马逊试图给出一些不错的默认值来调整它,但是很难为每个人解决这个问题.EMR的一个优点是每个节点往往会获得大量的RAM,因此您应该花一些时间确保最佳地使用RAM来最小化磁盘I/O. 对于映射器消耗大量原始数据的工作,Hadoop也非常有用,但是数据相对较少.对于您在每个作业中生成的所有数据,都会进行大规模的分布式排序,默认情况下,Hadoop尝试执行此操作,同时保留大部分RAM和磁盘空间可用于您的任务.让你的数据经过分区/排序可以真正将大量的工作从reducer中推出到mapper中,从而避免了TON的开销.机会是,这就是问题所在.