hdfs架构（hdfs架构设计）

本篇文章给大家谈谈hdfs架构，以及hdfs架构设计对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、HDFS架构和原理
• 2、HDFS架构
• 3、HDFS 系统架构
• 4、Hadoop系列之HDFS架构
• 5、HDFS 架构

HDFS架构和原理

之所以选择 HDFS 存储数据，因为 HDFS 具有以下优点：

当然 HDFS 也有它的劣势，并不适合所有的场合：

HDFS 采用Master/Slave的架构来存储数据，这种架构主要由四个部分组成，分别为HDFS Client、NameNode、DataNode和Secondary NameNode。下面我们分别介绍这四个组成部分

HDFS的文件读取原理，主要包括以下几个步骤：

HDFS的文件写入原理，主要包括以下几个步骤：

namenode如何选择在哪个datanode 存储副本（replication）？这里需要对可靠性、写入带宽和读取带宽进行权衡。Hadoop对datanode存储副本有自己的副本策略，在其发展过程中一共有两个版本的副本策略，分别如下所示

这样做的好处就是当NN内存受限时，能扩展内存，解决内存扩展问题，而且每个NN独立工作相互不受影响，比如其中一个NN挂掉啦，它不会影响其他NN提供服务，但我们需要注意的是，虽然有多个NN，分管不同的目录，但是对于特定的NN，依然存在单点故障，因为没有它没有热备，解决单点故障使用NameNode HA

2、NameNode HA

解决方案：

1、基于NFS方案

Active NN与Standby NN通过NFS实现共享数据，但如果Active NN与NFS之间或Standby NN与NFS之间，其中一处有网络故障的话，那就会造成数据同步问题

2、基于QJM方案

架构如下图

Active NN、Standby NN有主备之分，NN Active是主的，NN Standby备用的

集群启动之后，一个namenode是active状态，来处理client与datanode之间的请求，并把相应的日志文件写到本地中或JN中；

Active NN与Standby NN之间是通过一组JN共享数据（JN一般为奇数个，ZK一般也为奇数个），Active NN会把日志文件、镜像文件写到JN中去，只要JN中有一半写成功，那就表明Active NN向JN中写成功啦，Standby NN就开始从JN中读取数据，来实现与Active NN数据同步，这种方式支持容错，因为Standby NN在启动的时候，会加载镜像文件（fsimage）并周期性的从JN中获取日志文件来保持与Active NN同步

为了实现Standby NN在Active NN挂掉之后，能迅速的再提供服务，需要DN不仅需要向Active NN汇报，同时还要向Standby NN汇报，这样就使得Standby NN能保存数据块在DN上的位置信息，因为在NameNode在启动过程中最费时工作，就是处理所有DN上的数据块的信息

为了实现Active NN高热备，增加了FailoverController和ZK，FailoverController通过Heartbeat的方式与ZK通信，通过ZK来选举，一旦Active NN挂掉，就选取另一个FailoverController作为active状态，然后FailoverController通过rpc，让standby NN转变为Active NN

FailoverController一方面监控NN的状态信息，一方面还向ZK定时发送心跳，使自己被选举。当自己被选为主（Active）的时候，就会通过rpc使相应NN转变Active状态

3、结合HDFS2的新特性，在实际生成环境中部署图

这里有12个DN,有4个NN，NN-1与NN-2是主备关系，它们管理/share目录；NN-3与NN-4是主备关系，它们管理/user目录

HDFS架构

HDFS中的文件是以数据块（Block）的形式存储的，默认最基本的存储单位是128 MB（Hadoop 1.x为64 MB）的数据块。也就是说，存储在HDFS中的文件都会被分割成128 MB一块的数据块进行存储，如果文件本身小于一个数据块的大小，则按实际大竖岁答小存储，并不占用整个数据块空间。HDFS的数据块之所以会设置这么大，其目的是减少寻址开销。数据块数量越多，寻址数据块所耗的时间就越多。当然也不会设置过大，MapReduce中的Map任务通常一次只处理一个块中的数据，如果任务数太少，作业的运行速度就会比较慢。HDFS的每一个数据块默认都有三个副本，分别存储在不同的DataNode上，以实现容错功能。因此，若数据块的某个副本丢失并不会影响对数据块的访问。数据块大小和副本数量可在配置文件中更改

