03-分布式文件系统HDFS

目录

一，HDFS简介

1，什么是HDFS

2，优缺点

2.1 优点

2.2 缺点

二，HDFS原理

1，系统架构

1.1 角色分工

1.2 设计思想

2，数据存储

2.1 文件存储

2.2 元数据存储

3，读写操作

3.1 写操作

3.2 读操作

4，安全模式

4.1 什么是安全模式

4.2 何时离开安全模式

4.3 触发安全模式的原因

5，高可用

5.1 NameNode高可用

---

文章内容来自：南京大学 / 星环科技课程，大数据理论与实践课程Ⅰ

对细节部分引用其他网络资源进行补充。

一，HDFS简介

1，什么是HDFS

概念

• Hadoop分布式文件系统（Hadoop Distributed File System） • 2003年10月Google发表了GFS（Google File System）论文
• HDFS是GFS的开源实现
• HDFS是Apache Hadoop的核心子项目
• 在开源大数据技术体系中，地位无可替代

设计目标

• 运行在大量廉价商用机器上：硬件错误是常态，提供容错机制；
• 简单一致性模型：一次写入多次读取，支持追加写，但不允许并发写和随机修改，通过对写操作的严格限制来保证数据的一致性；
• 流式数据访问：批量读而非随机读，关注吞吐量而非时间；
• 存储大规模数据集：典型文件大小GB~TB（大文件），关注横向线性扩展；

2，优缺点

2.1 优点

高容错、高可用、高扩展

• 数据冗余，多Block多副本，副本丢失后自动恢复
• NameNode HA、安全模式
• 10K节点规模

海量数据存储

• 典型文件大小GB~TB，百万以上文件数量， PB以上数据规模

构建成本低、安全可靠

• 构建在廉价商用服务器上
• 提供了容错和恢复机制

适合大规模离线批处理

• 流式数据访问
• 数据位置暴露给计算框架

2.2 缺点

不适合低延迟数据访问

不适合存储小文件

• 元数据占用NameNode大量内存空间。每个文件或目录的元数据要占用150Byte，存储1亿个文件，大约需要20GB内存，如果一个文件为10KB，1亿个文件大小仅，1TB，却要消耗掉20GB内存
• 磁盘寻道时间超过读取时间

不支持并发写入

• 一个文件同时只能有一个写入者

不支持随机修改

• 仅支持追加写入

二，HDFS原理

1，系统架构

1.1 角色分工

Active NameNode（AN）

• 活动管理节点（Master / 集群中唯一）
• 管理命名空间：文件系统的目录层次空间
• 管理元数据：目录/文件的基本属性、Block相关信息、DataNode相关信息等
• 管理Block副本策略：副本数（默认3副本）、副本放置策略等
• 管理DataNode：节点上下线动态监测、文件系统健康状况监测、 Block恢复和重分布等
• 处理客户端读写请求：审核权限，编制计划，并为DataNode分配任务

Standby NameNode（SN）

• 热备管理节点（允许多个）。Hadoop 3.0允许配置多个SN，之前的版本只能有一个
• 主备切换：AN宕机后，经过Master选举和元数据恢复，SN升级为AN
• 元数据同步：正常运行期间的周期性同步、AN宕机后的最新同步
• 辅助AN完成FsImage和Edits的合并（合并操作由AN完成的话，效率太低）

DataNode（DN）

• 数据节点（Slave / 高扩展）
• 存储Block数据块和数据校验和
• 向AN和SN汇报情况
• 正常运行：通过心跳机制（默认3秒），定期汇报运行状况和Block信息（包括物理存储位置）
• 集群启动：进入安全模式，集中上报Block信息
• 执行客户端发送的读写命令

Client

• 文件管理
• －发送文件读写请求，并将文件切分为Block或将Block组装为文件
• －与NameNode交互，获取读写计划和相关元数据
• －与DataNode交互，读取或写入Block
• 系统管理：发送HDFS管理命令

1.2 设计思想

角色分工

 数据存储

2，数据存储

2.1 文件存储

1，Block数据块

1）HDFS的最小存储单元

2）多Block多副本

文件被切分为若干个Block，每个Block有多个副本（默认3副本）

Block以DataNode为存储单元，即一个DataNode上只能存放Block的一个副本

机架感知：尽量将副本存储到不同的机架上，以提升数据的容错能力

