SecondaryNameNode目录结构
SecondaryNameNode的目录结构和NameNode的目录结构一样。为啥要这么设计呢？主要的优点在于当NameNode发生故障的时候，我们可以从SecondaryNameNode恢复数据。恢复的方式有两种：
- 将相关的目录复制到NameNode的目录中，然后重启NameNode。
- 使用-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）就会创建一个子目录。
