-
当前HDFS实现的主要局限在于单个NameNode。由于所有文件元数据都保存在内存中，因此NameNode的内存量决定了hadoop集 群上可用文件的数量。为克服单个NameNode内存的限制并能够水平地扩展名称服务，Hadoop 0.23引入了HDFS联盟(HDFS Federation)，它基于多个独立的NameNode/名称空间。
以下是HDFS联盟的主要优势：
名称空间可扩展性——HDFS集群存储可以水平扩展，但名称空间不能。通过向集群添加更多的NameNode来扩展名称空间，大规模部署(或者使用大量小文件的部署)会因此受益。
性能——文件系统操作的吞吐量受到单个NameNode的限制。向集群添加更多的NameNode可以扩展文件系统读/写操作的吞吐量。
隔离——在多用户环境下，单个NameNode无法支持隔离。实验性应用可能会让NameNode过载，并拖慢关键的生产应用。使用多个NameNode，可以将不同类别的应用和用户隔离到不同的名称空间。
如图2-5所示，HDFS联盟的实现基于多个独立NameNode的汇集，它们之间不需要进行协调。所有NameNode均将DataNode作为 公共存储，用于保存块。每个DataNode都会向集群中的所有NameNode注册。DataNode周期性地发送心跳和块报告，并处理来自 NameNode的命令。
名称空间在块的集合——块池——上操作。尽管块池只能用于特定的名称空间，但实际的数据可以被分配到集群中的任意DataNode上。每个块池都是 独立管理的，这允许名称空间在不必与其他名称空间协调的情况下为新块生成块ID。某个NameNode的失效不会影响DataNode服务集群中的其他 NameNode。
名称空间和其块池一起被称为名称空间卷。这是一个自包含的管理单元。当删除NameNode/名称空间时，DataNode上相对应的块池也会被删除。在集群升级时，每个名称空间卷会被作为一个单元来升级。
HDFS联盟的配置是向后兼容的，且允许已有的单一NameNode配置能够在不进行任何改动的情况下正常工作。新配置的设计使得集群中所有节点的配置相同，不必根据其中节点的类型来部署不同的配置。
尽管HDFS联盟解决了HDFS扩展性的问题，但它并不解决NameNode可靠性问题(事实上，它使事情变得更糟——这种情况下单个 NameNode失效的概率更高)。图2-6展示了一种新的HDFS高可用性架构，包含两台配置为NameNode的独立机器，且在任意时间点只有其中一 台处于活动状态。活动的NameNode负责响应集群中的所有客户端操作，而另外一台(备机)仅作为从属，维护着足够的状态信息，并在需要时提供快速的故 障转移。为保持两个节点的状态同步，该实现要求两个节点均可以访问共享存储设备上的某个目录。
当活动节点进行任何名称空间修改时，它会向一个位于共享目录下的日志文件持久性地写入一条修改记录。备用节点持续观察该目录的变化，并且将改动应用于自身的名称空间。当发生故障转移时，备机在确保已经读取了所有改动之后，将自身切换为活动状态。
为支持快速的故障转移，备用节点也需要了解集群中块位置的最新信息。这可以通过配置DataNode来实现，让其同时向两台NameNode发送块位置信息和心跳。
目前，仅支持手工故障转移。Hortonworks公司提交到1.1版主干和分支中的核心Hadoop的补丁消除了该局限。该解决方案基于Hortonworks故障转移控制器，它会自动选择一个活动的NameNode。
HDFS为存储大量数据提供了非常强大和灵活的支持。一些特殊文件类型(类似于SequenceFile)非常适合支持MapReduce实现。MapFile及其衍生类型(Set、Array和BloomMap)在快速数据访问方面表现良好。
不过，HDFS只支持一组有限的访问模式——写、删除和追加。尽管从技术上讲，可以将更新实现为覆盖，但这种粒度的实现(覆盖仅能工作在文件级别 上)在大多数情况下都成本过高。此外，HDFS的设计专门针对支持大量顺序读取，这意味着随机访问数据会造成显著的性能开销。而且最后，HDFS并不适用 于较小的文件。尽管从技术上讲，HDFS支持这些文件，但它们的存在会造成NameNode内存的显著开销，因而降低了Hadoop集群内存容量的上限。
为了克服诸多局限，Hadoop以HBase的形式引入了一个更加灵活的数据存储和访问模型。