副本均匀分布：DataNode的Block副本数和访问负荷要比较接近，以实现负载均衡

3）Block大小

默认128M，可设置（若Block中数据的实际大小<设定值 ，则Block大小 = 实际数据大小）

如何调整Block大小。目标：①最小化寻址开销，降到1%以下；②任务并发度和集群负载比较适中，作业运行速度较快

• 块太小：①寻址时间占比过高；②任务太多，并发度太高，导致集群负载过高，作业变慢
• 块太大：任务太少，并发度太低，导致集群负载过低，作业变慢

2，Block副本放置策略

副本1：放在Client所在节点上。对于远程Client，系统会随机选择机架和节点

副本2：放在与副本1不同的机架上

副本3：放在与副本2同一机架的不同节点上

副本N：在遵循相关原则的前提下，随机选择

节点选择原则

－避免选择访问负荷太重的节点

－避免选择存储空间太满的节点

－将副本分散在不同的机架上

3，Block文件

Block数据文件：DataNode本地磁盘中名为“blk_blockId”的Linux文件

Block元数据文件：DataNode本地磁盘中名为“blk_blockId_*.meta”的Linux文件，由一个包含版本、类型信息的头文件和一系列校验值组成

Block文件目录：DataNode启动时自动创建，无需格式化

2.2 元数据存储

1，元数据

目录/文件的基本属性（如名称、所有者）、Block相关信息（如文件包含哪些Block、Block放在哪些节点上）、DataNode相关信息

2，内存元数据

Active NameNode：最新的元数据（= fsimage + edits）

Standby NameNode：通过QJM定期（默认60s）同步AN的元数据

3，文件元数据

1）内存元数据持久化后生成的文件，包括edits和fsimage

2）edits（编辑日志文件）

记录文件系统的每一个变更操作，并定期瘦身

先写edits，再写内存

edits文件名通过“txid前后缀”标记所包含变更操作的范围（txid为变更操作的Transaction id）

3）fsimage（元数据检查点镜像文件）

检查点（Checkpoint）：① 时间间隔（默认1小时），② 变更操作次数（默认100万）

在检查点定期对内存中的元数据进行持久化，生成fsimage镜像文件（速度较慢）

fsimage文件名标记出最后一个变更操作的txid，以下图为例，只要在内存中载入fsimage_19，然后执行edits_inprogress_20，即可还原出最新的元数据

在检查点，当fsimage生成后，删除“edits last txid < (fsimage last txid - txns)”的edits旧文件，从而实现定期瘦身（txns默认为100万）

4，edits与fsimage持久化（Hadoop 1.x）

基于远程合并的持久化

1. 在检查点，SN请求PN停用edits，后续变更操作写入edits.new
2. 将fsimage和edits下载到SN（第一次需下载fsimage）
3. 在内存中载入fsimage，与edits进行合并，然后生成新的fsimage，并将其上传给PN
4. 用新文件替换edits和fsimage（edits实现瘦身）

缺点

• 合并前要先将fsimage载入内存，速度慢 
• 未实现edits高可用：SN上的edits不是最新的，若PN上 的edits损毁，将导致元数据丢失

参考@尚硅谷【NN和2NN的工作机制】

5，edits与fsimage持久化（Hadoop 2.x） 

QJM（Quorum Journal Manager）共享存储系统

• 基于Paxos算法实现的JournalNode集群，实现了edits高可用和共享访问
• 最好部署奇数（2n+1）个节点，最多容忍n个节点宕机 
• 过半（>=n+1）节点写入成功，即代表写操作完成

基于QJM的edits持久化

1. AN将变更操作同步写入本地和QJM edits（该步骤为原子操作）
2. AN将该操作写入内存，并将结果反馈给Client

基于QJM的fsimage持久化 

1. 在检查点，SN通过对内存中的NameSpace上锁，先将QJM edits定期同步（默认60s）暂停下来，再生成fsimage
2. SN将fsimage上传到AN，同时恢复QJM定期同步
3. AN删除本地和QJM中的edits旧文件，完成瘦身

3，读写操作

3.1 写操作

注意：

1，文件在客户端client被切分为块，块的大小一般由磁盘传输速率决定。太小的话增加寻址时间，太大的话磁盘传输时间大于定位块所需时间，导致程序处理数据较慢；

