文章目录
- 1. HDFS 概述
- 2. HDFS 优缺点
- 2.1. 优点
- 2.2. 缺点
- 3. HDFS 组成架构
- 3.1. NameNode
- 3.2. DataNode
- 3.3. Client
- 3.4. Secondary NameNode
- 4. HDFS 读写流程
- 4.1 HDFS 写数据流程
- 4.2 HDFS 读数据流程
- 5. NameNode 高可用
- 5.1 SecondName 方案
- 5.2 HDFS HA 方案
- 5.2.1. HDFS HA 工作要点
- 5.2.2. HDFS-HA 自动故障转移工作机制
- 5.3 单点故障 与 脑裂
- 6. HDFS 文件块大小配置
- 7. DataNode工作机制
1. HDFS 概述
背景
:随着数据量越来越大,在一个操作系统存不下所有的数据,那么就分配到更多的操作系统管理的磁盘中,但是不方便管理和维护,迫切需要一种系统来管理多台机器上的文件,这就是分布式文件管理系统。HDFS 只是分布式文件管理系统中的一种,主流分布式文件管理系统还有 GFS(Google),TFS(Taobao),Ceph等,其他DFS参考博文:
定义
:HDFS(Hadoop Distributed File System),它是一个文件系统,用于存储文件,通过目录树来定位文件;其次,它是分布式的,由很多服务器联合起来实现其功能,集群中的服务器有各自的角色。
使用场景
:适合一次写入,多次读出的场景。一个文件经过创建、写入和关闭之后就不需要改变。
2. HDFS 优缺点
2.1. 优点
- 高容错
- 数据自动保存多个副本。它通过增加副本的形式,提高容错性。
- 某一个副本丢失以后,它可以自动恢复。
- 适合处理大数据
- 数据规模:能够处理数据规模达到GB、TB、甚至PB级别的数据;
- 文件规模:能够处理百万规模以上的文件数量,数量相当之大。
- 可构建在廉价机器上,通过多副本机制,提高可靠性。
2.2. 缺点
- 不适合低延时数据访问,比如毫秒级的存储数据,是做不到的。
- 无法高效的对大量小文件进行存储。
- 存储大量小文件的话,它会占用NameNode大量的内存来存储文件目录和块信息。这样是不可取的,因为NameNode的内存总是有限的;
生产环境NN的运行内存为128GB;
存储一个block元信息的需要150B;
理论上最大存储数量为916259689,约9亿1千6百2十5万多个。
- 小文件存储的寻址时间会超过读取时间,它违反了HDFS的设计目标。
家用机械硬盘转速主流为 7200,平均寻址速度大概多少为 14 ms左右,
服务器 机械硬盘 转速主流 为 10000~150000,平均寻址时间,取个整数 10 ms
- 不支持并发写入、文件随机修改。
- 一个文件只能有一个写,不允许多个线程同时写。
- 仅支持数据append(追加),不支持文件的随机修改
3. HDFS 组成架构
下图是 HDFS 写入及读取 的简单流程
3.1. NameNode
Master,它是集群的主管、管理者,简称 NN,负责如下工作:
- 管理HDFS的名称空间。
- 配置副本策略。
- 管理数据块(Block)映射信息。
- 处理客户端读写请求。
3.2. DataNode
Slave,NameNode下达命令,DataNode执行实际的操作,负责如下工作:
- 存储实际的数据块。
- 执行数据块的读/写操作。
3.3. Client
客户端,HDFS支持命令行/web(需要配置打开) 以及 API 方式 访问 HDFS
- 文件切分。文件上传HDFS的时候,Client将文件切分成一个一个的Block,然后进行上传。
- 与NameNode交互,获取文件的位置信息。
- 与DataNode交互,读取或者写入数据。
- Client提供一些命令来管理HDFS,比如NameNode格式化。
- Client可以通过一些命令来访问HDFS,比如对HDFS增删查改操作。
3.4. Secondary NameNode
并非NameNode的热备。当NameNode挂掉的时候,它并不能马上替换NameNode并提供服务。
- 辅助NameNode,分担其工作量,比如定期合并Fsimage和Edits,并推送给NameNode。
- 在紧急情况下,可辅助恢复NameNode。
4. HDFS 读写流程
4.1 HDFS 写数据流程
- 客户端通过 DistributedFileSystem 模块向 NameNode 请求上传文件,
- NameNode 检查父目录是否存在,目标文件是否已存在,是否拥有写入权限,响应客户端通过。
- 客户端请求第一个 Block 上传到哪几个 DataNode 服务器上。
- NameNode 通过计算(最短距离)获得,最佳存储节点,比如 dn1,dn2,dn3,响应给客户端。
节点距离:两个节点到达最近的共同祖先的距离总和。
Hadoop3.1.3副本节点选择:
- 第一个副本在Client所处的节点上。如果客户端在集群外,随机选一个。
- 第二个副本在另一个机架的随机一个节点
- 第三个副本在第二个副本所在机架的随机节点
- 客户端创建 FSDataOutputStream ,以及数据缓存区,将需要上传的数据封装为一个个的 chunk,一个chunk由4byte的chunksum头信息,和512byte 数据信息组成。当chunk累计大小到达64k时,就将这他们封装为一个packet,一个个的packet组成packet队列,等待上传。与此同时,还有一个ACK队列存在,ACK队列不但保存校验信息,还会保存一份packet数据,以供dn写入数据失败重新读取。
- FSDataOutputStream 模块请求建立 dn1 上传数据通道,dn1 收到请求,有请求建立dn2上传数据通道,然后 dn2 收到请求,又请求 建立 dn3 上传数据通道,将这个通信管道建立完成。
- 通信管道连接成功后,向客户端确认连接,准备开始上传数据。
- 客户端开始往 dn1 上传第一个 Block(先从磁盘读取数据放到一个本地内存缓存),以 Packet 为单位,dn1 收到一个 Packet 就会传给 dn2,dn2 传给 dn3;dn1 每传一个 packet会放入一个应答队列等待应答
- 一个 Block 数据 全部上传成功后,客户端向 NameNode 确认一个Block数据上传成功,重复以上操作。
4.2 HDFS 读数据流程
- 客户端通过 DistributedFileSystem 模块向 NameNode 请求读取文件,
- NameNode 检查父目录是否存在,目标文件是否已存在,是否拥有写入权限。通过则在元数据区检索文件对应的block所在 DataNode 信息,并响应给客户端
- 拿到节点信息之后,优先找最近的节点读取,如 DataNode1, block1。若最近的节点负载过高,则找下个节点读取下个block,如DataNode2, block2。
- 客户端请求 DataNode1,读取第一个文件块 即block1,DataNode1响应给客户端。
- 客户端请求 DataNode2,读取第二个文件块 即block2,DataNode2响应给客户端。
- 直到全部block都读取完成,HDFS的读数据流程完成。
5. NameNode 高可用
NN和2NN的故事
:
首先,我们做个假设,如果存储在 NameNode 节点的磁盘中,因为经常需要进行随机访问,还有响应客户请求,必然是效率过低。因此,元数据需要存放在内存中。但如果只存在内存中,一旦断电,元数据丢失,整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage
。
这样又会带来新的问题,当在内存中的元数据更新时,如果同时更新 FsImage,就会导致效率过低,但如果不更新,就会发生一致性问题,一旦 NameNode 节点断电,就会产生数据丢失。因此,引入 Edits 文件(只进行追加操作,效率很高)。每当元数据有更新或者添加元数据时,修改内存中的元数据并追加到 Edits
中。这样,一旦 NameNode 节点断电,可以通过 FsImage 和 Edits 的合并,合成元数据。
但是,如果长时间添加数据到 Edits 中,会导致该文件数据过大,效率降低,而且一旦断电,恢复元数据需要的时间过长。因此,需要定期进行 FsImage 和 Edits 的合并,如果这个操作由NameNode节点完成,又会效率过低。因此,引入一个新的节点SecondaryNamenode专门用于 FsImage 和 Edits 的合并
。
NN和2NN的区别和联系
:
- 区别:
- NameNode负责管理整个文件系统的元数据,以及每一个路径(文件)所对应的数据块信息。
- SecondaryNameNode主要用于定期合并命名空间镜像和命名空间镜像的编辑日志。
- 联系:
- SecondaryNameNode中保存了一份和namenode一致的镜像文件fsimage 和编辑日志 edits。
- 在Namenode发生故障时(假设没有及时备份数据),可以从SecondaryNameNode恢复数据。
5.1 SecondName 方案
Hadoop1.x使用的方案
- 第一阶段:namenode启动
- 第一次启动namenode格式化后,data/tmp/dfs/name/current生成如下文件:
fsimage_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION
Fsimage
:HDFS文件系统元数据的一个永久性的检查点,其中包含HDFS文件系统的所有目录和文件inode的序列化信息。
Edits
:存放HDFS文件系统的所有更新操作的路径,文件系统客户端执行的所有写操作首先会被记录到Edits文件中,只进行追加操作,效率很高。
seen_txid
:保存的是一个数字,就是最后一个edits_的数字每次NameNode启动的时候都会将Fsimage文件读入内存,加载Edits里面的更新操作,保证内存中的元数据信息是最新的、同步的,可以看成NameNode启动的时候就将Fsimage和Edits文件进行了合并。
- 客户端对元数据进行增删改的请求。
- NameNode 记录操作日志,更新滚动日志。
- NameNode 在内存中对元数据进行增删改。
- 第二阶段:Secondary NameNode工作
- Secondary NameNode 询问 NameNode 是否需要 CheckPoint, 带回 NameNode是否检查结果。
触发条件一:默认每隔一小时
。
触发条件二:一分钟
检查一次 NameNode,操作次数达到1百万
。 - Secondary NameNode 请求执行 CheckPoint。
- NameNode 滚动正在写的 Edits 日志, 生成
edits_inprogress
文件。 - 将滚动前的编辑日志和镜像文件拷贝到 Secondary NameNode。
- Secondary NameNode 加载编辑日志和镜像文件到内存,并合并。
- 生成新的镜像文件 fsimage.chkpoint。
- 拷贝 fsimage.chkpoint 到 NameNode。
- NameNode 将 fsimage.chkpoint 重新命名成 fsimage。
5.2 HDFS HA 方案
HDFS HA
功能通过配置 Active/Standby
两种 NameNodes 实现在集群中对 NameNode 的热备来解决上述问题。如果出现故障,如机器崩溃或机器需要升级维护,这时可通过此种方式将 NameNode 很快的切换到另外一台机器。
5.2.1. HDFS HA 工作要点
- 元数据管理方式需要改变
内存中都保存一份元数据。Edits日志只有 Active 的 NameNode 节点可以做写操作;两个 NameNode 都可以读取 Edits;共享的 Edits 放在一个共享存储中管理(qjournal
和 NFS
两个主流实现)。
- 需要一个状态管理功能模块
实现了一个zkfailover
,常驻在每一个 namenode 所在的节点,每一个 zkfailover 负责监控自己所在 NameNode 节点,利用 zk 进行状态标识,当需要进行状态切换时,由 zkfailover来负责切换,切换时需要防止brain split
现象的发生。 - 必须保证两个 NameNode 之间能够 ssh 无密码登录
- 隔离(
Fence
),即同一时刻仅仅有一个 NameNode 对外提供服务,防止脑裂。
5.2.2. HDFS-HA 自动故障转移工作机制
自动故障转移为 HDFS 部署增加了两个新组件:ZooKeeper
和 ZKFailoverController(ZKFC)
进程。ZooKeeper 是维护少量协调数据,通知客户端这些数据的改变和监视客户端故障的高可用服务。HA 的自动故障转移依赖于 ZooKeeper 的以下功能:
故障检测
:
集群中的每个 NameNode 在 ZooKeeper 中维护了一个持久会话,如果机器崩溃,ZooKeeper 中的会话将终止,ZooKeeper 通知另一个 NameNode 需要触发故障转移。现役NameNode选择
:
ZooKeeper 提供了一个简单的机制用于唯一的选择一个节点为 active 状态。如果目前现役 NameNode 崩溃,另一个节点可能从 ZooKeeper 获得特殊的排外锁
以表明它应该成为现役 NameNode。
ZKFailoverController(ZKFC)
是自动故障转移中的另一个新组件,是 ZooKeeper 的客户端
,也监视和管理NameNode 的状态。每个运行 NameNode 的主机也运行了一个 ZKFC 进程,ZKFC 负责:
健康监测
:
ZKFC 使用一个健康检查命令定期地 ping 与之在相同主机的 NameNode,只要该 NameNode 及时地回复健康状态,ZKFC 认为该节点是健康的。如果该节点崩溃,冻结或进入不健康状态,健康监测器标识该节点为非健康的。Zookeepr 会话管理
:
当本地 NameNode 是健康的,ZKFC 保持一个在 ZooKeeper中打开的会话。如果本地 NameNode 处于 active 状态,ZKFC 也保持一个特殊的 znode 锁,该锁使用了 ZooKeeper 对短暂节点的支持,如果会话终止,锁节点将自动删除。基于 ZooKeeper 的选择
:
如果本地 NameNode 是健康的,且 ZKFC 发现没有其它的节点当前持有 znode 锁,它将为自己获取该锁。如果成功,则它已经赢得了选择,并负责运行故障转移进程以使它的本地 NameNode 为 Active。首先补刀(ssh kill -9 xxx
和用户自定义kill脚本
)并确定杀死之前的服役 NameNode,防止脑裂,然后本地NameNode 转换为 Active 状态。
5.3 单点故障 与 脑裂
6. HDFS 文件块大小配置
HDFS中的文件在物理上是分块存储(Block),块的大小可以通过配置参数( dfs.blocksize)来规定,默认大小在 Hadoop1.x
版本中是64M
,在 Hadoop2.x/3.x
版本中是128M
。
dfs.blocksize 即 文件块大小配置受什么因素影响?
- HDFS的块设置太小,会增加寻址时间,程序一直在找块的开始位置;
- 如果块设置的太大,从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。导致程序在处理这块数据时,会非常慢。
上面说了服务器机械硬盘寻址时间约为 10 ms左右,根据公式 传输时间 X 1% = 寻址时间
,可以得到,传输时间为 1s,机械硬盘读写速率在 100 MB/s 左右,取一个最接近的值就是 128 MB
。如果使用 SSD,SSD读写速率在 300 MB/s 左右,寻址时间和读写速率都更优异,经过计算设置为 256MB
较为合适。
总结:HDFS块的大小设置主要取决于磁盘传输速率
7. DataNode工作机制
- 一个数据块在 DataNode 上以文件形式存储在磁盘上,包括两个文件,一个是数据本身,一个是元数据包括数据块的长度,块数据的校验和,以及时间戳。
- DataNode 启动后向 NameNode 注册,通过后,周期性(6 小时)的向 NameNode 上报所有的块信息。
dfs.blockreport.intervalMsec: DN 向 NN 汇报当前解读信息的时间间隔,默认
6 小时
dfs.datanode.directoryscan.interval: DN 扫描自己节点块信息列表的时间,默认
6 小时
心跳是每 3 秒一次
,心跳返回结果带有 NameNode 给该 DataNode 的命令如复制块数据到另一台机器,或删除某个数据块。如果超过 10 分钟
没有收到某个DataNode 的心跳,则认为该节点不可用。- 集群运行中可以安全加入和退出一些机器。