第一章 HDFS分布式文件系统

第一章 HDFS分布式文件系统

HDFS是一种允许文件通过网络在多台主机上分享的文件系统，可以让多台机器上的多个用户分享文件和存储空间。

HDFS只是分布式文件管理系统中的一种。

• 文件系统：文件系统是一种存储和组织计算机数据的方法， 它使得对其访问和查找变得容易。
• 文件名：在文件系统中，文件名是用于定位存储位置。
• 元数据（Metadata）：保存文件属性的数据，如文件名，文件长度， 文件所属用户组，文件存储位置等。
• 数据块（Block）：存储文件的最小单元。对存储介质划分了固定的区域，使用时按这些区域分配使用。

1.HDFS概述及应用场景

1.1 HDFS的适用场景

适合一次写入，多次读出的场景，且不支持文件的修改。

1.2 HDFS的优点

1. 高容错性 ---- 副本机制
2. 适合处理大数据
3. 可构建在廉价的机器上

1.3 HDFS的缺点

1. 不适合低延时数据访问

   HDFS是为高数据吞吐量应用优化的，这样就会造成以高时间延迟为代价。

2. 无法高效的对大量小文件进行存储

   NameNode启动时，将文件系统的元数据加载到内存，因此文件系统所能存储的文件总数受限于NameNode内存容量。根据经验，每个文件，目录和数据块的存储信息大约占150字节，如果一百万个文件，且每个文件占一个数据块，那至少需要300MB的内存空间，但是如果存储十亿个文件，那么需要的内存空间将是非常大的。

3. 不支持并发写入，文件随机修改

   现在HDFS文件只有一个writer，而且写操作总是写在文件的末尾。也不支持在文件的任意位置进行修改。可能以后会支持，但相对比较低效。

1.4 流式数据访问

1. 在数据集生成后，长时间在此数据集上进行各种分析。

2. 每次分析都将涉及该数据集的大部分数据甚至全部数据，因此读取整个数据集的时间延迟比读取第一条记录的时间延迟更重要。

3. 与流数据访问对应的是随机数据访问，它要求定位、查询或修改数据的延迟较小，比较适合于创建数据后再多次读写的情况，传统关系型数据库很符合这一点。

1.5 应用场景：

• 网站数据存储
• 交通电子眼
• 气象数据
• 传感器数据

2.HDFS相关概念

2.1 基本系统架构

HDFS架构包含三个部分：NameNode，DataNode，Client。

• NameNode

  NameNode用于存储、生成文件系统的元数据。运行一个实例。

• DataNode

  DataNode用于存储实际的数据，将自己管理的数据块上报给NameNode，运行多个实例。

• Client

  支持业务访问HDFS，从NameNode,DataNode获取数据返回给业务。多个实例，和业务一起运行。

2.2 Block-块

• HDFS默认一个块128M，是存储的基本单位
• 块大小远远大于普通文件系统，可以减少寻址开销

块的优势：

• 支持大规模文件存储：

  文件以块为单位进行存储，一个大规模文件可以被分拆成若干个文 件块，不同的文件块可以被分发到不同的节点上。
  因此，一个文件的大小不会受到单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量

• 简化系统设计：

  首先，大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块；
  其次，方便了元数据的管理，元数据不需要和文件块一起存储，
  可以由其他系统负责管理元数据。

• 方便数据备份：

  每个文件块都可以冗余存储到多个节点上，大大提高了系统的容错性和可用性。

2.3 NameNode和DataNode

NameNode：

• 管理HDFS的名称空间
• 配置副本策略
• 管理数据块的映射信息
• 处理客户端读写请求

在HDFS中，名称节点（NameNode）负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构，即FsImage和EditLog。

• FsImage

  用于维护文件系统树以及文件树中所有的文件和文件夹的元数据

• EditLog

  记录了所有针对文件的创建、删除、重命名等操作

DataNode：

• 存储实际的数据块
• 执行数据块的读/写操作

每个数据节点的数据都保存在各自节点的本地linux系统中。

3.HDFS体系架构介绍

3.1 体系架构概述

3.2 HDFS命名空间管理

• HDFS的命名空间包括目录，文件和块
• HDFS使用的是传统分级文件体系，用户可以创建，删除目录和文件，目录间转移文件，重命名文件
• NameNode负责维护命名空间，记录更改操作

应用程序可以指定应由HDFS维护的文件副本的数量。文件的副本数称为该文件的复制因子，此信息由NameNode存储。

3.3 通信协议

• 所有通信以TCP/IP为基础
• Client与NameNode间：TCP连接，客户端协议
• NameNode与DataNode间：数据节点协议
• Client与DataNode间：RPC框架，NameNode不会主动发起RPC，而是响应DataNode和Client的RPC请求

3.4 客户端

• 客户端是一个库，包含HDFS文件系统接口，隐藏了HDFS内部的实现复杂性
• 严格来说，客户端并不是HDFS的一部分
• 提供了Java API，供应用程序访问文件系统

3.5 单NameNode局限性

• 命名空间限制：

  NameNode是保存在内存中的，容纳对象个数（文件，块）受内存上限制约

• 性能瓶颈：

  整个分布式集群吞吐量受限于NameNode单节点吞吐量

• 隔离问题：

  只有一个命名空间，无法对不同应用隔离

4.关键特性介绍

4.1 HDFS高可用HA

• NameNode利用Zookeeper主备
• ZooKeeper主要用来存储HA下的状态文件，主备信息
• ZKFC(ZooKeeperFailover Controller)用于监控NameNode节点的主备状态
• JN(JournalNode)用于存储Active NameNode生成的Editlog。
  Standby NameNode加载JN上Editlog，同步元数据

