大数据处理从零开始————4.认识HDFS分布式文件系统

1.分布式文件系统HDFS        

1.1 认识HDFS        

        当单台服务器的存储容量和计算性能已经无法处理大文件时，分布式文件系统应运而生。什么是分布式系统，分布式系统是由多个独立的计算机或节点组成的系统，这些计算机通过网络连接，协同工作，以实现共同的目标或完成某些任务。Hadoop的分布式文件系统HDFS是基于Google的GFS（Google File System）论文建立的。HDFS优化了大数据的存储和访问，为处理海量数据提供了解决方案。

GFS架构图

        HDFS是一个典型的Master/ Slave（主从）架构模型系统，旨在管理大型分布式数据集和密集计算。什么是主从架构？主从架构是一种特殊的分布式架构，其中一个节点担任主节点（Master），其他节点担任从节点（Slave）。主节点负责处理读写请求，而从节点负责处理只读请求。这种架构可以提高系统的可扩展性和可用性，实现读写分离和负载均衡。

主从架构图

       

        在最新的Hadoop版本中，一个HDFS集群是由一个NameNode和多个DataNode组成。

        NameNode：HDFS的主节点，负责管理文件系统的元数据（例如，文件和目录的命名空间、文件到数据块的映射关系等）。通过内存中的数据结构来存储文件的元数据，确保快速访问。NameNode不存储实际的数据，而是存储数据块的位置。

        DataNode：HDFS的工作节点，负责实际存储数据块。每个文件在HDFS中被划分为若干个块，并分散存储在不同的DataNode上。DataNode定期向NameNode汇报它们存储的块的状态，以便NameNode能够维护一份最新的元数据。

        HDFS设计用于在通用硬件上运行，高度容错且适合部署在廉价机器上，提供高吞吐量的数据访问，非常适合大规模数据集应用。HDFS放宽了部分POSIX约束，以支持流式读取。最初，HDFS为Apache Nutch搜索引擎项目开发，也是Apache Hadoop Core项目的核心组成部分，为分布式计算框架MapReduce提供底层存储支持。

1.2 HDFS的优势

        HDFS设计上有以下的优点：

        1.高可靠性：HDFS通过在多个节点上存储数据的多个副本来提供容错能力。当某个节点发生故障时，系统可以从其他节点上的副本恢复数据，从而确保数据的完整性和可用性。这种设计减少了单点故障的风险，提高了系统的可靠性。

HDFS高容错性原因

         2.可扩展性：HDFS能够轻松添加新的节点到集群中，而不需要停机，支持成千上万个节点。这种设计允许系统有弹性地处理不断增长的数据量，确保用户根据需求扩展存储和计算能力。

         3.高吞吐量：HDFS优化了数据的读写操作，特别是对于大规模数据集的批量处理。它通过将大文件分割成多个块，并在多个节点上并行处理这些块，从而提高了数据处理的效率。这种设计减少了数据传输的延迟，提高了整体的处理速度

         4.适合大数据应用：HDFS的设计特别适合处理大规模数据集，这使得它成为数据密集型应用的理想选择。例如，在数据挖掘和机器学习中，需要处理和分析大量的数据，HDFS提供了必要的基础设施来支持这些操作。

        5.成本效益：HDFS可以使用普通的硬件构建，这意味着用户不需要购买昂贵的专业存储设备。通过使用标准的服务器和硬件，HDFS降低了构建和维护大规模存储系统的基础设施成本。此外，由于其容错能力，它减少了因硬件故障导致的额外成本。

