Hadoop中HDFS的知识

本文主要介绍 HDFS 的设计理念以及详解读流程、写流程和高可用机制等知识。

HDFS 简介

HDFS 是什么

Hadoop 中的 HDFS 被设计成适合运行在通用硬件上的分布式文件系统，他和现有的分布式文件系统有很多相同点，同时也是有区别的，HDFS 放宽了 POSIX 约束，来实现流式读取文件系统数据，并且能提高吞吐量的数据访问。

常见的分布式文件系统

HDFS 的由来

我们知道 HDFS 源于 Google 发布的 GFS 论文，GFS 是为了解决在网络抓取和索引过程产生大量的文件的存储需求，为解决大量文件的存储，HDFS 就诞生了。

HDFS 设计目标

大文件存储：支持 TB、PB 级的数据量；
高容错：运行在商业硬件上，而商业硬件并不可靠；
高吞吐量：为大量数据访问的应用提供高吞吐量的支持。

HDFS 适用场景与不适用场景

适用场景	不适用场景
大文件访问	存储大量小文件
流式数据访问	随机读取，低延迟读取

HDFS 的基本概念

block（数据块）
大文件被分割成多个 block 进行存储，在 Hadoop 1.x 版本的时候，block 默认为 64MB，在 2.x 后，block 默认为 128MB。而小于一个块的文件只会占据该文件的大小，而不是 128 MB。每个 block 在 DataNode 上会有多个副本，默认为 3 个。

磁盘的物理 block 一般也就 512 Byte，那为啥这里 block 要这么大？

是为了最小化查找（seek）时间，控制定位文件与传输文件所用的时间比例。假设定位到 block 所需的时间为 10ms，磁盘传输速度为 100M/s。如果要将定位到 block 所用时间占传输时间的比例控制 1%，则 block 大小需要约100M。

如果 block 设置过大，在 MapReduce 任务中，Map 或者 Reduce 任务的个数如果小于集群机器数量，会使得作业运行效率很低。

Client

文件切分，上传 HDFS 的时候，Client 将文件切分成一个一个的 block，然后进行存储。
与 NameNode 交互，获取文件的位置信息。
与 DataNode 交互，读取或者写入数据。
Client 提供一些命令来管理和访问 HDFS，比如启动或者关闭 HDFS。

NameNode

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

其中 NameNode 包含两个重要文件，fsimage 和 edits。

fsimage 用于维护文件系统树以及文件树中所有的文件和文件夹的元数据；
操作日志文件 edits 中记录了所有针对文件的创建、删除、重命名等操作。

当 NameNode 启动时，他会读取硬盘中的 fsimage 和 edits，将所有 edits 中的事务作用在内存中的 fsimage 上，并将新的 fsimage 从内存中保存到本地磁盘，然后会删除旧的 edits，这个过程称为 checkpoint，注意目前只是发生在 NameNode 启动的时候。

SecondaryNameNode

辅助 NameNode，分担其工作量。
定期合并 fsimage 和 edits，并推送给 NameNode。
在紧急情况下，可辅助恢复 NameNode。

NameNode 和 SecondaryNameNode工作机制

在 NameNode 挂掉的时候，他不能立刻去替换，而是通过 高可用机制 手段来实现原来的 NameNode 服务。

DataNode

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

NameNode 和 DataNode 相比，前者像是一本书的目录，而后者更像是目录对应的具体内容。

HDFS 机架感知

前面说到 HDFS 的副本默认为 3，对于这些副本 block 的存储，通常会有以下机制。

第一个副本在 client 所处的节点上。如果 client 在集群外，则随机选一个。
第二个副本和第一个副本位于相同机架，随机节点。
第三个副本位于不同机架，随机节点。

HDFS 读 / 写流程

HDFS 写流程

