为什么提交工作到mapreduce需要这么多时间在一般？

Question

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

每MapReduce的开销是显著：开始/结束MapReduce工作耗费时间

有些过程我知道： 1.数据分割 2. jar文件共享

Answer 1

有几件事情要了解有关HDFS和M/R，有助于理解这种延迟：

1. HDFS将您的文件存储为分布在多个称为datanode的计算机上的数据块
2. M/R在每个数据块或块上运行多个名为mapper的程序。这些映射器的（键，值）输出一起编译为reducers的结果。 （想象总结来自多个映射器的各种结果）
3. 每个映射器和简化器都是在这些分布式系统上产生的完整的程序。即使让我们说他们什么也没做（无OP图减少程序），它需要一些时间来产生一个完整的程序。
4. 当要处理的数据量变得非常大时，这些产卵时间变得无足轻重，这就是Hadoop发光时的情况。

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

现在将其扩展到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）的较低版本，它在hit和trial中工作。