2，HDFS先写block后写元数据（edits日志落盘、写内存），这样才完成。因为block写入时间比较长，出错概率大，所以先写block；

3，从图中可以看出，数据是由DN依次传给其他DN的（8.1-》8.2），而不是由客户端传送给各个DN。这样可以避免客户端无效等待（等最慢的一个DN数据传输结束）

4，如何确认数据传输完毕？按照数据传输的倒序传递成功信号（9.1-》9.2）

下图为尚硅谷课程中关于HDFS写数据流程的介绍，可以相互补充：

3.2 读操作

 下图为尚硅谷课程中关于HDFS读数据流程的介绍，可以相互补充：

注意，选择节点读取数据时有两个因素需要考虑：与客户端所在节点间距离，当前DN的负载情况。

4，安全模式

4.1 什么是安全模式

安全模式是HDFS的一种特殊状态（只读），在该状态下HDFS只接收读请求，不接收写入、删除和修改等变更请求

安全模式是HDFS确保Block数据安全的一种保护机制

Active NameNode启动时，HDFS会自动进入安全模式，DataNode主动向NameNode上报可用Block信息，在达到安全标准前，HDFS一直处于“只读”状态

4.2 何时离开安全模式

Block上报率：DataNode上报的可用Block个数 ÷ NameNode元数据记录的Block个数

当Block上报率 >= 阈值时，HDFS才能离开安全模式（默认阈值为0.999）

不建议手动强制退出安全模式

4.3 触发安全模式的原因

NameNode重启

NameNode磁盘空间不足

DataNode无法正常启动

Block上报率低于阈值

日志中出现严重异常

用户操作不当，如强制关机（特别注意）

5，高可用

在HDFS分布式文件系统中，NameNode是系统核心节点，存储各类元数据信息，并负责管理文件系统的命名空间和客户端对文件的访问。若NameNode发生故障，会导致整个Hadoop集群不可用，即单点故障问题。为了解决单点故障，Hadoop2.0中HDFS中增加了对高可用的支持。

在高可用HDFS中，通常有两台或两台以上机器充当NameNode，无论何时，都要保证至少有一台处于活动（Active）状态，一台处于备用（Standby）状态。Zookeeper为HDFS集群提供自动故障转移的服务，给每个NameNode都分配一个故障恢复控制器（简称ZKFC），用于监控NameNode状态。若NameNode发生故障，Zookeeper通知备用NameNode启动，使其成为活动状态处理客户端请求，从而实现高可用。

参考@悟空非空也​【6 Hadoop2.0新特性】

5.1 NameNode高可用

1，基于ZK实现Master选举

（1）AN或AN-ZKFC宕机，其创建的临时Znode被删除，但永久Znode（存储AN地址）被保留

• 若AN宕机，ZKFC失去与AN的心跳连接，从而监测到故障，然后主动删除临时Znode
• 若AN-ZKFC宕机，ZK失去与ZKFC的心跳连接，会话超时后，临时Znode被自动删除
• 不管是NameNode挂机还是整个服务器出问题（包括ZKFC），都会触发上面的机制。NameNode挂，ZKFC删除临时Znode。服务器挂，由于和session捆绑，所以临时Znode也会被删除

（2）Watcher触发，通知所有SN-ZKFC去竞争创建临时Znode，SN1-ZKFC创建成功，SN1被选举为New AN

（3）其他SN-ZKFC在临时Znode上注册监听器，等待下一次选举

2，通过AN-Fencing防止脑裂

选主结束后，会创建临时Znode和永久Znode。如果ActiveNode异常，由于捆绑删除了临时Znode，但永久Znode仍会存在，所以当再次选主时发现有永久Znode存在，表明属于故障切换，就需要通过fencing避免脑裂。fencing后standBy节点才能进行状态转换

（4）若New-AN-ZKFC发现永久Znode，则通过RPC调用AN-ZKFC的服务，将AN从Active切换为Standby

（5）若步骤④失败，则New-AN-ZKFC直接调用SSL命令（或者执行自定义Shell脚本），Kill AN进程

（6）若步骤④⑤均失败，则需要人工干预

（7）AN-Fencing成功后，New-AN-ZKFC将New AN从Standby切为Active，并正式对外服务（HDFS只读）

3，基于QJM实现元数据恢复

（8）New AN从QJM edits中下载最新的（≤60s）变更操作，并在内存中执行一遍，即可恢复