HDFS简介：

HDFS（Hadoop Distributed File System）是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。
它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集的应用处理带来了很多便利。

1、HDFS要求与限制

能处理超大文件
HDFS以支持大数据集合为目标，文件大小一般都在千兆至T字节，一个单一HDFS实例应该能支撑数以千万计的文件。

流式数据访问
HDFS设计的思想：一次写入、多次读取(write-one-read-many访问模型)。一个文件经过创建和写入，关闭之后就不需要改变。
这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。

使用商用硬件
Hadoop不需要运行在昂贵并且高可靠性的硬件上，因此，硬件错误是常态。
HDFS可能是有成百上千的server组成，任何一个组件都可能失效，因此错误检测和快速、自动地恢复是HDFS的核心架构目标。
HDFS在面对这种故障时，被设计为能够继续运行而不让用户觉察到明显的中断。

低延迟数据访问
HDFS为达到高数据吞吐量而优化的，这可能会以延迟为代价。因此，需要毫秒范围内低延迟访问数据的应用不适合HDFS。

小文件存储问题
HDFS中的名称节点（Namenode）存储着文件系统的元数据，因此文件数量的限制也由NameNode的内存大小决定。
HDFS上每个文件索引数据块的大小约为150个字节，因此，HDFS上存储文件个数的上限就能确定了。

文件随机读写限制
HDFS中的文件只有一个写入者，而且写操作总是在文件的末尾。它不支持多个写入者，或是在文件的任意位置修改。

总结：

• 流式数据访问模式—简化了数据一致性问题，使数据并发访问成为可能。
• 廉价设备—错误检测、快速恢复、不丢失数据。
• 超大文件存储方式—-分布式存储、分布式访问。
• HDFS存储空间—动态扩容
• 众多小文件的存储—–压缩
• 文件的随机读写—-Hbase

---

• 大文件总是被分隔成很多小的文件块，分散存储在机房的各个机器的不同磁盘上。
• 文件的读写都是并发执行的
• 一个磁盘或者一台服务器出故障不影响业务。
• 可根据实际需要增加或者删除集群中的节点数

2、HDFS设计需求

针对HDFS的要求，设计需求大概是这么几个：

• 透明性（针对HDFS的一切操作和管理都是透明的）
• 并发控制
• 可伸缩性
• 容错
• 安全需求

（1）透明性

开放分布式处理的标准确定就有8种透明性：访问的透明性、位置的透明性、并发透明性、复制透明性、故障透明性、移动透明性、性能透明性和伸缩透明性。
对于HDSF而言，最重要的是希望能达到如下5个透明性要求：

访问的透明性
用户访问本地文件和远程文件资源所采用的接口是一致的，通过修改配置文件来实现。访问HDFS时也不需要知道所访问的文件存放在集群的哪个节点的哪个磁盘上。

（a）Namenode负责HDFS的管理，Datanode负责HDFS中数据存储
（b）Client读写数据均需与Namenode连接，获得文件的存储位置，然后进行读写操作
（c）HDFS访问接口是通用的，可以通过配置决定访问HDFS还是本地文件系统

位置的透明性：
HDFS使用单一的文件命名空间，由Namenode来负责文件系统命名空间的管理。HDFS上文件的block可以重新分布复制，block可以增加或者减少副本，副本可以跨机架存储，而这一切对客户端都是透明的。

（a）文件可以分割成多个block，每个block存储的节点是在保证负载均衡的基础上随机确定的。
（b）为了保证数据不丢失，一个block都有多个副本。
（c）一个block的副本也是存放在不同节点上的

移动的透明性：
HDFS中的文件经常由于节点的失效、增加或者replication因子的改变或者重新均衡等进行着复制或者移动，而客户端和客户端程序并不需要改变什么，Namenode的edits日志文件记录着这些变更。

（a）Namenode中存储了两个非常重要的文件：fsimage和edits
（b）fsimage是HDFS文件系统的一个镜像文件
（c）edits是HDFS最近操作的日志

性能的透明性和伸缩的透明性：
HDFS的目标就是构建在大规模廉价机器上的分布式文件系统集群，可伸缩性毋庸置疑，至于性能可以参考它首页上的一些benchmark。

（a）Slave文件记录了所有Datanode节点的hostname.
（b）集群节点可以根据应用需要动态增加或者减少
（c）增加：在Namenode所在节点的slave文件中增加待增加Datanode节点的hostname，然后在相应的节点执行hadoop-daemon.sh start datanode
（d）下架：集群中增加配置文件exclude。并把要下架的节点hostname写入到exclude文件中。或者在下架的节点上执行hadoop-daemon.sh stop datanode强制下架

（2）并发控制

文件分隔成block，且分散存储在集群的各个节点的不同磁盘上，为大文件的并发读取提供了天然的优势。

（a）文件分隔后分散存储，大大增加了磁盘的IO，同时使分布式计算成为可能。
（b）block多副本也可实现同一数据多个并发读取，使得数据分析可并行执行。
（c）HDFS上的多个文件可以实现并发读写。