NameNode是HDFS中存储元数据（文件名称、大小和位置等信息）的地方，它将所有文件和文件夹的元数据保存在一个文件系统目录树中，任何元数据信息的改变，NameNode都会记录。HDFS中的每个文件都被拆分为多个数据块存放，这种文件与数据块的对应关系也存储在文件系统目录树中，由NameNode维护。NameNode还存储数据块到DataNode的映射信息，这种映射信息包括：数据块存放在哪些DataNode上、每个DataNode上保存了哪些数据块。NameNode也会周期性地接收来自集群中DataNode的“心跳”和“块报告”。通过“心跳”与DataNode保持通信，监控DataNode的状态（活着还是宕机），若长时间接收不到“心跳”信息，NameNode会认为DataNode已经宕机，从而做出相应的调整策略。“块报告”包含了DataNode上所有数据块的列表信息。

DataNode是HDFS中真正存储数据的地方。客户端可以向DataNode请求写入或读取数据块，DataNode还在来自NameNode的指令下执行块的创建、删除和复制，并且周期性地向NameNode汇报数据块信息。

NodeSecondaryNameNode用于帮助NameNode管理元数据，从而使NameNode能够快速、高效地工作。它并不是第二个NameNode，仅是NameNode的一个辅助工具。HDFS的元数据信息主要存储于两个文件中：fsimage和edits。fsimage是文件系统映射文件，主余慧要存储文件元数据信息，其中包含文件系统所有目录、文件信息以及数据块的索引；edits是HDFS操作日志文件，HDFS对文件系统的修改日志会存储到该文件中。当NameNode启动时，会从文件fsimage中读取HDFS的状态，雀辩也会对文件fsimage和edits进行合并，得到完整的元数据信息，随后会将新HDFS状态写入fsimage。但是在繁忙的集群中，edits文件会随着时间的推移变得非常大，这就导致NameNode下一次启动的时间会非常长。为了解决这个问题，则产生了SecondaryNameNode，SecondaryNameNode会定期协助NameNode合并fsimage和edits文件，并使edits文件的大小保持在一定的限制内。SecondaryNameNode通常与NameNode在不同的计算机上运行，因为它的内存需求与NameNode相同，这样可以减轻NameNode所在计算机的压力。

HDFS 系统架构

HDFS Architecture

Hadoop Distributed File System (HDFS) 是设计可以运行于普通商业硬件上的分布式文件系统。它跟现有的分布式文件系统有很多相通的地方，但是区别也是显著的。HDFS具有高度容错性能，被设计运行于低成本硬件上。HDFS可以向应用提供高吞吐带宽，适合于大数据应用。HDFS 放宽了一些 POSIX 的要求，以开启对文件系统数据的流式访问。HDFS 最初是作为Apache Nutch web 搜索引擎项目的基础设施开发的。HDFS 现在是 Apache Hadoop 核心项目的一部分。

HDFS是主从架构。一个HDFS集群包含一个NameNode，一个管理文件系统命名空间和控制客户端访问文件的master server。以及，若指衫干的 DataNodes，通常集群的每个node一个，管理运行DataNode的节点上的存储。HDFS 发布一个文件系统命名空间，并允许用户数据已文件的形式存储在上面。内部，一个文件被分成一个或多个块，存储在一组DataNodes上。NameNode 执行文件系统命名空间操作，比如：打开、关闭、重命名文件或目录。它还确定块到DataNodes的映射。DataNodes 负责向文件系统客户端提供读写服务。DataNodes 根据 NameNode 的指枯卜令执行块的创建、删除以及复制。

NameNode 和 DataNode 是设计运行于普通商业机器的软件。这些机器通常运行 GNU/Linux 操作系统。HDFS 是Java 语言编写的；任何支持Java的机器都可以运行NameNode or DataNode 软件。使用高移植性Java语言，意味着HDFS可以部署在很大范围的机器上。一个典型的部署就是一台特定的机器只运行NameNode 软件，而集群内的其他机器运行DataNode 软件的一个实例。这种架构不排除一台机器上运行多个DataNodes ，但是在实际部署中很少见。

单 NameNode 节点的存在大大简化了架构。NameNode 是所有HDFS 元数据的仲裁和仓库。系统设计上，用户数据永远不经过NameNode。

HDFS 支持传统的文件分级组织。用户或应用可以创建目录，并在目录内存储文件。 文件系统命名空间的层次结构跟其他文件系统类似；可以创建、删除、移动、重命名文件。HDFS 支持 user quotas 和 access permissions 。 HDFS 不支持软、硬链接。但是，HDFS 架构不排除实现这些功能。

