hadoop中NameNode、DataNode、Secondary、NameNode、JobTracker TaskTracker介绍

时间 2019-11-07

标签 hadoop namenode datanode secondary jobtracker tasktracker 介绍栏目 Hadoop 繁體版

原文原文链接

http://www.aboutyun.com/thread-7778-1-1.htmlhtml

问题导读：
1.job的本质是什么？
2.任务的本质是什么？
3.文件系统的Namespace由谁来管理，Namespace的做用是什么？
4.Namespace 镜像文件(Namespace image)和操做日志文件(edit log)文件的做用是什么？
5.Namenode记录着每一个文件中各个块所在的数据节点的位置信息，可是他并不持久化存储这些信息，为何？
6.客户端读写某个数据时，是否经过NameNode？
7.namenode，datanode，Namespace image，Edit log之间的关系是什么？
8.一旦某个task失败了，JobTracker如何处理？
9.JobClient JobClient在获取了JobTracker为Job分配的id以后，会在JobTracker的系统目录(HDFS)下为该Job建立一个单独的目录，目录的名字便是Job的id，该目录下
会包含文件job.xml、job.jar等文件，这两个文件的做用是什么？
10.JobTracker根据什么就能获得这个Job目录？
11.JobTracker提交做业以前，为何要检查内存？
12.每一个TaskTracker产生多个java 虚拟机（JVM）的缘由是什么？

概述：

Hadoop是一个可以对大量数据进行分布式处理的软件框架，实现了Google的MapReduce编程模型和框架，可以把应用程序分割成许多的小的工做单元，并把这些单元放到任何集群节点上执行。在MapReduce中，一个准备提交执行的应用程序称为“做业（job）”，而从一个做业划分出得、运行于各个计算节点的工做单元称为“任务（task）”。此外，Hadoop提供的分布式文件系统（HDFS）主要负责各个节点的数据存储，并实现了高吞吐率的数据读写。

