所以通常对于 20 节点集群提交作业来处理 3GB（200 次拆分）的数据大约需要 30 秒，实际执行大约需要 1m。我想了解作业提交过程中的瓶颈是什么，并了解下一个报价
每 MapReduce 开销是显著的：开始/结束 Map减少作业成本时间
我知道的一些过程：1. 数据拆分2.jar 文件共享
关于HDFS和M/R的一些事情，有助于理解这种延迟：
- HDFS将您的文件存储为数据块，分布在称为数据节点的多台机器上
- M/R在每个数据块或块上运行多个称为mapper的程序。这些映射器的（键，值）输出由化简器编译在一起作为结果。（考虑对来自多个映射器的各种结果求和）
- 每个映射器和化简器都是在这些分布式系统上生成的一个完整的程序。催生一个成熟的程序确实需要时间，即使我们说他们什么也没做（No-OP map reduce program）。
- 当要处理的数据量变得非常大时，这些生成时间变得微不足道，这就是Hadoop大放异彩的时候。
如果要处理具有 1000 行内容的文件，则最好使用普通的文件读取和处理程序。在分布式系统上生成进程的Hadoop基础设施不会产生任何好处，只会增加额外的开销，即定位包含相关数据块的数据节点，在其上启动处理程序，跟踪和收集结果。
现在将其扩展到 100 PB 的数据，与处理它们所需的时间相比，这些开销看起来完全微不足道。处理器（映射器和化简器）的并行化将在这里显示它的优势。
因此，在分析 M/R 的性能之前，您应该首先对集群进行基准测试，以便更好地了解开销。
在集群上执行无操作映射缩减程序需要多少时间？
将 MRBench 用于此目的：
- MRbench 多次循环一个小作业
- 检查小型作业运行是否响应迅速，是否在群集上高效运行。
- 它对HDFS层的影响非常有限
要运行此程序，请尝试以下操作（检查最新版本的正确方法：
hadoop jar /usr/lib/hadoop-0.20/hadoop-test.jar mrbench -numRuns 50
令人惊讶的是，在我们的一个开发集群上，它是 22 秒。
另一个问题是文件大小。
如果文件大小小于HDFS块大小，则Map/Reduce程序具有很大的开销。Hadoop通常会尝试为每个块生成一个映射器。这意味着如果你有 30 个 5KB 的文件，那么即使文件大小很小，Hadoop 最终每个块也可能生成 30 个映射器。这是一个真正的浪费，因为与处理小文件所花费的时间相比，每个程序的开销都很大。
据我所知，没有单一的瓶颈导致作业运行延迟; 如果有，早就解决了。
有许多步骤需要时间，并且该过程缓慢是有原因的。我将尝试列出它们并估计我可以：
- 运行 hadoop 客户端。它正在运行 Java，我认为可以假设大约 1 秒的开销。
- 将作业放入队列中，并让当前调度程序运行作业。我不确定开销是什么，但是，由于进程的异步性质，应该存在一些延迟。
- 计算拆分。
- 运行和同步任务。在这里，我们面对的是TaskTrackes轮询JobTracker的事实，而不是相反。我认为这样做是为了可扩展性。这意味着当 JobTracker 想要执行某个任务时，它不会调用任务跟踪器，而是等待适当的跟踪器将 ping 它以获得工作。任务跟踪器不能频繁地ping到JobTracker，否则它们会在大型集群中杀死它。
- 运行任务。如果没有 JVM 重用，它大约需要 3 秒，每个任务的开销约为 1 秒。
- 客户端轮询作业跟踪器以获取结果（至少我认为是这样），并且它还为获取工作已完成的信息增加了一些延迟。
我看到了类似的问题，我可以通过以下步骤说明要破解的解决方案：
- 当HDFS
- 存储太多具有固定块大小的小文件时，HDFS的效率就会出现问题，最好的方法是删除所有不必要的文件和具有数据的小文件。再试一次。
尝试使用数据节点和名称节点：
- 停止所有使用 stop-all.sh 的服务。
- 设置名称节点的格式
- 重新启动计算机
- 使用 start-all.sh 启动所有服务
- 检查数据和命名节点。
尝试安装较低版本的 hadoop （hadoop 2.5.2），它在两种情况下都有效，并且可以在命中和试用中工作。