名称节点（NameNode）和数据节点（DataNode）

HDFS 相关概念

HDFS要实现有以下优势：

HDFS 在满足上述优势的同时，也不可避免的有一些自身的局限性，主要包括以下几个方面：

块

HDFS 同计算机系统一样，有一个存储块的概念，默认大小为 64M，一个文件被分成多个块存储。块的大小远远大于计算机文件系统，可以减小寻址开销。其优势有：

名称节点（NameNode）和数据节点（DataNode） NameNodeDataNode

存储元数据

存储文件内容

元数据存储在内存

文件内容存储在磁盘

保存文件、block、 DataNode 之间的映射关系

维护block、本地文件系统的映射关系

名称节点（NameNode）数据结构

在 HDFS 中，名称节点复杂管理分布式文件系统的命名空间（NameSpace），保存两大核心数据结构：FSImage 和 EditLog。名称节点中还记录了每个文件中各个块所在的数据节点的位置信息。

FSImage 文件用于维护文件系统树以及文件树中所有文件和文件夹的元数据。FSImage 文件中包含文件系统所有目录和文件 inode 的序列化形式，每个 inode 是一个文件或目录的元数据表示，包含：文件复制等级、修改和访问时间、访问权限、块大小以及组成文件的块。

FSImage 中并没有记录块存储在哪个数据节点。而是由名称节点把这些映射保存在内存中大数据存储系统，当数据节点加入 HDFS 集群时，数据节点会报告自己所包含的数据块给名称节点，并定期执行告知，以确保名称节点的映射关系是正确的。

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

NameNode 将对文件系统的改动追加保存到本地文件系统上的一个日志文件（EditLog）。当一个 NameNode 启动时，它首先从一个映像文件（FSImage）中读取 HDFS 的状态，接着应用日志文件中的 EditLog 操作。然后它将新的HDFS状态写入（FSImage）中，并使用一个空的 EditLog 文件开始正常操作。因为NameNode只有在启动阶段才合并 FSImage 和 EditLog ，所以久而久之日志文件可能会变得非常庞大，特别是对大型的集群。日志文件太大的另一个副作用是下一次 NameNode 启动会花很长时间。

Secondary NameNode 定期合并 FSImage 和 EditLog 日志，将 EditLog 日志文件大小控制在一个限度下。

名称节点的启动 名称节点启动后，会将 FSImage 文件中的内容加载到内存，之后再执行 EditLog 文件中的各项操作，使得内存中的元数据与实际数据一致。一旦内存中管理文件系统元数据的映射，则会创建一个新的 FSImage 文件和一个空白的 EditLog 文件。名称节点启动后， HDFS 中的更新操作会重新写入 EditLog，因为 FSImage 文件一般很大，所以不直接向 FSImage 文件中写入数据，但是 EditLog 每次启动后都是空白的。每次执行完写操作，且在向客户端发送成功消息之前，EditLog 文件都需要同步更新。 数据节点

数据节点是 HDFS 的工作节点，负责数据的存储和读取，会根据客户端或者名称节点的调度来进行数据的存储和检索，并定期向名称节点发送自己所存储的块信息。每个数据节点中的数据都会被保存在各自节点的本地 Linux 文件系统中。

HDFS 体系结构

HDFS 采取主从模型，一个 HDFS 集群包含一个 NameNode 和若干个 DataNode 。名称节点作为中心服务器，负责管理文件系统的命名空间及客户端对文件的访问。

命名空间

HDFS 的命名空间包含块映射、以及相关属性，存储在 FSImage 中。在 HDFS 1.0 体系结构中，整个 HDFS 集群中只有一个命名空间，并且只有唯一一个名称节点，该节点对这个命名空间进行管理。在 HDFS 2.0 中提出了 联邦 （Federation） 的概念。

Federation

Federation 的设计就是为了解决 HDFS 1.0 中的单一 NameNode 的问题，采用 Federation 的最主要原因是设计实现简单。

block pool 存储在 DataNode 上，并通过 BPOfferService 提供服务