　　在分布式存储和分布式计算方面，Hadoop都是用从/从（Master/Slave）架构。在一个配置完整的集群上，想让Hadoop这头大象奔跑起来，须要在集群中运行一系列后台(deamon）程序。不一样的后台程序扮演不用的角色，这些角色由NameNode、DataNode、 Secondary NameNode、JobTracker、TaskTracker组成。其中NameNode、Secondary NameNode、JobTracker运行在Master节点上，而在每一个Slave节点上，部署一个DataNode和TaskTracker，以便这个Slave服务器运行的数据处理程序能尽量直接处理本机的数据。对Master节点须要特别说明的是，在小集群中，Secondary NameNode能够属于某个从节点；在大型集群中，NameNode和JobTracker被分别部署在两台服务器上。

咱们已经很熟悉这个5个进程，可是在使用的过程当中，咱们常常遇到问题，那么该如何入手解决这些问题。那么首先咱们需了解的他们的原理和做用。

1.Namenode介绍

Namenode 管理者文件系统的Namespace。它维护着文件系统树(filesystem tree)以及文件树中全部的文件和文件夹的元数据(metadata)。管理这些信息的文件有两个，分别是Namespace 镜像文件(Namespace image)和操做日志文件(edit log)，这些信息被Cache在RAM中，固然，这两个文件也会被持久化存储在本地硬盘。Namenode记录着每一个文件中各个块所在的数据节点的位置信息，可是他并不持久化存储这些信息，由于这些信息会在系统启动时从数据节点重建。java

Namenode结构图课抽象为如图：node

客户端(client)表明用户与namenode和datanode交互来访问整个文件系统。客户端提供了一些列的文件系统接口，所以咱们在编程时，几乎无须知道datanode和namenode，便可完成咱们所须要的功能。编程

1.1Namenode容错机制

没有Namenode，HDFS就不能工做。事实上，若是运行namenode的机器坏掉的话，系统中的文件将会彻底丢失，由于没有其余方法可以将位于不一样datanode上的文件块(blocks)重建文件。所以，namenode的容错机制很是重要，Hadoop提供了两种机制。安全

第一种方式是将持久化存储在本地硬盘的文件系统元数据备份。Hadoop能够经过配置来让Namenode将他的持久化状态文件写到不一样的文件系统中。这种写操做是同步而且是原子化的。比较常见的配置是在将持久化状态写到本地硬盘的同时，也写入到一个远程挂载的网络文件系统。服务器

第二种方式是运行一个辅助的Namenode(Secondary Namenode)。事实上Secondary Namenode并不能被用做Namenode它的主要做用是按期的将Namespace镜像与操做日志文件(edit log)合并，以防止操做日志文件(edit log)变得过大。一般，Secondary Namenode 运行在一个单独的物理机上，由于合并操做须要占用大量的CPU时间以及和Namenode至关的内存。辅助Namenode保存着合并后的Namespace镜像的一个备份，万一哪天Namenode宕机了，这个备份就能够用上了。网络

可是辅助Namenode老是落后于主Namenode，因此在Namenode宕机时，数据丢失是不可避免的。在这种状况下，通常的，要结合第一种方式中提到的远程挂载的网络文件系统(NFS)中的Namenode的元数据文件来使用，把NFS中的Namenode元数据文件，拷贝到辅助Namenode，并把辅助Namenode做为主Namenode来运行。架构

----------------------------------------------------------------------------------------------------------------------------------------------------框架

二、Datanode介绍

Datanode是文件系统的工做节点，他们根据客户端或者是namenode的调度存储和检索数据，而且按期向namenode发送他们所存储的块(block)的列表。分布式

集群中的每一个服务器都运行一个DataNode后台程序，这个后台程序负责把HDFS数据块读写到本地的文件系统。当须要经过客户端读/写某个数据时，先由NameNode告诉客户端去哪一个DataNode进行具体的读/写操做，而后，客户端直接与这个DataNode服务器上的后台程序进行通信，而且对相关的数据块进行读/写操做。

---------------------------------------------------------------------------------------------------------------------------------------------------

三、Secondary NameNode介绍

　Secondary NameNode是一个用来监控HDFS状态的辅助后台程序。就想NameNode同样，每一个集群都有一个Secondary NameNode，而且部署在一个单独的服务器上。Secondary NameNode不一样于NameNode，它不接受或者记录任何实时的数据变化，可是，它会与NameNode进行通讯，以便按期地保存HDFS元数据的快照。因为NameNode是单点的，经过Secondary NameNode的快照功能，能够将NameNode的宕机时间和数据损失下降到最小。同时，若是NameNode发生问题，Secondary NameNode能够及时地做为备用NameNode使用。

3.1NameNode的目录结构以下：

${dfs.name.dir}/current/VERSION

/edits

/fsimage

/fstime

3.2Secondary NameNode的目录结构以下：

${fs.checkpoint.dir}/current/VERSION

/edits

/fsimage

/fstime

/previous.checkpoint/VERSION

/edits

/fsimage

/fstime

如上图，Secondary NameNode主要是作Namespace image和Edit log合并的。

那么这两种文件是作什么的？当客户端执行写操做，则NameNode会在edit log记录下来，（我感受这个文件有些像Oracle的online redo logo file）并在内存中保存一份文件系统的元数据。

Namespace image（fsimage）文件是文件系统元数据的持久化检查点，不会在写操做后立刻更新，由于fsimage写很是慢（这个有比较像datafile）。

因为Edit log不断增加，在NameNode重启时，会形成长时间NameNode处于安全模式，不可用状态，是很是不符合Hadoop的设计初衷。因此要周期性合并Edit log，可是这个工做由NameNode来完成，会占用大量资源，这样就出现了Secondary NameNode，它能够进行image检查点的处理工做。步骤以下：

（1） Secondary NameNode请求NameNode进行edit log的滚动（即建立一个新的edit log），将新的编辑操做记录到新生成的edit log文件；

（2）经过http get方式，读取NameNode上的fsimage和edits文件，到Secondary NameNode上；

（3）读取fsimage到内存中，即加载fsimage到内存，而后执行edits中全部操做（相似OracleDG，应用redo log），并生成一个新的fsimage文件，即这个检查点被建立；

（4）经过http post方式，将新的fsimage文件传送到NameNode；

（5） NameNode使用新的fsimage替换原来的fsimage文件，让（1）建立的edits替代原来的edits文件；而且更新fsimage文件的检查点时间。

整个处理过程完成。

Secondary NameNode的处理，是将fsimage和edites文件周期的合并，不会形成nameNode重启时形成长时间不可访问的状况。

--------------------------------------------------------------------------------------------------------------------------------------------------

四、JobTracker介绍

JobTracker后台程序用来链接应用程序与Hadoop。用户代码提交到集群之后，由JobTracker决定哪一个文件将被处理，而且为不一样的task分配节点。同时，它还监控全部的task，一旦某个task失败了，JobTracker就会自动从新开启这个task，在大多数状况下这个task会被放在不用的节点上。每一个Hadoop集群只有一个JobTracker，通常运行在集群的Master节点上。

下面咱们详细介绍：

4.1JobClient

咱们配置好做业以后，就能够向JobTracker提交该做业了，而后JobTracker才能安排适当的TaskTracker来完成该做业。那么MapReduce在这个过程当中到底作了那些事情呢？这就是本文以及接下来的一片博文将要讨论的问题，固然本文主要是围绕客户端在做业的提交过程当中的工做来展开。先从全局来把握这个过程吧！

在Hadoop中，做业是使用Job对象来抽象的，对于Job，我首先不得不介绍它的一个你们伙JobClient——客户端的实际工做者。JobClient除了本身完成一部分必要的工做外，还负责与JobTracker进行交互。因此客户端对Job的提交，绝大部分都是JobClient完成的，从上图中，咱们能够得知JobClient提交Job的详细流程主要以下：

JobClient在获取了JobTracker为Job分配的id以后，会在JobTracker的系统目录(HDFS)下为该Job建立一个单独的目录，目录的名字便是Job的id，该目录下会包含文件job.xml、job.jar、job.split等，其中，job.xml文件记录了Job的详细配置信息，job.jar保存了用户定义的关于job的map、reduce操纵，job.split保存了job任务的切分信息。在上面的流程图中，我想详细阐述的是JobClient是任何配置Job的运行环境，以及如何对Job的输入数据进行切分。

4.2JobTracker

上面谈到了客户端的JobClient对一个做业的提交所作的工做，那么这里，就要好好的谈一谈JobTracker为做业的提交到底干了那些个事情——一.为做业生成一个Job；二.接受该做业。

咱们都知道，客户端的JobClient把做业的全部相关信息都保存到了JobTracker的系统目录下(固然是HDFS了)，这样作的一个最大的好处就是客户端干了它所能干的事情同时也减小了服务器端JobTracker的负载。下面就来看看JobTracker是如何来完成客户端做业的提交的吧！哦。对了，在这里我不得不提的是客户端的JobClient向JobTracker正式提交做业时直传给了它一个改做业的JobId，这是由于与Job相关的全部信息已经存在于JobTracker的系统目录下，JobTracker只要根据JobId就能获得这个Job目录。

对于上面的Job的提交处理流程，我将简单的介绍如下几个过程：

1.建立Job的JobInProgress

JobInProgress对象详细的记录了Job的配置信息，以及它的执行状况，确切的来讲应该是Job被分解的map、reduce任务。在JobInProgress对象的建立过程当中，它主要干了两件事，一是把Job的job.xml、job.jar文件从Job目录copy到JobTracker的本地文件系统(job.xml->*/jobTracker/jobid.xml，job.jar->*/jobTracker/jobid.jar)；二是建立JobStatus和Job的mapTask、reduceTask存队列来跟踪Job的状态信息。

2.检查客户端是否有权限提交Job

JobTracker验证客户端是否有权限提交Job其实是交给QueueManager来处理的。

3.检查当前mapreduce集群可以知足Job的内存需求

客户端提交做业以前，会根据实际的应用状况配置做业任务的内存需求，同时JobTracker为了提升做业的吞吐量会限制做业任务的内存需求，因此在Job的提交时，JobTracker须要检查Job的内存需求是否知足JobTracker的设置。

上面流程已经完毕，能够总结为下图：

--------------------------------------------------------------------------------------------------------------------------

五、TaskTracker介绍

TaskTracker与负责存储数据的DataNode相结合，其处理结构上也遵循主/从架构。JobTracker位于主节点，统领 MapReduce工做；而TaskTrackers位于从节点，独立管理各自的task。每一个TaskTracker负责独立执行具体的task，而 JobTracker负责分配task。虽然每一个从节点仅有一个惟一的一个TaskTracker，可是每一个TaskTracker能够产生多个java 虚拟机（JVM），用于并行处理多个map以及reduce任务。TaskTracker的一个重要职责就是与JobTracker交互。若是 JobTracker没法准时地获取TaskTracker提交的信息，JobTracker就断定TaskTracker已经崩溃，并将任务分配给其余节点处理。

5.1TaskTracker内部设计与实现

Hadoop采用master-slave的架构设计来实现Map-Reduce框架，它的JobTracker节点做为主控节点来管理和调度用户提交的做业，TaskTracker节点做为工做节点来负责执行JobTracker节点分配的Map/Reduce任务。整个集群由一个JobTracker节点和若干个TaskTracker节点组成，固然，JobTracker节点也负责对TaskTracker节点进行管理。在前面一系列的博文中，我已经比较系统地讲述了JobTracker节点内部的设计与实现，而在本文，我将对TaskTracker节点的内部设计与实现进行一次全面的概述。

TaskTracker节点做为工做节点不只要和JobTracker节点进行频繁的交互来获取做业的任务并负责在本地执行他们，并且也要和其它的TaskTracker节点交互来协同完成同一个做业。所以，在目前的Hadoop-0.20.2.0实现版本中，对工做节点TaskTracker的设计主要包含三类组件：服务组件、管理组件、工做组件。服务组件不只负责与其它的TaskTracker节点并且还负责与JobTracker节点之间的通讯服务，管理组件负责对该节点上的任务、做业、JVM实例以及内存进行管理，工做组件则负责调度Map/Reduce任务的执行。这三大组件的详细构成以下：

下面来详细的介绍这三类组件：服务组件 TaskTracker节点内部的服务组件不只用来为TaskTracker节点、客户端提供服务，并且还负责向TaskTracker节点请求服务，这一类组件主要包括HttpServer、TaskReportServer、JobClient三大组件。 1.HttpServer TaskTracker节点在其内部使用Jetty Web容器来开启http服务，这个http服务一是用来为客户端提供Task日志查询服务，二是用来提供数据传输服务，即在执行Reduce任务时是经过TaskTracker节点提供的该http服务来获取属于本身的map输出数据。这里须要详细介绍的是与该服务相关的配置参数，集群管理者能够经过TaskTracker节点的配置文件来配置该服务地址和端口号，对应的配置项为：mapred.task.tracker.http.address。同时，为了可以灵活的控制该该服务的吞吐量，管理者还能够设置该http服务的内部工做线程数量，对应的配置为：tasktracker.http.threads。 2.Task Reporter TaskTracker节点在接收到JobTracker节点发送过来的Map/Reduce任务以后，会把它们交给JVM实例来执行，而本身则须要收集这些任务的执行进度信息，这就使得Task在JVM实例中执行的时候须要不断地向TaskTracker节点报告当前的执行状况。虽然TaskTracker节点和JVM实例在同一台机器上，可是它们之间的进程通讯倒是经过网络I/O来完成的(此处并不讨论这种通讯方式的性能)，也就是TaskTracker节点在其内部开启一个端口来专门为任务实例提供进度报告服务。该服务地址能够经过配置项mapred.task.tracker.report.address来设置，而服务内部的工做线程的数量取2倍于该TaskTracker节点上的Map/Reduce Slot数量中的大者。