大数据篇--HDFS_hdfs架构图

一、HDFS架构

1.前言：

  HDFS(Hadoop Distributed File System)是我们熟知的Hadoop分布式文件系统，分布式文件系统 distributed file system 是指文件系统管理的物理存储资源不一定直接链接在本地节点上，而是通过计算机网络与节点相连，可让多机器上的多用户分享文件和存储空间。HDFS是一个高容错的系统，能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。
  本文根据Hadoop官网HDFS Architecture这一章节提炼而成。

参考官网：https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
也可以参考中文网址：http://hadoop.apache.org/docs/r1.0.4/cn/hdfs_design.html
 

2.架构详解：

hdfs架构图如下图所示：

  HDFS具有主/从架构。HDFS集群由单个NameNode，和多个datanode构成。

NameNode：Namenode是一个中心服务器，负责管理文件系统的命名空间(namespace)以及客户端对文件的访问。Namenode执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录。负责管理文件目录、文件和block的对应关系以及block和datanode的对应关系，维护目录树，接管用户的请求。如下图所示：

• 将文件的元数据保存在一个文件目录树中
• 在磁盘上保存为：fsimage 和 edits
• 保存datanode的数据信息的文件，在系统启动的时候读入内存

  因为它是系统的大管家，如果这个玩意坏了，丢失了怎么办。就相当于你系统的引导区坏了。那就玩完了。整个文件系统就崩溃了。 所以，这个重要的东西，需要备份。这个时候就产生了一个叫 seconndary Namenode 的节点用来做备份，它会定期的和 namenode 进行通信来完成整个备份操作。具体的操作如下：

  SecondaryNameNode主要负责下载NameNode中的fsImage文件和Edits文件，并合并生成新的fsImage文件，并推送给NameNode，工作原理如下：
（1）请求主namenode停止使用edits文件，暂时将新的写操作记录到一个新的文件中；
（2）从主namenode获取fsimage和edits文件（通过http get）
（3）将fsimage文件载入内存，逐一执行edits文件中的操作，创建新的fsimage文件。
（4）将新的fsimage文件发送回主namenode（使用http post）.
（5）namenode用从secondarynamenode接收的fsimage文件替换旧的fsimage文件；用步骤1所产生的edits文件替换旧的edits文件。同时，还更新fstime文件来记录检查点执行时间。
（6）最终，主namenode拥有最新的fsimage文件和一个更小的edits文件。当namenode处在安全模式时，管理员也可调用hadoop dfsadmin –saveNameSpace命令来创建检查点。

  从上面的过程中我们清晰的看到secondarynamenode和主namenode拥有相近内存需求的原因（因为secondarynamenode也把fsimage文件载入内存）。因此，在大型集群中，secondarynamenode需要运行在一台专用机器上。

DataNode：（数据节点）管理连接到它们运行的​​节点的存储，负责处理来自文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。启动DN线程的时候会向NN汇报block信息。

Client：(客户端)代表用户通过与nameNode和datanode交互来访问整个文件系统，用户通过客户端（Client）与HDFS进行通讯交互。HDFS对外开放文件命名空间并允许用户数据以文件形式存储。

• 文件切分。文件上传 HDFS 的时候，Client 将文件切分成一个一个的Block，然后进行存储。
• 与 NameNode 交互，获取文件的位置信息。
• 与 DataNode 交互，读取或者写入数据。
• Client 提供一些命令来管理 HDFS，比如启动或者关闭HDFS。
• Client 可以通过一些命令来访问 HDFS。

3.块和复制：

  我们都知道linux操作系统中的磁盘的块的大小默认是512Byte，而hadoop2.x版本中的块的大小默认为128M， 若文件大小不到128M，则单独存成一个block，默认情况下每个block都有三个副本，Block大小和副本数通过Client端上传文件时设置，文件上传成功后副本数可以变更，Block Size不可变更。
  那为什么要以块的形式存储文件，而不是整个文件呢？

• 因为一个文件可以特别大，可以大于一个磁盘的容量，所以以块的形式存储，可以用来存储无论大小怎样的文件
• 简化存储系统的设计。因为块是固定的大小，计算磁盘的存储能力就容易多了
• 以块的形式存储不需要全部存在一个磁盘上，可以分布在各个文件系统的磁盘上，有利于复制和容错，数据本地化计算

  NameNode 控制所有的数据块的复制决策，如下图所示。它周期性地从集群中的 DataNode 中收集心跳和数据块报告。收集到心跳则意味着 DataNode 正在提供服务。收集到的数据块报告会包含相应 DataNode 上的所有数据块列表。

  当一切运行正常时，DataNode 会周期性发送心跳信息给 NameNode（默认是每 3 秒钟一次）。如果 NameNode 在预定的时间内没有收到心跳信息（默认是 10 分钟），就会认为 DataNode 出现了问题，这时候就会把该 DataNode 从集群中移除，并且启动一个进程去恢复数据。DataNode 脱离集群的原因有多种，如硬件故障、主板故障、电源老化和网络故障等。
  对于 HDFS 来说，丢失一个 DataNode 意味着丢失了存储在它的硬盘上的数据块的副本。假如在任意时间总有超过一个副本存在，故障将不会导致数据丢失。当一个硬盘故障时，HDFS 会检测到存储在该硬盘上的数据块的副本数量低于要求，然后主动创建需要的副本，以达到满副本数状态。

