SecondaryNameNode和DataNode的目录结构

SecondaryNameNode目录结构

SecondaryNameNode的目录结构和NameNode的目录结构一样。为啥要这么设计呢？主要的优点在于当NameNode发生故障的时候，我们可以从SecondaryNameNode恢复数据。恢复的方式有两种：

1. 将相关的目录复制到NameNode的目录中，然后重启NameNode。
2. 使用-importCheckpoint选项启动NameNode，但是这种方式只有在NameNode的目录中没有元数据的时候才会有用。

DataNode的目录结构

data/
├── current
│   ├── BP-1627059714-192.168.142.9-1544608355749
│   │   ├── current
│   │   │   ├── dfsUsed
│   │   │   ├── finalized
│   │   │   │   └── subdir0
│   │   │   │       └── subdir0
│   │   │   │           ├── blk_1073741825
│   │   │   │           ├── blk_1073741825_1001.meta
│   │   │   │           ├── blk_1073741831
│   │   │   │           ├── blk_1073741831_1010.meta
│   │   │   │           ├── blk_1073741832
│   │   │   │           ├── blk_1073741832_1011.meta
│   │   │   │           ├── blk_1073741833
│   │   │   │           ├── blk_1073741833_1012.meta
│   │   │   │           ├── blk_1073741834
│   │   │   │           ├── blk_1073741834_1013.meta
│   │   │   │           ├── blk_1073741842
│   │   │   │           ├── blk_1073741842_1021.meta
│   │   │   │           ├── blk_1073741843
│   │   │   │           └── blk_1073741843_1022.meta
│   │   │   ├── rbw
│   │   │   └── VERSION
│   │   ├── scanner.cursor
│   │   └── tmp
│   └── VERSION
└── in_use.lock

我们的数据实际上都是存储在以blk_为前缀的文件中，文件名包含了该文件存储的块的原始字节数，每个块还带有一个相关联的以.meta为后缀的文件，这个文件包括头部（含版本和类型信息）和该区块各区段的一系列的校验和。
当目录中数据块的数量到达一定的规模的时候（可通过dfs.datanode.numblocks属性设置，默认为64）就会创建一个子目录。