❶ 第三章 大数据存储
一，HDFS的基本特征与构架
1.基本特征
（1）大规模数据分布存储能力：以分布式存储能力和良好的可扩展性。（基于大量分布节点上的本地文件系统，构建一个逻辑上具有巨大容量的分布式文件系统，并且整个文件系统的容量可随集群中节点的增加而线性扩展）
（2）高并发访问能力：提供很高的数据访问宽带（高数据吞吐率），并且可以把带宽的大小等比例扩展到集群中的全部节点上
（3）强大的容错能力：（设计理念中硬件故障被视作常态）保证在经常有节点发生硬件故障的情况下正确检测硬件故障，并且能自动从故障中快速恢复，确保数据不丢失（采用多副本数据块形式存储）
（4）顺序式文件访问：（大数据批处理都是大量简单数据记录的顺序处理）对顺序读进行了优化，支持大量数据的快速顺序读出，代价是对于随机的访问负载较高
（5）简单的一致性模型（一次写多次读）：支持大量数据的一次写入，多次读取；不支持已写入数据的更新操作，但允许在文件尾部添加新的数据
（6）数据块存储模式：默认的块大小是64MB。好处：减少元数据的数量，允许这些数据块通过随机方式选择节点，分布存储在不同地方
2.基本框架与工作过程
（1）基本组成结构与文件访问过程
[1]HDFS；一个建立在一组分布式服务器节点的本地文件系统之上的分布式文件系统（采用经典主-从结构）
[2]主控节点NameNode:
1）是一个主服务器，用来管理整个文件系统的命名空间和元数据,以及处理来自外界的文件访问请求
2）保存了文件系统的三中元数据
命名空间：整个分布式文件系统的目录结构
数据块与文件名的映射表
每个数据块副本的位置信息，每一个数据块默认有3个副本
[3]从节点DataNode：
1）用来实际存储和管理文件的数据块
2）为了防止数据丢失，每个数据块默认有3个副本，且3个副本会分别复制在不同节点上，以避免一个节点失效造成一个数据块的彻底丢失
[4]程序访问文件时，实际文件数据流并不会通过NameNode传送，而是从NameNode获得所需访问数据块的存储位置信息后，直接去访问对应的DataNode获取数据
[5]设计好处：
1）可以允许一个文件的数据能同时在不同DataNode上并发访问，提高数据访问的速度
2）减少NameNode的负担，避免使NameNode成为数据访问瓶颈
[6]基本访问过程：
1）首先，用户的应用程序通过HDFS的客户端程序将文件名发送至NameNode
2）NameNode接收到文件名之后，在HDFS目录中检索文件名对应的数据块，再根据数据块信息找到保存数据块的DataNode地址，讲这些地址回送到客户端
3）客户端接收到这些DataNode地址之后，与这些DataNode并行的进行数据传输操作，同时将操作结果的相关日志提交到NameNode
2.数据块
（1）为了提高硬盘的效率，文件系统中最小的数据读写单元是数据块
（2）HDFS数据块的默认大小是64MB，实际部署中，可能会更多
（3）将数据块设置大的原因是减少寻址开销的时间
（4）当应用发起数据传输请求：
[1]NameNode首先检索文件对应的数据块信息，找到数据块对应的DataNode
[2]DataNode根据数据块信息在自身的存储中寻找相应的文件，进而与应用程序之间交换数据
[3]因为检索过程是但进行，所以要增加数据块大小，这样就可以减少寻址的频度和时间开销
3.命名空间
（1）文件命名遵循“目录/子目录/文件”格式
（2）通过命令行或者是API可以创建目录，并且将文件保存在目录中。可以对文件进行创建，删除，重命名操作
（3）命令空间由NameNode管理。所有对命名空间的改动都会被记录
（4）允许用户配置文件在HDFS上保存的副本数量，保存的副本数称作“副本因子”
4.通信协议
（1）采用TCP协议作为底层的支撑协议
（2）应用协议
[1]应用可以向NameNode主动发起TCP连接
[2]应用和NameNode交互协议称为Client协议
[3]NameNode和DataNode交互的协议称为DataNode协议
（3）用户和DataNode的交互是通过发起远程调用（RPC），并由NameNode响应来完成的。另外，NameNode不会主动发起远程过程调用请求
5.客户端：是用户和HDFS通信最常见的渠道，部署的HDFS都会提供客户端
二，HDFS可靠性设计
1.HDFS数据块多副本存储设计
（1）采用了在系统中保存多个副本的方式保存数据，且同一个数据块的多个副本会存放在不同节点上
（2）优点：
[1]采用多副本，可以让客户从不同数据块中读取数据，加快传输速度
[2]HDFS的DataNode之间通过网络传输数据，如果采用多个副本可以判断数据传输是否出错
[3]多副本可以保证某个DataNode失效的情况下，不会丢失数据
2.可靠性的设计实现
（1）安全模式：
[1]HDFS启动时，NameNode进入安全模式
[2]处于安全模式的NameNode不能做任何文本操作，甚至内部的副本创建不允许
[3]NameNode需要和各个DataNode通信，获得其中保存的数据块信息，并对数据块信息进行检查
[4]只有通过了NameNode检查，一个数据块被认为安全。当被认为安全的数据块所占比例达到某个阈值，NameNode退出
（2）SecondaryNmaeNode
[1]使用它来备份NameNode元数据，以便在其失效时能从中恢复出其上的元数据
[2]它充当NameNode的一个副本，本身并不处理任何请求。
[3]作用：周期性保存NameNode的元数据
（3）心跳包和副本重新创建
[1]心跳包：位于HDFS核心的NameNode，通过周期性的活动检查DataNode的活动
[2]检测到DataNode失效，保存在其上的数据不可用。则其上保存的副本需要重新创建这个副本，放到另外可用的地方
（4）数据一致性
[1]采用了数据校验和机制
[2]创建文件时，HDFS会为这个文件生成一个校验和，校验和文件和文件本身保存在同一空间上，
[3]传输数据时会将数据与校验和一起传输，应用收到数据后可以进行校验
（5）租约
[1]防止同一个文件被多个人写入数据
[2]NameNode保证同一个文件只会发放一个允许的租约，可以有效防止出现多人写入的情况
（6）回滚
三，HDFS文件存储组织与读写
1.文件数据的存储组织
（1）NameNode目录结构
[1]借助本地文件系统来保存数据，保存文件夹位置由配置选项（{dfs.name.dir}/{/tmp/dfs/name}）决定
[2]在NameNode的${dfs.name.dir}之下有3个文件夹和1个文件：
1）current目录：
文件VERSION:保存了当前运行的HDFS版本信息
FsImages:是整个系统的空间镜像文件
Edit：EditLog编辑文件
Fstime：上一次检查点时间
2）previous.checkpoint目录：和上一个一致，但是保存的是上一次检查点的内容
3）image目录：旧版本的FsImage存储位置
4）in_use.look:NameNode锁，只在NameNode有效（启动并且能和DataNode正常交互）时存在。
（2）DataNode目录结构
[1]借助本地文件系统来保存数据。保存文件夹位置由配置选项{dfs.data.dir}决定
[2]在其之下有4个子目录和2个文件
1）current目录：已经成功写入的数据块，以及一些系统需要的文件
a)文件VERSION：保存了当前运行的HDFS版本信息
b)subdirXX:当同一目录下文件超过一定限制，新建一个目录，保存多出来的数据块和元数据
2）tmp目录和blockBeingWritten目录：正在写入的数据块，是HDFS系统内部副本创建时引发的写入操作对应的数据块
3）detach目录：用于DataNode升级
4）Storage目录：防止版本不同带来风险
5）in_user.lock文件：DataNode锁。只有在DataNode有效时存在。
（3）CheckPointNode目录结构：和上一个基本一致
2.数据的读写过程
（1）数据读取过程
[1]首先，客户端调用FileSystem实例的open方法，获得这个文件对应的输入流，在HDFS中就是DFSInputStream
[2]构造第一步的输入流时，通过RPC远程调用NameNode可以获得NameNode中此文件对应的数据块保存位置，包括这个文件副本的保存位置（注：在输入流中会按照网络拓扑结构，根据与客户端距离对DataNode进行简单排序）
[3]-[4]获得此输入流后，客户端调用READ方法读取数据。输入流选择最近的DFSInputStream会根据前面的排序结果，选择最近的DataNode建立连接并读取数据。
[5]如果已达到数据块末端，关闭这个DataNode的连接，然后重新查找下一个数据块
[6]客户端调用close，关闭输入流DFSInputStream
（2）数据输入过程
[1]-[2]:客户端调用FileSystem实例的create方法，创建文件。检查后，在NameNode添加文件信息，创建结束之后，HDFS会返回一个输出流DFSDataOutputStream给客户端
[3]调用输出流的write方法向HDFS中对应的文件写入数据。
数据首先会被分包，这些分包会写入一个输出流的内部队列Data队列中，接收完整数据分包，输出流回想NameNode申请保存文件和副本数据块的若干个DataNode
[4]DFSDataOutputStream会（根据网络拓扑结构排序）将数据传输给距离上最短的DataNode，这个节点接收到数据包后传给下一个。数据在各节点之间通过管道流通，减少传输开销
[5]数据节点位于不同机器上，数据需要通过网络发送。（为保证数据节点数据正确，接收到数据的节点要向发送者发送确认包）
[6]执行3-5知道数据全部写完，DFSDataInputStream继续等待知道所有数据写入完毕并确认，调用complete方法通知NameNode文件写入完成
[7]NameNode接收到complete消息之后，等待相应数量的副本写入完毕后，告知客户端
传输过程，当某个DataNode失效，HDFS执行：
1）关闭数据传输的管道
2）将等待ACK队列的数据放到Data队列头部
3）更新正常DataNode中所有数据块版本。当失效的DataNode重启，之前的数据块会因为版本不对被清除
4）在传输管道中删除失效的DataNode,重新建立管道并发送数据包
4.HDFS文件系统操作命令
（1）HDFS启动与关闭
[1]启动过程：
1）进入到NameNode对应节点的Hadoop安装目录
2）执行启动脚本:bin/start-dfs.sh
[2]关闭过程:bin/stop-dfs.sh
（2）文件操作命令格式与注意事项
[1]基本命令格式：
1）bin/hadoop dfs-cmd <args> args-> scheme://authority/path
2）args参数基本格式前面是scheme，authority是机器地址和对应端口
a)本地文件，scheme是file
b)HDFS上文件，scheme是hdfs
（3）文件操作基本格式
[1]hadoop dfs-cat URL [URL ...]
[2]作用：将参数所指示文件内容输出到stdout
❷ 分布式文件系统hdfs主要由哪些功能模块构成
Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的。HDFS是Apache Hadoop Core项目的一部分。
Hadoop分布式文件系统架构
1 NameNode（名称节点）
HDFS命名空间采用层次化（树状——译者注）的结构存放文件和目录。
2 映像和日志
Inode和定义metadata的系统文件块列表统称为Image(映像).NameNode将整个命名空间映像保存在RAM中。而映像的持久化记录则保存在NameNode的本地文件系统中，该持久化记录被称为Checkpoint(检查点)。NameNode还会记录HDFS中写入的操作，并将其存入一个记录文件，存放在本地文件系统中，这个记录文件被叫做Journal(日志)。
3 数据节点
DataNode上的每一个块(block)副本都由两个本地文件系统上的文件共同表示。其中一个文件包含了块（block）本身所需包含的数据，另一个文件则记录了该块的元数据，包括块所含数据大小和文件生成时间戳。数据文件的大小等于该块（block）的真实大小，而不是像传统的文件系统一样，需要用额外的存储空间凑成完整的块。因此，如果一个块里只需要一半的空间存储数据，那么就只需要在本地系统上分配半块的存储空间即可。
4 HDFS客户端
用户应用程序通过HDFS客户端连接到HDFS文件系统，通过库文件可导出HDFS文件系统的接口。像很多传统的文件系统一样，HDFS支持文件的读、写和删除操作，还支持对目录的创建和删除操作。与传统的文件系统不同的是，HDFS提供一个API用以暴露文件块的位置。这个功能允许应用程序。
5 检查点节点
HDFS中的NameNode节点，除了其主要职责是相应客户端请求以外，还能够有选择地扮演一到两个其他的角色，例如做检查点节点或者备份节点。该角色是在节点启动的时候特有的。
6 备份节点
HDFS的备份节点是最近在加入系统的一项特色功能。就像CheckpintNode一样，备份节点能够定期创建检查点，但是不同的是，备份节点一直保存在内存中，随着文件系统命名空间的映像更新和不断更新，并与NameNode的状态随时保持同步。
7 系统更新和文件系统快照
在软件更新的过程中，由于软件的bug或者人为操作的失误，文件系统损坏的几率会随之提升。在HDFS中创建系统快照的目的，就在于把系统升级过程中可能对数据造成的隐患降到最低。快照机制让系统管理员将当前系统状态持久化到文件系统中，这样以来，如果系统升级后出现了数据丢失或者损坏，便有机会进行回滚操作，将HDFS的命名空间和存储状态恢复到系统快照进行的时刻。
❸ HDFS是由哪些部分组成
HDFS命名空间采用层次化（树状——译者注）的结构存放文件和目录。文件和目版录用NameNode上的inodes表示。Inode记录了权限，权修改和访问时间，命名空间，磁盘容量等属性。文件内容会被分成不同的“大块”（典型分块策略是每块128M，不过用户可以对每个文件的分块大小进行选择）。NameNode负责维护命名空间树以及与DataNode上文件分块的映射关系。目前采用的设计结构是，没一个集群只有一个NameNode,一个NameNode可以对应多个DataNode以及成千上万的HDFS客户端。一个DataNode可以同步执行多个应用任务。
❹ 大数据之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中的。
❺ HDFS由什么组成
大数据平台包含了采集层、存储层、计算层和应用层，是一个复杂的IT系统，需要学会Hadoop等分布式系统的开发技能。
1.1采集层：Sqoop可用来采集导入传统关系型数据库的数据、Flume对于日志型数据采集，另外使用Python一类的语言开发网络爬虫获取网络数据；
1.2储存层：分布式文件系统HDFS最为常用；采用了主从（Master/Slave）结构模型，一个HDFS集群是由一个NameNode和若干个DataNode组成的。其中NameNode作为主服务器，管理文件系统的命名空间和客户端对文件的访问操作；集群中的DataNode管理存储的数据。
1.3计算层：有不同的计算框架可以选择，常见的如MapRece、Spark等，一般来讲，如果能使用计算框架的“原生语言”，运算效率会最高（MapRece的原生支持Java，而Spark原生支持Scala）；
1.4应用层：包括结果数据的可视化、交互界面开发以及应用管理工具的开发等，更多的用到Java、Python等通用IT开发前端、后端的能力；
❻ 大数据原理及技术—HDFS
4V：数据量大（volume）、数据类型繁多（variety）、处理速度快（velocity）、价值密度低（value）
Hadoop 是一个开源分布式计算平台，提供了系统底层细节透明的分布式架构基础。Hadoop的核心是分布式文件系统HDFS和MapRece。Hadoop采用分布式存储和分布式处理两大核心技术，其设计目标是可以高效稳定运行在廉价的计算机集群上(低成本)，可以扩展到数以千计计算机节点，从而可以采用冗余数据存储方式，当一个节点数据出现问题，其他副本可以提供服务。
同普通文件系统，分布式文件系统采用块（磁盘块）的概念，是文件系统读写操作的最小单位，块是数据读写的基本单元。HDFS默认一个块大小是64MB。
由计算机集群多个节点构成，两类节点：主节点（master）／名称节点（name）、从节点（slave）／数据节点（data）。名称节点负责文件（包括数据节点）和目录的创建、删除和重命名等，同时管理数据节点和文件块的映射关系，因此客户端只有访问名称节点才能找到请求的文件块所在位置，进而找到相应位置读取文件块。数据节点负责数据的存储和读取。存储时，名称节点分配存储位置；读取时，从名称节点获取数据节点文件块，再由客户端写入或访问数据。
客户端需要访问一个文件时，首先从名称节点获得这个文件的数据块的位置列表，然后根据列表获取实际存储各个数据块的数据节点的位置，最后数据节点根据数据块信息在本地文件系统找到对应文件，并把数据返回客户端。
采用主从（master／slave）结构模型，一个HDFS集群包括一个名称节点和若干个数据节点。名称节点作为中心服务器，负责管理文件系统的命名空间（命名空间包括目录、文件和块）和客户端对文件的访问；数据节点负责处理文件系统客户端的读写请求，在名称节点统一调度下进行数据块创建、删除、复制等操作。每个数据节点会周期性向名称节点发送“心跳”信息，报告自己的状态，没有按时发送则会被标记为“宕机”。
冗余存储：采取多副本方式存储数据，因此保证了系统的容错性和可用性。
❼ 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并释放空间。