2.3　分布式文件系统

谈到分布式文件系统，不得不提Google的GFS。基于大量安装有Linux操作系统的普通PC构成的集群系统，整个集群系统由一台Master（通常有几台备份）和若干台TrunkServer构成。GFS中文件被分成固定大小的Trunk分别存储在不同的TrunkServer上，每个Trunk有多份（通常为3份）副本，也存储在不同的TrunkServer上。Master负责维护GFS中的Metadata，即文件名及其Trunk信息。客户端先从Master上得到文件的Metadata，根据要读取的数据在文件中的位置与相应的TrunkServer通信，获取文件数据。

1.HDFS的优点

HDFS（Hadoop Distributed File System）是Google的GFS文件系统的开源实现，HDFS的优点主要有：

1）处理超大文件

这里的超大文件通常是指百MB、甚至数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据。在雅虎Hadoop集群上已经扩展到4000个节点。

2）流式的访问数据

HDFS的设计建立在“一次写入、多次读/写”任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。

3）运行于廉价的商用机器集群上

Hadoop设计对硬件需求比较低，只须运行在低廉的商用硬件集群上，而无须在昂贵的高可用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。HDFS遇到了上述故障时，被设计成能够继续运行且不让用户察觉到明显的中断。典型的Hadoop集群物理架构如图2-3所示。

2.HDFS的局限性

基于以上优势考虑，HDFS在处理一些特定问题时不但没有优势，反而存在诸多局限性，它的局限性主要表现在以下3个方面。

1）不适合低延迟数据访问

如果要处理一些用户要求时间比较短的低延迟应用请求，则HDFS不适合。HDFS是为了处理大型数据集分析任务的，主要是为了达到高的数据吞吐量而设计的，这就可能要求以高延迟作为代价。

改进策略：对于那些有低延时要求的应用程序，HBase是一个更好的选择，通过上层数据管理项目尽可能地弥补这个不足。在性能上有了很大的提升，它的口号是goes real time。使用缓存或多个master设计可以降低Client的数据请求压力，以减少延时。

2）无法高效存储大量的小文件

因为NameNode把文件系统的元数据放置在内存中，所有文件系统所能容纳的文件数目由NameNode的内存大小决定。还有一个问题就是，因为MapTask的数量是由Splits来决定的，所以用MR处理大量的小文件时，就会产生过多的MapTask，线程管理开销将会增加作业时间。当hadoop处理很多小文件（文件小于HDFS中Block大小）的时候，由于FileInputFormat不会对小文件进行划分，所以每个小文件都会被当作一个Split并分配一个Map任务，导致效率低下。例如：一个1GB的文件，会被划分成16个64MB的Split，并分配16个Map任务处理，而10000个100KB的文件会被10000个Map任务处理。

改进策略：要想让HDFS能处理好小文件，有不少方法。利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。

3）不支持多用户写入及任意修改文件

在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作，目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。