HDFS原理初探

柔情只为你懂 2022-03-20 15:14 189阅读 0赞

### 1. HDFS简介 ###

HDFS:Hadoop Distributed File System(hadoop分布式文件系统)  
分布式，感觉好厉害的样子啊，有网络文件系统，有本地文件系统，现在又多了一个分布式的文件系统。之所以是要分布式，是数据要放到多个主机上面去。放的东西在集群中，就是分布式啦！  
想要了解这个东东，先找一张原理图瞅瞅。  
![在这里插入图片描述][70]

### 2. HDFS 1.0 ###

每个一学习的模块要搞懂一个点内容，学完这个就需要对下面这些名词非常的了解。 `Namenode`，`Datanode`，`块`，`冷备份(sendarynamenode)`

#### 2.1 NameNode ####

NameNode又称为名称节点，是负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构，即`FsImage`和`EditLog`。 你可以把它理解成大管家，它不负责存储具体的数据。

*  FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据；
 *  操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作 ；

> 注意，这个两个都是文件，也会加载解析到内存中。

为啥会拆成两个呢? 主要是因为fsimage这个文件会很大的，多了之后就不好操作了，就拆分成两个。把后续增量的修改放到EditLog中, 一个FsImage和一个Editlog 进行合并会得到一个新的FsImage.

因为它是系统的大管家，如果这个玩意坏了，丢失了怎么办。就相当于你系统的引导区坏了。那就玩完了。整个文件系统就崩溃了。 所以，这个重要的东西，需要备份。这个时候就产生了一个叫sendaryNamenode的节点用来做备份，它会定期的和namenode就行通信来完成整个的备份操作。具体的操作如下:  
![在这里插入图片描述][70 1]

**SecondaryNameNode的工作情况：**

1.  SecondaryNameNode会定期和NameNode通信，请求其停止使用EditLog文件，暂时将新的写操作写到一个新的文件edit.new上来，这个操作是瞬间完成，上层写日志的函数完全感觉不到差别；
2.  SecondaryNameNode通过HTTP GET方式从NameNode上获取到FsImage和EditLog文件，并下载到本地的相应目录下；
3.  SecondaryNameNode将下载下来的FsImage载入到内存，然后一条一条地执行EditLog文件中的各项更新操作，使得内存中的FsImage保持最新；这个过程就是EditLog和FsImage文件合并；
4.  SecondaryNameNode执行完`（3）`操作之后，会通过post方式将新的FsImage文件发送到NameNode节点上
5.  NameNode将从SecondaryNameNode接收到的新的FsImage替换旧的FsImage文件，同时将edit.new替换EditLog文件，通过这个过程EditLog就变小了

除了这个自带的备份操作，还需要进行人工的备份，把一份fsimage到多个地方进行备份，万一namenode的节点坏了呢。

#### 2.2 DataNode ####

DataNode数据节点，用来具体的存储文件，维护了blockId 与 datanode本地文件的映射。 需要不断的与namenode节点通信，来告知其自己的信息，方便nameode来管控整个系统。

这里还提到一个`块`的概念，就想linux本地文件系统中也有块的概念一样，这里也有块的概念。这里的块会默认是128m 每个块都会默认储存三份。

### 3. HDFS 2.0 ###

有问题，就得改。1.0上有很多的毛病，为了修复这些问题才出了2.0

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

解决上面这些问题所使用的手段就是：`热备份`、`federation`

#### 3.1 热备份 (NameNode HA) ####

NameNode HA 是为了解决单点故障问题

*  HA集群设置两个NameNode ，“`活跃（Active）`”和“`待命（Standby）`”
 *  两种NameNode 的状态同步，可以借助于一个共享存储系统来实现
 *  一旦活跃NameNode 出现故障，就可以立即切换到待命NameNode
 *  Zookeeper确保一个NameNode 在对外服务
 *  NameNode 维护映射信息，DataNode同时向两个NameNode 汇报信息

![在这里插入图片描述][70 2]

#### 3.2 Federation(联盟) ####

多个命名空间。为了处理一个namenode的局限性，搞了几个namanode大家一起来管理。就像编程中的命名空间一样。

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

![在这里插入图片描述][70 3]

**HDFS Federation设计可解决单名称节点存在的以下几个问题：**

1.  HDFS集群扩展性。多个名称节点各自分管一部分目录，使得一个集群可以扩展到更多节点，不再像HDFS1.0中那样由于内存的限制制约文件存储数目
2.  性能更高效。多个名称节点管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率
3.  良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理，这样不同业务之间影响很小

--------------------

##### 转自：[https://blog.csdn.net/xjz729827161/article/details/79463140][https_blog.csdn.net_xjz729827161_article_details_79463140] #####

[70]: /images/20220320/adaccf7ee3a24edea63825d1eed80a0c.png
[70 1]: /images/20220320/bfe3374859fd4a42b85e0ad25df1d35a.png
[70 2]: /images/20220320/34e20aa03cfa4ecf9d496af414b81b71.png
[70 3]: /images/20220320/d5fad5ebd28649329ce39f05e3a23880.png
[https_blog.csdn.net_xjz729827161_article_details_79463140]: https://blog.csdn.net/xjz729827161/article/details/79463140