HDFS基础

本文转载自：https://www.cnblogs.com/qingyunzong/p/8524594.html

HDFS前言

HDFS：Hadoop Distributed File System ，Hadoop分布式文件系统，主要用来解决海量数据的存储问题

设计思想

1、分散均匀存储 dfs.blocksize = 128M
2、备份冗余存储 dfs.replication = 3

在大数据系统中作用

为各类分布式运算框架（如：mapreduce，spark，tez，……）提供数据存储服务。

重点概念

文件切块，副本存放，元数据

HDFS的概念和特性

概念

首先，它是一个文件系统，用于存储文件，通过统一的命名空间——目录树来定位文件

其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色；

重要特性

（1）HDFS中的文件在物理上是分块存储（block），块的大小可以通过配置参数( dfs.blocksize)来规定，默认大小在hadoop2.x版本中是128M，老版本中是64M

（2）HDFS文件系统会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件，形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data

（3）目录结构及文件分块信息(元数据)的管理由namenode节点承担

----namenode是HDFS集群主节点，负责维护整个hdfs文件系统的目录树，以及每一个路径（文件）所对应的block块信息（block的id，及所在的datanode服务器）

（4）文件的各个block的存储管理由datanode节点承担

---- datanode是HDFS集群从节点，每一个block都可以在多个datanode上存储多个副本（副本数量也可以通过参数设置dfs.replication）

（5）HDFS是设计成适应一次写入，多次读出的场景，且不支持文件的修改

(注：适合用来做数据分析，并不适合用来做网盘应用，因为，不便修改，延迟大，网络开销大，成本太高)。

图解HDFS

通过上面的描述我们知道，hdfs很多特点：

• 保存多个副本，且提供容错机制，副本丢失或宕机自动恢复（默认存3份）。

• 运行在廉价的机器上

• 适合大数据的处理。HDFS默认会将文件分割成block，在hadoop2.x以上版本默认128M为1个block。然后将block按键值对存储在HDFS上，并将键值对的映射存到内存中。如果小文件太多，那内存的负担会很重。
  
  如上图所示，HDFS也是按照Master和Slave的结构。分HDFS client、NameNode、SecondaryNameNode、DataNode这几个角色。

• HDFS client：系统使用者，调用HDFS API操作文件;与NameNode交互获取文件元数据;与DataNode交互进行数据读写。注意：写数据时文件切分由Client完成。

• NameNode：是Master节点，是大领导。管理数据块映射；处理客户端的读写请求；配置副本策略；管理HDFS的名称空间。

• SecondaryNameNode：是一个小弟，分担大哥namenode的工作量；是NameNode的冷备份；合并fsimage和fsedits然后再发给namenode。注意：在hadoop 2.x 版本，当启用 hdfs ha 时，将没有这一角色。

• DataNode：Slave节点，奴隶，干活的。负责存储client发来的数据块block；执行数据块的读写操作。

• 热备份：b是a的热备份，如果a坏掉。那么b马上运行代替a的工作。

• 冷备份：b是a的冷备份，如果a坏掉。那么b不能马上代替a工作。但是b上存储a的一些信息，减少a坏掉之后的损失。

• fsimage:元数据镜像文件（文件系统的目录树。）

• edits：元数据的操作日志（针对文件系统做的修改操作记录）

• namenode内存中存储的是=fsimage+edits。

• SecondaryNameNode负责定时默认1小时，从namenode上，获取fsimage和edits来进行合并，然后再发送给namenode。减少namenode的工作量。

hdfs构架原则：

• 元数据与数据分离：文件本身的属性（即元数据）与文件所持有的数据分离
• 主/从架构：一个HDFS集群是由一个NameNode和一定数目的DataNode组成
• 一次写入多次读取：HDFS中的文件在任何时间只能有一个Writer。当文件被创建，接着写入数据，最后，一旦文件被关闭，就不能再修改
• 移动计算比移动数据更划算：数据运算，越靠近数据，执行运算的性能就越好，由于hdfs数据分布在不同机器上，要让网络的消耗最低，并提高系统的吞吐量，最佳方式是将运算的执行移到离它要处理的数据更近的地方，而不是移动数据

