Hadoop分布式文件系统(HDFS)是一种被设计成适合运行在通用硬件上的分布式文件系统。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。它能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。要理解HDFS的内部工作原理，首先要理解什么是分布式文件系统。

1.分布式文件系统 
多台计算机联网协同工作(有时也称为一个集群)就像单台系统一样解决某种问题，这样的系统我们称之为分布式系统。 
分布式文件系统是分布式系统的一个子集，它们解决的问题就是数据存储。换句话说，它们是横跨在多台计算机上的存储系统。存储在分布式文件系统上的数据自动分布在不同的节点上。 分布式文件系统在大数据时代有着广泛的应用前景，它们为存储和处理来自网络和其它地方的超大规模数据提供所需的扩展能力。

 

  • hdfs 名词解释
  • hdsf 架构
  • NameNode(NN)
  • Secondary NN
  • hdfs 写文件
  • hdfs 读文件
  • block持续化结构

HDFS名词解释：

  • Block： 在HDFS中，每个文件都是采用的分块的方式存储，每个block放在不同的datanode上，每个block的标识是一个三元组（block id， numBytes，generationStamp），其中block id是具有唯一性，具体分配是由namenode节点设置，然后再由datanode上建立block文件，同时建立对应block meta文件
  • Packet：在DFSclient与DataNode之间通信的过程中，发送和接受数据过程都是以一个packet为基础的方式进行
  • Chunk：中文名字也可以称为块，但是为了与block区分，还是称之为chunk。在DFSClient与DataNode之间通信的过程中，由于文件采用的是基于块的方式来进行的，但是在发送数据的过程中是以packet的方式来进行的，每个packet包含了多个chunk，同时对于每个chunk进行checksum计算，生成checksum bytes
  • 小结：
  1. 一个文件被拆成多个block持续化存储（block size 由配置文件参数决定）   思考： 修改 block size 对以前持续化的数据有何影响?
  2. 数据通讯过程中一个 block 被拆成 多个 packet
  3. 一个 packet 包含多个 chunk
  • Packet结构与定义： Packet分为两类，一类是实际数据包，另一类是heatbeat包。一个Packet数据包的组成结构，如图所示
  • 上图中，一个Packet是由Header和Data两部分组成，其中Header部分包含了一个Packet的概要属性信息，如下表所示：
  • Data部分是一个Packet的实际数据部分，主要包括一个4字节校验和（Checksum）与一个Chunk部分，Chunk部分最大为512字节
  • 在构建一个Packet的过程中，首先将字节流数据写入一个buffer缓冲区中，也就是从偏移量为25的位置（checksumStart）开始写Packet数据Chunk的Checksum部分，从偏移量为533的位置（dataStart）开始写Packet数据的Chunk Data部分，直到一个Packet创建完成为止。
  • 当写一个文件的最后一个Block的最后一个Packet时，如果一个Packet的大小未能达到最大长度，也就是上图对应的缓冲区中，Checksum与Chunk Data之间还保留了一段未被写过的缓冲区位置，在发送这个Packet之前，会检查Chunksum与Chunk Data之间的缓冲区是否为空白缓冲区（gap），如果有则将Chunk Data部分向前移动，使得Chunk Data 1与Chunk Checksum N相邻，然后才会被发送到DataNode节点

 

hdsf架构：

  • hdfs的构架图网上一堆，抓了一张表述比较清楚的图如下, 主要包含因类角色：Client、NameNode、SecondayNameNode、DataNode
  • HDFS Client: 系统使用者，调用HDFS API操作文件;与NN交互获取文件元数据;与DN交互进行数据读写, 注意：写数据时文件切分由Client完成
  • Namenode：Master节点（也称元数据节点），是系统唯一的管理者。负责元数据的管理(名称空间和数据块映射信息);配置副本策略；处理客户端请求
  • Datanode：数据存储节点(也称Slave节点)，存储实际的数据；执行数据块的读写；汇报存储信息给NN
  • Secondary NameNode：小弟角色，分担大哥namenode的工作量；是NameNode的冷备份；合并fsimage和fsedits然后再发给namenode, 注意：在hadoop 2.x 版本，当启用 hdfs ha 时，将没有这一角色。（详见第二单）
  • 解释说明：
  1. 热备份：b是a的热备份，如果a坏掉。那么b马上运行代替a的工作
  2. 冷备份：b是a的冷备份，如果a坏掉。那么b不能马上代替a工作。但是b上存储a的一些信息，减少a坏掉之后的损失
  • hdfs构架原则：
  1. 元数据与数据分离：文件本身的属性（即元数据）与文件所持有的数据分离
  2. 主/从架构：一个HDFS集群是由一个NameNode和一定数目的DataNode组成
  3. 一次写入多次读取：HDFS中的文件在任何时间只能有一个Writer。当文件被创建，接着写入数据，最后，一旦文件被关闭，就不能再修改。
  4. 移动计算比移动数据更划算：数据运算，越靠近数据，执行运算的性能就越好，由于hdfs数据分布在不同机器上，要让网络的消耗最低，并提高系统的吞吐量，最佳方式是将运算的执行移到离它要处理的数据更近的地方，而不是移动数据

 