虽然HDFS遵守 文件系统命名约定 ，一些路径和名称 (比如/.reserved 和.snapshot ) 保留了。比如功能 transparent encryption 和 snapshot 就使用的保留路径。

NameNode 维护文件系统命名空间。任何文件系统命名空唯败腔间或属性的变化，都会被NameNode记录。 应用可以指定HDFS应维护的文件副本数量。文件副本的数量被称为该文件的复制因子 replication factor 。该信息存储于NameNode。

HDFS 被设计用于在一个大规模集群上跨机器可靠地存储巨大的文件。它以一序列的块的方式存储文件。每个文件都可以配置块尺寸和复制因子。

一个文件除了最后一个块外，其他的块一样大。在 append 和 hsync 添加了可变长度块的支持后，用户可以启动一个新的块，而不用填充最后一个块到配置的块大小。

应用可以指定一个文件的副本数量。复制因子可以在创建的时候指定，也可以以后更改。HDFS的文件只写一次(除了 appends 和 truncates) ，并在任何时候只允许一个 writer 。

NameNode 指定块复制的所有决策。它周期性的从集群的每个DataNodes 接受 Heartbeat 和 Blockreport。Heartbeat 的接受代表 DataNode 工作正常。Blockreport 包含了DataNode上所有块的清单。

副本的位置对HDFS的可靠性和性能至关重要。副本位置的优化是HDFS和其他大多数分布式文件系统的区别。这是一个需要大量调优和经验的特性。Rack-aware 复制策略的目的就是提高数据可靠性，可用性和网络带宽利用率。当前副本位置策略的实现是这个方向的第一步。实施该策略的短期目标是在生产环境验证它，了解其更多的行为，为测试和研究更复杂的策略打下基础。

大型HDFS实例运行在跨多个Rack的集群服务器上。不同rack的两个node通信需要通过交换机。大多数情况下，同一rack内的带宽大于rack之间的带宽。

NameNode 通过在 Hadoop Rack Awareness 内的进程描述 判断DataNode 属于哪个rack id。一个简单但是并非最佳的策略是将副本分布于不同的racks。这可以防止整个机架发生故障时丢失数据，并允许在读取数据时使用多个机架的带宽。该策略在群集中均匀地分布副本，使得组件故障时很容易平衡负载。 但是，该策略会增加写入成本，因为写入操作需要将块传输到多个机架。

一般，复制因子设置为3， HDFS 的分布策略是：如果writer在datanode上则将一个副本放到本地机器， 如果writer不在datanode上则将一个副本放到writer所在机柜的随机datanode 上；另一个副本位于不同机架的node上；最后一个副本位于同一远程机架的不同node上。 该策略减少了机架间的写流量，提升了写性能。机架故障的概率远小于节点故障的概率；此策略不会影响数据可靠性和可用性承诺。但是，在读取数据时，它确实减少了聚合带宽，因为块存储于两个机柜而不是三个机柜内。使用此策略，副本不会均匀的分布于机架上。1/3 副本 位于同一节点， 2/3 副本位于同一机架， 另1/3副本位于其他机架。该策略提升了写性能而不影响数据可靠性和读性能。

如果复制因子大于3，那么第4个及以后的副本则随机放置，只要满足每个机架的副本在(replicas - 1) / racks + 2)之下。

因为 NameNode 不允许 DataNodes 拥有同一个块的多个副本，所以副本的最大数就是DataNodes的数量。

在把对 存储类型和存储策略 的支持添加到 HDFS 后，除了上面介绍的rack awareness外， NameNode 会考虑其他副本排布的策略。NameNode 先基于rack awareness 选择节点，然后检查候选节点有文件关联的策略需要的存储空间。 如果候选节点没有该存储类型， NameNode 会查找其他节点。如果在第一条路径中找不到足够的节点来放置副本，NameNode会在第二条路径中查找具有回滚存储类型的节点。 、

当前，这里描述的默认副本排布策略正在使用中。

为了最小化全局带宽消耗和读取延迟， HDFS 会尝试从最靠近reader的副本响应读取请求。如果在reader节点的同一机架上上存在副本，则该副本有限响应读请求。如果HDFS集群跨多个数据中心，则本地数据中心优先。