二、HDFS读写流程

  HDFS 的文件访问机制为流式访问机制，即通过 API 打开文件的某个数据块之后，可以顺序读取或者写入某个文件。由于 HDFS 中存在多个角色，且对应的应用场景主要为一次写入、多次读取的场景，因此其读和写的方式有较大不同。读/写操作都由客户端发起，并且由客户端进行整个流程的控制，NameNode 和 DataNode 都是被动式响应。

1.读取流程：

  客户端发起读取请求时，首先与 NameNode 进行连接。连接建立完成后，客户端会请求读取某个文件的某一个数据块。NameNode 在内存中进行检索，查看是否有对应的文件及文件块，若没有则通知客户端对应文件或数据块不存在，若有则通知客户端对应的数据块存在哪些服务器之上。
  客户端接收到信息之后，与对应的 DataNode 连接，并开始进行数据传输。客户端会选择离它最近的一个副本数据进行读操作。如下图所示，读取文件的具体过程如下。

1. 客户端调用 DistributedFileSystem 的 Open() 方法打开文件。
2. DistributedFileSystem 用 RPC 连接到 NameNode，请求获取文件的数据块的信息；NameNode 返回文件的部分或者全部数据块列表；对于每个数据块，NameNode 都会返回该数据块副本的 DataNode 地址；DistributedFileSystem 返回 FSDataInputStream 给客户端，用来读取数据。
3. 前两步会返回一个FSDataInputStream对象，该对象会被封装成 DFSInputStream对象，DFSInputStream可以方便的管理datanode和namenode数据流。客户端调用read方法，DFSInputStream就会找出离客户端最近的datanode并连接datanode。
4. 通过数据流反复调用read()方法，可以将数据从datanode传送到客户端。
5. 当读完这个块时，DFSInputStream关闭与该datanode的连接，然后寻址下一个位置最佳的datanode。
6. 当客户端读取完所有数据块的数据后，调用 Close() 方法关闭掉所有的流。

  在读取数据的过程中，如果客户端在与数据结点通信时出现错误，则尝试连接包含此数据块的下一个数据结点。失败的数据结点将被记录，并且以后不再连接。

2.写入流程：

  写入文件的过程比读取较为复杂，在不发生任何异常情况下，客户端向 HDFS 写入数据的流程如下图所示，具体步骤如下：

1. 客户端调用 DistribuedFileSystem 的 Create() 方法来创建文件。
2. DistributedFileSystem 通过 RPC（远程过程调用）调用 NameNode，去创建一个没有blocks关联的新文件。创建前，NameNode 会做各种校验，比如文件是否存在，客户端有无权限去创建等。如果校验通过，NameNode 就会记录下新文件，否则就会抛出IO异常。
3. 前两步结束后会返回 FSDataOutputStream 的对象，和读文件的时候相似，FSDataOutputStream 被封装成 DFSOutputStream，DFSOutputStream 可以协调 NameNode和 DataNode。客户端开始写数据到DFSOutputStream,DFSOutputStream会把数据切成一个个小packet，然后排成队列 data queue。
4. DataStreamer 会去处理接受 data queue，它先问询 NameNode 这个新的 block 最适合存储的在哪几个DataNode里，比如重复数是3，那么就找到3个最适合的 DataNode，把它们排成一个 pipeline。DataStreamer 把 packet 按队列输出到管道的第一个 DataNode 中，第一个 DataNode又把 packet 输出到第二个 DataNode 中，以此类推。
   队列中的分包被打包成数据包，发往数据流管道中的第一个 DataNode。第一个 DataNode 将数据包发送给第二个 DataNode，第二个 DataNode 将数据包发送到第三个 DataNode。这样，数据包会流经管道上的各个 DataNode。
5. 为了保证所有 DataNode 的数据都是准确的，接收到数据的 DataNode 要向发送者发送确认包（ACK Packet）。确认包沿着数据流管道反向而上，从数据流管道依次经过各个 DataNode，并最终发往客户端。当客户端收到应答时，它将对应的分包从内部队列中移除。
6. 客户端完成写数据后，调用close方法关闭写入流。这个操作会冲洗（flush）所有剩下的package到pipeline中。
7. 等待这些package确认成功，然后通知namenode写入文件成功。这时候namenode就知道该文件由哪些block组成（因为DataStreamer向namenode请求分配新block，namenode当然会知道它分配过哪些blcok给给定文件）。

三、HDFS HA

  HDFS HA（High Availability）是为了解决单点故障问题；HA集群设置两个名称节点，“活跃（Active）”和“待命（Standby）”；两种名称节点的状态同步，可以借助于一个共享存储系统来实现；一旦活跃名称节点出现故障，就可以立即切换到待命名称节点；Zookeeper确保一个名称节点在对外服务；名称节点维护映射信息，数据节点同时向两个名称节点汇报信息；

