一文读懂为什么HDFS更适合存储大文件

HDFS（分布式文件系统）是大数据生态圈中不可或缺的一部分，作为大数据生态圈中的存储层，HDFS能够存储结构及非结构化的数据，数据吞吐量大但延时较高，一般用于离线批处理。此外，由于其架构设计，HDFS更适合存储大文件。要了解为什么HDFS更适合存储大文件，首先需要了解其架构设计。

HDFS采用主从架构设计，由NameNode、SecondaryNameNode及DataNode组成。其中，NameNode为主节点，负责维护文件系统命名空间，DataNode为工作节点，负责数据存储及心跳机制（定时向NameNode发送心跳），SecondaryNameNode为备份节点，定时合并NameNode中的元数据信息。

DataNode主要负责文件的存储，其基本存储单位为数据块（block，一般为128M）。DataNode数据块比磁盘的块（512B）大，其目的是为了最小化寻址开销，如果块足够大，从磁盘传输数据的时间会明显大于定位这个块开始位置需要的时间。为了防止数据丢失，HDFS会对block进行数据备份，在其他的DataNode节点上拷贝一份相同的block（备份数默认为3）。数据备份节点选择采用机架感知策略，第一个副本在客户端相同的节点（如果客户端是集群外的一台机器，就随机选择节点，但是系统会避免挑选太满或太忙的节点），第二个副本放在随机选择的不同机架的节点上，第三个副本放在与第二个副本同机架的另一个节点上。

root@test:~/hadoop/tmp/dfs# tree name
name
├── current
│   ├── edits_0000000000000000001-0000000000000000002
│   ├── edits_0000000000000000003-0000000000000000003
│   ├── edits_0000000000000000004-0000000000000000005
│   ├── edits_0000000000000000006-0000000000000000006
│   ├── edits_0000000000000000007-0000000000000000008
│   ├── edits_0000000000000000009-0000000000000000010
│   ├── edits_0000000000000000011-0000000000000000012
│   ├── edits_0000000000000000013-0000000000000000014
│   ├── edits_0000000000000000015-0000000000000000016
│   ├── edits_0000000000000000017-0000000000000000018
│   ├── edits_0000000000000000019-0000000000000000020
│   ├── edits_inprogress_0000000000000000021
│   ├── fsimage_0000000000000000000
│   ├── fsimage_0000000000000000000.md5
│   ├── fsimage_0000000000000000020
│   ├── fsimage_0000000000000000020.md5
│   ├── seen_txid
│   └── VERSION
└── in_use.lock

NameNode负责维护文件系统树及整棵树内所有的文件和目录。NameNode保存元信息的种类包括文件目录之间的层级关系、文件目录的所有者及其权限、每个文件块的名称及文件由那些块组成。NameNode元信息保存在内存中，NameNode元信息并不包括每个块的位置信息，而是保存文件、block及DataNode之间的映射关系。

一般来说，一条元信息记录会占用200byte内存空间。假设块大小为64M，备份数量是3，那么1G大小的文件将占用16*3个文件块。如果现在有1000个1M大小的文件，则会占用1000*3个文件块（多个文件不能放到一个块中）。可以发现，文件越小，存储同等大小的文件所需的元信息就越多，对NameNode内存要求更大。因此，HDFS更适合存储大文件。