NameNode

• NameNode是整个文件系统的管理节点，也是HDFS中最复杂的一个实体，它维护着HDFS文件系统中最重要的两个关系：
  • HDFS文件系统中的文件目录树，以及文件的数据块索引，即每个文件对应的数据块列表
  • 数据块和数据节点的对应关系，即某一块数据块保存在哪些数据节点的信息
• 第一个关系即目录树、元数据和数据块的索引信息会持久化到物理存储中，实现是保存在命名空间的镜像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)。
• 类似于数据库中的检查点，为了避免edits日志过大，在Hadoop1.X中，SecondaryNameNode会按照时间阈值（比如24小时）或者edits大小阈值（比如1G），周期性的将fsimage和edits的合并，然后将最新的fsimage推送给NameNode。而在Hadoop2.X中，这个动作是由Standby NameNode来完成.
• 由此可看出，这两个文件一旦损坏或丢失，将导致整个HDFS文件系统不可用。
• 在hadoop1.X为了保证这两种元数据文件的高可用性，一般的做法，将dfs.namenode.name.dir设置成以逗号分隔的多个目录，这样，多个目录至少不要在一块磁盘上，最好放在不同的机器上，比如：挂载一个共享文件系统
• fsimage\edits 是序列化后的文件，想要查看或编辑里面的内容，可通过 hdfs 提供的 oiv\oev 命令。

小结：

• NameNode管理着DataNode，接收DataNode的注册、心跳、数据块提交等信息的上报，并且在心跳中发送数据块复制、删除、恢复等指令；同时，NameNode还为客户端对文件系统目录树的操作和对文件数据读写、对HDFS系统进行管理提供支。
• Namenode 启动后会进入一个称为安全模式的特殊状态。处于安全模式的 Namenode 是不会进行数据块的复制的。Namenode 从所有的 Datanode 接收心跳信号和块状态报告。块状态报告包括了某个 Datanode 所有的数据块列表。每个数据块都有一个指定的最小副本数。当Namenode检测确认某 个数据块的副本数目达到这个最小值，那么该数据块就会被认为是副本安全 (safely replicated) 的；在一定百分比（这个参数可配置）的数据块被 Namenode 检测确认是安全之后（加上一个额外的 30 秒等待时间）， Namenode 将退出安全模式状态。接下来它会确定还有哪些数据块的副本没有达到指定数目，并将这些数据块复制到其他 Datanode 上。

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

Secondary NameNode 定期合并 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 文件中记下检查点发生的时

工作原理

说明：该小节内容参考自https://www.cnblogs.com/laov/p/3434917.html

写操作

有一个文件FileA，100M大小。Client将FileA写入到HDFS上。HDFS按默认配置。HDFS分布在三个机架上Rack1，Rack2，Rack3。

写过程如下：
a. Client将FileA按64M分块。分成两块，block1和Block2;

b. Client向nameNode发送写数据请求，如图蓝色虚线①。

c. NameNode节点，记录block信息。并返回可用的DataNode，如粉色虚线②。

Block1: host2,host1,host3
Block2: host7,host8,host4

原理：

• NameNode具有RackAware机架感知功能，这个可以配置。
• 若client为DataNode节点，那存储block时，规则为：副本1，同client的节点上；副本2，不同机架节点上；副本3，同第二个副本机架的另一个节点上；其他副本随机挑选。
• 若client不为DataNode节点，那存储block时，规则为：副本1，随机选择一个节点上；副本2，不同副本1，机架上；副本3，同副本2相同的另一个节点上；其他副本随机挑选。

d. client向DataNode发送block1；发送过程是以流式写入。
流式写入过程，

