Hadoop学习笔记：HDFS 基础

HDFS：Hadoop Distributed Filesystem

---

HDFS 的设计

HDFS 以流式数据访问模式来存储超大文件，运行于商用硬件集群上。

特点

1. 超大文件：指几百 MB、几百 GB 甚至几百 TB。
2. 流式数据访问：HDFS 的构建思路是，一次写入，多次读取；每次数据分析都将涉及数据集的大部分甚至全部，因此，读取整个数据集的时间延迟比读取一条记录的时间延迟更重要。
3. 商用硬件：Hadoop 并不需要运行在昂贵且高可靠的硬件上，普通商用硬件即可。
4. 时间延迟：要求低时间延迟的数据访问，如几十毫秒级别的，不适合在 HDFS 上运行。HDFS 是为高数据吞吐量运用优化的，可能会以时间延迟为代价。对于低延迟的访问需求，HBase 是更好的选择。
5. 大量的小文件：因为 namenode 将文件系统的元数据存储在内存中，因此文件系统的存储文件总数受限于 namenode 的内存总量，所以不适用于大量小文件。
6. HDFS 只支持单个文件写入着写入，写操作是以只添加的方式在文件末尾写数据。

---

HDFS 的概念

数据块

HDFS 同其他文件系统一样，也具有块的概念，默认 128MB。
小于块大小的文件不会占据整个块的空间。

对分布式文件系统进行块抽象的好处：

1. 一个文件的大小可以大于网络上任意一个磁盘的容量，文件的所有块并不需要存储在同一个磁盘上。
2. 简化了存储子系统的设计，对于故障种类繁多的分布式系统来说简化尤为重要，将存储子系统的处理对象设置为块，可以简化存储管理，消除对元数据的顾虑。
3. 块还非常适用于数据备份进而提高数据容错能力和高可用性

利用 fsck 指令显示块信息。

列出文件系统中各个文件由那些块组成
hdfs fsck / -files -blocks

namenode 与 datanode

namenode：管理结点

1. 管理文件系统的命名空间，维护着文件系统树及整棵树内所有文件和目录。这些信息以命名空间镜像文件和编辑日志文件的形式存储，
2. 也记录着每个文件各个块所在的数据结点信息，但并不永久保存数据块的位置信息，因为这些信息会在系统启动时根据数据结点信息重建。

客户端（client）代表用户通过与 namenode 和 datanode 交互来访问整个文件系统，客户端提供一个类似于 POSIX 的文件系统接口。

datanode：工作结点

1. 根据需要存储并检索数据块，并定期向 namenode 发送他们所存储的数据块的列表。

namenode 实现容错

1. 备份组成文件系统元数据持久状态的文件，hadoop可以通过配置使 namenode 在多个文件系统上保存元数据的持久状态，这些写操作是实时的，且是原子的。
2. 运行一个辅助 namenode，但是它不能用做 namenode，其作用是定期合并编辑日志与命名空间镜像，防止编辑日志过大。会保存合并后的命名空间镜像副本，并在 namenode 发生故障时启用。但是辅助 namenode 保存的状态总是滞后于主结点，所以在主结点全部失效时，会出现数据丢失的情况。

块缓存

对于访问频繁的文件，其对应的块可能会被显式的换存在 datanode 的内存中，以堆外块缓存的形式存在。

联邦 HDFS

namenode 在内存中保存文件系统中每个文件和每个数据块的引用关系，所以对于拥有大量文件的超大集群，内存将成为限制系统横向扩展的瓶颈。
2.x 中引入了联邦 HDFS 允许系统通过添加 namenode 实现扩展，其中每个 namenode 管理文件系统命名空间中的一部分。

在联邦环境下，每个 namenode 维护一个命名空间卷（namespace volume），由命名空间的元数据和一个数据块池（block pool）组成，数据块池包含该命名空间下文件的所有数据块。
命名空间卷时相互独立的，两两之间并不会相互通信，数据块池也不再进行切分。

HDFS 高可用性

通过联合使用多个文件系统中备份 namenode 的元数据和通过备份 namenode 创建监测点能防止数据丢失，但是依旧无法实现文件系统的高可用性，namenode 依旧存在单点失效的问题，hadoop 系统在新的 namenode 上线之前无法提供服务。

新的 namenode 需要满足以下情形：

1. 将命名空间的映像导入内存中；
2. 重演编辑日志；
3. 接收到足够多的来自 datanode 的数据块报告并退出安全模式。

Hadoop 2 增加了 HDFS 高可用行（HA）的支持，配置了一对活动-备用（active-standby）namenode。当活动 namenode 失效，备用 namenode 就会接管它的任务并开始服务于来自客户端的请求，不会有任何明显中断。
实现这一目标需要在架构上做如下修改：

1. namenode 之间需要通过高可用共享存储实现编辑日志的共享。当备用 namenode 接管工作之后，它将通读共享编辑日志直到末尾，以实现与活动 namenode 的状态同步，并继续读取有活动 namenode 写入的新条目。
2. datanode 需要同时向两个 namenode 发送数据块处理报告，因为数据块的映射信息存储到 namenode 的内存中，而非磁盘。
3. 客户端需要使用特定的机制来处理 namenode 的失效问题，这一机制对用户事透明的。
4. 辅助 namenode 的角色被备用 namenode 所包含，备用 namenode 为活动的 namenode 命名空间设置周期性检查点。

两种高可用共享存储

1. NFS 过滤器
2. 集群日志管理器（QJM，quorum journal manager）：QJM是一个专用的 HDFS 实现，为提供一个高可用的编辑日志而设计，以一组日志结点（journal node）的形式运行，每一次编辑必须写入多数日志结点。

故障切换与规避
故障转移控制器（failover controller），管理将活动 namenode 转移为备用 namenode 的转换过程。
有多种故障转移控制器，默认一种是使用了 ZooKeeper 来确保有且仅有一个活动 namenode。
每一个 namenode 运行着一个轻量级的故障转移控制器，负责监视宿主 namenode 是否失效（心跳机制），并在 namenode 失效时进行故障切换。