近年来，已经有越来越多的企业参与到Hadoop社区的发展中来，它们对HDFS的改造提出了不同的方案，有的是基于社区版HDFS源码进行改造，比如Cloudera的CDH版本和Facebook的AvatarNode，也有的是参照HDFS重写一套分布式文件系统，比如百度的HDFS2和腾讯的XFS，当然社区也推出了新的版本Hadoop0.23。总的来看，Hadoop 0.23的Federation HDFS、百度的HDFS2和腾讯的XFS做了较为全面的改造，而ClouderaCDH4 beta1、Facebook的AvatarNode以及Hadoop 0.23 HA是为了解决特定问题——Namenode单点故障而做的。
首先，我们来介绍Hadoop0.23中Federation HDFS的架构，如下图所示。从逻辑上看，FederationHDFS中命名空间和文件块管理还是由Namenode负责，Datanode负责文件块物理存储和访问，但是FederationHDFS允许在一个集群中运行多个Namenode，每个Namenode负责一个命名空间(可以是非HDFS的命名空间)，每个命名空间拥有至少一个逻辑的BlockPool，命名空间和它所拥有的BlockPool统称为一个NamespaceVolume。虽然这些命名空间从物理上看是共享集群中的Datanode，但是在每个Datanode上还是对每个命名空间的BlockPool进行了隔离的，而且Datanode需要向每个相关的Namenode进行汇报。采用FederationHDFS架构，集群失去了统一的命名空间管理，换来的是多个命名空间可自主升级的灵活性和降低集群整体不可用的风险。
百度的HDFS2架构如下图所示，从上到下分大致划分为两个层次:Namespace Federation(原Namenode)和Object Manager Layer(原Datanode)。在Namespace Federation层，HDFS2不再包括文件属性和块管理功能，实现了轻量级命名空间管理，和社区版Federation HDFS类似，Namespace Federation也支持多种命名空间，包括层次化的和平坦的；在Object ManagementLayer中，它不仅负责块的物理存储和访问，还整合了文件属性和块管理功能，每个Datanode对该功能进行了垂直切分，各自管理一部分。客户端访问HDFS2时，通过Namespace找到该文件名对应的Datanode和文件标识，并根据这些信息访问指定的Datanode获取文件属性和它的块信息。但是，HDFS2现有版本还没有实现高可用解决方案。
腾讯的XFS是由搜索部门采用C++开发的分布式文件系统，它也实现了元数据信息的分离，并且通过SDK包兼容HDFS，即让HDFS运行在XFS上。如下图所示，XFS中命名空间由Master进行管理，XFS的Master通过主从热备实现了高可用解决方案，由Zookeeper实现监控、选举和切换；文件标识和块管理由独立的MetaServer进行管理，它记录了文件属性、长度以及该文件拥有的块等信息；与Datanode类似，块物理存储和访问由NodeServer负责。客户端在访问XFS时，先通过文件名在Master上获取MetaServer标识和文件标识等信息，然后在指定的MetaServer上获得需要请求的文件信息或者块信息，如果要访问文件的块，则通过NodeServer获取块内容。