1.3 HDFS的局限性

        HDFS也有以下局限性：

     （1）低时间延迟的数据访问：HDFS要求低时间延迟数据访问的应用，例如几十毫秒内的应用不适合在HDFS上运行。HDFS是为高数据吞吐量应用优化的，这会以提高时间延迟为代价。如果有对低延迟访问需求的应用，建议使用HBase会更好一些。

     （2）存储大量的小文件：由于NameNode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总数受限于NameNode的内存容量。每个文件、目录和数据块的存储信息大约占150个字节。因此，举例来说，如果有一百万个文件，且每个文件占一个数据块，那至少需要300MB的内存。但是如果存储数据十亿的文件就超出了当前硬件的能力。所以存储文件时尽量将小文件合并成较大的文件。

     （3）不支持并发写入、文件随机修改：一个文件只能有一个写，不允许多个线程同时写，这种设计有助于简化数据一致性管理，因为不需要处理并发写入带来的复杂性，对于需要并发写入的应用，HDFS可能不是最佳选择。在这种情况下，可以考虑使用支持并发写入的文件系统或数据库；仅支持数据append（追加），不支持文件的随机修改，这意味着一旦文件被创建，只能向文件末尾添加数据，而不能修改文件的中间部分，这种限制使得HDFS不适合需要频繁修改文件内容的应用，如某些类型的事务处理系统。

2.HDFS的特性和设计目标

2.1 HDFS的特性

        高度容错，可扩展性及可配置性强。

        跨平台。使用Java语言开发，以JVM为运行环境，支持多个主流平台的环境。

        Shell命令接口。HDFS拥有一套文件系统操作的Shell命令，可以用来直接操作HDFS文件系统。

        Web管理平台。NameNode和DataNode内置有Web服务器，方便用户检查集群的当前运行状态。

        文件权限管理。Hadoop分布式文件系统实现了一个和POSIX系统类似的文件和目录的权限模型。每个文件和目录有一个所有者（owner）和一个组（group）。文件或目录对其所有者、同组的其他用户以及所有其他用户分别有不同的权限。

        机架感知功能。机架感知功能使得Hadoop在任务调度和分配存储空间时系统会考虑节点的物理位置，从而实现高效的访问和计算。

        安全模式。安全模式是Hadoop的一种保护机制，用于保证集群中的数据块的安全性。集群维护时进入这种管理模式。当集群启动时会首先进入安全模式。当系统处于安全模式时会检查数据块的完整性。

        Rebalancer功能。当DataNode之间数据不均衡时，可以平衡集群上的数据负载，实现数据负载均衡。

        允许升级和回滚。在软件更新后有异常情况发生时，HDFS允许系统回滚到更新或升级之前的状态。

2.1 HDFS的设计目标

        检测和快速恢复硬件故障：硬件错误是常态而不是异常。因此错误检测和快速、自动的恢复是HDFS最核心的架构目标。

         流式数据访问：运行在HDFS上的应用和普通的应用不同，需要流式访问它们的数据集。比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。

        大规模数据集：运行在HDFS上的应用具有很大的数据集。因此，HDFS被调节以支持大文件存储。
        简化一致的模型：“一次写入多次读取”的文件访问模型。一个文件经过创建、写入和关闭之后就不需要改变。这一假设简化了数据一致性问题，并且使高吞吐量的数据访问成为可能。

        移动计算的代价比移动数据的代价低：一个应用请求的计算，离它操作的数据越近就越高效，在数据达到海量级别的时候更是如此。因为这样就能降低网络阻塞的影响，提高系统数据的吞吐量。

        在不同的软硬件平台间的可移植性：HDFS在设计的时候就考虑到平台的可移植性。这种特性方便了HDFS作为大规模数据应用平台的推广。

        健壮性：在出错时也要保证数据存储的可靠性。

        标准的通信协议：所有的HDFS通讯协议都是建立在TCP/IP协议之上。客户端通过一个可配置的TCP端口连接到Namenode，通过ClientProtocol协议与Namenode交互。

3. HDFS的核心概念

