hadoop技术之hdfs工作流程与机制

hadoop技术之hdfs工作流程与机制

NameNode是Hadoop分布式文件系统的核心，架构中的主角色。

NameNode维护和管理文件系统元数据，包括名称空间目录树结构、文件和块的位置信息、访问权限等信息。    

基于此，  NameNode成为了访问HDFS的唯一入口。

NameNode内部通过内存和磁盘文件两种方式管理元数据。

其中磁盘上的元数据文件包括Fsimage内存元数据镜像文件和edits log  (Journal)编辑日志。

DataNode是Hadoop HDFS中的从角色，负责具体的数据块存储。

DataNode的数量决定了HDFS集群的整体数据存储能力。通过和NameNode配合维护着数据块。

Secondary NameNode充当NameNode的辅助节点，但不能替代NameNode。

主要是帮助主角色进行元数据文件的合并动作。可以通俗的理解为主角色的“秘书”。

NameNode仅存储HDFS的元数据：文件系统中所有文件的目录树，  并跟踪整个集群中的文件，  不存储实际数据。    

NameNode知道HDFS中任何给定文件的块列表及其位置。使用此信息NameNode知道如何从块中构建文件。        

NameNode不持久化存储每个文件中各个块所在的datanode的位置信息，  这些信息会在系统启动时从DataNode 重建。

NameNode是Hadoop集群中的单点故障。

NameNode所在机器通常会配置有大量内存(RAM)  。

DataNode负责最终数据块block的存储。是集群的从角色，也称为Slave。

DataNode启动时，会将自己注册到NameNode并汇报自己负责持有的块列表。

当某个DataNode关闭时，不会影响数据的可用性。  

NameNode将安排由其他DataNode管理的块进行副本复制。

DataNode所在机器通常配置有大量的硬盘空间，  因为实际数据存储在DataNode中。

 Pipeline，中文翻译为管道。这是HDFS在上传文件写数据过程中采用的一种数据传输方式。

客户端将数据块写入第一个数据节点，  第一个数据节点保存数据之后再将块复制到第二个数据节点，  后者保存后将其复制到第三个数据节点。

为什么datanode之间采用pipeline线性传输，而不是一次给三个datanode拓扑式传输呢？

因为数据以管道的方式，  顺序的沿着一个方向传输，  这样能够充分利用每个机器的带宽，避免网络瓶颈和高延迟时的连接，最小化推送所有数据的延时。

在线性推送模式下，每台机器所有的出口宽带都用于以最快的速度传输数据，而不是在多个接受者之间分配宽带。

ACK (Acknowledge character)即是确认字符，在数据通信中，接收方发给发送方的一种传输类控制字符。表示发来的数据已确认接收无误。

在HDFS pipeline管道传输数据的过程中，传输的反方向会进行ACK校验，  确保数据传输安全。

默认副本存储策略是由BlockPlacementPolicyDefault指定。 

核心概念--默认3副本存储策略     第一块副本：优先客户端本地，  否则随机     第二块副本：不同于第一块副本的不同机架。     第三块副本：第二块副本相同机架不同机器。

1、HDFS客户端创建对象实例DistributedFileSystem，   该对象中封装了与HDFS文件系统操作的相关方法。

2、调用DistributedFileSystem对象的create()方法，通过RPC请求NameNode创建文件。 NameNode执行各种检查判断：目标文件是否存在、父目录是否存在、客户端是否具有创建该文件的权限。检查通过 ，  NameNode就会为本次请求记下一条记录，返回FSDataOutputStream输出流对象给客户端用于写数据。 

3、客户端通过FSDataOutputStream输出流开始写入数据。

4、客户端写入数据时，将数据分成一个个数据包(packet 默认64k)  , 内部组件DataStreamer请求NameNode挑 选出适合存储数据副本的一组DataNode地址，默认是3副本存储。 DataStreamer将数据包流式传输到pipeline的第一个DataNode,该DataNode存储数据包并将它发送到pipeline的第 二个DataNode。  同样，第二个DataNode存储数据包并且发送给第三个(也是最后一个)  DataNode。 

5、传输的反方向上，  会通过ACK机制校验数据包传输是否成功；

6、客户端完成数据写入后，在FSDataOutputStream输出流上调用close()方法关闭。

7、  DistributedFileSystem联系NameNode告知其文件写入完成，等待NameNode确认。

因为namenode已经知道文件由哪些块组成(DataStream请求分配数据块)，  因此仅需等待最小复制块即可成功返回。