启动时，NameNode 会进入一个称为 Safemode 的特殊状态。当NameNode处于Safemode状态时，不会复制数据块。NameNode从DataNodes接收Heartbeat和Blockreport消息。Blockreport包含DataNode托管的数据块列表。每个块都指定了最小副本数。当数据块的最小副本数已与NameNode签入时，该块被认为是安全复制的。在NameNode签入安全复制数据块的已配置百分比（加上额外的30秒）后，NameNode退出Safemode状态。然后，它判断列表内的数据块清单是否少于副本指定的数量。NameNode 然后复制这些块给其他 DataNodes。

HDFS 命名空间由 NameNode 存储。NameNode 使用事务日志 EditLog 来持久化的保存系统元数据的每次变更。比如，在HDFS创建一个新文件，NameNode会在 EditLog 插入一条记录来指示该变更。类似的，变更文件的复制因子也会在 EditLog 插入一条新记录。NameNode 以文件的形式，将 EditLog 保存在本地OS文件系统上。整个文件系统命名空间，包括块到文件的映射、文件系统属性，都存储于名字为 FsImage 的文件内。 FsImage 也以文件的形式，存储在NameNode的本地文件系统上。

NameNode 将包含整个文件系统和块映射的image保存在内存中。当NameNode启动时，或检查点被预先定义的阈值触发时，它会从磁盘读取 FsImage 和 EditLog ，把 EditLog 内的事物应用到内存中的FsImage，再将新版本刷新回磁盘的新 FsImage 。然后会截断旧的 EditLog ，因为它的事物已经应用到了持久化的 FsImage 上。 这个过程称为检查点 checkpoint 。检查点的目的是通过对文件系统元数据进行快照并保存到FsImage，来确保HDFS拥有文件系统元数据的一致性视图。尽管读取 FsImage 是高效的，但是对 FsImage 直接增量修改是不高效的。不是对每次编辑修改 FsImage ，而是将每次编辑保存到 Editlog 。在检查点期间，将 Editlog 的变更应用到 FsImage 。一个检查点可以在固定周期(dfs.namenode.checkpoint.period)(以秒为单位)触发，也可以文件系统事物数量达到某个值(dfs.namenode.checkpoint.txns)的时候触发。

DataNode 在本地文件系统上以文件的形式存储 HDFS data 。DataNode 不知道 HDFS 文件。它将HDFS data 的每个块以独立的文件存储于本地文件系统上。DataNode 不在同一目录创建所有的文件。而是，使用heuristic来确定每个目录的最佳文件数量，并适当的创建子目录。在一个目录创建所有的本地文件是不好的，因为本地文件系统可能不支持单目录的海量文件数量。当DataNode启动的时候，它扫描本地文件系统，生成与本地文件系统一一对应的HDFS数据块列表，然后报告给NameNode。这个报告称为 Blockreport。

所有的HDFS通信协议都在TCP/IP协议栈上。客户端与NameNode指定的端口建立连接。与NameNode以ClientProtocol 通信。DataNodes与NameNode以DataNode Protocol进行通信。远程过程调用(RPC)封装了Client Protocol 和 DataNode Protocol。设计上，NameNode从不启动任何RPCs。相反，它只应答DataNodes or clients发出的RPC请求。

HDFS的主要目标是可靠的存储数据，即使是在故障的情况下。常见故障类型有三种： NameNode failures , DataNode failures 和 network partitions 。

每个DataNode都周期性的向NameNode发送心跳信息。 一个 network partition 可能导致DataNodes子集丢失与NameNode的连接。NameNode会基于心跳信息的缺失来侦测这种情况。NameNode将没有心跳信息的DataNodes标记为 dead ，并不再转发任何IO请求给它们。任何注册到dead DataNode的数据对HDFS将不再可用。DataNode death会导致某些块的复制因子低于它们指定的值。NameNode不断跟踪需要复制的块，并在必要时启动复制。很多因素会导致重新复制：DataNode不可用，副本损坏，DataNode上硬盘故障，复制因子增加。

标记 DataNodes dead 的超时时间保守地设置了较长时间 (默认超过10分钟) 以避免DataNodes状态抖动引起的复制风暴。对于性能敏感的应用，用户可以设置较短的周期来标记DataNodes为过期，读写时避免过期节点。

HDFS 架构支持数据再平衡schemes。如果一个DataNode的空余磁盘空间低于阈值，sheme就会将数据从一个DataNode 移动到另外一个。在某些文件需求突然增长的情况下，sheme可能会在集群内动态的创建额外的副本，并再平衡其他数据。这些类型的数据再平衡schemes还没有实现。