1.基于NFS共享存储解决方案：

  Active NN与Standby NN通过NFS实现共享数据，但如果Active NN与NFS之间或Standby NN与NFS之间，其中一处有网络故障的话，那就会造成数据同步问题。

2.基于Qurom Journal Manager(QJM)解决方案：

架构如下图：

  Active NN、Standby NN有主备之分，NN Active是主的，NN Standby备用的。
  集群启动之后，一个namenode是active状态，来处理client与datanode之间的请求，并把相应的日志文件写到本地中或JN中。
  Active NN与Standby NN之间是通过一组JN共享数据（JN一般为奇数个，ZK一般也为奇数个），Active NN会把日志文件、镜像文件写到JN中去，只要JN中有一半写成功，那就表明Active NN向JN中写成功啦，Standby NN就开始从JN中读取数据，来实现与Active NN数据同步，这种方式支持容错，因为Standby NN在启动的时候，会加载镜像文件（fsimage）并周期性的从JN中获取日志文件来保持与Active NN同步。
  为了实现Standby NN在Active NN挂掉之后，能迅速的再提供服务，需要DN不仅需要向Active NN汇报，同时还要向Standby NN汇报，这样就使得Standby NN能保存数据块在DN上的位置信息，因为NameNode在启动过程中最费时的工作，就是处理所有DN上的数据块的信息。
  为了实现Active NN高热备，增加了FailoverController和ZK，FailoverController通过Heartbeat的方式与ZK通信，通过ZK来选举，一旦Active NN挂掉，就选取另一个FailoverController作为active状态，然后FailoverController通过rpc，让standby NN转变为Active NN。
  FailoverController一方面监控NN的状态信息，一方面还向ZK定时发送心跳，使自己被选举。当自己被选为主（Active）的时候，就会通过rpc使相应NN转变Active状态。

具体配置实现参考官网NameNode HA：https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html
YARN HA：https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html
和我写得一篇文章：搭建hadoop2.6.0 HDFS HA及YARN HA

四、hadoop2.x新特性

  hadoop1.0是最早的版本，只是在google上发表的三篇论文转变过来的。所以hadoop1.0在开发过程当中存在诸多的缺陷，hadoop1.0主要是有HDFS(分布式系统)和一个分布式计算框架（MapReduce）组成的。
  hadoop1.0中，NameNode节点有且只有一个，虽然可以通过SecondaryNameNode进行主节点数据备份，但是存在延时情况，假如主节点挂掉，这时部分数据还未同步到SecondaryNameNode节点上，就会存在资源数据的缺失。因为NameNode是存储着DataNode节点等元数据信息。
  对于MapReduce，hadoop1.0也是一个简单的主从结构，是有一个主JobTracker和多个从的TaskTracker组成，而且在hadoop1.0中JobTracker任务繁重：负责接收客户端的计算任务，同时要把任务分发给TaskTracker进行执行；通过心跳机制来管理TaskTracker节点的运行情况。
  在hadoop2.0当中增加了YARN框架，针对hadoop1.0中主JobTracker压力太大的不足，把JobTracker资源分配和作业控制分开，利用Resource Manager在namenode上进行资源管理调度，利用ApplicationMaster进行任务管理和任务监控。由NodeManager替代TaskTracker进行具体任务的执行，因此MapReduce2.0只是一个计算框架。对比hadoop1.0中相关资源的调用全部给Yarn框架管理。

• 引入了NameNode Federation，解决了横向内存扩展
• 引入了Namenode HA，解决了namenode单点故障
• 引入了YARN，负责资源管理和调度
• 增加了ResourceManager HA解决了ResourceManager单点故障

1.NameNode Federation：

架构如下图：

• 在HDFS Federation中，设计了多个相互独立的名称节点，使得HDFS的命名服务能够水平扩展，这些名称节点分别进行各自命名空间和块的管理，相互之间是联盟（Federation）关系，不需要彼此协调。并且向后兼容。
• HDFS Federation中，所有名称节点会共享底层的数据节点存储资源，数据节点向所有名称节点汇报。

  这样做的好处就是当NN内存受限时，能扩展内存，解决内存扩展问题，而且每个NN独立工作相互不受影响，比如其中一个NN挂掉啦，它不会影响其他NN提供服务，但我们需要注意的是，虽然有多个NN，分管不同的目录，但是对于特定的NN，依然存在单点故障，因为没有它没有热备，解决单点故障使用NameNode HA。

2.结合HDFS2的新特性，在实际生成环境中部署图：

  这里有12个DN,有4个NN，NN-1与NN-2是主备关系，它们管理/share目录；NN-3与NN-4是主备关系，它们管理/user目录。

3.hadoop3.x：

  hadoop2.0之后版本就相对稳定，大部分实际生产环境中都使用的是2.0，包括本次我们教程也是基于2.0上进行讲解，hadoop3.0主要增加了一些性能上的优化和支持：

• java运行环境升级为1.8，对之前低版本的Java不在支持。
• HDFS3.0支持数据的擦除编码，调高存储空间的使用率。
• 一些默认端口的改变。
• 增加一些MapReduce的调优。

参考：初步掌握HDFS的架构及原理