最小复制是由参数dfs.namenode.replication.min指定，默认是1.

 1、  HDFS客户端创建对象实例DistributedFileSystem，   调用该对象的open()方法来打开希望读取的文件。

2、  DistributedFileSystem使用RPC调用namenode来确定文件中前几个块的块位置(分批次读取)  信息。对于每个块，  namenode返回具有该块所有副本的datanode位置地址列表，并且该地址列表是排序好的，  与客户端的 网络拓扑距离近的排序靠前。 

3、  DistributedFileSystem将FSDataInputStream输入流返回到客户端以供其读取数据。

4、客户端在FSDataInputStream输入流上调用read()方法。然后，已存储DataNode地址的InputStream连接到文件 中第一个块的最近的DataNode。数据从DataNode流回客户端，  结果客户端可以在流上重复调用read  ()  。

5、当该块结束时，  FSDataInputStream将关闭与DataNode的连接，然后寻找下一个block块的最佳datanode位置。 这些操作对用户来说是透明的。所以用户感觉起来它一直在读取一个连续的流。客户端从流中读取数据时，也会根据需要询问NameNode来检索下一批数据块的DataNode位置信息。

6、一旦客户端完成读取，就对FSDataInputStream调用close()方法。

相关内容

分布式计算mapreduce与yarn工作机制

一、第一代hadoop组成与结构

第一代Hadoop，由分布式存储系统HDFS和分布式计算框架MapReduce组成，其中，HDFS由一个NameNode和多个DataNode组成，MapReduce由一个JobTracker和多个TaskTracker组成，对应Hadoop版本为Hadoop 1.x和0.21.X，0.22.x。  

1、MapReduce角色分配

Client ：作业提交发起者。

JobTracker: 初始化作业，分配作业，与TaskTracker通信，协调整个作业。

TaskTracker：保持JobTracker通信，在分配的数据片段上执行MapReduce任务。

2、MapReduce执行流程

（1）提交作业

在作业提交之前，需要对作业进行配置

程序代码，主要是自己书写的MapReduce程序。

输入输出路径

其他配置，如输出压缩等。

配置完成后，通过JobClinet来提交

（2）作业的初始化

客户端提交完成后，JobTracker会将作业加入队列，然后进行调度，默认的调度方法是FIFO调试方式。

（3）任务的分配

TaskTracker和JobTracker之间的通信与任务的分配是通过心跳机制完成的。

TaskTracker会主动向JobTracker询问是否有作业要做，如果自己可以做，那么就会申请到作业任务，这个任务可以使Map也可能是Reduce任务。

（4）任务的执行

申请到任务后，TaskTracker会做如下事情：

拷贝代码到本地

拷贝任务的信息到本地

启动JVM运行任务

（5）状态与任务的更新

任务在运行过程中，首先会将自己的状态汇报给TaskTracker，然后由TaskTracker汇总告之JobTracker。

任务进度是通过计数器来实现的。

（6）作业的完成

JobTracker是在接受到最后一个任务运行完成后，才会将任务标志为成功。

此时会做删除中间结果等善后处理工作。

二、第二代hadoop组成与结构

第二代Hadoop，为克服Hadoop 1.0中HDFS和MapReduce存在的各种问题而提出的。针对Hadoop 1.0中的单NameNode制约HDFS的扩展性问题，提出了HDFS Federation，它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展；针对Hadoop 1.0中的MapReduce在扩展性和多框架支持方面的不足，提出了全新的资源管理框架YARN(Yet Another Resource Negotiator)，它将JobTracker中的资源管理和作业控制功能分开，分别由组件ResourceManager和ApplicationMaster实现，其中，ResourceManager负责所有应用程序的资源分配，而ApplicationMaster仅负责管理一个应用程序。对应Hadoop版本为Hadoop 0.23.x和2.x。

1、 yarn运行架构

YARN 是下一代Hadoop计算平台，如下所示：

在 YARN 架构中，一个全局ResourceManager 以主要后台进程的形式运行，它通常在一台独立机器上运行，在各种竞争的应用程序之间仲裁可用的集群资源。

ResourceManager会追踪集群中有多少可用的活动节点和资源，协调用户提交的哪些应用程序应该在何时获取这些资源。ResourceManager是惟一拥有此信息的进程，所以它可通过某种共享的、安全的、多租户的方式制定分配（或者调度）决策（例如，依据应用程序优先级、队列容量、ACLs、数据位置等）。

