一、hdfs基本介绍
全程hadoop distributed file system
技术体系
计算框架:MapReduce。值得注意的是另外一个同属于Apache基金会的开源计算框架Apache Spark,当前业界的使用已经远超于MapReduce,尽管它不属于Hadoop项目,但是和Hadoop也有紧密关系。
单机文件系统
文件系统:单机文件系统非常普遍,从Windows NTFS到Linux的Ext4等,分布式文件系统是单机文件的延伸,概念术语是相通的,比如目录、文件、目录树等。
-
单机文件系统:常见的如Windows NTFS,Linux的Ext4,虽然不同的操作系统和实现,但是本质都是一样的,解决相同的问题。
-
分布式文件系统:本质上扩展、延伸了单机文件系统,提供了大容量、高可靠、低成本等功能特性;实现上一般也更为复杂。
分布式文件系统
分布式文件系统优点
-
大容量
- 更多的机器,更多的存储介质
-
高可靠
- 多个副本提高容错能力
-
低成本
- 不需要高端硬件来扩容
对象存储:例如AWS的S3,阿里云的OSS,开源的Minio。
块存储:例如AWS的EBS,开源社区也有Ceph等。
文件系统:HDFS、GlusterFS、CubeFS等
数据库:KV数据库比如Cassandra,关系型数据库如TiDB、OceanBase等
HDFS功能特性
- 分布式
- 受GFS启发,用Java实现的开源系统,没有量client并发读写
- 容错
- 自动处理、规避多种错误场景,例如常见的网络错误、机器宕机等。
- 高可用
- —主多备模式实现元数据高可用,数据多副本实现用户数据的高可用
- 高吞吐
- Client直接从DataNode读取用户数据,服务端支持海量client并发读写
- 可扩展
- 支持联邦集群模式,DataNode数量可达10w级别
- 廉价
- 只需要通用硬件,不需要定制高端的昂贵硬件设备
二、架构原理
HDFS组件
- Client/SDK:读写操作的发起点,HDFS很多读写逻辑都是在SDK中实现的。
- NameNode:元数据节点,是HDFS的中枢节点,也是服务的入口。
- DataNode:数据节点,存放实际用户数据。
client写流程
数据存储到一个datanode后会依次复制到两个datanode
client读流程
读流程只读其中一个副本
NameNode
Namenode作用
- 维护目录树
- 维护目录树的增删改查操作,保证所有修改都能持久化,以便机器掉电不会造成数据丢失或不一致。
- 维护文件和数据块的关系
- 文件被切分成多个块,文件以数据块为单位进行多副本存放
- 维护文件块存放节点信息
- 通过接收DataNode的心跳汇报信息,维护集群节点的拓扑结构和每个文件块所有副本所在的DataNode类表。
- 分配新文件存放节点
- Client创建新的文件时候,需要有NameNode来确定分配目标DataNode
DateNode
Datenode作用
-
数据块存取
- DataNode需要高效实现对数据块在硬盘上的存取
-
心跳汇报
-
把存放在本机的数据块列表发送给NameNode,以便NameNode能维护数据块的位置信息,同时让
-
NameNode确定该节点处于正常存活状态
-
-
副本复制
- 1.数据写入时Pipeline lO操作
- 2.机器故障时补全副本
三、关键设计
基本设计
-
容错能力
- 能够处理绝大部分异常场景,例如服务器宕机、网络异常、磁盘故障、网络超时等。
-
一致性模型
- 为了实现容错,数据必须多副本存放,一致性要解决的问题是如何保障这多个副本的内容都是一致的
-
可扩展性
- 分布式存储系统需要具备横向扩张scale-out的能力
-
节点体系
- 常见的有主从模式、对等模式等,不管哪种模式,高可用是必须的功能。
-
数据放置
- 系统是由多个节点组成,数据是多个副本存放时,需要考虑数据存放的策略。
-
单机存储引擎
- 在绝大部分存储系统中,数据都是需要落盘持久化,单机引擎需要解决的是根据系统特点,如何高效得存取硬盘数据。
-
NameNode目录树设计,重点理解EditLog的设计,可类比关系型数据库中的Transaction Log概念。
- 仅在内存中修改:fsimage
- 文件系统目录树完整的存放在内存中
- 定时存放到硬盘上
- 修改是只会修改内存中的目录树
- 需要立即保存到硬盘:EditLog
- 目录树的修改日志
- client更新目录树需要持久化EditLog后才能表示更新成功EditLog可存放在本地文件系统,也可存放在专用系统
- NameNode HA方案一个关键点就是如何实现EditLog共享
- 仅在内存中修改:fsimage
-
NameNode数据放置:数据分散在各个节点上,如何定位找到它们?
- 数据块信息维护
- 目录树保存每个文件的块id
- NameNode维护了每个数据块所在的节点信息
- NameNode根据DataNode汇报的信息动态维护位置信息NameNode不会持久化数据块位置信息
- 数据块的放置分布策略
- 新数据存放到哪写节点
- 数据均衡需要怎么合理搬迁数据
- 3个副本怎么合理放置
- 数据块信息维护
-
DataNode设计:数据如何落盘存放?
- 数据块硬盘存放
- 文件在NameNode已分割成block
- DataNode以block为单位对数据进行存取
- 启动扫盘获得本机文件块列表
- DataNode需要知道本机存放了哪些数据块
- 启动时把本机硬盘上的数据块列表加载在内存中
- 数据块硬盘存放
-
Client读写链路的异常处理
-
Server端异常
- 情景:文件写入过程中,DataNode侧出现异常挂掉了。
- 可能出现在:创建连接时、数据传输时、complete阶段
- 解决方法:Pipeline Recovery
-
Client端异常
-
client写异常处理: 解决方法—Lease Recovery
-
租约:Client要修改一个文件时,需要通过NameNode上锁,这个锁就是租约(Lease)。
-
情景:文件写了一半,client自己挂掉了。可能产生的问题:副本不一致、Lease无法释放
-
client读异常: 解决方法—节点faliover
- 读取文件的过程,DataNode 侧出现异常挂掉了
-
-
慢节点 (判断读取速度)
-
-
旁路系统:保障系统稳定运行
- HouseKeeping组件:比如Balancer,Mover等, 这些组件不运行不会马上影响读写操作,但是长时间会积累系统性问题,例如读写不均衡导致IO热点等。
- Balancer:均衡DataNode的容量
- Mover:确保副本放置符合策略要求
- HouseKeeping组件:比如Balancer,Mover等, 这些组件不运行不会马上影响读写操作,但是长时间会积累系统性问题,例如读写不均衡导致IO热点等。
-
控制面建设:好的系统不是只实现基本功能,还要实现监控和运维体系
-
可观测性设施:比如系统指标监控设施等,帮助快速发现定位问题。
- 指标埋点
- 数据米乐
- 访问日志
- 数据分析
-
运维体系建设:从最基本的命令行手工操作,脚本自动化再到完善的运维平台。
- 运维操作需要平台化
- NameNode操作复杂
- DataNode机器规模庞大
-
可观测性设施:比如系统指标监控设施等,帮助快速发现定位问题。
- 指标埋点
- 数据米乐
- 访问日志
- 数据分析
-
运维体系建设:从最基本的命令行手工操作,脚本自动化再到完善的运维平台。
- 运维操作需要平台化
- NameNode操作复杂
- DataNode机器规模庞大
- 组件控制面API
-