有可能从DataNode获取的数据块，到达的时候损坏了。这种损坏可能是由于存储设备故障、网络故障、软件bug。HDFS客户端软件会HDFS的内容进行校验。当客户端创建HDFS文件的时候，它计算文件每个块的校验值，并以独立的隐藏文件存储在同一HDFS命名空间内。当客户端检索文件时候，它会校验从每个DataNode获取的数据，是否与关联校验文件内的校验值匹配。 如果不匹配，客户端可以从另外拥有副本块的DataNode检索。

FsImage 和 EditLog 是HDFS的核心数据结构。这些文件的损坏将导致HDFS实例异常。 因此，NameNode可以配置为支持多 FsImage 和 EditLog 副本模式。任何对 FsImage or EditLog 的更新都会导致每个 FsImages 和 EditLogs 的同步更新。 FsImage 和 EditLog 的同步更新会导致降低命名空间每秒的事物效率。但是，这种降级是可以接受的，因为HDFS应用是数据密集型，而不是元数据密集型。当NameNode重启的时候，它会选择最新的一致的 FsImage 和 EditLog 。

另外一种提供故障恢复能力的办法是多NameNodes 开启HA，以 shared storage on NFS or distributed edit log (called Journal)的方式。推荐后者。

Snapshots - 快照，支持在特定时刻存储数据的副本。快照功能的一个用法，可以回滚一个故障的HDFS实例到已知工作良好的时候。

HDFS被设计与支持超大的文件。与HDFS适配的软件都是处理大数据的。这些应用都只写一次，但是它们会读取一或多次，并且需要满足流式读速度。HDFS支持文件的 一次写入-多次读取 语义。 HDFS典型的块大小是128 MB.。因此，HDFS文件被分割为128 MB的块，可能的话每个块都位于不同的DataNode上。

当客户端以复制因子3写入HDFS文件时，NameNode以 复制目标选择算法 replication target choosing algorithm 检索DataNodes 列表。该列表包含了承载该数据块副本的DataNodes清单。然后客户端写入到第一个DataNode。第一DataNode逐步接受数据的一部分，将每一部分内容写入到本地仓库，并将该部分数据传输给清单上的第二DataNode。第二DataNode，按顺序接受数据块的每个部分，写入到仓库，然后将该部分数据刷新到第三DataNode。最终，第三DataNode将数据写入到其本地仓库。

因此，DataNode从管道的前一个DataNode获取数据，同时转发到管道的后一个DataNode。因此，数据是以管道的方式从一个DataNode传输到下一个的。

应用访问HDFS有很多方式。原生的，HDFS 提供了 FileSystem Java API 来给应用调用。还提供了 C language wrapper for this Java API 和 REST API 。另外，还支持HTTP浏览器查看HDFS实例的文件。 通过使用 NFS gateway ，HDFS还可以挂载到客户端作为本地文件系统的一部分。

HDFS的用户数据是以文件和目录的形式组织的。它提供了一个命令行接口 FS shell 来提供用户交互。命令的语法类似于其他shell (比如：bash, csh)。如下是一些范例：

FS shell 的目标是向依赖于脚本语言的应用提供与存储数据的交互。

DFSAdmin 命令用于管理HDFS集群。这些命令仅给HDFS管理员使用。如下范例：

如果启用了回收站配置，那么文件被 FS Shell 移除时并不会立即从HDFS删除。HDFS会将其移动到回收站目录(每个用户都有回收站，位于 /user/username/.Trash )。只要文件还在回收站内，就可以快速恢复。

最近删除的文件大多数被移动到 current 回收站目录 ( /user/username/.Trash/Current )，在配置周期内，HDFS给 current目录内的文件创建检查点 checkpoints (位于 /user/username/.Trash/date ) ，并删除旧的检查点。参考 expunge command of FS shell 获取更多关于回收站检查点的信息。

在回收站过期后，NameNode从HDFS命名空间删除文件。删除文件会将文件关联的块释放。注意，在用户删除文件和HDFS增加free空间之间，会有一个明显的延迟。

如下范例展示了FS Shell如何删除文件。我们在delete目录下创建两个文件(test1 test2)

我们删除文件 test1。如下命令显示文件被移动到回收站。

现在我们尝试以skipTrash参数删除文件，该参数将不将文件发送到回收站。文件将会从HDFS完全删除。

我们检查回收站，只有文件test1。