在用户提交一个应用程序时，一个称为ApplicationMaster的轻量型进程实例会启动来协调应用程序内的所有任务的执行。这包括监视任务，重新启动失败的任务，推测性地运行缓慢的任务，以及计算应用程序计数器值的总和。这些职责以前是分配给单个 JobTracker来完成的。ApplicationMaster和属于它的应用程序的任务，在受NodeManager控制的资源容器中运行。

NodeManager是TaskTracker的一种更加普通和高效的版本。没有固定数量的 map 和 reduce slots，NodeManager 拥有许多动态创建的资源容器。容器的大小取决于它所包含的资源量，比如内存、CPU、磁盘和网络 IO。目前，仅支持内存和 CPU (YARN-3)。一个节点上的容器数量，由节点资源总量（比如总CPU数和总内存）共同决定。

需要说明的是：ApplicationMaster可在容器内运行任何类型的任务。例如，MapReduce ApplicationMaster请求一个容器来启动map或reduce 任务，而 Giraph ApplicationMaster请求一个容器来运行Giraph任务。

我们还可以实现一个自定义的 ApplicationMaster 来运行特定的任务，进而发明出一种全新的分布式应用程序框架，改变大数据格局。

在YARN中，MapReduce降级为一个分布式应用程序的一个角色（但仍是一个非常流行且有用的角色），现在称为 MRv2。MRv2 是经典MapReduce引擎（称为 MRv1）的重现，运行在YARN之上。

2、YARN可运行任何分布式应用程序

ResourceManager、NodeManager 和容器都不关心应用程序或任务的类型。所有特定于应用程序框架的代码都会转移到ApplicationMaster，以便任何分布式框架都可以受 YARN 支持。

得益于这个一般性的方法，Hadoop YARN集群可以运行许多不同分布式计算模型，例如：MapReduce、Giraph、Storm、Spark、Tez/Impala、MPI等。

3、YARN中提交应用程序

下面讨论在应用程序提交到YARN集群时，ResourceManager、ApplicationMaster、NodeManagers和容器如何相互交互。下图显示了一个例子。

假设用户采用与MRv1中相同的方式键入hadoop jar命令，将应用程序提交到 ResourceManager。ResourceManager维护在集群上运行的应用程序列表，以及每个活动的 NodeManager上的可用资源列表。

ResourceManager 需要确定哪个应用程序接下来应该获得一部分集群资源。该决策受到许多限制，比如队列容量、ACL 和公平性。ResourceManager 使用一个可插拔的 Scheduler。Scheduler 仅执行调度；它管理谁在何时获取集群资源（以容器的形式），但不会对应用程序内的任务执行任何监视，所以它不会尝试重新启动失败的任务。

在 ResourceManager接受一个新应用程序提交时，Scheduler制定的第一个决策是选择将用来运行ApplicationMaster的容器。在 ApplicationMaster启动后，它将负责此应用程序的整个生命周期。首先也是最重要的是，它将资源请求发送到 ResourceManager，请求运行应用程序的任务所需的容器。

资源请求是对一些容器的请求，用以满足一些资源需求，比如：

一定量的资源，目前使用MB内存和CPU份额来表示

一个首选的位置，由主机名、机架名称指定

此应用程序中的一个优先级，而不是跨多个应用程序

如果可能的话，ResourceManager 会分配一个满足ApplicationMaster在资源请求中所请求的容器（表达为容器 ID和主机名）。该容器允许应用程序使用特定主机上给定的资源量。分配一个容器后，ApplicationMaster会要求NodeManager（管理分配容器的主机）使用这些资源来启动一个特定于应用程序的任务。此任务可以是在任何框架中编写的任何进程（比如一个 MapReduce 任务或一个Giraph任务）。

NodeManager 不会监视任务；它仅监视容器中的资源使用情况，例如，如果一个容器消耗的内存比最初分配的更多，它会结束该容器。

ApplicationMaster会竭尽全力协调容器，启动所有需要的任务来完成它的应用程序。它还监视应用程序及其任务的进度，在新请求的容器中重新启动失败的任务，以及向提交应用程序的客户端报告进度。

应用程序完成后，ApplicationMaster 会关闭自己并释放自己的容器。

尽管ResourceManager不会对应用程序内的任务执行任何监视，但它会检查 ApplicationMaster的健康状况。如果 ApplicationMaster失败，ResourceManager 可在一个新容器中重新启动它。我们可以认为ResourceManager负责管理ApplicationMaster，而 ApplicationMasters负责管理任务。

本文出自 “爱维Linux” 博客，请务必保留此出处http://ixdba.blog.51cto.com/2895551/1870189