3.1 数据块

        HDFS文件系统的块比一般文件系统的块要大得多，默认为128MB（Hadoop 2.X）或256MB（hadoop3.x），并且可以根据实际需求进行配置，通过配置hdfs-site.xml文件中的dfs.block.size属性，可以改变块的大小。与一般文件系统相似，HDFS上的文件也被划分为块大小的多个分块，作为独立的存储单元，它是HDFS文件系统存储处理数据的最小单元。但是与其他文件系统不同的是，HDFS中小于一个块大小的文件并不会占据整个块的空间。例如：一个128MB的数据块，有一个文件大小10MB，那么剩下的118MB空间还可以被其他文件使用.

        这里不知道大家有没有产生一个疑惑，为什么HDFS的数据块如此之大？其实HDFS的块比磁盘的块大，其目的是为了最小化寻址开销。如果块设置得足够大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间，因此，传输一个由多个块组成的文件的时间取决于磁盘传输的速率。例如：要传输100MB的数据，假设寻址时间为10ms，而传输的速率为100MB/s：如果我们将块大小设置为100MB，这时寻址的时间仅占传输时间的1%；如果将块的大小设置为10MB，这时寻址的时间会占传输时间的10%。所以在允许的范围内，增加块的大小，可以有效缩短数据传输的时间。所以以后随着新一代磁盘驱动器传输速率的提升，块的大小将被设置的更大。但是，这个数也不会设置得过大。如果任务数太少（少于集群中的节点数量），作业的运行速度也会受到很大的影响。

        像HDFS这样的数据块设计被成为数据块抽象设计。数据块抽象设计可以带来以下三点设计：

        1.一个文件的大小可以大于集群中任意一个磁盘的容量。块的设计实际上就是对文件进行分片，分片可以保存在集群的任意节点，从而使文件存储不受单一磁盘大小和机器的限制，例如，一个文件可以被切分成为3个块，并存放在3个不同的DataNode中。
        2.简化存储子系统。将存储子系统控制单元设置为块，可以简化存储管理，并且也实现了元数据和数据的分开管理和存储。
        3.块还非常适合用于数据备份，提供数据冗余，进而提高数据容错能力和提高可用性。这是块非常重要的一点，例如，在保存数据时，可以为数据提供多个副本，那么在任意一个块损坏时，都不会影响数据的完整性，用户在读取文件时，并不会察觉到异常。集群会将损坏的块的副本从其他候选节点复制到集群正常工作的节点以后，将损坏的块删除掉，从而使副本数量回到配置的水平。

3.2 数据快复制

        HDFS被设计成一个可以在大型集群中跨机器并可靠地存储海量数据的框架。在HDFS中以块（Block）序列存储文件，除了最后一个Block，所有的Block都是同样大小的。HDFS的容错机制确保所有的Block都会被复制以达到冗余的目的。每个文件的Block的大小和复制因子（Replication）都是可配置的。在文件创建时会默认读取客户端的HDFS配置，然后创建Replication因子，也可以根据实际情况进行修改。HDFS中的文件只写入一次（write-one），并且严格要求在任何时候只有一个写入者（writer）。

        上图显示了Replication因子和Block存储的关系：
        文件/users/sameerp/data/part-0的Replication因子值是2，Block的ID列表包括了1和3，可以看到块1和块3分别被冗余复制了两份数据块。
        文件/users/sameerp/data/part-1的Replication因子值是3，Block的ID列表包括了2、4和5，可以看到块2、块4和块5分别被冗余复制了三份数据块。

3.3 数据副本的存放策略

        HDFS默认的副本复制因子是3。为了数据的安全和高效，Hadoop默认对3个副本的存放策略，如下图所示：

        第一个Block副本放在client所在机架的node里（如果client不在集群范围内，则存放这第一个Block副本的node是随机选取的，当然系统会尝试不选择哪些太满或者太忙的node）。
        第二个Block副本放置在与第一个Block副本不同机架的node中（随机选择）。
        第三个Block副本和第二个Block副本在同一个机架，随机放在不同的node中。

        在我们了解了数据块存放策略之后，接着看看如何设置集群Block的备份数？

        方法1：修改配置文件hdfs-site.xml。（需要重启HDFS系统才能生效）

        <property><name>dfs.replication</name><value>1</value></property>

        默认dfs.replication的值为3，通过这种方法虽然更改了配置文件，但是参数只在文件被写入dfs时起作用，不会改变之前写入的文件的备份数。

        方法2：通过命令更改备份数。（不需要重启HDFS系统即可生效）

