hdfs分布式文件系统简介与设计原理_计算机文件系统与hdfs研究

一、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共享

• 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:确保副本放置符合策略要求

• 控制面建设：好的系统不是只实现基本功能，还要实现监控和运维体系

  • 可观测性设施：比如系统指标监控设施等，帮助快速发现定位问题。

    • 指标埋点
    • 数据米乐
    • 访问日志
    • 数据分析

  • 运维体系建设：从最基本的命令行手工操作，脚本自动化再到完善的运维平台。

    • 运维操作需要平台化
    • NameNode操作复杂
    • DataNode机器规模庞大

  • 可观测性设施：比如系统指标监控设施等，帮助快速发现定位问题。

    • 指标埋点
    • 数据米乐
    • 访问日志
    • 数据分析

  • 运维体系建设：从最基本的命令行手工操作，脚本自动化再到完善的运维平台。

    • 运维操作需要平台化
    • NameNode操作复杂
    • DataNode机器规模庞大
    • 组件控制面API