如上，文件test1进了回收站，文件test2被永久删除了。

当缩减文件的复制因子时，NameNode选择可以被删除的多余副本。下一个Heartbeat会通报此信息给DataNode。DataNode然后会删除响应的块，相应的剩余空间会显示在集群内。同样，在setReplication API调用完成和剩余空间在集群显示之间会有一个时间延迟。

Hadoop JavaDoc API .

HDFS source code:

Hadoop系列之HDFS架构

    本篇文章翻译了Hadoop系列下的 HDFS Architecture ，原文最初经过笔者翻译后大概有6000字，之后笔者对内容进行了精简化压缩，从而使笔者自己和其他读者们阅读本文时能够更加高效快速的完成对Hadoop的学习或复习。本文主要介绍了Hadoop的整体架构，包括但不限于节点概念、命名空间、数据容错机制、数据管理方式、简单的脚本命令和垃圾回收概念。

    PS：笔者新手一枚，如乱棚老果看出哪里存在问题，欢迎下方留言！

    Hadoop Distributed File System（HDFS）是高容错、高吞吐量、用于处理海量数据的分布式文件系统。

    HDFS一般由成百上千的机器组成，每个机器存储整个数据集的一部分数据，机器故障的快速发现与恢复是HDFS的核心目标。

    HDFS对接口的核心目标是高吞吐量而非低延迟。

    HDFS支持海量数据集合，一个集群一般能够支持千万以上数量级的文件。

    HDFS应用需要对文件写一次读多次的接口模型，文件变更只支持尾部添加和截断。

    HDFS的海量数据与一致性接口特点，使得迁移计算以适应文件内容要比迁移数据从而支持计算更加高效。

    HDFS支持跨平台使用。

    HDFS使用主从架构。一个HDFS集群由一个NameNode、一个主服务器（用于管理系统命名空间和控制客户端文件接口）、大量的DataNode（一般一个节点一个，用于管理该节点数据存储）。HDFS对外暴露了文件系统命名空间并允许在文件中存储用户数据。一个文件被分成一个或多个块，这些块存储在一组DataNode中。NameNode执行文件系统命名空间的打开关闭重命名等命令并记录着块和DataNode之间的映射。DataNode用于处理客户端的读写请求和块的相关操作。NameNode和DataNode一般运行在GNU/Linux操作系统上，HDFS使用Java语言开发的，因此NameNode和DataNode可以运行在任何支持Java的机器上，再加上Java语言的高度可移植性，使得HDFS可以发布在各种各样的机器上。一个HDFS集和亩群中运行一个NameNode，其他机器每个运行一个（也可以多个，非常少见）DataNode。NameNode简化了系统的架构，只用于存储所有HDFS元数据，用户数据不会进入该节点。下图为HDFS架构图：

    HDFS支持传统的分层文件管理，用户或者应用能够在目录下创建目录或者文件。文件系统命名空间和其他文件系统是相似的，支持创建、删除、移动和重命名文件。HDFS支持用户数量限制和访问权限控制，不支持软硬链接，用户可以自己实现软硬链接。NameNode控制该命名空间，命名空间任何变动几乎都要记录到NameNode中。应用可以在HDFS中对文件声明复制次数，这个次数叫做复制系数，会被记录到NameNode中。

    HDFS将每个文件存储为一个或多个块，并为文件设置了块的大小和复制系数从而支持文件容错。一个文件所有的块（除了最后一个块）大小相同，后来支持了可变长度的块。复制系数在创建文件时赋值，后续可以更改。文件在任何时候只能有一个writer。NameNode负责块复制，它周期性收到每个数据节点的心跳和块报告，心跳表示数据节点的正常运作，块报告包含了这个DataNode的所有块。

    副本存储方案对于HDFS的稳定性和性能至关重哗升要。为了提升数据可靠性、灵活性和充分利用网络带宽，HDFS引入了机架感知的副本存储策略，该策略只是副本存储策略的第一步，为后续优化打下基础。大型HDFS集群一般运行于横跨许多支架的计算机集群中，一般情况下同一支架中两个节点数据传输快于不同支架。一种简单的方法是将副本存放在单独的机架上，从而防止丢失数据并提高带宽，但是增加了数据写入的负担。一般情况下，复制系数是3，HDFS存储策略是将第一份副本存储到本地机器或者同一机架下一个随机DataNode，另外两份副本存储到同一个远程机架的不同DataNode。NameNode不允许同一DataNode存储相同副本多次。在机架感知的策略基础上，后续支持了 存储类型和机架感知相结合的策略 ，简单来说就是在机架感知基础上判断DataNode是否支持该类型的文件，不支持则寻找下一个。

    HDFS读取数据使用就近原则，首先寻找相同机架上是否存在副本，其次本地数据中心，最后远程数据中心。

    启动时，NameNode进入安全模式，该模式下不会发生数据块复制，NameNode接收来自DataNode的心跳和块报告，每个块都有一个最小副本数量n，数据块在NameNode接受到该块n次后，认为这个数据块完成安全复制。当完成安全复制的数据块比例达到一个可配的百分比值并再过30s后，NameNode退出安全模式，最后判断是否仍然存在未达到最小复制次数的数据块，并对这些块进行复制操作。

    NameNode使用名为EditLog的事务日志持续记录文件系统元数据的每一次改动（如创建文件、改变复制系数），使用名为FsImage的文件存储全部的文件系统命名空间（包括块到文件的映射关系和文件系统的相关属性），EditLog和FsImage都存储在NameNode本地文件系统中。NameNode在内存中保存着元数据和块映射的快照，当NameNode启动后或者某个配置项达到阈值时，会从磁盘中读取EditLog和FsImage，通过EditLog新的记录更新内存中的FsImage，再讲新版本的FsImage刷新到磁盘中，然后截断EditLog中已经处理的记录，这个过程就是一个检查点。检查点的目的是确保文件系统通过在内存中使用元数据的快照从而持续的观察元数据的变更并将快照信息存储到磁盘FsImage中。检查点通过下面两个配置参数出发，时间周期（dfs.namenode.checkpoint.period）和文件系统事务数量（dfs.namenode.checkpoint.txns），二者同时配置时，满足任意一个条件就会触发检查点。

    所有的HDFS网络协议都是基于TCP/IP的，客户端建立一个到NameNode机器的可配置的TCP端口，用于二者之间的交互。DataNode使用DataNode协议和NameNode交互，RPC包装了客户端协议和DataNode协议，通过设计，NameNode不会发起RPC，只负责响应来自客户端或者DataNode的RPC请求。

    HDFS的核心目标是即使在失败或者错误情况下依然能够保证数据可靠性，三种常见失败情况包括NameNode故障、DataNode故障和network partitions。

    网络分区可能会导致部分DataNode市区和NameNode的连接，NameNode通过心跳包判断并将失去连接的DataNode标记为挂掉状态，于是所有注册到挂掉DataNode的数据都不可用了，可能会导致部分数据块的复制数量低于了原本配置的复制系数。NameNode不断地追踪哪些需要复制的块并在必要时候进行复制，触发条件包含多种情况：DataNode不可用、复制乱码、硬件磁盘故障或者认为增大负值系数。为了避免DataNode的状态不稳定导致的复制风暴，标记DataNode挂掉的超时时间设置比较长（默认10min），用户可以设置更短的时间间隔来标记DataNode为陈旧状态从而避免在对读写性能要求高的请求上使用这些陈旧节点。

    HDFS架构兼容数据各种重新平衡方案，一种方案可以在某个DataNode的空闲空间小于某个阈值时将数据移动到另一个DataNode上；在某个特殊文件突然有高的读取需求时，一种方式是积极创建额外副本并且平衡集群中的其他数据。这些类型的平衡方案暂时还未实现（不太清楚现有方案是什么...）。

    存储设备、网络或者软件的问题都可能导致从DataNode获取的数据发生乱码，HDFS客户端实现了对文件内容的校验，客户端在创建文件时，会计算文件中每个块的校验值并存储到命名空间，当客户端取回数据后会使用校验值对每个块进行校验，如果存在问题，客户端就会去另一个DataNode获取这个块的副本。

    FsImage和EditLog是HDFS的核心数据结构，他们的错误会导致整个HDFS挂掉，因此，NameNode应该支持时刻维持FsImage和EditLog的多分复制文件，它们的任何改变所有文件应该同步更新。另一个选择是使用 shared storage on NFS 或者 distributed edit log 支持多个NameNode，官方推荐 distributed edit log 。

    快照能够存储某一特殊时刻的数据副本，从而支持HDFS在发生错误时会滚到上一个稳定版本。

    HDFS的应用场景是大的数据集下，且数据只需要写一次但是要读取一到多次并且支持流速读取数据。一般情况下一个块大小为128MB，因此一个文件被切割成128MB的大块，且每个快可能分布在不同的DataNode。

    当客户端在复制系数是3的条件下写数据时，NameNode通过目标选择算法收到副本要写入的DataNode的集合，第1个DataNode开始一部分一部分的获取数据，把每个部分存储到本地并转发给第2个DataNode，第2个DataNode同样的把每个部分存储到本地并转发给第3个DataNode，第3个DataNode将数据存储到本地，这就是管道复制。

    HDFS提供了多种访问方式，比如 FileSystem Java API 、 C language wrapper for this Java API 和 REST API ，而且还支持浏览器直接浏览。通过使用 NFS gateway ，客户端可以在本地文件系统上安装HDFS。

    HDFS使用目录和文件的方式管理数据，并提供了叫做 FS shell 的命令行接口，下面有一些简单的命令：

    DFSAdmin命令集合用于管理HDFS集群，这些命令只有集群管理员可以使用，下面有一些简单的命令：