# bin/hadoop fs -setrep -R 1 /

3.4 机架感知(原理)

        HDFS（Hadoop Distributed File System）中的副本存放策略通过机架感知实现了可靠性与性能之间的平衡。NameNode作为HDFS的中心组件，负责管理文件系统的元数据，并周期性接收DataNode的心跳和块报告，以维护系统健康。简单的副本放置策略将副本分散到不同机架或IDC，以增强数据冗余性，但这种方法增加了写入时在多个机架间的数据传输，从而降低了性能。因此，机架感知策略则在同一机架和不同机架之间合理分配副本，通常一个副本存放在本地机架，其他副本分布在不同机架，既保证了高冗余性，防止单一机架故障造成的数据丢失，又减少了网络带宽消耗和延迟，提升了数据访问效率。机架感知机制对需要高可用性和大规模数据处理的应用场景尤为重要。

        机架感知功能需要 net.topology.script.file.name 属性定义的可执行文件（或者脚本）来实现，文件提供了NodeIP对应RackID的翻译。如果 net.topology.script.file.name 没有设定，则每个IP都会翻译成/default-rack。
        默认Hadoop机架感知是没有启用的，需要在NameNode机器的core-site.xml里配置一个选项，例如：

<property><name>net.topology.script.file.name</name><value>/home/hadoop/hadoop-3.3.3/etc/hadoop/topology.sh</value>
</property>

        这个配置选项的value指定为一个可执行程序，通常为一个脚本，该脚本接受一个参数，输出一个值。接收参数通常为DataNode机器的ip地址，而输出的值通常为该ip地址对应的DataNode所在的RackID，例如”/rack1”。
 

        当没有配置机架感知信息时
        所有的机器上的Hadoop都默认在同一个默认的机架下，名为 “/default-rack”，此时，任何一台DataNode机器，不管物理上是否属于同一个机架，都会被认为是在同一个机架下，此时，就很容易出现之前提到的增添机架间网络负载的情况。
        在没有机架信息的情况下，NameNode默认将所有的slaves机器全部默认为在/default-rack下，此时写Block时，所有DataNode机器的选择完全是随机的。

        当配置了机架感知信息以后，Hadoop在选择三个DataNode时，就会进行相应的判断：
        如果上传文件的机器是一个DataNode，那么就将该DataNode本身作为第一个块写入机器(DataNode 1)。否则，就从所有slave机器中随机选择一台作为第一个块的写入机器(DataNode 1)。
        在DataNode 1所属机架以外的另一个机架上随机的选择一台，作为第二个块的写入机器(DataNode 2)。
        在DataNode 2所在机架上选择一台作为第三个块的写入机器(DataNode 3)。如果前两个DataNode是在同一个机架，那么就选择另外一个机架上的DataNode作为第三个块的写入机器(DataNode 3)。
        NameNode得到3个DataNode的列表以后，首先会在NameNode端根据该写入客户端跟DataNode列表中每个DataNode之间的“距离”由近到远进行一个排序。
        当根据“距离”排好序的DataNode节点列表返回给DFSClient以后，DFSClient便会创建Block
OutputStream，并向最近的节点开始写入Block数据。
        写完第一个Block以后，依次按照DataNode列表中的次远的node进行写入，直到最后一个Block写入成功，DFSClient返回成功，该Block写入操作结束。

        我们这里讲的都是基本原理，其实机架感知这部分是要里了解真实的网络拓扑和机架信息。

