HDFS原理与应用
这是我参与「 第四届青训营 」笔记创作活动的的第八天
1.HDFS概述
Hadoop Distributed File System,简称 HDFS,是一个分布式文件系统。HDFS 有着高容错性的特点,并且设计用来部署在低廉的硬件上。而且它提供高吞吐量来访问应用程序的数据,适合那些有着超大数据集的应用程序。HDFS 放宽了POSIX 的要求这样可以实现流的形式访问文件系统中的数据。
1.hadoop技术体系
- 存储层:HDFS
- 调度层:YARN
- 计算框架:MapReduce。值得注意的是另外一个同属于Apache基金会的开源计算框架Apache Spark,当前业界的使用已经远超于MapReduce,尽管它不属于Hadoop项目,但是和Hadoop也有紧密关系。
2.文件系统
单机文件系统非常普遍,从Windows NTFS到Linux的Ext4等,分布式文件系统是单机文件的延伸,概念术语是相通的,比如目录、文件、目录树等。
- 单机文件系统:常见的如Windows NTFS,Linux的Ext4,虽然不同的操作系统和实现,但是本质都是一样的,解决相同的问题。
- 分布式文件系统:本质上扩展、延伸了单机文件系统,提供了大容量、高可靠、低成本等功能特性;实现上一般也更为复杂。
3.分布式存储系统
了解分布式存储系统的分类,理解不同存储系统的使用场景。直观的区别是用户使用方式,本质是针对不同的使用场景提供高效合理的系统。
- 对象存储:例如AWS的S3,阿里云的OSS,开源的Minio。
- 块存储:例如AWS的EBS,开源社区也有Ceph等。
- 文件系统:HDFS、GlusterFS、CubeFS等
- 数据库:KV数据库比如Cassandra,关系型数据库如TiDB、OceanBase等
4.HDFS功能特性
需要注意HDFS尽管是一个文件系统,但是它没有完整实现POSIX文件系统规范。
- 分布式:受GFS启发,用Java实现的开源系统,没有实现完整的POSIX文件系统语义
- 容错:自动处理,规避多种错误场景,例如常见的网络错误、机器宕机等
- 高可用:一主多备模式实现元数据高可用,数据多副本实现用户数据的高可用
- 高吞吐:Client直接从DataNode读取用户数据,服务端支持海量client并发读写
- 可扩展:支持联邦集群模式,DataNode数量可达10w级别
- 廉价:只需要通用硬件,不需要定制昂贵的硬件设备
2.HDFS架构原理
1.HDFS组件
- Client/SDK:读写操作的发起点,HDFS很多读写逻辑都是在SDK中实现的。
- NameNode:元数据节点,是HDFS的中枢节点,也是服务的入口。
- DataNode:数据节点,存放实际用户数据。
2.HDFS读流程
客户端先跟NameNode交互,问要读取的数据在哪里,NameNode告诉客户端数据存储在哪些DataNode,用户端直接读取DateNode的数据
3.HDFS写流程
客户端先跟NameNode交互,可以写到哪个节点上,NameNode会在自己的DataNode选择三块返回给他,拿到列表后,客户端在其中一个DateNode开始写数据,然后DateNode把数据复制到另外两个DateNode当中去。
4.源数据节点NameNode
- 维护目录树:维护目录树的增删改查操作,保证所有修改都能持久化,以便机器掉电不会造成数据丢失或不一致
- 维护文件和数据块的关系:文件被切分成多个块,文件以数据块为单位进行多副本存放,这些块存放在DataNode上,由NameNode来维护
- 维护文件快存放节点信息:通过接受DataNode的心跳汇报信息,维护集群节点的拓扑结构和每个文件块所有副本所在的DataNode等
- 分配新文件存放节点:Client创建新的文件时候,需要有NameNode来确定分配目标DataNode
5.数据节点DataNode
- 数据块存取:DataNode需要高效实现对数据块在硬盘上的存取
- 心跳汇报:把存放在本机的数据块列表发送给NameNode,以便NameNode能维护数据块的位置信息,同时让NameNode确定该节点处于正常存活状态
- 副本复制:1.数据写入时Pipeline IO操作 2.机器故障时补全副本
3.关键设计
1.分布式存储系统基本概念
- 容错能力:能够处理绝大部分异常场景,例如服务器宕机、网络异常、磁盘故障、网络超时等
- 一致性模型:为了实现容错,数据必须多副本存放,一致性要解决的问题时如何保障这不同机器多个副本的内容都是一致的
- 可扩展性:分布式存储系统需要具备横向扩张scale-out的能力,容量不够,可以通过加节点做一些扩展等
- 节点体系:常见的有主从模式、对等模式等,不管哪种模式,高可用是必须的功能
- 数据防止:系统是由多个节点组成,数据是多个副本存放时,需要考虑数据存放的策略
- 单机存储引擎:在绝大部分存储系统中,数据都是需要落盘持久化,单机引擎需要解决的时根据兄特点,如何高效的存取硬盘数据
2.NameNode目录树维护
fsimage
- 文件系统目录树
- 完整的存放在内存中
- 定时存放到硬盘上
- 修改是只会修改内存中的目录树 EditLog
- 目录树的修改日志
- client更新目录树需要持久化EditL og后才能表示更新成功
- EditL og可存放在本地文件系统,也可存放在专用系统上
- NameNode HA方案一个关键 点就是如何实现EditL og共享
3.NameNode数据放置
数据块信息维护
- 目录树保存每个文件的块id
- NameNode维护了每个数据块所在的节点信息
- NameNode根据DataNode汇报的信息动态维护位置信息
- NameNode不会持久化数据块位置信息 数据放置策略
- 新数据存放到哪写节点
- 数据均衡需要怎么合理搬迁数据
- 3个副本怎么合理放置
4.DataNode
数据块的硬盘存放
- 文件在 NameNode 已分割成 block
- DataNode 以 block 为单位对数据进行存取 启动扫盘
- DataNode需要知道本机存放了哪些数据块
- 启动时把本机硬盘上的数据块列表加载在内存中
5.HDFS写异常处理: Lease Recovery
情景:文件写了一半,client自己挂掉了。可能产生的问题:没有ACK,副本不一致;Lease无法释放
租约:Client要修改一个文件时,需要通过NameNode上锁,这个锁就是租约(Lease)
解决方法:Lease Recovery(租约恢复) 副本不一致,比较三个副本大小长度,选择最小的作为最终版本去更新,返回给NameNode作为最终结果 租约无法释放,客户端拿到租约需要定期续租,挂掉了无法续约,客户端就会判断他死了,如果有别的进程想拿租约,就会把原来的踢掉。
6.HDFS写异常处理:Pipeline Recovery
情景:文件写入过程中,DataNode侧出现异常挂掉了,服务端出错了 异常出现的时机:
- 创建连接时
- 数据传输时
- complete阶段
解决方法: Pipeline Recovery
7.Client读异常处理
情景:读取文件的过程,DataNode 侧出现异常挂掉了
解决方法: 节点Failover
增强情景: 节点半死不过,读取很慢