9 HDFS架构剖析

问题

100台服务器，存储空间单个200GB 20T
5T文件如何存储？
128MB一块 128MB8=1GB 1288*1024=1TB
5T数据分成的128MB的块数 = 8192 * 5


客户端(client)代表用户通过与namenode和datanode交互来访问整个文件系统。

HDFS集群有两类节点：
一个namenode(管理节点)和多个datanode(工作节点）。
namenode管理文件系统的命名空间。它维护着文件系统树及整棵树内的所有文件和目录。这些信息以两个文件形式永久保存在本地磁盘上：命名空间**镜像文件(fsimage)和编辑日志(edits log)**文件。

namenode也记录着每个文件中各个块所在的dataNode信息，但是它并不会永久保存块的位置信息，因为这些信息会在系统启动时根据数据节点信息重建。
4
之后DataNode会周期性地通过心跳包向NameNode报告block信息。DataNode向NameNode注册的时候NameNode请求DataNode发送block列表信息。

1、NameNode

NameNode在内存中保存着整个文件系统的名字空间和文件数据块的地址映射(Blockmap)。是整个文件系统的管理节点。
如果NameNode宕机，那么整个集群就瘫痪了。因此，对namenode实现容错非常重要，Hadoop 为此提供两种机制。
①备份：
备份那些组成文件系统元数据的文件，Hadoop可以通过配置使namenode在多个文件系统上保存元数据的持久状态。这些写操作是实时同步的，且是原子操作。一般的配置是，将持久状态写入本地磁盘的同时，写入一个远程挂载的网络文件系统(NFS)。
②辅助namenode：
运行一个辅助namenode,但它不能被用作namenode。这个辅助namenode的重要作用是定期合并编辑日志与命名空间镜像，以防止编辑日志过大。这个辅助namenode一般在另一台单独的物理计算机上运行，因为它需要占用大量CPU时间，并且需要与namenode一样多的内存来执行合并操作。它会保存合并后的命名空间镜像的副本，并在namenode 发生故障时启用。但是，辅助namenode保存的状态总是滞后于主节点，所以在主节点全部失效时，难免会丢失部分数据。在这种情况下，一般把存储在 NFS上的namenode元数据复制到辅助namenode并作为新的主namenode 运行。

1. 文件和目录的元数据：(运行时，元数据放内存)
   文件的block副本个数
   修改和访问的时间
   访问权限
   block大小以及组成文件的block信息列表
2. NameNode的目录结构,该目录结构在第一次格式化的时候创建.

├── current
│   ├── edits_0000000000000000001-0000000000000000125
│   ├── edits_0000000000000000126-0000000000000000344
│   ├── edits_0000000000000000345-0000000000000000386
│   ├── edits_0000000000000000387-0000000000000000388
│   ├── edits_0000000000000000389-0000000000000000484
│   ├── edits_0000000000000000485-0000000000000000566
│   ├── edits_0000000000000000567-0000000000000000568
│   ├── edits_inprogress_0000000000000000569
│   ├── fsimage_0000000000000000566
│   ├── fsimage_0000000000000000566.md5
│   ├── fsimage_0000000000000000568
│   ├── fsimage_0000000000000000568.md5
│   ├── seen_txid
│   └── VERSION
└── in_use.lock
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

其中VERSION是一个JAVA属性文件，其中包含正在运行的HDFS的版本信息,内容如下：

[root@hadoop001 current]# vi VERSION
#Tue Aug 14 19:59:14 PDT 2018
//namespaceID是该文件系统的唯一标志符，当NameNode第一次格式化的时候生成
namespaceID=672644148
//clusterID是将HDFS集群作为一个整体赋予的唯一标识符，当一个集群拥有多个namenode时，数值相同
clusterID=CID-c49b4913-f14f-43d2-bffd-740d6021cc3c
//cTime标记着当前NameNode创建的时间。对于刚格式化的存储，该值永远是0，但是当文件系统更新的时候，这个值就会更新为一个时间戳
cTime=0
//storageType表示当前目录存储NameNode内容的数据结构
storageType=NAME_NODE
//blockpoolID是block池的唯一标志符，一个NameNode管理一个命名空间，该命名空间中的所有文件存储的block都在block池中。
blockpoolID=BP-1958150420-192.168.170.131-1534301954910
/*
1.layoutVersion是一个负数，定义了HDFS持久化数据结构的版本
2.这个版本数字跟hadoop发行的版本无关.
3.当layout改变的时候，该数字减1（比如从-57到-58）
4.当对HDFDS进行了升级，就会发生layoutVersion的改变.
*/
layoutVersion=-60
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

//namenode的本地目录可以配置成多个，且每个目录存放内容相同，增加了可靠性
//尤其是当其中一个是挂载的NFS的时候，这种机制为管理提供了一些弹性。备份数据.
1.如果属性dfs.namenode.name.dir指定了多个路径，则每个路径中的内容是一样的;
2.in_use.lock文件用于NameNode锁定存储目录。这样就防止其他同时运行的NameNode实例使用相同的存储目录.
3.edits表示edits log日志文件
4.fsimage表示文件系统元数据镜像文件.
5.NameNode在checkpoint之前首先要切换新的edits log文件，在切换时更新seen_txid的值。上次合并fsimage和editslog之后的第一个操作编号.
1
2
3
4
5
6
7

3. 操作流程

1.当客户端进行了写操作（例如创建或移动了文件），这个事务首先在edits log中记录下来。
2.NameNode在内存中有文件系统的元数据，当edits log记录结束后，就更新内存中的元数据。内存中的元数据用于响应客户端的读请求。
3.edits log在磁盘上表现为一定数量的文件。每个文件称为片段（Segment），前缀“edits”，后缀是其中包含的事务ID（transaction IDs）。
4.每个写操作事务都仅仅打开一个文件（比如：edits_inprogress_00000000000010），写完后冲刷缓冲区并同步到磁盘，然后返回客户端success状态码。
5.如果NameNode的元数据需要写到多个目录中，则对于每个写事务需要所有的写操作都完成，并冲刷缓冲区同步到磁盘才返回success状态码。这样就可以保证在发生宕机的时候没有事务数据丢失。
1
2
3
4
5

用户的操作是一个事务，每个操作NN都要先将操作记录到edits log中，如果给NN指定了多个目录，则在多个目录中都存在edits log文件，用户的操作要在多个目录中都写完成，才让NN同步数据到内存中。当NN在内存中也同步了数据，就返回客户端success。
每个fsimage文件都是系统元数据的一个完整的持久化检查点（checkpoint）（后缀表示镜像中的最后一个事务）。写操作不更新这个数据，因为镜像文件通常为GB数量级，写到磁盘很慢。如果NameNode宕机，可以将最新fsimage加载到内存，同时执行edits log对应于该fsimage之后的操作，就可以重建元数据的状态。而这正是每次启动NameNode的时候NameNode要做的工作。

2、SecondaryNameNode