3.5 安全模式

        安全模式是Hadoop集群的一种保护模式。NameNode在启动时会自动进入安全模式（SafeMode），也可以手动进入。当系统进入安全模式时，会检查数据块的完整性。假设我们设置的副本数是5，那么在DataNode上就应该有5个副本存在，如果只有3个副本，那么比率就是3/5=0.6。在配置文件hdfs-default.xml中定义了一个最小的副本比率是0.999。

<property><name>dfs.safemode.threshold.pct</name><value>0.999f</value>
</property>

        当前的副本比率0.6明显小于0.999，因此系统会自动复制副本到其他的DataNode，当DataNode上报的副本数达到了元数据记录的Block个数的0.999倍时才可以离开安全模式，否则一直是只读模式。如果这个比率设置为1，则永远处于安全模式。同理，如果系统中有8个副本，系统也会删除多余的3个副本。

        当系统处于安全模式时，不接受任何对名称空间的修改，也不会对数据块进行复制或删除，但是可以浏览目录结构、查看文件内容等操作。
        在安全模式下运行Hadoop时，可能会报以下错误：
org.apache.hadoop.dfs.SafeModeException:
                        Cannotdelete/user/hadoop/input. Name node is in safe mode.
        正常情况下，安全模式运行一段时间后就会自动退出，如果希望直接退出，可以使用一些命令来完成：

hadoop dfsadmin -safemode leave //强制退出安全模式
hadoop dfsadmin -safemode enter //进入安全模式
hadoop dfsadmin -safemode get //查看安全模式状态
hadoop dfsadmin -safemode wait //等待，一直到安全模式结束

3.6 负载均衡

        在Hadoop集群中，HDFS的数据并不一定是非常均匀地分布在各个DataNode中。
        机器与机器之间磁盘利用率不平衡是HDFS集群非常容易出现的情况，特别是在DataNode节点出现故障或在现在的集群上增加新的DataNode的时候。当新增一个数据块时，NameNode在选择DataNode接收这个数据块之前，要考虑到很多因素。
        其中的一些因素如下：

• 将数据块的一个副本放在正在写这个数据块的节点上。
• 尽量将数据块的不同副本分布在不同的机架上，这样集群在完全失去某一机架的情况下还能存活。
• 一个副本通常被放置在和写文件的节点同一机架的某个节点上，这样可以减少跨越机架的网络I/O。
• 尽量均匀地将HDFS数据分布在集群的DataNode中。

        由于上述多种考虑需要取舍，数据可能并不会均匀分布在DataNode中。

        当HDFS出现不平衡状况的时候，将引发很多问题，比如MapReduce程序无法很好地利用本地计算的优势，机器之间无法达到更好的网络带宽使用率、机器磁盘无法利用等。可见，保证HDFS中的数据平衡是非常重要的。
        为此，HDFS为管理员提供了一个工具，用于分析数据块分布和重新均衡DataNode上的数据分布：

