Hadoop学习篇(二)——HDFS

在大数据时代，分布式文件处理系统目前是我们的必然选项。作为Hadoop核心组件之一的HDFS，整个大数据处理技术的学习中，占有主导地位。

上一节内容总结开源计算框架Hadoop的相关基本理论。其中就提到了分布式文件处理系统HDFS这一重要组件。在Hadoop生态系统中，位于底层数据位置，可以看出，HDFS的重要性。

本节内容将围绕HDFS理论基础，即计算机集群和HDFS结构、HDFS相关基本概念、文件系统读写策略等进行总结。实验将重点放在实验报告中总结。

上篇链接：

Hadoop学习篇(一)——初识Hadoop & Hadoop单机配置

Hadoop学习篇(一)——Hadoop分布式配

Hadoop学习篇(二)——HDFS

说明：如涉及到侵权，请及时联系我，并在第一时间删除文章。

2. HDFS

2.1 HDFS理论基础

HDFS指的是Hadoop分布式文件处理系统(Hadoop Distributed File System)。要想总结HDFS理论基础，就要先进行计算机集群的总结。HDFS理论基础将从计算机集群、HDFS基本概念进行总结。

2.1.1 计算机集群

• 计算机集群
  • 计算机集群：计算机集群在学习过程中，我喜欢将计算机集群和分布式文件系统结合起来。因为计算机集群就是机房中交换机与刀片机的集合体。形象一点，这里计算机集群就好比快递仓库。每个刀片机就好比货架，每个交换机就好比仓库的管理部门。
  • 分布式文件系统：这里分布式文件系统，可以是说是客户端+计算机集群结构的组合体。它主要实现逻辑是，由客户端向计算机集群的主机发送请求，集群中主机对接受到的命令作出反应，并映射到对应分机上进行处理。比如：公司内部人员想要访问机房中的某些数据，需要发送请求到机房主机(交换机)，然后由主机相应到的存放指定数据的刀片机，读取文件后并返回数据。再具像化一点，就好比我们的快递仓库。这里交换机就好比仓库的总管，在有人来仓库找包裹时，管理员会通过快递件存放的位置，去货架上寻找。找到后，将其交给收件人。

(这里需要注意一点：分布式文件系统结构和计算机集群结构的不同。)

分布式文件系统的结构是【客户端+主节点+数据结点】，即【客户端+计算机集群】。但是主节点和数据结点分别有什么用处呢？为什么要这样做呢？

这里简单总结一下分布式文件系统架构的原理：客户端负责发送数据请求，主结点通过客户端发送的请求，对不同的、需要相应的数据结点进行相应。可以说，主结点只起到了一个桥梁作用，它既不用来存数据，也不用来进行数据的操作。换句话说，主结点就好比整个系统的一个“小BOSS”，数据结点能就好比一个个的部门。“小BOSS”每天只需要记得那个结点干的什么活就成。这边有客户来谈生意，或者来安排任务，“小BOSS”完全不用干，只需要告诉他们去哪个部门处理就行了。

2.2.2 HDFS基本概念

要想了解HDFS，就必须要了解HDFS的相关基本概念和名词。

• HDFS基本概念

  • 块：在计算机集群架构中，文件并不是以字节为单位进行存储，而是被分成了不同大小的块，分别存储在不同的数据结点中。（这样做的优势在于每次读取文件的时候，没有必要一个字节一个字节对文件进行读取，在获取到文件分成块后所在数据结点的地址后，直接进行调用，从而大大提高了文件的读写速度；将文件切分开存储在不同的机器上，可以达到扩容的效果，可以存储大规模的文件。）在Hadoop2.x的时代，一般情况下，每个块的大小会默认设定为128MB。
  • 主结点：NameNode，又被称为“名称结点”。在HDFS中可以看作是“总管”。它的主要作用就是管理HDFS的命名空间。在我们每一次需要进行文件读写操作时，都需要经过“总管”(NameNode)的许可，才能够去“仓库”(DataNode)去进行文件的读写操作。

