HDFS的设计——两大一小+又多又快

HDFS的设计——两大一小+又多又快

HDFS是为以流式数据访问模式存储超大文件而设计的文件系统，在商用硬件的集群上运行。让我们仔细看看下面的明。

超大文件   

"超大文件"在这里指几百MB，几百GB甚至几百TB大小的文件。目前已经有Hadoop集群存储PB(petabytes)级的数据了。

流式数据访问   

HDFS建立在这样一个思想上：一次写入、多次读取模式是最高效的。一个数据集通常由数据源生成或复制，接着在此基础上进行各种各样的分析。每个分析至少都会涉及数据集中的大部分数据 (甚至全部)，因此读取整个数据集的时间比读取第一条记录的延迟更为重要。

商用硬件   

Hadoop不需要运行在昂贵并且高可靠性的硬件上。它被设计运行在商用硬件(在各种零售店都能买到的普通硬件)的集群上，因此至少对于大的集群来说，节点故障的几率还是较高的。HDFS在面对这种故障时，被设计为能够继续运行而让用户察觉不到明显的中断。

同时，那些并不适合HDFS的应用也是值得研究的。在目前，HDFS还不太适用于某些领域，不过日后可能会有所改进。

低延迟数据访问   

需要低延迟访问数据在毫秒范围内的应用并不适合HDFS。HDFS是为达到高数据吞吐量而优化的，这有可能会以延迟为代价。目前，对于低延迟访问，HBase(参见第12章)是更好的选择。

大量的小文件   

名称节点(namenode)存储着文件系统的元数据，因此文件数量的限制也由名称节点的内存量决定。根据经验，每个文件，索引目录以及块占大约150个字节。因此，举例来说，如果有一百万个文件，每个文件占一个块，就至少需要300 MB的内存。虽然存储上百万的文件是可行的，十亿或更多的文件就超出目前硬件的能力了。

多用户写入，任意修改文件  

HDFS中的文件只有一个写入者，而且写操作总是在文件的末尾。它不支持多个写入者，或是在文件的任意位置修改。(可能在以后这些会被支持，但它们也相对不那么高效。