ZKFC：

• ZKFC作为一个精简的仲裁代理，其利用zookeeper的分布式锁功能，实现主备仲裁，再通过命令通道，控制NameNode的主备状态。
• ZKFC与NameNode部署在一起，两者个数相同。

4.2 元数据同步

• 主NameNode提供服务，生成的EditLog同时写入本地和JN，同时更新内存中元数据
• 备NameNode监控到JN的EditLog变化，加载EditLog进内存，生成与主NameNode一样的元数据，同步完成
• 主备的FSImage保存在各自磁盘中，不产生交互，定期与EditLog进行合并。FSImage是内存中元数据定期写入本地磁盘的副本，也叫元数据镜像

4.3 元数据持久化

FSImage.ckpt:

• 在内存中对 fsimage 文件和 EditLog 文件合并（merge） 后产生新的 fsimage，写到磁盘上，这个过程叫checkpoint。
• 备用 NameNode 加载完 fsimage 和 EditLog 文件后， 会将 merge后的结果同时写到本地磁盘和 NFS。此时磁盘上有一份原始的 fsimage 文件和一 份新生成的 checkpoint 文件： fsimage.ckpt. 而后将 fsimage.ckpt 改名为 fsimage （ 覆盖原 有的 fsimage ） 。

EditLog.new:

• NameNode 每隔 1 小时或 Editlog 满 64MB 就触发合并 , 合并时 , 将数据传到 Standby NameNode时 , 因数据读写不能同步进行 , 此时 NameNode 产生一个新的日志文件 Editlog.new 用来存放这段时间的操作日志。
• Standby NameNode 合并成 fsimage 后回传给主NameNode 替换掉原有 fsimage, 并将Editlog.new 命名为 Editlog 。

4.4 HDFS联邦机制

应用场景：

超大规模文件存储。

如互联网公司存储用户行为数据、电信历史数据、语音数 据等超大规模数据存储。
此时 NameNode的内存不足以支撑如此庞大的集群。

Federation简单理解：

各 NameNode 负责自己所属的目录。与 Linux 挂载磁盘到目录类似， 此时每个 NameNode 只负责整个 hdfs 集群中部分目录。

如 NameNode1 负责 /database 目录， 那么在 /database 目录下的文件元数据都由NameNode1 负责。
各 NameNode 间元数据不共享， 每个 NameNode 都有对应的 standby 。

4.5 数据副本机制：

副本距离计算公式：

• Distance(Rack1/D1, Rack1/D1)=0 同一台服务器的距离为 0 。
• Distance(Rack1/D1, Rack1/D3)=2 同一机架不同的服务器距离为 2 。
• Distance(Rack1/D1, Rack2/D1)=4 不同机架的服务器距离为 4 。
• 不同数据中心的节点距离为 6

副本放置策略：

• 第一个副本： 放置在上传文件的数据节点； 如果是集群外提交， 则随机挑选一台磁盘 不太满、 CPU 不太忙的节点
• 第二个副本：放置在与第一个副本不同的机架的节点上
• 第三个副本： 与第一个副本相同机架的其他节点上
• 更多副本： 随机节点

4.6 数据完整性保障：

• 重建失效副本数据

  NameNode与DataNode间心跳保持，如有损坏发起重建

• 集群数据均衡

  DataNode数据分布平均，避免热点节点

• 元数据可靠保障

  日志机制，快照机制

• 安全模式

  当节点硬盘故障时，进入安全模式，HDFS 只支持访问元数据， 此时 HDFS 上的数据是只读的，其他的操作如创建、删除文件等操作都会导致失败。待硬盘问题解决、 数据恢复后， 再退出安全模式。

4.7 HDFS3.0新特性

• 纠删码 Erasure Encoding

在原始数据中加入校验数据，用于数据恢复，冷存储，节省存储空间

• 基于 HDFS 路由器的联合添加一个 RPC 路由层， 提供多个 HDFS 命名空间的联合视图。

• 简化了对现有HDFS客户端的访问

5.HDFS的读写数据流程

5.1 HDFS写入流程

HDFS写入流程如下：

• 业务应用调用 HDFS Client 提供的 API ，请求写入文件。
• HDFS Client 联系 NameNode，NameNode 在元数据中创建文件节点。
• 业务应用调用 write API 写入文件。
• HDFS Client 收到业务数据后，从 NameNode 获取到数据块编号、位置信息后，联系 DataNode，并将需要写入数据的 DataNode 建立起流水线。完成后，客户端再通过 自有协议 写入数据到 DataNode1，再由 DataNode1 复制到 DataNode2, DataNode3 。
• 写完的数据， 将返回确认信息给 HDFS Client 。
• 所有数据确认完成后， 业务调用 HDFS Client 关闭文件。
• 业务调用 close, flush 后 HDFS Client 联系 NameNode ， 确认数据写完成，NameNode 持久化元数据。

5.2 HDFS读取流程

HDFS数据读取流程如下：

• 业务应用调用 HDFS Client 提供的 API 打开文件。
• HDFS Client 联系 NameNode ，获取到文件信息（数据块编号、 DataNode 位置信息）。
• 业务应用调用 read API 读取文件。
• HDFS Client根据从 NameNode 获取到的信息， 联系 DataNode ， 获取相应的数据块。 (Client 采用就近原则读取数据 ) 。
• HDFS Client 会与多个 DataNode 通讯获取数据块。
• 数据读取完成后， 业务调用 close 关闭连接。