为什么向mapreduce提交工作需要花费这么多时间？

Question

因此通常对于20节点集群提交作业来处理3GB(200个分裂)的数据需要大约30秒并且实际执行大约1m.我想了解工作提交过程中的瓶颈是什么,并了解下一个报价

Per-MapReduce开销很重要:开始/结束MapReduce作业成本时间

我知道一些过程:1.数据拆分2. jar文件共享

Answer 1

有关HDFS和M/R的一些事项有助于理解这种延迟:

1. HDFS将您的文件存储为分布在多台名为datanode的计算机上的数据块
2. M/R在每个数据块或块上运行称为映射器的多个程序.这些映射器的(键,值)输出由reducers汇总在一起.(想想总结来自多个映射器的各种结果)
3. 每个映射器和reducer都是在这些分布式系统上生成的完整程序.即使我们说他们没有做任何事情(No-OP map reduce program),它确实需要时间来产生一个完整的程序.
4. 当要处理的数据的大小变得非常大时,这些生成时间变得微不足道,这就是Hadoop闪耀的时候.

如果您要处理1000行内容的文件,那么您最好使用普通的文件读取和处理程序.在分布式系统上生成进程的Hadoop基础结构不会产生任何好处,但只会导致定位包含相关数据块的数据节点,启动处理程序,跟踪和收集结果的额外开销.

现在将其扩展到100个Peta字节数据,与处理它们所需的时间相比,这些开销看起来完全无关紧要.处理器(映射器和缩减器)的并行化将在这里显示出它的优势.

因此,在分析M/R的性能之前,首先应该对集群进行基准测试,以便更好地了解开销.

在集群上执行无操作map-reduce程序需要多长时间？

使用MRBench实现此目的:

1. MRbench多次循环一个小工作
2. 检查小作业运行是否响应并在群集上高效运行.
3. 它对HDFS层的影响非常有限

要运行此程序,请尝试以下操作(检查最新版本的正确方法:

hadoop jar /usr/lib/hadoop-0.20/hadoop-test.jar mrbench -numRuns 50

令人惊讶的是,在我们的一个开发群集中它是22秒.

另一个问题是文件大小.

如果文件大小小于HDFS块大小,则Map/Reduce程序会产生很大的开销.Hadoop通常会尝试为每个块生成一个映射器.这意味着如果你有30个5KB的文件,那么即使文件的大小很小,Hadoop也可能最终每个块产生30个映射器.这是一个真正的浪费,因为与处理小尺寸文件所花费的时间相比,每个程序开销都很重要.

Answer 2

据我所知,没有单一的瓶颈导致工作延迟; 如果有的话,它很久以前就会得到解决.

有许多步骤需要时间,并且有理由说明该过程很慢.我会尝试列出它们并估计我可以在哪里:

1. 运行hadoop客户端.它正在运行Java,我认为可以假设大约1秒的开销.
2. 将作业放入队列并让当前的调度程序运行该作业.我不确定什么是开销,但是,由于进程的异步性质,应该存在一些延迟.
3. 计算拆分.
4. 运行和同步任务.在这里,我们面对的事实是TaskTrackes轮询JobTracker,而不是相反.我认为这是为了扩展性而做的.这意味着当JobTracker想要执行某项任务时,它不会调用任务跟踪器,而是等待该适当的跟踪器将ping它以获得该作业.任务跟踪器无法频繁ping JobTracker,否则会在大型集群中将其杀死.
5. 运行任务.如果没有JVM重用,大约需要3秒,每个任务的开销大约为1秒.
6. 结果的客户端轮询作业跟踪器(至少我认为是这样),它还增加了一些延迟,以获取作业完成的信息.