（3）文件复制功能

鉴于商业设备的不可靠性，需要保证数据的安全性，确保数据不会丢失。HDFS采用了副本复制策略来实现这一要求。

H：Host
R：Rack 机架
D：DataCenter 数据中心

HDFS副本复制策略：

HDFS默认的副本因子replication=3，也就是说每个block都必须在HDFS上保存三份。

副本存放的策略也很有讲究，一个放在本地机架的节点，一个放在其他机架上，另一个放在同一机架的另一节点。这样可以最大限度地防止因故障导致的副本的丢失。不仅如此，HDFS读文件的时候也将优先选择从同一机架乃至同一数据中心的节点上读取block。

1st replica. 如果写请求方所在机器是其中一个Datanode，则直接存放在本地，否则由Namenode随机在集群中选择一个Datanode.
2nd replica. 第二个副本存放于不同第一个副本的所在的机架。
3rd replica.第三个副本存放于第二个副本所在的机架，但是属于不同的节点。

（4）硬件和操作系统的异构性

由于构建在java平台上，HDFS的跨平台能力毋庸置疑，得益于java平台已经封装好的文件IO系统，HDFS可以在不同的操作系统和计算机上实现同样的客户端和服务端程序。

（5）容错能力

尽管使用廉价的商用设备，HDFS仍然需要为用户提供企业级专用设备所具有的可靠性和容错能力。因此，在客户端或者服务端出现问题的时候, HDFS必须保证文件服务仍能正常使用。HDFS的容错能力大概可以分为两个方面：文件系统的容错性、Hadoop本身的容错能力

HDFS容错性：

Datenode以固定周期向Namenode发送心跳，Namenode如果在一段时间内没有收到心跳，就会标记datenode为宕机。此段时间的计算公式是：timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval

而默认的heartbeat.recheck.interval 大小为5分钟，dfs.heartbeat.interval默认的大小为3秒。 所以Namenode如果在10分钟+30秒后，仍然没有收到Datanode的心跳，就认为Datanode已经宕机，并标记为dead.

Namenode就不会将任何新的IO操作派发给那个Datanode，该Datanode上的数据被认为是无效的，因此Namenode会检测是否有文件block的副本数目小于设置值，如果小于就自动开始复制新的副本并分发到其他Datanode节点。

由于节点的失效或者增加，可能导致数据分布的不均匀，当某个Datanode节点的空闲空间大于一个临界值的时候，HDFS会自动从其他Datanode迁移数据过来。

这就是HDFS的负载均衡策略。

文件系统容错性

检测文件block的完整性，HDFS会记录每个新创建的文件的所有block的校验和。当以后检索这些文件的时候，从某个节点获取block，会首先确认校验和是否一致，如果不一致，会从其他Datanode节点上获取该block的副本。

Namenode上的fsimage和edits日志文件是HDFS的核心数据结构，如果这些文件损坏了，HDFS将失效。因而，Namenode可以配置成支持维护多 个fsimage和editlog的拷贝。任何对fsimage或者editlog的修改，都将同步到它们的副本上。它总是选取最近的一致的fsimage和editlog使用。

文件的删除，删除并不是马上从Namenode移出namespace，而是放在/trash目录随时可恢复，直到超过设置时间才被正式移除。。

Hadoop本身的容错性

Hadoop支持升级和回滚，当升级Hadoop软件时出现bug或者不兼容现象，可以通过回滚恢复到老的Hadoop版本。

（6）安全性问题

HDFS自身安全性是比较弱的，只有简单的与unix文件系统类似的文件许可控制。
Hadoop kerberos子系统服务安全和验证服务。

总结

HDFS作为通用的分布式文件系统并不适合，它在并发控制、缓存一致性以及小文件读写的效率上是比较弱的。但是它有自己明确的设计目标，那就是支持大的数据文件（兆至T级），并且这些文件以顺序读为主，以文件读的高吞吐量为目标，并且与MapReduce框架紧密结合。

3、HDFS—NameNode启动过程

1、namenode格式化时生成fsimage文件。
2、第一次启动namenode硬盘中将fsimage加载到内存中。
3、datanode向namenode发送block report，汇报datanode的数据节点情况。如果HDFS存在修改，则写入edits日志中。

4、HDFS—fsimage与edits合并机制

fsimage：HDFS元数据文件
edits：HDFS操作日志

（1）Primary Namenode启动时读取fsimag文件并加载到内存。
（2） Primary NameNode相应客户端的操作，生成edits文件。
（3）Secondary Namenode周期性同Primary Namenode通信，请求停止使用edits文件，将新的操作写入到edits.new文件中。
（4） Secondary Namenode从Primary Namenode读取fsimage和edits文件，并将它们合并成fsimage.ckpt，并发送给Primary Namenode
（5）Primary Namenode将接收到的fsimage文件替换原来的fsimage，同时用edits.new替换原来的edits。

