数据词典：Hadoop分布式文件系统（Hadoop Distributed File System）

赵老师

Hadoop分布式文件系统HDFS开源实现了GFS的基本思想。HDFS原来是Apache Nutch搜索引擎的一部分，后来独立出来作为一个Apache子项目，并和MapReduce一起成为Hadoop的核心组成部分。HDFS支持流数据读取和处理超大规模文件，并能够运行在由廉价的普通机器组成的集群上，这主要得益于HDFS在设计之初就充分考虑了实际应用环境的特点，那就是，硬件出错在普通服务器集群中是一种常态，而不是异常。因此，HDFS在设计上采取了多种机制保证在硬件出错的环境中实现数据的完整性。总体而言，HDFS要实现以下目标：

1．兼容廉价的硬件设备。在成百上千台廉价服务器中存储数据，常会出现节点失效的情况，因此HDFS设计了快速检测硬件故障和进行自动恢复的机制，可以实现持续监视、错误检查、容错处理和自动恢复，从而使得在硬件出错的情况下也能实现数据的完整性。

2．流数据读写。普通文件系统主要用于随机读写以及与用户进行交互，而HDFS则是为了满足批量数据处理的要求而设计的，因此为了提高数据吞吐率，HDFS放松了一些POSIX的要求，从而能够以流式方式来访问文件系统数据。

3．大数据集。HDFS中的文件通常可以达到GB甚至TB级别，一个数百台机器组成的集群里面可以支持千万级别这样的文件。

4．简单的文件模型。HDFS采用了“一次写入、多次读取”的简单文件模型，文件一旦完成写入，关闭后就无法再次写入，只能被读取。

5．强大的跨平台兼容性。HDFS是采用Java语言实现的，具有很好的跨平台兼容性，支持JVM（Java Virtual Machine）的机器都可以运行HDFS。

HDFS特殊的设计，在实现上述优良特性的同时，也使得自身具有一些应用局限性，主要包括以下几个方面：

1．不适合低延迟数据访问。HDFS主要是面向大规模数据批量处理而设计的，采用流式数据读取，具有很高的数据吞吐率，但是，这也意味着较高的延迟。因此，HDFS不适合用在需要较低延迟（如数十毫秒）的应用场合。对于低延时要求的应用程序而言，HBase是一个更好的选择。

2．无法高效存储大量小文件。小文件是指文件大小小于一个块的文件，HDFS无法高效存储和处理大量小文件，过多小文件会给系统扩展性和性能带来诸多问题。首先，HDFS采用名称节点（NameNode）来管理文件系统的元数据，这些元数据被保存在内存中，从而使客户端可以快速获取文件实际存储位置。通常，每个文件、目录和块大约占150字节，如果有1 000万个文件，每个文件对应一个块，那么，名称节点至少要消耗3 GB的内存来保存这些元数据信息。很显然，这时元数据检索的效率就比较低了，需要花费较多的时间找到一个文件的实际存储位置。而且，如果继续扩展到数十亿个文件时，名称节点保存元数据所需要的内存空间就会大大增加，以现有的硬件水平，是无法在内存中保存如此大量的元数据的。其次，用MapReduce处理大量小文件时，会产生过多的Map任务，线程管理开销会大大增加，因此处理大量小文件的速度远远低于处理同等大小的大文件的速度。再次，访问大量小文件的速度远远低于访问几个大文件的速度，因为访问大量小文件，需要不断从一个数据节点跳到另一个数据节点，严重影响性能。

3．不支持多用户写入及任意修改文件。HDFS只允许一个文件有一个写入者，不允许多个用户对同一个文件执行写操作，而且只允许对文件执行追加操作，不能执行随机写操作。

【出处】林子雨.大数据技术原理与应用（第3版）.人民邮电出版社，2021年1月.