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 回答