客户端通过 Distributed FileSystem 模块向 NameNode 请求上传文件；
NameNode 检查目标文件是否已存在，父目录是否存在；
NameNode 返回是否可以上传；
客户端请求第一个 block 上传到哪几个 DataNode ；
NameNode 选出可上传的 3 个 DataNode，分别为 DN1、DN2、DN3；
返回列表给客户端；
客户端通过 FSDataOutputStream 模块请求 DN1 上传数据，DN1 收到请求会继续调用 DN2，然后 DN2 调用 DN3，将这个通信管道建立完成；
客户端开始往 DN1 上传第一个 block（先从磁盘读取数据放到一个本地内存缓存），以 packet 为单位；
DN1 收到一个 packet 就会传给 DN2，DN2 传给 DN3；DN1 每传一个 packet 会放入一个应答队列等待应答；
DN 缓存完成后，发送应答 ack 给客户端；
当一个 block 传输完成之后，客户端再次请求 NameNode 上传第二个 block 的服务器。（重复执行 4-10 步）。

HDFS 读流程

客户端通过 Distributed FileSystem 向 NameNode 请求下载文件；
NameNode 通过查询元数据，找到文件块所在的 DataNode；
返回列表给客户端；
挑选 DataNode（就近原则，然后随机）服务器，建立管道，传输数据给客户端（从磁盘里面读取数据输入流，以 Packet 为单位来做校验）；
客户端以 packet 为单位接收，先在本地缓存，然后写入目标文件。

HDFS 高可用机制

HDFS 集群中 NameNode 是非常重要的，整个 HDFS 元数据信息都由他来管理，一旦他挂了，就无了。因此一台 NameNode 是存在单点故障，为了实现 高可用（High Available），其实包括 HDFS-HA 和 YARN-HA。HDFS 可以通过配置 Active / Standby 两个 NameNodes 实现在集群中对 NameNode 的热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，可将NameNode很快的切换到另外一台机器。实现 HA 功能主要依赖 ZooKeeper 和 ZKFC 进程。
ZKFC组件

ZKFailoverController：
是基于 Zookeeper 的故障转移控制器，它负责控制 NameNode 的主备切换， ZKFailoverController 会监测 NameNode 的健康状态，当发现 Active NameNode 出现异常时会通过 Zookeeper 进行一次新的选举，完成 Active 和 Standby 状态的切换。
HealthMonitor：
周期性调用 NameNode 的 HAServiceProtocol RPC接口（monitorHealth 和 getServiceStatus），监控 NameNode 的健康状态并向 ZKFailoverController 反馈。
ActiveStandbyElector：
接收 ZKFC 的选举请求，通过 Zookeeper 自动完成主备选举，选举完成后回调
ZKFailoverController 的主备切换方法对 NameNode 进行 Active 和 Standby 状态的切换。

高可用流程图

HDFS 联邦机制

联邦机制 Federation 是指 HDFS 可使用多个独立的 NameSpace(NameNode节点管理) 来满足 HDFS 命名空间的水平扩展。这些 NameNode 分别管理一部分数据，且共享所有DataNode的存储资源。

缺点：

HDFS Federation 并没有完全解决单点故障问题。虽然 NameNode/NameSpace 存在多个，但是从单个 NameNode/NameSpace 看，仍然存在单点故障，如果某个 NameNode 挂了，其管理的相应的文件就不可以访问了。

因此可以让每个 NameNode 都采用 HA 的模式，即 HA+Federation 的部署方案。

HDFS 安全模式

为了防止数据丢失，安全模式是 Hadoop 的一种保护机制，用于保证集群中的数据块的安全性。当集群启动的时候，会首先进入安全模式，系统处于安全模式时会检查数据块的完整性，且不能修改文件。

HDFS 默认的副本率为 0.999。

假设现在 HDFS 设定的副本数为 3 个，但是 DataNode 只有 2 个副本，副本率就是 2/3=0.666，此时副本率 0.666 明显小于 0.999，因此系统会自动复制副本到其他的 DataNode，使副本率不小于 0.999。如果系统中有 5 个副本，超过我们设定的 3 个副本，那么系统也会删除多于的 2 个副本。

其他系列文章：