正常的HDFS安装都会配置一个web服务，通过可配的TCP端口对外暴露命名空间，从而使得用户可以通过web浏览器查看文件内容。

如果垃圾回收配置打开，通过FS shell移除的文件不会立刻删除，而是会移动到一个垃圾文件专用的目录（/user/username/.Trash），类似回收站，只要文件还存在于那个目录下，则随时可以被回复。绝大多数最近删除的文件都被移动到了垃圾目录（/user/username/.Trash/Current），并且HDFS每个一段时间在这个目录下创建一个检查点用于删除已经过期的旧的检查点，详情见 expunge command of FS shell 。在垃圾目录中的文件过期后，NameNode会删除这个文件，文件删除会引起这个文件的所有块的空间空闲，需要注意的是在文件被删除之后和HDFS的可用空间变多之间会有一些时间延迟（个人认为是垃圾回收机制占用的时间）。下面是一些简单的理解删除文件的例子：

    当文件复制系数减小时，NameNode会选择多余的需要删除的副本，在收到心跳包时将删除信息发送给DataNode。和上面一样，这个删除操作也是需要一些时间后，才能在集群上展现空闲空间的增加。

HDFS Architecture

HDFS 架构

HDFS 涉及两个重要进程：NameNode、DataNode。

他们一般都部署单独部署在不同服务器上，运行 NameNode 的服务器是主服务器，运行 DataNode 的服务器是从服务器。主服务器只有一个，从服务器有多个。