Federation 的核心思想是将一个大的 namespace 划分多个子 namespace ，并且每个 namespace 分别由单独的 NameNode 负责，这些 NameNode 之间互相独立，不会影响，不需要做任何协调工作（其实跟拆集群有一些相似），集群的所有 DataNode 会被多个 NameNode 共享。

其中，每个子 namespace 和 DataNode 之间会由数据块管理层作为中介建立映射关系，数据块管理层由若干 数据块池（Pool） 构成，每个数据块只会唯一属于某个固定的数据块池，而一个子 namespace 可以对应多个数据块池。每个 DataNode 需要向集群中所有的 NameNode 注册，且周期性地向所有 NameNode 发送心跳和块报告，并执行来自所有 NameNode 的命令。

HA

在 Hadoop 1.0 时代，Hadoop 的两大核心组件 HDFS NameNode 和 JobTracker 都存在着单点问题，这其中以 NameNode 的单点问题尤为严重。因为 NameNode 保存了整个 HDFS 的元数据信息，一旦 NameNode 挂掉，整个 HDFS 就无法访问，同时 Hadoop 生态系统中依赖于 HDFS 的各个组件，并且重新启动 NameNode 和进行数据恢复的过程也会比较耗时。这些问题在给 Hadoop 的使用者带来困扰的同时，也极大地限制了 Hadoop 的使用场景，使得 Hadoop 在很长的时间内仅能用作离线存储和离线计算，无法应用到对可用性和数据一致性要求很高的在线应用场景中。

所幸的是，在 Hadoop2.0 中，HDFS NameNode 和 YARN ResourceManger 的单点问题都得到了解决，经过多个版本的迭代和发展，目前已经能用于生产环境。

NameNode 的高可用架构主要分为下面几个部分：

NameNode 主备切换主要由 ZKFailoverController、HealthMonitor 和 ActiveStandbyElector 这 3 个组件来协同实现：

HDFS 脑裂问题

在实际中，NameNode 可能会出现这种情况，NameNode 在垃圾回收（GC）时，可能会在长时间内整个系统无响应，因此，也就无法向 ZK 写入心跳信息，这样的话可能会导致临时节点掉线，备 NameNode 会切换到 Active 状态。这种情况，可能会导致整个集群会有同时有两个 NameNode，这就是脑裂问题。

脑裂问题的解决方案是隔离（Fencing），主要是在以下三处采用隔离措施：

共享存储

上述 HA 方案还有一个明显缺点，那就是第三方存储节点有可能失效，目前社区已经把由 Clouderea 公司实现的基于 QJM 的方案作为默认的共享存储实现。QJM（Quorum Journal Manager）本质上是利用 Paxos 协议来实现的，QJM 在 2F+1 个 JournalNode 上存储 NameNode 的 EditLog ，每次写入操作都通过 Paxos 保证写入的一致性，它最多可以允许有 F 个 JournalNode 节点同时故障。

Active NameNode 首先把 EditLog 提交到 JournalNode 集群，然后 Standby NameNode 再从 JournalNode 集群定时同步 EditLog 。还有一点需要注意的是，在 2.0 中不再有 SNN 这个角色了，NameNode 在启动后，会先加载 FSImage 文件和共享目录上的 EditLog Segment 文件，之后 NameNode 会启动 EditLogTailer 线程和 StandbyCheckpointer 线程，正式进入 Standby 模式，其中：

通信协议 局限性 HDFS 存储原理 冗余数据保存

HDFS 采用多副本方式对数据进行冗余存储，通常一个数据库的多个副本会被分布到不同的数据节点。这样多副本具有以下几个优点：

加速数据传输容易检查数据错误保证数据可靠性

数据存取策略

HDFS 使用的是传统的分级文件体系，因此，用户可以像使用普通文件系统一样，创建、删除目录和文件，在目录之间移动、重命名文件，但不支持修改。

存储类型 存储策略

存储策略允许不同的文件存储在不同的存储类型上。目前有以下策略：