$ HADOOP_HOME/bin/start-balancer.sh -t 10%

        在这个命令中，-t参数后面跟的是HDFS达到平衡状态的磁盘使用率偏差值。如果机器与机器之间磁盘使用率偏差小于10%，那么我们就认为HDFS集群已经达到了平衡状态。

        负载均衡程序作为一个独立的进程与NameNode进行分开执行。HDFS负载均衡的处理步骤如下：

        ① 数据均衡服务( Rebalancing Server) 首先要求 NameNode 生成 DataNode 数据分布分析报告， 获取每个 DataNode磁盘使用情况。
        ② 数据均衡服务汇总需要移动的数据块分布情况，计算具体数据块迁移路线图， 确保为网络内的最短路径。
        ③ 开始数据块迁移任务, Proxy Source DataNode(代理源数据节点)复制一块需要移动的数据块。
        ④ 将复制的数据块复制到目标 DataNode节点上。
        ⑤ 删除原始数据块及在 NameNode 上存储的元信息， 并将新的元信息更新到 NameNode上。
        ⑥目标 DataNode 向 Proxy Source DataNode 确认该数据块迁移完成。
        ⑦ Proxy Source DataNode 向数据均衡服务确认本次数据块迁移完成， 然后继续执行这个过程， 直至集群达到数据均衡标准。

        上述HDFS的这种负载均衡工作机制在绝大多数情况下都是非常适合的，然而一些特定的场景确实还是需要不同的处理方式，这里假定一种场景：
        复制因子是3。HDFS由两个机架组成。两个机架中的机器磁盘配置不同，第一个机架中每一台机器的磁盘配置为2TB，第二个机架中每一台机器的磁盘配置为12TB。大多数数据的两份备份都存储在第一个机架中。在这样的情况下，HDFS集群中的数据肯定是不平衡的，现在运行负载均衡程序，会发现运行结束以后整个HDFS集群中的数据依旧不平衡：rack1中的磁盘剩余空间远远小于rack2，这是因为负载均衡程序的原则是不能改变每一个机架中所具备的Block数量的。简单地说，就是在执行负载均衡程序的时候，不会将数据从一个机架移到另一个机架中，所以就导致了负载均衡程序永远无法平衡HDFS集群的情况。
        针对于这种情况就需要HDFS系统管理员手动操作来达到负载均衡，操作步骤如下：
        使用现有的负载均衡程序，但修改机架中的机器分布，将磁盘空间小的机器部署到不同的机架中去。
        修改负载均衡程序，允许改变每一个机架中所具有的Block数量，将磁盘空间告急的机架中存放的Block数量减少，或者将其移到其他磁盘空间富余的机架中去。

3.7 心跳机制

        Hadoop集群节点之间的通信是通过心跳机制实现的。所谓“心跳”是指的持续的按照一定频率在运行，执行请求和响应。当长时间没有发送心跳时，NameNode就判断DataNode的连接已经中断，不能继续工作了，就被定性为”dead node”。NameNode会检查"dead node"中的副本数据，复制到其他的DataNode中。

        Hadoop的心跳机制的具体实现思路是：

• 当master节点启动时，会开一个rpc server，等待slave的心跳连接。
• slave节点启动时，会连接到master，并开始每隔3秒钟主动向master发送一个“心跳”，这个时间间隔可以通过heartbeat.recheck.interval属性来设置。
• slave通过“心跳”将自己的状态告诉master，master返回“心跳”值，向slave节点传达指令。
• Hadoop集群中各个进程之间的通信，都是通过“心跳”这种RPC通信来完成的。
• 当NameNode长时间没有接收到DataNode发送的“心跳”时，NameNode就判断DataNode的连接已经中 断，就被定性为”dead node”。NameNode会检查dead node中的副本数据，复制到其他的DataNode中。

4.HDFS体系结构

4.1 HDFS体系结构

        HDFS是一个主/从(Master/slave)体系结构，从最终用户的角度来看，它就像传统的文件系统一样，可以通过目录路径对文件系统执行CRUD(Create、Read、Update、Delete)操作。但由于分布式存储的性质，HDFS集群拥有一个NameNode和一些DataNode。NameNode管理文件系统的元数据，DataNode存储实际的数据。客户端通过同NameNode和DataNode的交互访问文件系统。客户端联系NameNode以获取文件的元数据，而真正的文件I/O操作是直接和DataNode进行交互的。
        例如：一个典型的HDFS集群。
        一个HDFS集群包含一个逻辑上的Master节点和多个Slave节点服务器，一个逻辑上的Master节点可以包括一台或两台物理主机。一台Master服务器组成单NameNode集群，两台Master服务器组成双NameNode集群，并且同时被多个客户端访问，所有的节点服务器都是运行着Linux操作系统的普通商用主机。

        单NameNode节点的HDFS集群架构：

