这是我参与「第四届青训营 」笔记创作活动的第7天
1.HDFS架构原理
HDFS(Hadoop Distributed File System)是我们熟知的Hadoop分布式文件系统，是一个高容错的系统，能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS以流式数据访问模式存储超大文件，将数据按块分布式存储到不同机器上， 并被设计成 适合运行在普通廉价硬件之上。
2.HDFS架构
HDFS采用Master/Slave架构。一个HDFS集群有两个重要的角色，分别是Namenode和Datanode。Namenode是管理节点，负责管理文件系统的命名空间(namespace)以及客户端对文件的访问。Datanode是实际存储数据的节点。HDFS暴露了文件系统的命名空间，用户能够以操作文件的形式在上面操作数据。HDFS架构图如下：
HDFS上的文件是以数据块的形式存放的，这些数据块通常存储在一组Datanode上。Namenode执行文件系统的命名空间操作，比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理文件系统客户端的读写请求，并在Namenode的统一调度下执行数据块的创建、删除和复制。
3.HDFS元数据管理
Namenode上保存着HDFS的命名空间。对于任何对文件系统元数据产生修改的操作，Namenode都会使用一种称为EditLog的事务日志记录下来。例如，在HDFS中创建一个文件，Namenode就会在Editlog中插入一条记录来表示;同样地，修改文件的副本系数也将往Editlog插入一条记录。Namenode在本地操作系统的文件系统中存储这个Editlog。整个文件系统的命名空间，包括数据块到文件的映射、文件的属性等，都存储在一个称为FsImage的文件中，这个文件也是放在Namenode所在的本地文件系统上。
Namenode在内存中保存着整个文件系统的命名空间和文件数据块映射(Blockmap)的映像。当Namenode启动，或者检查点被周期性触发时，它从硬盘中读取Editlog和FsImage，将所有Editlog中的事务作用在内存中的FsImage上，并将这个新版本的FsImage从内存持久化到本地磁盘上。然后HDFS删除旧的Editlog，因为这个旧 的Editlog的事务都已经作用在FsImage上了。这个过程被称为一个 检查点 (checkpoint)。 在检查点期间，Editlog的更改将应用于FsImage。 checkpoint 触发时机 ，可以是以给定的时间间隔(dfs.namenode.checkpoint.period，单位秒)触发，或者在给定数量的文件系统事务累积之后(dfs.namenode.checkpoint.txns)触发。 如果设置了这两个属性，则要达到的第一个阈值将触发检查点。
4.HDFS应用场景
适合的应用场景：
- 存储非常大的文件：这里非常大指的是成百上千 MB、GB，甚至 TB 级别的文件，需要高吞吐量，对延时没有要求。
- 采用流式的数据访问方式：即 一次写入、多次读取，数据集经常从数据源生成或者拷贝一次，然后在其上做很多分析工作。
- 运行于廉价的硬件上：不需要性能特别高的机器，可运行于普通廉价机器，节约成本。
- 需要高容错性，HDFS 有多副本机制，丢失/损坏一定个数的副本后，不影响文件的完整性。
- 用作数据存储系统，方便横向扩展。 不适合的应用场景：
- 低延时的数据访问：对延时要求在毫秒级别的应用，不适合采用 HDFS。HDFS 是为高吞吐数据传输设计的，延时较高。
- 大量小文件：HDFS 系统中，文件的元数据保存在 NameNode 的内存中， 文件数量会受限于 NameNode 的内存大小。
- 多方读写，需要任意的文件修改：HDFS采用追加（append-only）的方式写入数据。不支持文件任意 offset 的修改，也不支持多个写入器（writer）
个人总结：通过这节课，我主要学到了HDFS的原理，基本架构，以及应用场景等
