大数据 T3 Hadoop运行过程详解

307 阅读4分钟

专栏 大数据 数据处理原理
如果对你有帮助求个赞或者关注,谢谢谢谢。

谷歌论文中的MapReduce

下面是之前讲过的,一开始提出的MapReduce的概念流程。

image.png

Hadoop中的MapReduce

再来看一下Hadoop中MapReduce的流程。

image.png 概念不变,只是更加具体了。不了解的可以看 T2分布式计算与MapReduce

Hadoop的版本更迭

  • V1:实现了论文中最基础的概念,MapReduce
  • V2: 加入了YARN (Yet Another Resource Negotiator),提供了更好的资源管理和调度
  • V3: 加入了multi-Name Node的支持,减少读写开销,添加GPU支持

流程中的额外开销

分布式计算一定会有额外开销,比如通信,汇总等。MapReduce除了map与Reduce之外的开销主要有以下几个方面:

  1. 从HDFS中读取信息
  2. Map之后的sort
  3. sort之后的写入
  4. Reduce中的读
  5. Reduce之后的写

可以看到有很多额外开销都是IO开销,所以 数据本地化?(Data locality) 非常重要。就是每个Map读取的数据都在本地。如果远程读取其他节点上的数据,就需要通过网络进行传输,而网络传输通常是不稳定且速度较低的(相比于本地磁盘),所以要尽量避免这种情况。当然如何分配给每个节点的数据量成了一个新的挑战,我们目前先假设它可以比较完美的做到。无论如何,尽量做到Data locality对数据处理是有帮助的。

注意1:Map到sort的过程是在内存中进行的,sort的过程也是在内存中进行。

注意2: Reduce过程中,是两两进行的,不是一下读取很多个加一起。

image.png

Hadoop中各个节点工作流

刚刚大概了解了总体的MapReduce过程,那么如何跟实际结合呢?每个节点都干了些什么?过程是什么样的?

Work flow

首先,Client开始运行一个任务

image.png

然后Client联系Job Tracker,获得一个Job ID,用来唯一标识当前Job

image.png

接下来将Job Resources分配给各个节点,由于Hadoop最初是用java进行实现的,所以图中以.jar方式表示。

image.png

然后Client将任务提交给Job Tracker,JobTracker进行相应的初始化。 查看当前各种资源的位置,比如资源(计算资源和存储)的位置

image.png 之后JobTracker 通过hartbeat确定节点是不是正常工作,然后将任务分配不同节点中的Task Tracker。之后Task Tracker获取之前分配的存储在HDFS中的资源并且开始工作。对应概念图中的读取与Map。

image.png 计算完成之后内存中进行sort,然后将结果输出到HDFS(存储系统)中。对应概念图中的sort与读过程。

image.png

写入完成后向JobTracker报告任务完成。

image.png

至此,整个第一步的Map结束,等待开始Reduce阶段。 这个时候,JobTracker再次确认资源,并且将Reduce任务分给节点(Task Tracker)。 Task Tracker重复之前的步骤:获取资源,初始化并且开始执行Reduce任务(Map和Reduce只是功能不同,但是说到底,他们就是一段代码,所以流程并没有变化),完成后再次写入HDFS然后想JobTracker进行报告。

JobTracker发现这个任务的所有阶段完成后,向Client报告任务完成,整个流程结束。

image.png

Hadoop带来的新概念和问题

计数器(counter)

  • 当进行计算的时候,我们有时候需要维护一个全局的值,Hadoop中,可以通过counter来进行实现,他可以在运行时被更新,并且在JobTracker中进行分享。

压缩(Compression)

  • 文件压缩,减少数据传输的消耗,变相提高了IO,比如ZLib,GZip等。

HDFS存储问题

简单来说,HDFS就是一个文件系统,他规定了Hadoop如何存储文件。HDFS的问题是,他是以块为单位进行存储的,每个块的大小是固定的,这就意味着它不适合存小文件。因为一个文件占用一个块的话,会有很多的闲置空间,(10k的文件,在文件系统中占用一个128m的块)。这个可以通过文件合并进行优化,把多个小文件放在同一个块中,但是Name Node仍然需要为每一个小文件维护一个索引,因此小文件多了索引开销会极大。而且读取的时候也是以块为单位,导致了很大的IO开销。

也有其他的解决方案:HBase。后面也会进行讲解。

处理速度与延迟

多年前Hadoop最初被实现的时候,内存还比较小,所以会有很多的读写到HDFS的过程,并且没有缓存,每一次Map或者Reduce都需要进行读写,这导致IO开销很大。如果是多个Map步骤的话,开销会更大。

没有被覆盖的应用场景

有些场景无法使用Hadoop,比如流式传输

接下来?

下一篇文章中会介绍Spark,并讲解Spark是如何解决上述这些问题的。