这种一主多从的架构基本适用于所有分布式系统或框架。可重复使用的架构方案叫作架构模式，一主多从可谓是大数据领域的最主要的架构模式。主服务器只有一台，掌控全局。从服务器有很多台，负责具体的事情。这样很多台服务器可以有效组织起来，对外表现出一个统一又强大的存储计算键搜能力。

DataNode 负责文件数据的存储和读写操作，HDFS 将文件数据分割成若干数据块（Block），每个 DataNode 存储一部分数据块，这样文件就分布存储在整个 HDFS 服务器集群中。应用程序客户端（Client）可以并行对这些数据块进行访问，从而使得 HDFS 可以在服务器集群规模上实现数据并行访问，极大地提高了访问速度。

在实践中，HDFS 集群的 DataNode 服务器会有很键亮坦多台，一般在几百台到几千台这样的规模，每台服务器配有数块磁盘，整个集群的存储容量大概在几 PB 到数百 PB。

NameNode 负责整个分布式文件系统的元数据（MetaData）管理，也就是文件路径名、数据块的 ID 以及存储位置等信息，相当于操作系统中文件分配表（FAT）的角色稿桐。HDFS 为了保证数据的高可用，会将一个数据块复制为多份（默认3份），并将多份相同的数据块存储在不同的机架的服务器上。这样当有磁盘损坏，或者某个 DataNode 服务器宕机，甚至某个交换机宕机时，系统能通过其备份的数据块进行查找。

处理客户端的请求。

客户端向 HDFS 上传文件。

客户端向 HDFS 读取文件。

像 NameNode 这样主从服务器管理同一份数据的场景，如果从服务器错误地以为主服务器宕机而接管集群管理，会出现主从服务器一起对 DataNode 发送指令，进而导致集群混乱，也就是所谓的“脑裂”。这也是这类场景选举主服务器时，引入 ZooKeeper 的原因。

[img]

关于hdfs架构和hdfs架构设计的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。