hdfs存储结构
A. HDFS的基本概念和体系结构
NameNode是Apache Hadoop HDFS体系结构中的主节点，用于维护和管理DataNode（从节点）上存在的块。NameNode是一个非常高可用性的服务器，用于管理文件系统命名空间并控制客户端对文件的访问。HDFS体系结构的构建方式使用户数据永远不会驻留在NameNode上。数据仅驻留在DataNodes上。
Functions of NameNode:
第二名称节点（Secondary NameNode，SNN）是用于定期合并命名空间镜像和镜像编辑日志的辅助守护进程。和名称节点一样，每个集群都有一个第二名称节点，在大规模部署的集群条件下，一般第二名称节点也独自占用一台服务器。
除了这两个守护进程之外，还有第三个守护进程或称为辅助NameNode的进程。辅助NameNode作为辅助守护进程与主NameNode并发工作。不要混淆次要的NameNode是备份的NameNode，因为它不是。
Functions of Secondary NameNode:
新的FsImage被复制回NameNode，下一次启动NameNode时将使用该FsImage）
Hence, Secondary NameNode performs regular checkpoints in HDFS. Therefore, it is also called CheckpointNode（因此，辅助NameNode在HDFS中执行常规检查点。因此，它也称为CheckpointNode。）
Functions of DataNode:
到现在为止，你一定已经意识到NameNode对我们来说非常重要。如果失败了，我们就完了。但是不要担心，我们将在下一篇Apache Hadoop HDFS架构博客中讨论Hadoop如何解决这个单点故障问题。
block不过是硬盘上存储数据的最小连续位置。通常，在任何文件系统中，您都将数据存储为块的集合。类似地，HDFS将每个文件存储为块，这些块分散在整个Apache Hadoop集群中。在Apache Hadoop 2.x中，每个块的默认大小是128 MB（在Apache Hadoop 1.x中是64 MB），您可以根据需要进行配置。
在HDFS中，不必将每个文件都以配置的块大小的精确倍数存储（128 MB，256 MB等）。让我们举一个例子，我有一个大小为514 MB的文件“ example.txt”，如上图所示。假设我们使用的默认块大小配置为128 MB。那么，将创建多少个块？5个：前四个块的大小为128 MB。但是，最后一个块的大小仅为2 MB。
现在，你一定在想为什么我们需要这么大的块大小，即128兆字节？
每当我们谈到HDFS，我们就谈到巨大的数据集，即兆兆字节和千兆字节的数据。因此，如果我们有一个比如4 KB的块大小，就像在Linux文件系统中一样，我们会有太多的块，因此会有太多的元数据。因此，管理这些数量的块和元数据会产生巨大的开销，这是我们不想要的
HDFS提供了一种以数据块的形式在分布式环境中存储大量数据的可靠方法。还复制这些块以提供容错能力。默认的复制因子是3，这也是可配置的。因此，如下图所示，每个块复制三次并存储在不同的datanode上(考虑默认的复制因子)
NameNode定期从DataNode收集阻止报告以维护复制因子。因此，每当块被过度复制或复制不足时，NameNode都会根据需要删除或添加副本。
同样，NameNode还确保所有副本都不存储在同一机架或单个机架中。它遵循内置的机架感知算法，以减少延迟并提供容错能力。考虑到复制因子为3，机架感知算法表示，一个块的第一个副本将存储在本地机架上，接下来的两个副本将存储在不同的（远程）机架上。下面就是实际的Hadoop生产集群的外观。在这里，可以装多个有DataNodes的机架。
Advantages of Rack Awareness:
So, now you will be thinking why do we need a Rack Awareness algorithm? The reasons are:
https://www.ereka.co/blog/apache-hadoop-hdfs-architecture/
B. 3.4 HDFS存储原理
一、涉及的问题
1. 冗余数据保存
2. 数据保存策略
3. 数据恢复
二、冗余数据保存问题
1. 冗余因子
出于成本考虑（也是HDFS优势），HDFS常架构在廉价机器上——经常出故障。所以必须有冗余机制。一般每个块都保存3份，即冗余因子默认是3
注意：伪分布式配置，即名称节点和数据节点都放在同一个机器上，则冗余因子显然只能是1，因为只有一个机器
2. 冗余机制的好处
(1) 加快数据传输速度——当多个客户端同时想访问相同数据块时，可以同时并行而不需要排队
(2) 很容易检查数据错误——互相对照发现错误
(3) 保证数据可靠性——HDFS有这样的机制：一旦探测到一个副本故障，会自动复制正确副本，使冗余因子恢复默认值
三、数据保存与读取
1. 第一副本存放策略：
(1) 如果保存请求来自集群内部，第一个副本放在发起者（应用）所在节点。比如一个在DataNode1上的应用发起存数据请求，那就把它第一份副本也存在DataNode1
(2) 如果保存请求来自集群外部，HDFS会随机挑选一台磁盘不太忙且CPU不太忙的节点来放置第一个副本
2. 第二个副本存放策略：
放在和第一副本不同的机架的节点上 。如下图中DataNode4，它和DataNode1在不同机架上
3. 第三副本放置策略：
放在和第一副本相同的机架的其他节点。如图中的DataNode2或DataNode3
4. 更多副本存放策略：
全部随机放置（依靠随机算法）
5、数据读取
原则：就近读取
——HDFS提供一个API可以告诉数据节点的机架ID，客户端也可以用API诊断自己所在机架ID。ID相同说明在同一机架。而相同机架数据间通信很快，它们就是“相近”的数据。
——而前面也说了，每个数据块都有多个不同的副本，如果找到某个副本和客户端在同一个机架上，就优先选此副本。如果没有就随机找一个副本读取
四、数据的错误与恢复
1. 名称节点出错
只有一个名称节点，而且它保存了核心数据结构FsImage和EditLog。恢复方法：
(1) 在HDFS1.0里只能暂停服务，从第二名称节点（冷备份）恢复
(2) 在HDFS2.0里可以直接用热备份恢复而不用暂停服务
2. 数据节点出错
(1) 如何发现数据节点出问题：
在整个运行期间，DataNode都会定期通过远程调用向NameNode发送心跳信息。一旦隔了一个周期收不到心跳信息，则NameNode就知道这个DataNode发生了故障
(2) 如何恢复数据节点：
NameNode会在状态列表里把出错的DataNode标记为不可用（宕机），然后把它里面的数据块对应的备份（在其他DataNode上）复制到另一个DataNode上去
——HDFS和其他分布式文件系统最大的区别就是 可以调整冗余数据位置 。这种调整不仅发生在故障时，也可以在在机器负载不均衡时把一个DataNode的数据迁移到另一个上面以平衡负载
3. 数据出错
(1) 如何发现数据出错：
“校验码机制”——客户端每写入一个数据块，都会为其生成一个校验码并保存在同一文件目录下。读取数据块同时会核对其校验码，如果不对说明数据出问题了。
(2) 如何恢复数据：
从备份复制过来
Reference:
https://www.icourse163.org/learn/XMU-1002335004#/learn/content?type=detail&id=1214310117&cid=1217922275&replay=true
C. HDFS组成架构及四大机制
HDFS：分布式文件系统。用于存储文件，通过目录树来定位文件。由多台服务器联合起来实现其功能，集群中的服务器有各自的角色。适合一次写入，多次读出的场景，且不支持文件修改。适合做数据分析，不适合做网盘应用。
NameNode :
DataNode :
Client :
Secondary NameNode
HDFS中的文件在物理上是分块存储（Block），快的大小可以通过配置参数（dfs.blcoksize）来规定，默认大小在Hadoop2.x中是128M，老版本中是64M。
DataNode定期向NameNode 发送心跳报告 已告知自己的状态。
心跳内容：
心跳报告周期
NameNode判断DataNode宕机的基准：
连续 10次 接收不到dataNode的 心跳信息 ，和 2次的检查时间 。
NameNode判断DataNode宕机的基准： 连续 10次 接收不到dataNode的 心跳信息 ，和 2次的检查时间 。
检查时间 ：表示在NameNode在接收不到DataNode的心跳时，此时会向DataNode主动发送检查
HDFS在 启动 的时候，首先会进入的安全模式中，当达到规定的要求时，会退出安全模式。在安全模式中，不能执行任何 修改元数据信息的操作 。
HDFS的元数据的介绍（三个部分）：
HDSF元数据的存储位置：
手动退出或者进入安全模式
集群启动后：
将每个文件的数据进行分块存储，每一个数据块又保存有多个副本，这些数据块副本分布在不同的机器节点上。默认情况下每个数据有3个副本。
真实生产中需要手动配置机架策略。
每个节点上储存的数据百分比相差不大。
集群会有一个自动的负载均衡的操作，传输速度相对较慢，节点较少时是可以的。
如果集群较大，需要手动负载均衡。集群空闲下执行。
D. 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
E. 大数据之HDFS
在现代的企业环境中，单机容量往往无法存储大量数据，需要跨机器存储。统一管理分布在集群上的文件系统称为 分布式文件系统 。
HDFS （Hadoop Distributed File System）是 Hadoop 的核心组件之一， 非常适于存储大型数据 (比如 TB 和 PB)， HDFS 使用多台计算机存储文件，并且提供统一的访问接口，像是访问一个普通文件系统一样使用分布式文件系统。
HDFS是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的 高容错、高可靠性、高可扩展性、高获得性、高吞吐率 等特征为海量数据提供了不怕故障的存储，为超大数据集的应用处理带来了很多便利。
HDFS 具有以下 优点 ：
当然 HDFS 也有它的 劣势 ，并不适合以下场合：
HDFS 采用Master/Slave的架构来存储数据，这种架构主要由四个部分组成，分别为HDFS Client、NameNode、DataNode和Secondary NameNode。
Namenode是整个文件系统的管理节点，负责接收用户的操作请求。它维护着整个文件系统的目录树，文件的元数据信息以及文件到块的对应关系和块到节点的对应关系。
Namenode保存了两个核心的数据结构：
在NameNode启动的时候，先将fsimage中的文件系统元数据信息加载到内存，然后根据edits中的记录将内存中的元数据同步到最新状态；所以，这两个文件一旦损坏或丢失，将导致整个HDFS文件系统不可用。
为了避免edits文件过大， SecondaryNameNode会按照时间阈值或者大小阈值，周期性的将fsimage和edits合并 ，然后将最新的fsimage推送给NameNode。
并非 NameNode 的热备。当NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。其主要任务是辅助 NameNode，定期合并 fsimage和fsedits。
Datanode是实际存储数据块的地方，负责执行数据块的读/写操作。
一个数据块在DataNode以文件存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据，包括数据块的长度，块数据的校验和，以及时间戳。
文件划分成块，默认大小128M，以快为单位，每个块有多个副本（默认3个）存储不同的机器上。
Hadoop2.X默认128M， 小于一个块的文件，并不会占据整个块的空间 。Block数据块大小设置较大的原因：
文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储。
Client 还提供一些命令来管理 HDFS，比如启动或者关闭HDFS。
Namenode始终在内存中保存metedata，用于处理“读请求”，到有“写请求”到来时，namenode会首 先写editlog到磁盘，即向edits文件中写日志，成功返回后，才会修改内存 ，并且向客户端返回，Hadoop会维护一个fsimage文件，也就是namenode中metedata的镜像，但是fsimage不会随时与namenode内存中的metedata保持一致，而是每隔一段时间通过合并edits文件来更新内容。
HDFS HA（High Availability）是为了解决单点故障问题。
HA集群设置两个名称节点，“活跃（ Active ）”和“待命（ Standby ）”，两种名称节点的状态同步，可以借助于一个共享存储系统来实现，一旦活跃名称节点出现故障，就可以立即切换到待命名称节点。
为了保证读写数据一致性，HDFS集群设计为只能有一个状态为Active的NameNode，但这种设计存在单点故障问题，官方提供了两种解决方案：
通过增加一个Secondary NameNode节点，处于Standby的状态，与Active的NameNode同时运行。当Active的节点出现故障时，切换到Secondary节点。
为了保证Secondary节点能够随时顶替上去，Standby节点需要定时同步Active节点的事务日志来更新本地的文件系统目录树信息，同时DataNode需要配置所有NameNode的位置，并向所有状态的NameNode发送块列表信息和心跳。
同步事务日志来更新目录树由JournalNode的守护进程来完成，简称为QJM，一个NameNode对应一个QJM进程，当Active节点执行任何命名空间文件目录树修改时，它会将修改记录持久化到大多数QJM中，Standby节点从QJM中监听并读取编辑事务日志内容，并将编辑日志应用到自己的命名空间。发生故障转移时，Standby节点将确保在将自身提升为Active状态之前，从QJM读取所有编辑内容。
注意，QJM只是实现了数据的备份，当Active节点发送故障时，需要手工提升Standby节点为Active节点。如果要实现NameNode故障自动转移，则需要配套ZKFC组件来实现，ZKFC也是独立运行的一个守护进程，基于zookeeper来实现选举和自动故障转移。
虽然HDFS HA解决了“单点故障”问题，但是在系统扩展性、整体性能和隔离性方面仍然存在问题：
HDFS HA本质上还是单名称节点。HDFS联邦可以解决以上三个方面问题。
在HDFS联邦中，设计了多个相互独立的NN，使得HDFS的命名服务能够水平扩展，这些NN分别进行各自命名空间和块的管理，不需要彼此协调。每个DN要向集群中所有的NN注册，并周期性的发送心跳信息和块信息，报告自己的状态。
HDFS联邦拥有多个独立的命名空间，其中，每一个命名空间管理属于自己的一组块，这些属于同一个命名空间的块组成一个“块池”。每个DN会为多个块池提供块的存储，块池中的各个块实际上是存储在不同DN中的。
F. 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: http://hadoop.apache.org/version_control.html
G. Hadoop文档（2.9.2） - HDFS架构
Hadoop分布式文件系统（HDFS）是一种运行在通用硬件上的分布式文件系统。它与传统的分布式文件系统有很多相似之处，但是也有显着的不同。HDFS是高容错的，可以部署在低成本硬件上。HDFS提供了对应用数据的高吞吐量访问，适用于具有大数据集的应用。HDFS为了流数据访问放松了一些POSIX的限制。
HDFS是主从结构。一个HDFS集群由一个NameNode和一组DataNode组成。NameNode是主服务器，负责管理文件系统命名空间以及客户端对文件的访问。DataNode通常每个节点一个，负责管理存储。HDFS对外暴露了一个文件系统命名空间并允许用户数据作为文件存储。在内部实现上，一个文件会被分割成一个或多个block，这些block存储在一组DataNode上。NameNode负责执行文件系统命名空间操作，例如打开，关闭，重命名文件和目录等。此外NameNode还维护着block和DataNode之间的映射关系。DataNode负责处理来自客户端的读写请求，并根据NameNode的指令创建，删除，备份block。
NameNode和DataNode都是运行在通用机器上的软件。这些机器通常使用Linux系统。HDFS使用Java构建，任何支持Java的机器都可以运行NameNode和DataNode。一种典型的集群部署方式是使用一台机器运行NameNode，其它机器每台运行一个DataNode实例。
HDFS使用传统的分层文件结构。用户可以创建目录并在目录下存储文件。文件系统命名空间结构与传统文件系统类似，用户可以创建，删除文件，将文件从一个目录移动到另一个目录，重命名文件。HDFS支持用户限额和访问权限。
NameNode维护整个文件系统命名空间，它会记录任何对命名空间的修改。应用程序可以指定HDFS中文件的备份数量。文件的拷贝数称为该文件的备份因子。这个信息也存储在NameNode中。
HDFS可以跨机器存储海量文件。每个文件分成一个block的序列存储。为了容错，文件的block会被备份。每个文件的block大小和备份因子都是可配置的。
文件中所有block的大小是相等的（除了最后一个），而对append和hsync提供可变长block支持后，用户可以直接创建一个新block，不必继续填充最后一个block。
应用程序可以指定文件的备份数。备份因子可在文件创建时指定，也可以稍后修改。HDFS的文件都是一次写入的（除了append和truncate），并且任何时候都只有一个写入器。
NameNode决定如何备份block。它周期性的接收来自DataNode的心跳检测和block报表。收到心跳检测说明DataNode工作正常，block报表包含该DataNode上的所有block。
备份文件的位置对HDFS的可用性和性能至关重要。对备份的优化让HDFS从众多分布式系统中脱颖而出。这个工作需要大量的优化和经验。机架感知备份放置策略的目的是提高数据的可靠性，可用性和网络带宽利用率。目前的备份放置策略实现是这个方向上的第一步。短期目标是在生产环境上对其进行验证，更多的了解它的行为，为测试和研究更复杂的策略奠定基础。
大型HDFS集群的机器通常隶属于多个机架。两个不同机架上的节点进行通信必须通过交换机。一般来说，同一机架机器之间的网络带宽要优于不同机架机器间的网络带宽。
NameNode通过Hadoop Rack Awareness进程确定每个DataNode所属的机架ID。一个简单但是并非最优的策略是将备份放置在独立的机架上。这种策略可以避免机架故障时丢失数据，读数据时也可以利用多个机架的网络带宽。这种策略在集群中平均分配备份文件，这样组件发生故障时可以平衡负载。但是这种策略会增加写入成本，因为数据需要跨机架传输。
最常见的情况，备份因子是3。HDFS的放置策略是：如果写入器位于DataNode上，则将副本放置在本地计算机，否则随机选择一个DataNode，另一个副本放置在另一个远程机架的节点上，最后一个副本放在同一个远程机架的另一个节点上。这种策略减少了机架间的写入流量，从而提高写性能。机架发生故障的几率远小于节点故障几率。这种策略并不影响数据可靠性和可用性，但是它确实减少了读操作时的聚合网络带宽，因为一个block被放置到两个机架上而不是三个。这种策略的文件副本并不是均匀的分布在所有机架上，副本的三分之一位于一个节点，剩下的三分之二位于另一个机架上。这种策略可以提高写性能，而不会影响数据可靠性和读性能。
如果备份因子大于3，那么第四个和之后的副本随机放置，同时要保证副本数量不能超过机架的上限（公式： (replicas - 1) / racks + 2 ）。
由于DataNode不能放置同一个block的多个副本，所以最大备份因子就是最大DataNode数。
在提供了存储类型和存储策略的支持之后，除了机架感知，NameNode放置副本时也会考虑放置策略。NameNode首先根据机架感知选择节点，然后根据备份文件的放置策略检查该节点的存储类型，如果该候选节点没有要求的存储类型，NameNode会查找下一个节点。如果第一轮没有找到足够的节点放置备份，NameNode会使用后备存储类型开始第二轮查找。
目前，副本放置策略依然在开发中。
为了减少带宽消耗和读延迟，HDFS会尝试找寻一个离读请求最近的副本。如果读请求节点所在机架有这样一个副本，HDFS就优先使用这个副本。如果HDFS集群跨越多个数据中心，则本地数据中心的副本优先于远程副本。
启动HDFS时，NameNode会进入一种称为安全模式的特殊状态。安全模式下数据block无法备份。NameNode会从DataNode接收心跳检测和block报表。block报表包含该DataNode下所有数据block的列表信息。每个block都有一个指定的最小备份数。只有block的最小备份数登记到NameNode中后，block才可以备份。备份登记结束后，NameNode退出安全模式。这是如果还有block不满足最小备份数的条件，NameNode才开始备份这些block。
HDFS命名空间由NameNode保存，NameNode使用一个称为EditLog的事务日志记录对文件系统元数据的所有更改。例如，创建一个新文件会在EditLog中插入一条对应记录，同样的，修改文件备份因子也会插入一条记录。NameNode使用本地文件存储EditLog。整个文件系统命名空间，包括文件与block之间的映射关系，文件系统数据等，都保存在FsImage文件中。
NameNode在内存中维护文件系统命名空间和文件block映射关系的镜像。当NameNode启动，或者某个阈值触发了检查点时，NameNode从磁盘上读取FsImage和EditLog的内容，将所有EditLog中的事务操作应用到FsImage的内存镜像中，然后在磁盘上生成一个全新的FsImage。之后可以截断EditLog，因为所有事务都已持久化到FsImage。这个过程称为检查点。检查点的目的是通过获取文件系统元数据的快照并保存到FsImage来保证HDFS文件系统元数据的一致性。读取FsImage可能很快，但是持续编辑FsImage就不同了。因此我们将操作记录到EditLog中，而不是直接修改FsImage。在检查点期间，所有EditLog操作应用到FsImage。检查点可以按周期触发（ dfs.namenode.checkpoint.period ），也可以按事务数触发（ dfs.namenode.checkpoint.txns ）。如果两个属性都设置了，第一个满足的阈值会触发检查点。
DataNode在本地文件系统中存储HDFS数据。DataNode对HDFS文件一无所知，它以block为单位存储HDFS数据。DataNode不会在同一个目录下保存所有文件。相反，它使用启发式方法来确定每个目录的最佳文件数，并适时创建子目录。在同一个目录下创建所有文件并不是最佳选择，因为本地文件系统可能无法支持一个目录下的大量文件。DataNode启动时，它会扫描整个本地文件系统，生成一个本地文件与数据block之间的关系列表，将其发送给NameNode，这个列表称为block报告。
所有HDFS通信协议都构建在TCP/IP协议之上。客户端通过TCP端口与NameNode建立连接，它使用ClientProtocol与NameNode交互。DataNode使用DataProtocol与NameNode交互。一个RPC抽象封装了客户端协议和DataNode协议。NameNode从不初始化任何RPC，它只是响应来自的客户端和DataNode的请求。
HDFS的主要目标是即使出现故障也可以可靠的存储数据。三种常见的故障分别是：NameNode故障，DataNode故障和网络分区。
DataNode周期性的发送心跳检测给NameNode。网络分区可能导致某些DataNode无法连接NameNode。NameNode无法收到DataNode的心跳检测后，它会把这样的DataNode标记为dead，并不在发送新的I/O请求。注册到死亡DataNode上的数据对HDFS来说不再可用，也会导致某些block的备份数少于文件指定的最小备份数。NameNode持续追踪block的备份情况并在必要时初始化备份操作。重备份的原因是多种多样的：DataNode不可用，某个备份文件损坏，DataNode磁盘故障，或者文件的备份因子增大。
为了避免DataNode状态抖动引起的备份风暴，标记DataNode死亡的超时时间设置的很长（默认超过10分钟）。用户可以设置一个更短的时间将DataNode标记为陈旧（stale），这样可以避免对性能敏感的工作负载的陈旧DataNode的读写操作。
HDFS架构与数据重平衡scheme兼容。scheme可以在DataNode的磁盘空间低于某个阈值时将数据移动到另一个DataNode上。如果对某个文件的需求特别高，scheme还可以动态创建额外的副本并平衡到整个集群中。这些数据平衡scheme还未实现。
从DataNode中读取的block可能是损坏的。损坏的原因有多种：磁盘故障，网络故障，或者软件问题。HDFS客户端会对文件内容进行校验和检查。当客户端创建一个HDFS文件时，它会计算出文件所有block的校验和并保存在同一个命名空间的一个独立的隐藏文件中。当客户单检索文件时还要检查对应校验和文件中的值。如果校验和不匹配，客户端会尝试该block其它节点上的副本。
FsImage和EditLog是HDFS的核心数据结构。如果它们发生损坏，HDFS就无法使用了。因此，可以通过配置让NameNode维护多个FsImage和EditLog的拷贝。对两个文件的修改会同步到所有拷贝中。这种同步操作会降低NameNode的TPS，但是这种牺牲是可接受的，因为HDFS是数据密集，不是元数据密集。NameNode重启时，它会选择最一致的FsImage和EditLog使用。
另一种减低故障的办法是使用HA。
（略）
HDFS的目的是支持大型文件。HDFS支持一次写入多次读取。一个典型的block大小是128MB。因此，HDFS文件按照128MB的大小分割，每个block可能分布在不同的节点上。
客户端向HDFS文件写入数据时，如果备份因子是三，NameNode使用备份目标选择算法检索出一组DataNode。这个列表是可以存储副本的DataNode。客户端先向第一个DataNode写入数据，DataNode接收数据并将数据传输到列表中的第二个DataNode。第二个DataNode开始接收数据并继续传输数据到第三个DataNode。这样，数据通过管道从一个DataNode传输到下一个。
（略）
如果开启了trash配置，从FS shell中删除的文件并不会立刻从HDFS中删除，HDFS将它移动到一个trash目录（每个用户都有自己的trash目录， /user/<username>/.Trash ）。只要文件还在trash目录中就可以快速恢复。
最近删除的文件移动到 /user/<username>/.Trash/Current 目录中，每隔一段时间，HDFS会为这些文件创建检查点文件（ /user/<username>/.Trash/<date> ）并删除旧检查点文件。
如果trash中的文件过期了，NameNode将这些文件从命名空间中删除。与文件关联的block被释放。删除文件和空间释放之间可能会有延迟。
下面是一个例子，首先创建两个文件：
然后删除test1，该文件会被移到Trash目录：
接着跳过Trash删除test2：
现在可以查看Trash目录：
文件的备份因子降低后，NameNode选择可以删除的副本，在下次心跳检测时把信息发送给DataNode，之后DataNode删除block并释放空间。