• • 在主结点中，主要由FsImage和EditLog组成。

  • • 这里FsImage保存的是所有文件在该空间下的位置，相当于该空间下的一个“地图”，通过这个地图，我们可以快速找到该文件被分成了几块，分别存储到了哪些“仓库”中，存储到了“仓库”中的哪个货架上。
    • EditLog可以看作是“记录本”。“总管”每次上班时，会带一个新的“记录本”。每一次我们找“总管”的时候，都应该先制定好任务规划，并且记录到“记录本”。之后“总管”会经过判断，决定是给予我们权限做这项任务。允许之后，我们就可以根据“记录本”上的任务规划进行文件的更新操作，这样可以提高我们的工作效率。（这里引用一个EditLog文件，可以理解为，“总管”管理“仓库”时，因为手下人很多，如果来一个就在地图上标记一下，来一个就标记一下，工作效率会很慢。而且，有的时候，他只是来询问，并不是要真正要做。不如直接设立一个“记录本”，你来一个提需求的，我就在“记录本”上记录一条，不需要“总管”修改地图。第二天“总管”上班时，秘书会提前修改好地图信息，并放在“总管”桌子上。）

  • 所以，每一次NameNode启动时，“地图”信息（FsImage）都会加载到内存中，然后执行“记录本”（EditLog）中的各项操作，使得内存中的数据保持最新。之后，NameNode会创建一个新的FsImage和一个空的EditLog文件，每一次进行HDFS中的更新操作是，都会直接将操作记在“记录本”上，从而增加工作效率。“总管”每天的工作就是，检查“地图”，管理仓库。有人来提需求，我就干活，没人来，我就看好仓库，防止货架倒塌意外的发生(数据结点宕机)。

  • NameNode的工作流程可以总结为：启动NameNode—>加载FsImage内容—>执行EditLog中的操作—>创建新的FsImage和EditLog文件—>更新信息时，直接在EditLog中进行更新。(通俗点讲：“总管”上班了—>拿到“仓库地图”—>有人来提任务？允许你做，记在“记录本”上—>下班了。第二天上班前，秘书负责按照“记录本”上的内容对“查看地图进行更新—>“总管”上班了。依次循环更新。)

• 数据结点：DataNode。数据结点在HDFS中可以看作是“仓库”。它的主要作用就是存放那些被分成快的文件内容。需要的时候，我们需通过“总管”同意后挪用，进行文件的读写操作。

• • 在计算机集群中，DataNode一般会有多个冗余项存在。其优点在于，我们每次去找这些数据时，可以不用花费在一台机器上，可以在多台机器上进行查找，在哪个地方先找到，就调用哪个DataNode的数据。假设我们有两个“仓库”存放这个文件的原件和复印件的相同数据块，只不过原件在仓库1的最后一个货架上，复印件在仓库2的第一个货架上。我现在需要找第三个数据块的内容，我就让工人从两个“仓库”中同时查找，我先找到了复印件，就直接去读复印件的内容即可，这样也大大提高了数据的传输速度。这里可以总结为“优先原则”。我不管是原件还是复印件，谁能先找到，我就要哪一个。(这也就是数据结点的存取原理，可以加快数据的传输速度、检查数据是否出错、确保数据的真实可靠。)
  • 同时，为了防止读取到的内容在传送过程中出现错误，可以返回到其它DataNode中进行检查，简化了单个DataNode检查的程度。意思是，我这边找到了复印件1，其他货架上的工人的活不能停，直到他们找到了他们货架的文件，拿过来和我的比对，正确的话，我的就被拿走使用。不对，那我就被淘汰了，“优先原则”看那三个的，然后比对。这里可以总结为“正确原则”。拿的快，好！但要注意正确性。
  • 日常生活中，对于重要的数据或者文件，我们都会对其进行备份。多个DataNode就可以通过备份文件内容，保证数据的可靠性。如果一个“仓库”损坏导致数据丢失，我们的备份文件就可以避免这种危险。

• 第二名称结点：SecondaryNameNode。我们可以把它看作“副总管”。现实生活中，往往“副总管”权力小、干活多。这里SecondaryNameNode基本上是这样的。和“总管”不同，他不像“总管”那样清闲。他需要时刻关注“总管”动向、身体情况。在“总管”不能来的情况下，“副总管”需要迅速顶替“总管”的位置，确保仓库内工作的有序进行。而且，他还要合并更新“记录本”和“地图”。因为每天上班都会有一个新的“记录本”和“地图”，有的时候，“记录本”根本用不完。为了节省空间，就需要将上边的内容进行合并，这样方便今后工作。即SecondaryNameNode有两个用处：一是NameNode宕机时，SecondaryNameNode会快速顶替NameNode位置，确保集群工作有序进行；二是合并整理EditLog和FsImage，减小其占用空间的大小。

