HDFS（Hadoop Distributed File System）是GFS的开源实现。
HDFS架构
HDFS是一个典型的主/备（Master/Slave）架构的分布式系统，由一个名字节点Namenode(Master) +多个数据节点Datanode(Slave)组成。其中Namenode提供元数据服务，Datanode提供数据流服务，用户通过HDFS客户端与Namenode和Datanode交互访问文件系统。
如图3-1所示HDFS把文件的数据划分为若干个块（Block），每个Block存放在一组Datanode上，Namenode负责维护文件到Block的命名空间映射以及每个Block到Datanode的数据块映射。
▲图3-1 HDFS架构
HDFS客户端对文件系统进行操作时，如创建、打开、重命名等，Namenode响应请求并对命名空间进行变更，再返回相关数据块映射的Datanode，客户端按照流协议完成数据的读写。
- HDFS基本概念
HDFS架构比较简单，但涉及概念较多，其中几个重要的概念如下：
1. 块（Block）
Block是HDFS文件系统处理的最小单位，一个文件可以按照Block大小划分为多个Block，不同于Linux文件系统中的数据块，HDFS文件通常是超大文件，因此Block大小一般设置得比较大，默认为128MB。
2. 复制（Replica）
HDFS通过冗余存储来保证数据的完整性，即一个Block会存放在N个Datanode中，HDFS客户端向Namenode申请新Block时，Namenode会根据Block分配策略为该Block分配相应的Datanode replica，这些Datanode组成一个流水线（pipeline），数据依次串行写入，直至Block写入完成。
3. 名字节点（Namenode）
Namenode是HDFS文件系统的管理节点，主要负责维护文件系统的命名空间（Namespace）或文件目录树（Tree）和文件数据块映射（BlockMap），以及对外提供文件服务。
HDFS文件系统遵循POXIS协议标准，与Linux文件系统类似，采用基于Tree的数据结构，以INode作为节点，实现一个目录下多个子目录和文件。INode是一个抽象类，表示File/Directory的层次关系，对于一个文件来说，INodeFile除了包含基本的文件属性信息，也包含对应的Block信息。
数据块映射信息则由BlockMap负责管理，在Datanode的心跳上报中，将向Namenode汇报负责存储的Block列表情况，BlockMap负责维护BlockID到Datanode的映射，以方便文件检索时快速找到Block对应的HDFS位置。
HDFS每一步操作都以FSEditLog的信息记录下来，一旦Namenode发生宕机重启，可以从每一个FSEditLog还原出HDFS操作以恢复整个文件目录树，如果HDFS集群发生过很多变更操作，整个过程将相当漫长。
因此HDFS会定期将Namenode的元数据以FSImage的形式写入文件中，这一操作相当于为HDFS元数据打了一个快照，在恢复时，仅恢复FSImage之后的FSEditLog即可。
由于Namenode在内存中需要存放大量的信息，且恢复过程中集群不可用，HDFS提供HA（主/备Namenode实现故障迁移Failover）以及Federation（多组Namenode提供元数据服务，以挂载表的形式对外提供统一的命名空间）特性以提高稳定性和减少元数据压力。
4. Datanode
Datanode是HDFS文件系统的数据节点，提供基于Block的本地文件读写服务。定期向Namenode发送心跳。Block在本地文件系统中由数据文件及元数据文件组成，前者为数据本身，后者则记录Block长度和校验和（checksum）等信息。扫描或读取数据文件时，HDFS即使运行在廉价的硬件上，也能通过多副本的能力保证数据一致性。
5. FileSystem
HDFS客户端实现了标准的Hadoop FileSystem接口，向上层应用程序提供了各种各样的文件操作接口，在内部使用了DFSClient等对象并封装了较为复杂的交互逻辑，这些逻辑对客户端都是透明的。
HDFS读写流程
HDFS写流程
写详细步骤：
- 客户端向NameNode发出写文件请求。
- 检查是否已存在文件、检查权限。若通过检查，直接先将操作写入EditLog，并返回输出流对象。
（注：WAL，write ahead log，先写Log，再写内存，因为EditLog记录的是最新的HDFS客户端执行所有的写操作。如果后续真实写操作失败了，由于在真实写操作之前，操作就被写入EditLog中了，故EditLog中仍会有记录，我们不用担心后续client读不到相应的数据块，因为在第5步中DataNode收到块后会有一返回确认信息，若没写成功，发送端没收到确认信息，会一直重试，直到成功） - client端按128MB的块切分文件。
- client将NameNode返回的分配的可写的DataNode列表和Data数据一同发送给最近的第一个DataNode节点，此后client端和NameNode分配的多个DataNode构成pipeline管道，client端向输出流对象中写数据。client每向第一个DataNode写入一个packet，这个packet便会直接在pipeline里传给第二个、第三个…DataNode。
（注：并不是写好一个块或一整个文件后才向后分发） - 每个DataNode写完一个块后，会返回确认信息。
（注：并不是每写完一个packet后就返回确认信息，个人觉得因为packet中的每个chunk都携带校验信息，没必要每写一个就汇报一下，这样效率太慢。正确的做法是写完一个block块后，对校验信息进行汇总分析，就能得出是否有块写错的情况发生） - 写完数据，关闭输输出流。
- 发送完成信号给NameNode。
（注：发送完成信号的时机取决于集群是强一致性还是最终一致性，强一致性则需要所有DataNode写完后才向NameNode汇报。最终一致性则其中任意一个DataNode写完后就能单独向NameNode汇报，HDFS一般情况下都是强调强一致性）
HDFS客户端写流程详解
图3-2所示为客户端完成HDFS文件写入的主流程。
▲图3-2 客户端完成HDFS写入的主流程
1）创建文件并获得租约
HDFS客户端通过调用DistributedFileSystem# create来实现远程调用Namenode提供的创建文件操作，Namenode在指定的路径下创建一个空的文件并为该客户端创建一个租约（在续约期内，将只能由这一个客户端写数据至该文件），随后将这个操作记录至EditLog（编辑日志）。Namenode返回相应的信息后，客户端将使用这些信息，创建一个标准的Hadoop FSDataOutputStream输出流对象。
2）写入数据
HDFS客户端开始向HdfsData-OutputStream写入数据，由于当前没有可写的Block，DFSOutputStream根据副本数向Namenode申请若干Datanode组成一条流水线来完成数据的写入，如图3-3所示。
▲图3-3 流水线数据写入示意图
3）串行写入数据，直到写完Block
客户端的数据以字节（byte）流的形式写入chunk（以chunk为单位计算checksum（校验和））。若干个chunk组成packet，数据以packet的形式从客户端发送到第一个Datanode，再由第一个Datanode发送数据到第二个Datanode并完成本地写入，以此类推，直到最后一个Datanode写入本地成功，可以从缓存中移除数据包（packet），如图3-4所示。
▲图3-4 串行写入数据示意图
4）重复步骤2和步骤3，然后写数据包和回复数据包，直到数据全部写完。
5）关闭文件并释放租约
客户端执行关闭文件后，HDFS客户端将会在缓存中的数据被发送完成后远程调用Namenode执行文件来关闭操作。
Datanode在定期的心跳上报中，以增量的信息汇报最新完成写入的Block，Namenode则会更新相应的数据块映射以及在新增Block或关闭文件时根据Block映射副本信息判断数据是否可视为完全持久化（满足最小备份因子）。
HDFS读流程
读详细步骤：
- client访问NameNode，查询元数据信息，获得这个文件的数据块位置列表，返回输入流对象。
- 就近挑选一台datanode服务器，请求建立输入流 。
- DataNode向输入流中中写数据，以packet为单位来校验。
- 关闭输入流
HDFS客户端读流程详解
相对于HDFS文件写入流程，HDFS读流程相对简单，如图3-5所示。
▲图3-5 HDFS读流程
1）HDFS客户端远程调用Namenode，查询元数据信息，获得这个文件的数据块位置列表，返回封装DFSIntputStream的HdfsDataInputStream输入流对象。
2）客户端选择一台可用Datanode服务器，请求建立输入流。
3）Datanode向输入流中写原始数据和以packet为单位的checksum。
4）客户端接收数据。如遇到异常，跳转至步骤2，直到数据全部读出，而后客户端关闭输入流。当客户端读取时，可能遇到Datanode或Block异常，导致当前读取失败。正由于HDFS的多副本保证，DFSIntputStream将会切换至下一个Datanode进行读取。与HDFS写入类似，通过checksum来保证读取数据的完整性和准确性。
