2023/11/5
分布式文件系统
传统的网络文件系统（NFS）
-
文件存储在单机上，无法提供可靠性暴躁。
-
很多客户端同时访问NFS Server时，容易造成服务器压力。
-
对文件修改时，得先同步到本地。在未同步到服务端之前，其他客户端是不可见的。
HDFS设计原则
设计目标
-
存储非常大的文件：指的是几百M、G或者TB级别。
-
采用流式的数据访问方式： HDFS基于这样的一个假设：最有效的数据处理模式是一次写入，多次读取数据集。经常从数据源生成或者拷贝一次，然后在其上做很多分析工作。 收集到部分数据就开始读取，而不是收集到全部数据再处理。如果一个文件太大，不需要把一个文件全部读到内存中，然后再做计算；只需要一小块一小块的读。（通过分块机制解决）
-
运行于商业硬件上：Hadoop不需要特别贵的、可靠的机器，可运行于普通商用机器。
HDFS不适合的应用类型
-
低延时的数据访问
-
大量小文件：文件的元数据（目录结构、文件block的节点列表，block-node mapping）保存在NameNode的内存中，整个文件系统的文件数量会受限于NameNode的内存大小。 经验而言，一个文件、目录、文件块一般占有150字节的元数据内存空间。
-
多方读写，需要任意的文件修改：HDFS采用追加（append-only）的方式写入数据，不支持文件任意offset的修改，不支持多个写入器（writer）。
HDFS核心概念
Blocks
-
默认大小为128M。
-
比Block小的文件不会占用整个Block，只会占据实际大小。
-
HDFS的Block为什么设置这么大：为了最小化查找时间。控制 定位文件与传输文件所用时间的比例。 如果Block设置过大。在MapReduce任务中，Map或者Reduce任务的个数如果小于进群机器数量，会使得作业运行效率很低。
-
Block抽象的好处：使得单个文件大小可以大于整个磁盘的容量。构成文件的Block可以分布在整个集群，理论上，单个文件可以占据集群中所有机器的磁盘。 Block的抽象也简化了存储系统，对于Block，无需关注其权限，所有者等内容。（这些内容都在文件级别上进行控制）。 Block作为容错和高可用机制中的副本单元，即以Block为单位进行复制。（如果某个数据块丢失或损坏，只需复制丢失或损坏的数据块，而不需要复制整个文件）
Namenode & Datanode
整个HDFS集群有Namenode和Datanode构成master-worker（主从）模式。Namenode负责构建命名空间，管理文件的元数据等。Datanode负责实际存储数据，负责读写工作。
Namenode
Namenode存放文件系统树及所有文件、目录的元数据。元数据持久化为2种：
-
namespace image
-
edit log
持久化数据中不包括Block所在的节点列表，及文件的Block分布在集群的哪些节点上。这些信息在系统重启的时候重新构建（通过Datanode汇报的Block信息）。
在HDFS中，Namenode可能成为集群的单点故障。有两种解决机制：
-
备份持久化数据
将文件系统的元数据同时写到多个文件系统，例如同时将元数据写到本地文件系统及NFS。这些备份操作都是同步的，原子的。
-
Secondary Namenode Secondary节点定期合并主Namenode的namespace image和edit log，避免edit log过大。通过创建检查的checkpoint来合并。它会维护一个合并后的namespace image副本，可用于在Namenode完全崩溃时恢复数据。 Secondary Namenode通常运行在另一台机器，因为合并操作需要耗费大量的CPU和内存。其数据落后于Namenode，因此当Namenode完全崩溃时，会出现数据丢失。通常做法是拷贝NFS中的备份元数据到Second，将其作为新的Namenode。 在HA（High Availability高可用性）中可以运行一个Hot Standby，作为热备份，在Active Namenode故障之后，替代原有Namenode成为Active Namenode
Datanode