• • 由于Secondary NameNode的特殊性，其始终还是NameNode的一个备份，不能够完全替代NameNode，所以真的在发生NameNode宕机时，现实中还是会造成一定的数据丢失。
  • 这里插一句：在Hadoop2.x时代以前，我们也知道设立备份结点，但其用途主要是在主结点宕机后，关闭整个集群进行恢复。这种“事后弥补”的措施我们称为“冷备份”。而现在的SecondaryNameNode，可以迅速顶替“总管”位置，达到“遇到问题有人顶”的效果。这种我们称为“热结点”。

有关HDFS，这里还需要注意：HDFS集群中有且只有一个名称结点和第二名称结点，若干个数据结点，每个数据结点会被分为若干个块，该系统下的文件会被分为不同的块，存储在不同的数据结点上。

HDFS示意图如图所示：

2.2.3 HDFS读写策略

我们知道，HDFS中的文件是以块的模式存储，同时，块模式下的数据全部都是字节数据，所以，我们在读写HDFS文件时，都需要注意数据类型的转换。

• HDFS读过程

• • HDFS下的文件读取，相当于我们要从“仓库”中去找一个东西。首先我们要把诉求告诉“总管”。这个时候，我们首先会打开与HDFS的连接，即Open DistributedFileSystem，之后与“总管”取得联系，从这里获取我们想要的文件的地址。在获得地址后，我们要开始与“仓库”取得联系，确定所在“货架”，从而获取文件。此时，我们需要创建FSDataInputStream数据流，然后分别从不同的“仓库”中寻找最近的数据块进行内容的读取。由于有些“仓库”的ID与我们的ID不一致，这个时候就会随机选择副本进行读取。这里和Java利用Input数据流读取本地文件原理类似。

  • 简单总结可以分为五步：

  • • 打开分布式文件系统通道
    • 从NameNode中获取文件位置信息
    • 创建文件系统的数据输入流
    • 匹配ID，读取DataNode中数据块
    • 读取结束，关闭数据流

  • 注意：这里我们是要读数据，所以要将数据输入到我们这里，所以使用时，需要利用Input的数据流。在编程操作时要注意。

其流程图如图：

• HDFS写过程

• • HDFS下的文件写入采用的是流水线复制。我们想要在“仓库”添加一个文件，我们首先需要去“总管”那里进行登记。所以，我们首先需要进行打开与HDFS的连接，即Open DistributedFileSystem，并在“总管”这里进行新文件登记，即create操作。之后，就是写入文件的操作了。创建分布式文件数据输出流，即FSDataOutputStream，进行数据内容写入。为了保证数据写入的正确性，我们每一次完成写入操作后都会告知客户该块内容写入完成，请求用户确认。因为再进行写入数据块时，我们是将数据进行打包，排队发送到各个DataNode，在确认队列中的包完成工作后，就可以让其离队了，从而进行下一个包的写入。由于要将数据内容写复制至不同的DataNode中去，所以采取了流水线的复制策略。即一个DataNode向下一个DataNode发送写入请求，完成写入后该DataNode逆向原路发送确认信息，以此类推，反复执行。在所有DataNode都完成数据读写后，关闭数据输出流，告诉“总管”，任务完成，文件可以关闭。

  • 简单总结可以分为七步：

  • • 打开分布式文件系统通道
    • 在NameNode中创建文件信息
    • 创建文件系统的输出流
    • 写入DataNode
    • DataNode返回确认包
    • 反复执行3～5步，直到DataNode全部写入完成
    • 关闭数据流。完成文件写入，将complete信息通知NameNode，并关闭文件

  • 注意：这里我们是要写数据，所以要将数据从我们这里输出，再写入HDFS文件中去。所以使用时，需要利用Output的数据流。而且，这里的写操作使用的流水线模式进行的。

其流程图如图：

以上内容便是HDFS理论基础方面的学习，关于实验部分留到下篇文章中进行。

最后，附上本作理论学习绘制的思维导图：