• 1>将64M的block1按64k的package划分;
• 2>然后将第一个package发送给host2;
• 3>host2接收完后，将第一个package发送给host1，同时client想host2发送第二个package；
• 4>host1接收完第一个package后，发送给host3，同时接收host2发来的第二个package。
• 5>以此类推，如图红线实线所示，直到将block1发送完毕。
• 6>host2,host1,host3向NameNode，host2向Client发送通知，说“消息发送完了”。如图粉红颜色实线所示。
• 7>client收到host2发来的消息后，向namenode发送消息，说我写完了。这样就真完成了。如图黄色粗实线
• 8>发送完block1后，再向host7，host8，host4发送block2，如图蓝色实线所示。
• 9>发送完block2后，host7,host8,host4向NameNode，host7向Client发送通知，如图浅绿色实线所示。
• 10>client向NameNode发送消息，说我写完了，如图黄色粗实线。。。这样就完毕了。

分析，通过写过程，我们可以了解到：

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

读操作

读操作就简单一些了，如图所示，client要从datanode上，读取FileA。而FileA由block1和block2组成。

那么，读操作流程为：

a. client向namenode发送读请求。

b. namenode查看Metadata信息，返回fileA的block的位置。

block1:host2,host1,host3
block2:host7,host8,host4

c. block的位置是有先后顺序的，先读block1，再读block2。而且block1去host2上读取；然后block2，去host7上读取；

上面例子中，client位于机架外，那么如果client位于机架内某个DataNode上，例如,client是host6。那么读取的时候，遵循的规律是：优选读取本机架上的数据。

HDFS的局限性

1）低延时数据访问。在用户交互性的应用中，应用需要在ms或者几个s的时间内得到响应。由于HDFS为高吞吐率做了设计，也因此牺牲了快速响应。对于低延时的应用，可以考虑使用HBase或者Cassandra。
2）大量的小文件。标准的HDFS数据块的大小是128M，存储小文件并不会浪费实际的存储空间，但是无疑会增加了在NameNode上的元数据，大量的小文件会影响整个集群的性能。
Btrfs为小文件做了优化-inline file，对于小文件有很好的空间优化和访问时间优化。
3）多用户写入，修改文件。HDFS的文件只能有一个写入者，而且写操作只能在文件结尾以追加的方式进行。它不支持多个写入者，也不支持在文件写入后，对文件的任意位置的修改。
但是在大数据领域，分析的是已经存在的数据，这些数据一旦产生就不会修改，因此，HDFS的这些特性和设计局限也就很容易理解了。HDFS为大数据领域的数据分析，提供了非常重要而且十分基础的文件存储功能。

HDFS保证可靠性的措施

1）冗余备份
每个文件存储成一系列数据块（Block）。为了容错，文件的所有数据块都会有副本（副本数量即复制因子，可配置）（dfs.replication）

2）副本存放
采用机架感知（Rak-aware）的策略来改进数据的可靠性、高可用和网络带宽的利用率

3）心跳检测
NameNode周期性地从集群中的每一个DataNode接受心跳包和块报告，收到心跳包说明该DataNode工作正常

4）安全模式

系统启动时，NameNode会进入一个安全模式。此时不会出现数据块的写操作。

5）数据完整性检测

HDFS客户端软件实现了对HDFS文件内容的校验和（Checksum）检查（dfs.bytes-per-checksum）。

单点故障（单点失效）问题

单点故障问题

如果NameNode失效，那么客户端或MapReduce作业均无法读写查看文件

解决方案

1）启动一个拥有文件系统元数据的新NameNode（这个一般不采用，因为复制元数据非常耗时间）

2）配置一对活动-备用（Active-Sandby）NameNode，活动NameNode失效时，备用NameNode立即接管，用户不会有明显中断感觉。

共享编辑日志文件（借助NFS、zookeeper等）。
DataNode同时向两个NameNode汇报数据块信息。
客户端采用特定机制处理 NameNode失效问题，该机制对用户透明。