1. 系统介绍

阿里分布式文件系统(Ali Distributed File System，简称ADFS)是中国国内最大的电子商务公司——阿里巴巴根据自身的业务需求对Cloudera版本的Hadoop系统进行深度重构的一次重要实践。一直以来，阿里巴巴坚持广泛采用开源社区的力量和技术来解决自身业务发展所遇到的问题，同时也将相关的技术改进和创新积极地回馈到开源社区中去。ADFS来源于Hadoop开源社区，我们也希望在合适的时候通过恰当的方法和途径将ADFS向整个Hadoop社区公开，从而增进Hadoop社区的活力并促进其多元化发展。

目前，阿里巴巴拥有国内负载量最大的Hadoop集群，该集群以社区版Hadoop 0.20.2为基础，根据业务需求不断进行补丁升级。自上线以来，该集群已经为成百上千的业务线提供了服务，阿里巴巴很多重要的数据资产都存储在其中。根据3月底的最新数据，该集群拥有2000台Datanode服务器，装机容量为37PB，目前已经使用了23PB，文件和目录数近1亿2千万，文件块达到1亿6千万，每天完成的MapReduce Job数目超过为3万，分配给Namenode服务器的内存有120GB，已经使用了83GB。可以说，该集群为整个阿里巴巴的业务发展起到了非常重要的作用。不过，该集群也存在着一些问题：

一、HDFS的Namenode在设计上存在单点故障(SPOF)，缺乏高可用解决方案。当然，近年来Hadoop社区和一些相关企业也在试图解决这一问题，但是社区还没有正式发布一个真正可用的高可用方案。就这个问题，我们将在后面进行更详细的讨论。

二、随着负载增加，Namenode所耗费更多的内存来存储命名空间(Namespace)和块对应关系(BlocksMap)。对于Namenode这样的Java进程来讲，在大内存空间中进行FullGC可能导致该进程长达数分钟不可用，严重影响上层业务的正常运行。

三、集群重启时间过长，期间无法对集群进行写操作。HDFS集群重启以后，会首先进入安全模式(Safe Mode)，在该模式中Namenode从EditLog和FSImage恢复Namespace内存结构，并通过Datanode的blockReport信息恢复BlocksMap内存结构，同时还进行block是否达到最小副本数要求、合格Datanode数目是否满足要求等一系列检查。按照上述集群的规模，重启时间一般在40-60分钟，对业务影响也是较大的。

四、该集群的基础版本(Hadoop 0.20.2)版本较早，截止2011年底，该集群对于一些新的应用场景还不能够较好地支持，比如HBase。

综上所述，社区版Hadoop的问题主要还是出在Namenode设计和实现上。为了解决上述问题，阿里集团核心系统部海量数据团队(原淘宝网数据平台海量数据团队)于2010年底启动对社区Hadoop的Namenode深度重构，希望改造成更适合阿里巴巴自身业务发展的分布式文件系统ADFS(原TBDFS)，该系统需要达到如下业务目标: 1. 实现Namenode高可用，解决单点问题；2. 实现Namenode在线(不停机)升级；3. 实现Namenode快速重启(5分钟内)；4. 提供可支持5000-10000台Datanode服务器的集群规模；5. 提供10亿文件和目录、10亿文件块的管理能力；6. 提供与社区实现相当的稳定性、性能和可维护性。

经过团队1年多的设计、开发和测试，深度重构后的ADFS系统初具雏形，并已经能够较好地支持HBase应用。借此机会，我们也希望把ADFS开源出去，让Hadoop社区中更多的同行来了解、学习或批评，共同把Hadoop社区做大做强。

在接下来的篇幅中，我们首先会介绍现有ADFS的架构设计，然后会将ADFS和目前业界对HDFS改造的其他方案进行对比，总结各自的特点和优劣，我们还会提供ADFS的测试报告和部署方法，方便大家对ADFS的性能参数和使用方法有更深入的了解，虽然ADFS已经取得阶段性成果，但是目前的系统架构还有很多需要改进的地方，我们在路线演进部分中会给出未来的改进方案。