当创建文件/目录的时候，并未为它们设定了存储策略。 但可以通过hdfs storagepolicies 命令来管理。文件/路径的存储策略按照如下规则解析：

存储时 DataNode 选择

默认情况下，Hadoop 机架感知是没有启用的，需要在NameNode机器的hadoop-site.xml 里配置一个选项。

当没有配置机架信息时，所有的机器 Hadoop 都默认在同一个默认的机架下，名为 /default-rack，这种情况下，任何一台 DataNode 机器，不管物理上是否属于同一个机架，都会被认为是在同一个机架下，此时，就很容易出现之前提到的增添机架间网络负载的情况。在没有机架信息的情况下， NameNode 默认将所有的 slaves 机器全部默认为在 /default-rack 下，此时写 block 时，三个 DataNode 机器的选择完全是随机的。

当配置了机架感知信息以后，hadoop在选择三个datanode时，就会进行相应的判断。

数据读取策略 数据错误与恢复 NameNode 出错

HDFS 有备份机制，定时将 FSImage 和 EditLog 备份到 SecondaryNameNode 。当 NameNode 出错，就可以根据 SecondaryNameNode 中的数据进行恢复。

DataNode 出错

当 DataNode 发生网络问题或机器故障时，这些 DataNode 会被标记为 “宕机”，节点上的数据均被标记为 “不可读”， NameNode 不会再对它发送任何数据请求。这时，由于部分 DataNode 不可用，会导致一些数据块的副本数量小于冗余因子。在这种情况下，NameNode 会启动冗余复制，为数据块生成新的副本。

数据出错

当文件被创建时，客户端都会对每个文件块进行信息摘要，并将其存储在同路径的隐藏文件里。客户端在读取数据时，会首先获取信息摘要，并对数据块进行 MD5 和 SHA1 校验。如果数据错误，则会向 NameNode 报告错误，NameNode 定时检查并重新复制该数据块。

HDFS 数据读写过程 写数据过程

具体过程如下：

Client 调用 DistributedFileSystem 对象的 create 方法，创建一个文件输出流（FSDataOutputStream）对象；通过 DistributedFileSystem 对象与集群的 NameNode 进行一次 RPC 远程调用，在 HDFS 的 Namespace 中创建一个文件条目（Entry），此时该条目没有任何的 Block，NameNode 会返回该数据每个块需要拷贝的 DataNode 地址信息；通过 FSDataOutputStream 对象，开始向 DataNode 写入数据，数据首先被写入 FSDataOutputStream 对象内部的数据队列中，数据队列由 DataStreamer 使用，它通过选择合适的 DataNode 列表来存储副本，从而要求 NameNode 分配新的 block；DataStreamer 将数据包以流式传输的方式传输到分配的第一个 DataNode 中，该数据流将数据包存储到第一个 DataNode 中并将其转发到第二个 DataNode 中，接着第二个 DataNode 节点会将数据包转发到第三个 DataNode 节点；DataNode 确认数据传输完成，最后由第一个 DataNode 通知 client 数据写入成功；完成向文件写入数据，Client 在文件输出流（FSDataOutputStream）对象上调用 close 方法，完成文件写入；调用 DistributedFileSystem 对象的 complete 方法，通知 NameNode 文件写入成功，NameNode 会将相关结果记录到 editlog 中。

注意：client运行 write 操作后，写完的 block 才是可见的，正在写的 block 对 client 是不可见的，仅仅有调用 sync 方法。client才确保该文件的写操作已经全部完毕。当 client 调用 close 方法时，会默认调用 sync 方法。是否须要手动调用取决你依据程序须要在数据健壮性和吞吐率之间的权衡。

读数据过程

Client 通过 DistributedFileSystem 对象与集群的 NameNode 进行一次 RPC 远程调用，获取文件 block 位置信息；NameNode 返回存储的每个块的 DataNode 列表；Client 将连接到列表中最近的 DataNode；Client 开始从 DataNode 并行读取数据；一旦 Client 获得了所有必须的 block，它就会将这些 block 组合起来形成一个文件。 参考

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!