7

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

每个 MapReduce 开销很大:启动/结束 MapReduce 作业需要时间

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

4

3 回答 3

14

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

  1. HDFS 将您的文件存储为分布在称为数据节点的多台机器上的数据块
  2. M/R 在每个数据块或块上运行多个称为映射器的程序。这些映射器的 (key,value) 输出由 reducer 编译为结果。(考虑将多个映射器的各种结果相加)
  3. 每个 mapper 和 reducer 都是在这些分布式系统上生成的完整程序。生成一个完整的程序确实需要时间,即使我们说它们什么也没做(No-OP map reduce 程序)。
  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 个映射器。这是一种真正的浪费,因为与处理小文件所花费的时间相比,每个程序的开销都很大。

于 2012-07-06T21:00:36.967 回答
5

据我所知,没有一个瓶颈会导致作业运行延迟;如果有,早就解决了。

有许多步骤需要时间,而且过程缓慢是有原因的。我将尝试列出它们并估计我可以:

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

我已经看到了类似的问题,我可以在以下步骤中说明要破解的解决方案:

  1. 当 HDFS 存储了太多固定块大小的小文件时,HDFS 的效率就会出现问题,最好的方法是删除所有不必要的文件和有数据的小文件。再试一次。
  2. 尝试使用数据节点和名称节点:

    • 使用 stop-all.sh 停止所有服务。
    • 格式名称节点
    • 重启机器
    • 使用 start-all.sh 启动所有服务
    • 检查数据和名称节点。
  3. 尝试安装低版本的 hadoop (hadoop 2.5.2),它在两种情况下都有效,并且在命中和试验中都有效。

于 2017-02-01T01:53:27.773 回答