obsidian-sync/日常学习/大数据/Hadoop/HDFS基础.md

一、概述

“HDFS(Hadoop Distributed File System)基于Google发布的GFS论文设计开发。HDFS是Hadoop技术框架中的分布式文件系统，对部署在多台独立物理机器上的文件进行管理。

!

1.1 优缺点及设计特点

1.1.1 优点

1. 大数据文件，非常适合上T级别的大文件或者一堆大数据文件的存储，如果文件只有几个G甚至更小就没啥意思了。
2. 文件分块存储，HDFS会将一个完整的大文件平均分块存储到不同计算器上，它的意义在于读取文件时可以同时从多个主机取不同区块的文件，多主机读取比单主机读取效率要高得多得都。
3. 流式数据访问，一次写入多次读写，这种模式跟传统文件不同，它不支持动态改变文件内容，而是要求让文件一次写入就不做变化，要变化也只能在文件末添加内容。
4. 廉价硬件，HDFS可以应用在普通PC机上，这种机制能够让给一些公司用几十台廉价的计算机就可以撑起一个大数据集群。
5. 硬件故障，HDFS认为所有计算机都可能会出问题，为了防止某个主机失效读取不到该主机的块文件，它将同一个文件块副本分配到其它某几个主机上，如果其中一台主机失效，可以迅速找另一块副本取文件。

1.1.2 缺点

1. 低时间延迟数据访问的应用，例如几十毫秒范围。 原因：HDFS是为高数据吞吐量应用优化的，这样就会造成以高时间延迟为代价。
2. 大量小文件 。 原因：NameNode启动时，将文件系统的元数据加载到内存，因此文件系统所能存储的文件总数受限于NameNode内存容量。，那么需要的内存空间将是非常大的。
3. 多用户写入，任意修改文件。 原因：现在HDFS文件只有一个writer，而且写操作总是写在文件的末尾。

1.2 HDFS架构

! HDFS架构包含三个部分：NameNode，DataNode，Client。（图中Secondary NameNode也属于NameNode，是备节点)

• NameNode：NameNode用于存储、生成文件系统的元数据。管理数据块映射；处理客户端的读写请求；配 置副本策略；管理 HDFS 的名称空间。 NameNode 保存的 metadata 包括：
  • 文件 ownership 和 permission
  • 文件包含的 block 信息（Block 保存在DataNode 节点上）
• DataNode：DataNode用于存储实际的数据，将自己管理的数据块上报给NameNode ，负责存储client发来的数据块；执行数据块读写操作。
• Client：支持业务访问HDFS，从NameNode ,DataNode获取数据返回给业务。多个实例，和业务一起运行。

1.3 读数据流程

!

1. 业务应用调用HDFS Client提供的API打开文件。
2. HDFS Client联系NameNode，获取到文件信息（数据块、DataNode位置信息）。
3. 业务应用调用read API读取文件。
4. HDFS Client根据从NameNode获取到的信息，联系DataNode，获取相应的数据块。(Client采用就近原则读取数据)。
5. HDFS Client会与多个DataNode通讯获取数据块。
6. 数据读取完成后，业务调用close关闭连接。

1.4 写数据流程

!

1. 业务应用调用HDFS Client提供的API，请求写入文件。
2. HDFS Client联系NameNode，NameNode在元数据中创建文件节点。
3. 业务应用调用write API写入文件。
4. HDFS Client收到业务数据后，从NameNode获取到数据块编号、位置信息后，联系DataNode，并将需要写入数据的DataNode建立起流水线。完成后，客户端再通过自有协议写入数据到DataNode1，再由DataNode1复制到DataNode2, DataNode3。
5. 写完的数据，将返回确认信息给HDFS Client。
6. 所有数据确认完成后，业务调用HDFS Client关闭文件。
7. 业务调用close, flush后HDFSClient联系NameNode，确认数据写完成，NameNode持久化元数据。

二、HDFS 关键特性

!

2.1 HA高可靠性

• HDFS的高可靠性（HA）主要体现在利用zookeeper实现主备NameNode，以解决单点NameNode故障问题。
• ZooKeeper主要用来存储HA下的状态文件，主备信息。ZK个数建议3个及以上且为奇数个。
• NameNode主备模式，主提供服务，备同步主元数据并作为主的热备。
• ZKFC(ZooKeeper Failover Controller)用于监控NameNode节点的主备状态。
• JN(JournalNode)用于存储Active NameNode生成的Editlog。Standby NameNode加载JN上Editlog，同步元数据。

2.2 ZKFC控制NameNode主备仲裁

• ZKFC作为一个精简的仲裁代理，其利用zookeeper的分布式锁功能，实现主备仲裁，再通过命令通道，控制NameNode的主备状态。ZKFC与NN部署在一起，两者个数相同。

2.3 元数据同步

• 主NameNode对外提供服务。生成的Editlog同时写入本地和JN，同时更新主NameNode内存中的元数据。
• 备NameNode监控到JN上Editlog变化时，加载Editlog进内存，生成新的与主NameNode一样的元数据。元数据同步完成。
• 主备的FSImage仍保存在各自的磁盘中，不发生交互。FSImage是内存中元数据定时写到本地磁盘的副本，也叫元数据镜像。

2.4 元数据持久化

• EditLog:记录用户的操作日志，用以在FSImage的基础上生成新的文件系统镜像。
• FSImage:用以阶段性保存文件镜像。
• FSImage.ckpt:在内存中对fsimage文件和EditLog文件合并（merge）后产生新的fsimage，写到磁盘上，这个过程叫checkpoint.。备用NameNode加载完fsimage和EditLog文件后，会将merge后的结果同时写到本地磁盘和NFS。此时磁盘上有一份原始的fsimage文件和一份新生成的checkpoint文件：fsimage.ckpt. 而后将fsimage.ckpt改名为fsimage（覆盖原有的fsimage）。
• EditLog.new: NameNode每隔1小时或Editlog满64MB就触发合并,合并时,将数据传到Standby NameNode时,因数据读写不能同步进行,此时NameNode产生一个新的日志文件Editlog.new用来存放这段时间的操作日志。Standby NameNode合并成fsimage后回传给主NameNode替换掉原有fsimage,并将Editlog.new 命名为Editlog。