5、HDFS负载均衡策略

进行数据的负载均衡调整，必须要满足如下原则：

• 数据平衡不能导致数据块减少，数据块备份丢失
• 管理员可以中止数据平衡进程
• 每次移动的数据量以及占用的网络资源，必须是可控的
• 数据均衡过程，不能影响Namenode的正常工作

数据均衡过程的核心是一个数据均衡算法，该数据均衡算法将不断迭代数据均衡逻辑，直至集群内数据均衡为止。该数据均衡算法每次迭代的逻辑如下：

（1）数据均衡服务（Rebalancing Server）首先要求 NameNode 生成 DataNode 数据分布分析报告,获取每个DataNode磁盘使用情况
（2）Rebalancing Server汇总需要移动的数据分布情况，计算具体数据块迁移路线图。数据块迁移路线图，确保网络内数据移动的路径最短
（3）开始数据块迁移任务，Proxy Source Data Node复制一块需要移动数据块
（4）将复制的数据块复制到目标DataNode上
（5）删除原始数据块
（6）目标DataNode向Proxy Source Data Node确认该数据块迁移完成
（7）Proxy Source Data Node向Rebalancing Server确认本次数据块迁移完成。然后继续执行这个过程，直至集群达到数据均衡标准

（1）HDFS会把当前的DataNode节点,根据阈值的设定情况划分到Over、Above、Below、Under四个组中。
（2）在移动数据块的时候，Over组、Above组中的块向Below组、Under组移动。

导致负载不均衡的原因：

（1）部分节点网络延迟大
（2）一些节点经常出现故障
（3）集群中增加了新的节点

当HDFS负载不均衡时，需要对HDFS进行数据的负载均衡调整，即对各节点机器上数据的存储分布进行调整。从而，让数据均匀的分布在各个DataNode上，均衡IO性能，防止热点的发生。HDFS为管理员提供了一个工具，用于分析数据块分布和重新均衡DataNode上的数据分布：

$HADOOP_HOME/bin/start-balancer.sh -t 10%

在这个命令中，-t参数后面跟的是HDFS达到平衡状态的磁盘使用率偏差值。如果机器与机器之间磁盘使用率偏差小于10%，那么我们就认为HDFS集群已经达到了平衡状态。

6、HDFS读文件

（1）客户端通过调用FileSystem对象的open()来读取希望打开的文件。

（2）DistributedFileSystem通过RPC来调用namenode，以确定文件的开头部分的块位置。对于每一块，namenode返回具有该块副本的datanode地址。DistributedFileSystem 返回一个FSDataInputStream对象给client读取数据，FSDataInputStream转而包装成一个DFSInputStream对象

（3）client对这个输入流调用read()方法。存储着文件开头部分的块的数据节点的地址DFSInputStream随即与这些块最近的datanode相连接。

（4）通过在数据流中反复调用read()，数据会从datanode返回client。

（5）到达块的末端时，DFSInputStream会关闭与datanode间的联系，然后为下一个块找到最佳的datanode。client端只需要读取一个连续的流，这些对于client来说都是透明的。

client在读取文件时，如果与datanode通信遇到错误，那么它就会去尝试对这个块来说下一个最近的块，并记住那个故障的datanode，以保证不会再对之后的块进行徒劳无益的尝试。

client也会确认datanode发来的数据的校验和。如果发现一个损坏的块，client在会试图从别的datanode中读取一个块的副本之前，将这个错误报告给namenode。

client检索数据时，总是被namenode指引到块中最好的datanode。（这里涉及到一个数据块选择算法）

集群中，namenode仅提供数据块的位置请求（存储在内存中，十分高效），不是提供数据。否则如果客户端数量增长，namenode就会快速成为一个“瓶颈”。

7、HDFS写文件

（1）客户端通过在DistributedFileSystem中调用create()来创建文件。

（2）DistributedFileSystem 使用RPC去调用namenode，在HDFS命名空间创一个新的文件。HDFS返回一个文件系统数据输出流FSDataOutputStream，让client开始写入数据。 FSDataOutputStream控制一个DFSOutputStream，负责处理datanode和namenode之间的通信。

（3）client写入数据时，DFSOutputStream将文件切分一个个的Block，对于每个block有分成一个个数据包写入数据队列。数据队列在数据节点管线中流动。

（4）对于任意一个数据包，首先写入管线中第一个的datanode，第一个节点会存储包并且发送给管线中的第二个datanode。同样地，第二个datanode存储包并且传给管线中的第三个数据节点。与此同时，client会将当前block的下一个包发给第一个datanode。

（5）DFSOutputStream也有一个内部的包队列来等待datanode收到确认。一个Block只有其所有的包在被管线中所有的节点确认后才会被移除出确认队列。

（6）client完成数据的写入后，就会在流中调用close()。

（7）向namenode节点发生写文件已经完成的消息。与此同步的，datanode主动向namenode汇报所存储文件块的位置信息