分布式文件系统HDFS

HDFS全称为Hadoop Distributed File System，是整个Hadoop平台上的两大核心组件之一
在这里插入图片描述
HDFS用于解决海量数据的分布式存储问题

计算机集群结构

分布式文件系统把文件分布存储到多个计算机节点上，成千上万的计算机节点构成计算机集群
与之前使用多个处理器和专用高级硬件的并行化处理装置不同的是，目前的分布式文件系统所采用的计算机集群，都是由普通硬件构成的，这就大大降低了硬件上的开销

机架内部的机器通过光纤高速交换机进行连接，机架和机架之间通过带宽更高的几个光纤交换机来完成彼此之间的交互和连接

分布式文件系统的结构

分布式文件系统在物理结构上是由计算机集群中的多个节点构成的，这些节点分为两类，一类叫“主节点”(Master Node)或者也被称为“名称结点”(NameNode)，另一类叫“从节点”（Slave Node）或者也被称为“数据节点”(DataNode)一个作为主节点，其余作为从节点，主节点承担起数据目录（元数据）服务，从节点要具体完成数据的存储任务
在这里插入图片描述

HDFS简介

HDFS要实现以下目标：

兼容廉价的硬件设备
流数据读写
大数据集
简单的文件模型
强大的跨平台兼容性

传统的文件系统在进行数据读写的时候是以块数据为单位，每一次可以读取指定的某一部分数据，而HDFS设计的目标就是对大量数据的读写，不会访问某个文件的子集或去访问一块一块的数据
HDFS支持简单的文件模型支持高效的数据读写，能快速处理批量的数据集，只允许追加数据，不允许修改数据

HDFS特殊的设计，在实现上述优良特性的同时，也使得自身具有一些应用局限性，主要包括以下几个方面：

不适合低延迟数据访问
无法高效存储大量小文件
不支持多用户写入及任意修改文件

HDFS不能满足实时的数据处理需求，分布式数据库HBase具备随机读写特性，可以满足实时性处理需求

块（整个HDFS中最核心的概念）

与普通的文件系统的区别：
在这里插入图片描述

HDFS默认一个块64MB，一个文件被分成多个块，以块作为存储单位块的大小远远大于普通文件系统，可以最小化寻址开销
HDFS采用抽象的块概念可以带来以下几个明显的好处：

支持大规模文件存储：文件以块为单位进行存储，一个大规模文件可以被分拆成若干个文件块，不同的文件块可以被分发到不同的节点上，因此，一个文件的大小不会受到单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量
简化系统设计：首先，大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块；其次，方便了元数据的管理，元数据不需要和文件块一起存储，可以由其他系统负责管理元数据
适合数据备份：每个文件块都可以冗余存储到多个节点上，大大提高了系统的容错性和可用性

名称节点和数据节点

在这里插入图片描述
名称节点（NameNode）：

存储元数据
元数据保存在内存中
保存文件，block，datanode之间的映射关系

数据节点（DataNode）：

存储文件内容
文件内容保存在磁盘
维护了block id到datanode本地文件的映射关系

在这里插入图片描述

在HDFS中，名称节点（NameNode）负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构，即FsImage和EditLog

FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据
操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作

名称节点记录了每个文件中各个块所在的数据节点的位置信息
在这里插入图片描述

FsImage文件

FsImage文件包含文件系统中所有目录和文件inode的序列化形式。每个inode是一个文件或目录的元数据的内部表示，并包含此类信息：文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块。对于目录，则存储修改时间、权限和配额元数据
FsImage文件没有记录块存储在哪个数据节点。而是由名称节点把这些映射保留在内存中，当数据节点加入HDFS集群时，数据节点会把自己所包含的块列表告知给名称节点，此后会定期执行这种告知操作，以确保名称节点的块映射是最新的。
在这里插入图片描述

名称节点的启动

在名称节点启动的时候，它会将FsImage文件中的内容加载到内存中，之后再执行EditLog文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作。
一旦在内存中成功建立文件系统元数据的映射，则创建一个新的FsImage文件和一个空的EditLog文件
名称节点起来之后，HDFS中的更新操作会重新写到EditLog文件中，因为FsImage文件一般都很大（GB级别的很常见），如果所有的更新操作都往FsImage文件中添加，这样会导致系统运行的十分缓慢，但是，如果往EditLog文件里面写就不会这样，因为EditLog 要小很多。每次执行写操作之后，且在向客户端发送成功代码之前，edits文件都需要同步更新

名称节点运行期间EditLog不断变大的问题

在名称节点运行期间，HDFS的所有更新操作都是直接写到EditLog中，久而久之， EditLog文件将会变得很大
虽然这对名称节点运行时候是没有什么明显影响的，但是，当名称节点重启的时候，名称节点需要先将FsImage里面的所有内容映像到内存中，然后再一条一条地执行EditLog中的记录，当EditLog文件非常大的时候，会导致名称节点启动操作非常慢，而在这段时间内HDFS系统处于安全模式，一直无法对外提供写操作，影响了用户的使用

如何解决？答案是：SecondaryNameNode第二名称节点

第二名称节点是HDFS架构中的一个组成部分，它是用来保存名称节点中对HDFS 元数据信息的备份，并减少名称节点重启的时间。SecondaryNameNode一般是单独运行在一台机器上
在这里插入图片描述
SecondaryNameNode的工作情况：

SecondaryNameNode会定期和NameNode通信，请求其停止使用EditLog文件，暂时将新的写操作写到一个新的文件edit.new上来，这个操作是瞬间完成，上层写日志的函数完全感觉不到差别；
SecondaryNameNode通过HTTP GET方式从NameNode上获取到FsImage和EditLog文件，并下载到本地的相应目录下；
SecondaryNameNode将下载下来的FsImage载入到内存，然后一条一条地执行EditLog文件中的各项更新操作，使得内存中的FsImage保持最新；这个过程就是EditLog和FsImage文件合并；
SecondaryNameNode执行完操作3之后，会通过post方式将新的FsImage
文件发送到NameNode节点上NameNode将从SecondaryNameNode接收到的新的FsImage替换旧的FsImage文件，同时将edit.new替换EditLog文件，通过这个过程EditLog就变小了

在这里插入图片描述