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

Question

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

  

每MapReduce开销很重要：开始/结束MapReduce作业成本时间

我知道一些过程： 数据分裂 2. jar文件共享

Answer 1

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

1. HDFS将您的文件存储为分布在多台名为datanodes的计算机上的数据块
2. M / R在每个数据块或块上运行称为映射器的多个程序。这些映射器的（键，值）输出由reducers汇总在一起。 （想想总结来自多个映射器的各种结果）
3. 每个映射器和reducer都是在这些分布式系统上生成的完整程序。即使让我们说他们没有做任何事情（No-OP地图减少程序），它确实需要时间来产生一个完整的程序。
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. 结果的客户端轮询作业跟踪器（至少我认为是这样），它还会增加一些延迟，以获取作业完成的信息。

Answer 3

我已经看到了类似的问题，我可以通过以下步骤说明要解决的问题：

1. 当HDFS存储太多具有固定块大小的小文件时，HDFS的效率会出现问题，最好的方法是删除所有不必要的文件和有数据的小文件。再试一次。

2. 尝试使用数据节点和名称节点：

   • 使用stop-all.sh停止所有服务。
   • 格式名称节点
   • 重启机器
   • 使用start-all.sh
   启动所有服务
   • 检查数据和名称节点。

3. 尝试安装较低版本的hadoop（hadoop 2.5.2），该版本在两种情况下工作，并且在命中和试用中都有效。