• 单NameNode节点的HDFS集群是由一个NameNode和一定数目的DataNode组成。
• NameNode是一个中心服务器，负责管理文件系统的命名空间和客户端对文件的访问。
• NameNode执行文件系统的命名空间操作，例如打开、关闭、重命名文件和目录，同时决定Block到DataNode节点的映射。
• DataNode负责处理文件系统的读写请求，在NameNode的指挥下进行Block的创建、删除等。
• 一个文件被分成一个或多个Block，这些Block存储在DataNode集合里。

单NameNode节点HDFS集群架构

4.2 HDFS集群各节点解析

        一个典型的HDFS集群通常由NameNode、SecondaryNameNode和DataNode三个节点组成，其实就是运行在这些节点服务器上的进程。

HDFS 架构图

        

        1、NameNode
        NameNode被称为名称节点或元数据节点，是整个集群的管理者。一个集群通常只有一个活动的NameNode节点，通常NameNode独立运行在集群的某个节点上，主要职责是HDFS文件系统的管理工作，具体包括命名空间管理（NameSpace）和文件Block管理。NameNode决定是否将文件映射到DataNode的副本上。
        NameNode的主要功能：

•         NameNode提供名称查询服务，它是一个Jetty服务器
•         NameNode保存metadate信息。具体包括：owership和permissions；文件包括哪些块；Block块保存在哪个DataNode（DataNode通过“心跳”机制上报）
•         NameNode的metadate信息在启动后会加载到内存

        NameNode容错机制：

•         使用SecondaryNameNode恢复NameNode
•         利用NameNode的HA机制

        2、SecondaryNameNode
        SNN会周期性地将Edits文件中记录的对HDFS的操作合并到一个FsImage文件中，然后清空Edits文件。NameNode的重启就会加载最新一个FsImage文件，并重新创建一个Edits文件来记录HDFS操作，Edits中记录的是从上一次FsImage以后到现在的操作列表，所以会比较小。每次重启NameNode的时候，能减少重启的时间，同时也能保证HDFS系统的完整性。

        NN管理的元数据信息会定期的刷到磁盘中，其中的两个文件是edits即操作日志文件和fsimage即元数据镜像文件，新的操作日志会先写到edits中。当edits文件达到临界值或者间隔一段时间checkpoint会触发SNN进行工作。
        触发checkpoint操作时，NameNode会生成一个新的edits.new文件，同时SNN将edits文件和fsimage复制到本地。（checkpoint触发的条件可以在core-site.xml文件中进行配置，如下：）

<property><name>fs.checkpoint.period</name><value>3600</value>
</property>
<property><name>fs.checkpoint.size</name><value>67108864</value>
</property>

        SNN将本地的fsimage文件加载到内存中，然后再与edits文件进行合并生成一个新的fsimage文件即上图中的fsimage.ckpt文件。
        SNN将新生成的fsimage.ckpt文件复制到NN节点。
        在NN结点的edits.new文件和fsimage.ckpt文件会替换掉原来的edits文件和fsimage文件，至此是一个轮回。

        3、DataNode
        DN主要负责数据存储计算的组件，DataNode上存储了数据块的ID和数据块的内容，以及它们的映射关系。DataNode通常以机架的形式组织，机架通过一个交换机将所有系统连接起来。
集群中包含的DataNode定时和NameNode进行通信，接受NameNode的指令，为减轻负担，NameNode并不永久保存哪个DataNode上有哪些数据块信息，而是通过DataNode启动时的上报来更新NameNode上的映射表。DataNode和NameNode建立连接后，就会不断地通过“心跳机制”和NameNode保持联系。
        DataNode的主要功能如下：
        保存Block块，每个块对应一个元数据信息文件。该文件描述这个块属于哪个文件、第几个块等等。
        启动DataNode线程时会向NameNode汇报Block信息。
        通过向NameNode发送心跳以保持与其的联系，如果NameNode10分种没有收到DataNode的心跳，则认为其已经Lost，并将Block的信息复制到其他DataNode上，以保证副本数。