HDFS-架构原理

Posted 2021-04-02 码农大腿哥

前言：

在HDFS入门第一课我们对HDFS的核心思想有所了解。本篇将深入HDFS的底层细节，看看HDFS是如何解决一个分布式存储系统面临的诸多问题

本篇目标

1.掌握HDFS框架的核心组件及其作用

2.掌握各组件底层的主要运行机制

3.理解HDFSZ中Block的概念

4.学会解决HDFS的小文件问题

---

01

架构组成与作用

HDFS采用了Master/Slave的架构存储数据，由NameNode、DataNode、Secondary NameNode、Client四部分组成

1.NameNode

NameNode(NN)是集群的Master，相当于一个管理者。主要作用有：

1）管理HDFS的名称空间（就是管理文件目录）

2）管理数据块Block的映射信息（每个Block会被存储在哪台机器上）

3）配置副本策略（一个Blcok配置几个副本，放在那里）

4）处理客户端读写请求（读取哪些数据，写入哪些数据）

2.DataNode

DataNode(DN)就是Slave，相当于一个打工人，执行NameNode下达的命令。主要作用有：

1）存储实际的数据块Blocak

2）执行Block的读写、创建、删除操作

3.Secondary NameNode

Secondary NameNode(SN)相当于一个秘书，辅助NameNode完成一些工作。主要作用有：

1）辅助NN，分担其工作量，比如定期合并fsimage和edits.log并推送给NN（后面会介绍SN的工作机制）

2）紧急情况下，辅助恢复NameNode

4. Client

Client就是客户端，主要作用有：

1）文件切分。上传文件时，Client将文件切分成Block后进行上传

2）与NameNode交互，获取文件位置信息

3）与DataNode交互，读取或写入数据

4）提供一些命令管理和访问HDFS，如对HDFS进行增删改查

---

02

各组件工作机制

1.NameNode

1）元数据持久化机制

元数据存储在内存里，这样修改的时候比较快。不过元数据迟早要持久化到内存里，不然一断电就全没了

首先来了解两个文件：

EditLog：该文件记录了元数据的每一次改动，由于只进行追加操作，所以效率很高

FsImage：在磁盘里备份的内存中的元数据

NameNode启动时，会从磁盘读取FsImage和EditLog，根据EditLog的修改记录对FsImage进行修改，二者合并后应用到内存中

然后，刷新磁盘中的FsImage文件，EditLog文件从当前位置截断

2）高可用机制-HA

集群只有一台NN时，如果它发生了故障整个集群都无法使用。为了消除NN的单点故障，我们可以设置两个NN

HDFS HA功能可以配置Active/Standby两个NN，如果其中一台故障，可以很快的切换到另一台NN

HDFS HA的工作机制如下：

① 两个NN内存中各自保存一份元数据

两个NN都能读取EditLog，但只有Active状态的NN可以操作。共享的EditLog放在一个共享存储中管理

②一个状态管理功能模块

zkfailover是一个Zookeeper客户端，可以监控NN的状态。当需要切换状态时，zkfailover负责切换

③ 同一时刻仅有一个NN对外提供服务

2.DataNode

1）DataNode心跳监测

① DN启动后向NN注册，成功后，周期性的向NN上报所有块信息

② 心跳3s一次，心跳的返回结果带有NN给该DN的命令(复制块数据到另一节点或删除数据块等)

③ 如果超过10分钟没有收到某个NN的心跳，则认为该节点不可用

2）校验和机制(CheckSum)

HDFS采用校验和机制，保障了数据的完整性

• 当DN创建Block时，会先计算这个Block的校验和并存储在一个隐藏文件中
  

• 当DN读取Block时，会验证接收数据的校验和与之前保存的是否一致

• 如果不一致，Client将查找另一个副本

• DN在创建完Block会周期性的验证CheckSum

3）退役DataNode

如果某DN需要退役，可以将DN添加到黑名单

此后，该节点的数据会复制到其他节点。所有块复制完成，则停止该节点及节点资源管理器

3.Secondary NameNode

1）检查点机制-CheckPoint

如果长时间添加数据到Edits中，会导致该文件数据过大，一旦断电，恢复元数据需要的时间会很长。所以，需要定期将FsImage和Edits合并

如果这个操作由NameNode节点完成，对NN的要求很高。因此，引入一个新的节点SecondaryNamenode，专门用于FsImage和Edits的合并，这一过程称为Check Point

2）CheckPoint的流程

如果设定时间到或者Edits写入了指定的条数，会触发CheckPoint执行；

首先，NN会生成一个空的edits.inprogress，后续的元数据更改写入这个文件

然后，Edits和Fsimage会拷贝到2NN，由2NN加载到内存进行合并，生成fsimage.chkpoint

最后，fsimage.chkpoint拷贝给NN，重命名为Fsimage替换条之前的文件

---

03

Block

HDFS中的文件在物理上是分块存储的，一个文件被分割成很多Block。一块只有128M，可以通过dfs.blocksize参数设置

一个Block在DN上以文件形式存储在磁盘中，包括两个文件：一个是数据本身；一个是元数据(数据块长度、校验和、时间戳)

1.块大小的确定

Block默认大小为128MB，之所以这么设定取决于 寻址时间和 磁盘传输时间

寻址时间一般为10ms，寻址时间为传输时间的1%时，是最佳状态。也就是说，传输时间为1s。目前磁盘传输速率约为100MB/s，所以一个Block设置为128MB

块太小会增加寻址时间，程序一直在定位Block；块太大，会导致数据处理时间增加，让程序变慢

2.三副本机制

HDFS默认将一个Block保存3份，

注意：同一个DataNode不允许有相同的Block副本。因此，副本数不能超过当前DataNode的数量

3.副本放置策略

一般一个机架能放20台左右服务器，不同机架的服务器通信需要通过交换机进行。一般来说，同一机架服务器的网络带宽，大于不同机架 服务器之间的网络带宽

如果都存在同一个机架，整个机架故障就完蛋了；如果放在不同机架，又会增加写入成本，因为副本要在不同机架之间传输

以3副本为例，第 1 个副本一般在数据源所在的节点，或者同一个机架的不同节点。第2、3个副本放在另一个机架的不同节点上

4.副本读取策略

HDFS会尽量读取离Reader最近的副本，比如同一机架上的副本

---

04

小文件存档

HDFS中的文件按块存档，Block的元数据信息存储在NN的内存中。如果小文件过多，内存中的记录过多就会影响查询效率

一条元数据记录150byte，1G内存可以存715w个Block信息

1.小文件归档

小文件归档就是把众多小文件打包成一个文件，打包后文件可以按 dfs.block.size的大小分块。对外作为一个整体，对内仍是独立的文件，从而降低NN的内存压力

可以使用archive命令进行归档

//将/bigleg/input目录下的文件归档为one.har文件并存在/bigleg/outputbin/hadoop archive -archiveName one.har –p /bigleg/input /bigleg/output
//查看归档文件hadoop fs -lsr har:///bigleg/output/one.har
//解归档文件hadoop fs -cp har:///bigleg/output/one.har/* /bigleg/input

---

你学废了吗?

— END  —