NameNode:

  • NameNode是整个文件系统的管理节点，也是HDFS中最复杂的一个实体，它维护着HDFS文件系统中最重要的两个关系：
  1. HDFS文件系统中的文件目录树，以及文件的数据块索引，即每个文件对应的数据块列表
  2. 数据块和数据节点的对应关系，即某一块数据块保存在哪些数据节点的信息
  • 第一个关系即目录树、元数据和数据块的索引信息会持久化到物理存储中，实现是保存在命名空间的镜像fsimage和编辑日志edits中，注意：在fsimage中，并没有记录每一个block对应到哪几个Datanodes的对应表信息
  • 第二个关系是在NameNode启动后，每个Datanode对本地磁盘进行扫描，将本Datanode上保存的block信息汇报给Namenode，Namenode在接收到每个Datanode的块信息汇报后，将接收到的块信息，以及其所在的Datanode信息等保存在内存中。HDFS就是通过这种块信息汇报的方式来完成 block -> Datanodes list的对应表构建
  • fsimage记录了自最后一次检查点之前HDFS文件系统中所有目录和文件的序列化信息;
  • edits是元数据操作日志(记录每次保存fsimage之后到下次保存之间的所有hdfs操作)
  • 在NameNode启动时候，会先将fsimage中的文件系统元数据信息加载到内存，然后根据eidts中的记录将内存中的元数据同步至最新状态，将这个新版本的 FsImage 从内存中保存到本地磁盘上，然后删除 旧的 Editlog，这个过程称为一个检查 点 (checkpoint)， 多长时间做一次 checkpoint？（见第四章 参数配置） checkpoint 能手工触发吗？ 验证重启hdfs服务后editlog没删除呢？
  • 类似于数据库中的检查点，为了避免edits日志过大，在Hadoop1.X中，SecondaryNameNode会按照时间阈值（比如24小时）或者edits大小阈值（比如1G），周期性的将fsimage和edits的合并，然后将最新的fsimage推送给NameNode。而在Hadoop2.X中，这个动作是由Standby NameNode来完成.
  • 由此可看出，这两个文件一旦损坏或丢失，将导致整个HDFS文件系统不可用，在HDP2.4安装(五)：集群及组件安装  集群安装过程中，hdfs 默认的只能选择一个NN，是否意味着NN存在单点呢？(见第二单 hdfs HA)
  • 在hadoop1.X为了保证这两种元数据文件的高可用性，一般的做法，将dfs.namenode.name.dir设置成以逗号分隔的多个目录，这多个目录至少不要在一块磁盘上，最好放在不同的机器上，比如：挂载一个共享文件系统
  • fsimage\edits 是序列化后的文件，想要查看或编辑里面的内容，可通过 hdfs 提供的 oiv\oev 命令，如下：
  • 命令: hdfs oiv （offline image viewer） 用于将fsimage文件的内容转储到指定文件中以便于阅读,，如文本文件、XML文件，该命令需要以下参数：
  1. -i  (必填参数)  –inputFile <arg>  输入FSImage文件
  2. -o (必填参数)  –outputFile <arg> 输出转换后的文件，如果存在，则会覆盖
  3. -p (可选参数） –processor <arg>   将FSImage文件转换成哪种格式： (Ls|XML|FileDistribution).默认为Ls
  4. 示例：hdfs oiv -i /data1/hadoop/dfs/name/current/fsimage_0000000000019372521 -o /home/hadoop/fsimage.txt
  • 命令：hdfs oev (offline edits viewer 离线edits查看器）的缩写， 该工具只操作文件因而并不需要hadoop集群处于运行状态。
  1. 示例:  hdfs oev -i edits_0000000000000042778-0000000000000042779 -o edits.xml
  2. 支持的输出格式有binary（hadoop使用的二进制格式）、xml（在不使用参数p时的默认输出格式）和stats（输出edits文件的统计信息）
  • 小结：
  1. NameNode管理着DataNode，接收DataNode的注册、心跳、数据块提交等信息的上报，并且在心跳中发送数据块复制、删除、恢复等指令；同时，NameNode还为客户端对文件系统目录树的操作和对文件数据读写、对HDFS系统进行管理提供支持
  2. Namenode 启动后会进入一个称为安全模式的特殊状态。处于安全模式 的 Namenode 是不会进行数据块的复制的。 Namenode 从所有的 Datanode 接收心跳信号和块状态报告。块状态报告包括了某个 Datanode 所有的数据 块列表。每个数据块都有一个指定的最小副本数。当 Namenode 检测确认某 个数据块的副本数目达到这个最小值，那么该数据块就会被认为是副本安全 (safely replicated) 的；在一定百分比（这个参数可配置）的数据块被 Namenode 检测确认是安全之后（加上一个额外的 30 秒等待时间）， Namenode 将退出安全模式状态。接下来它会确定还有哪些数据块的副本没 有达到指定数目，并将这些数据块复制到其他 Datanode 上。

 

Secondary NameNode：在HA cluster中又称为standby node

  • 定期合并 fsimage 和 edits 日志，将 edits 日志文件大小控制在一个限度下
  • namenode 响应 Secondary namenode 请求，将 edit log 推送给 Secondary namenode ， 开始重新写一个新的 edit log
  • Secondary namenode 收到来自 namenode 的 fsimage 文件和 edit log
  • Secondary namenode 将 fsimage 加载到内存，应用 edit log ， 并生成一 个新的 fsimage 文件
  • Secondary namenode 将新的 fsimage 推送给 Namenode
  • Namenode 用新的 fsimage 取代旧的 fsimage ， 在 fstime 文件中记下检查 点发生的时


HDFS写文件：

  • 写文件部分参考blog 地址 （），2.X版本默认block的大小是 128M 
  1. Client将FileA按64M分块。分成两块，block1和Block2;
  2. Client向nameNode发送写数据请求，如图蓝色虚线①------>
  3. NameNode节点，记录block信息。并返回可用的DataNode (NameNode按什么规则返回DataNode? 参见第三单 hadoop机架感知），如粉色虚线②--------->
  • Block1: host2,host1,host3
  • Block2: host7,host8,host4
  1. client向DataNode发送block1；发送过程是以流式写入，流式写入过程如下：
  1. 将64M的block1按64k的packet划分
  2. 然后将第一个packet发送给host2
  3. host2接收完后，将第一个packet发送给host1，同时client想host2发送第二个packet
  4. host1接收完第一个packet后，发送给host3，同时接收host2发来的第二个packet
  5. 以此类推，如图红线实线所示，直到将block1发送完毕
  6. host2,host1,host3向NameNode，host2向Client发送通知，说“消息发送完了”。如图粉红颜色实线所示
  7. client收到host2发来的消息后，向namenode发送消息，说我写完了。这样就真完成了。如图黄色粗实线
  8. 发送完block1后，再向host7，host8，host4发送block2，如图蓝色实线所示
  •  说明：
  1. 当客户端向 HDFS 文件写入数据的时候，一开始是写到本地临时文件中。假设该文件的副 本系数设置为 3 ，当本地临时文件累积到一个数据块的大小时，客户端会从 Namenode 获取一个 Datanode 列表用于存放副本。然后客户端开始向第一个 Datanode 传输数据，第一个 Datanode 一小部分一小部分 (4 KB) 地接收数据，将每一部分写入本地仓库，并同时传输该部分到列表中 第二个 Datanode 节点。第二个 Datanode 也是这样，一小部分一小部分地接收数据，写入本地 仓库，并同时传给第三个 Datanode 。最后，第三个 Datanode 接收数据并存储在本地。因此， Datanode 能流水线式地从前一个节点接收数据，并在同时转发给下一个节点，数据以流水线的 方式从前一个 Datanode 复制到下一个
  2. 时序图如下：

hadoop分布式集群启动 hadoop分布式系统原理_hadoop分布式集群启动

  • 小结：
  1. 写入的过程，按hdsf默认设置，1T文件，我们需要3T的存储，3T的网络流量
  2. 在执行读或写的过程中，NameNode和DataNode通过HeartBeat进行保存通信，确定DataNode活着。如果发现DataNode死掉了，就将死掉的DataNode上的数据，放到其他节点去。读取时，要读其他节点去
  3. 挂掉一个节点，没关系，还有其他节点可以备份；甚至，挂掉某一个机架，也没关系；其他机架上，也有备份

 

hdfs读文件： 

  •  读到文件示意图如下：
  • 客户端通过调用FileSystem对象的open()方法来打开希望读取的文件，对于HDFS来说，这个对象时分布文件系统的一个实例；
  • DistributedFileSystem通过使用RPC来调用NameNode以确定文件起始块的位置，同一Block按照重复数会返回多个位置，这些位置按照Hadoop集群拓扑结构排序，距离客户端近的排在前面 (详见第三章）
  • 前两步会返回一个FSDataInputStream对象，该对象会被封装成DFSInputStream对象，DFSInputStream可以方便的管理datanode和namenode数据流，客户端对这个输入流调用read()方法
  • 存储着文件起始块的DataNode地址的DFSInputStream随即连接距离最近的DataNode，通过对数据流反复调用read()方法，将数据从DataNode传输到客户端
  • 到达块的末端时，DFSInputStream会关闭与该DataNode的连接，然后寻找下一个块的最佳DataNode，这些操作对客户端来说是透明的，客户端的角度看来只是读一个持续不断的流
  • 一旦客户端完成读取，就对FSDataInputStream调用close()方法关闭文件读取

 

block持续化结构:

  •  DataNode节点上一个Block持久化到磁盘上的物理存储结构，如下图所示：
  • 每个Block文件（如上图中blk_1084013198文件）都对应一个meta文件（如上图中blk_1084013198_10273532.meta文件），Block文件是一个一个Chunk的二进制数据（每个Chunk的大小是512字节），而meta文件是与每一个Chunk对应的Checksum数据，是序列化形式存储
  •