2012年1月11日，第六届中国IDC产业年度大典在北京国家会议中心盛大开幕，本届大会以“构建云数据中心暨云应用创新论坛”为主题，邀电信运营商、IDC企业、设备厂商、互联网等业界同仁共同探讨云计算时代下的IDC产业机遇与责任，中科院计算所 研究员熊劲发表演讲：数据中心文件系统技术初探。

中科院计算所研究员熊劲：大家好！非常感谢大会组委会给我一个机会，跟大家一起交流分享，我们在云计算数据中心方面的工作。我来自中科院计算所，计算机系统实验室，我们的实验室是去年下半年刚刚成立的实验室，主要工作是围绕数据中心需要的关键技术，做的内容包括数据中心的应用结点的技术，内存的技术，数据存储，文件系统，以及数据中心的网络等。我大概讲三个内容，是跟前面演讲者的内容不太相同，我们现在的工作都是偏向新的技术点的探索，而不是实实在在运行的系统以及提供服务的系统。数据中心的应用对于数据存储、数据访问提出哪些新的需求和挑战。

之后，介绍我们的两个工作，一个是高效管理，万亿个文件的文件系统。

第二，面向海量小文件，高效访问的系统。

简要回顾一下文件系统，在座的对文件系统都很熟悉，由于时间关系，我就不讲了。大家就记住，在之前的话，主要有三种文件系统。一种单机文件系统，主要是管理主机本地磁盘上的数据。第二种，面向局域网环境下，文件共享的网络文件系统。还有面向并行计算机的并行软件系统。

现在云计算来了，云计算使得大量的资源，包括计算资源和存储资源都汇聚到数据中心，我们终端用户的话，是通过数据中心提供的各种服务获取信息的。这些服务是运行在数据中心，刚才已经讲了很多的硬件平台，以及平台软件上。比如说平台软件，包括分布式软件系统，并行数据库，以及并行数据处理等等。数据中心典型的应用，包括有搜索引擎，社交网络，电子商务，还有音视频共享等，我们看一下应用在数据访问上，有哪些新的特征。

首先，一个特征，就是数据量特别大，而且增长速度非常快，Facebook的数据，2010年数据就是20pb的图片，日上传量近9TB，还有一些大企业都是几十PB的数据量，平均日增长量是几个TB到10几个TB的样子。数据说明了什么？数据中心的应用对于底层存储数据的容量和IO带宽带来很大的挑战，存储系统需要采用增量式的方式进行升级。第二，数据访问是高度并发的。因为服务的是互联网上的数千万的在线用户，用户都是用交互式的访问。

所以，每秒提供几万到几十万的请求，这个表里有数据了，就不讲了。都是想说明对性能的要求非常高的。这些数据说明对底层的文件系统、存储系统来看的话，需要提供很高的随机访问的性能。而且要提供很高的数据可用性。

第三，就是文件数量非常大，而且是大文件，小文件并存，刚才讲到了，互联网数据中心，既要存储图片，还有音视频，图片是典型的小文件，音视频是典型的大文件，访问频率抖非常高。这样的话，实际上对底层的文件系统元数据处理能力提出很高的要求。小文件的访问，需要很低的访问延迟，以及高的聚合吞吐率。

还有一点，就是数据中心的应用，他们在数据访问的语意和接口上更加的简化，大量的服务都是通过典型的KV的接口访问。根据一个标签，或者根据关键词找到所需要的内容。而且名字空间是扁平化的，不像以前的文件系统采用复杂的、层次化的空间。数据也拥有更多属性和更加丰富的属性，属性是用户和应用自身定义的，还要追溯数据的起源。这些内容说明，传统的文件系统在空间和访问接口上，对于数据中心来讲并不是很合适。
另外一点，就是数据共享和数据的安全。这一点，我们没有太关注。但是吴教授讲了很多他们关于这个方面的研究和探索。

总结一下，我们这边比较关注的文件系统方面面临的挑战。第一高效的管理EB级的存储空间。高效管理万亿数量的文件。第三，对于海量小文件高并发访问性能吞吐率。第四，存储成本怎么控制。第五，数据访问的控制，第六，基于多个数据中心怎么提供全局的数据视图。我们在过去的两三年里，主要是围绕其中的两个问题，做了一些探索，下面介绍一下在这两个方面的研究结果。

一个是高效管理万亿级文件的分布式系统，我们的目标是这个文件系统的文件数量超过万亿个。而且文件可能在同一个目录下面，需要文件系统提供非常高的元数据处理能力。每秒希望创建几十万个文件。这张图是分布式文件系统的典型架构，应用程序通过客户端服务数据的。对于原数据的访问，发到元数据的服务器，对数据文件的内容访问发到存储服务器上。谷歌FS为代表第一代数据文件系统，是采用集中式的元数据管理，一个Master管理整个文件系统的名字空间，可以复制到多个元数据服务器，对于修改操作，比如说创建文件或者删除文件来说，只能有元数据进行处理。集中式的元数据管理存在很大的局限性。

第一点，能管理的文件数量受限于Master结点的内存大小。比如说11个文件，可能最少的情况下，大概也是需要超过400GB的空间管理。第二个局限性，就是元数据的吞吐率，是受限于单个元数据服务器自身的处理，CPU、内存、网络等。于是我们得出这样的观点，也就是说我们要管理万亿文件的话，我们不能采用集中式的元数据管理，而需要分布式的元数据管理，多个元数据服务器共同管理一个空间，每一个元数据服务器就是管理其中一个部分。元数据管理从集中式走到分布式，复杂度大大增加了。对于分布式元数据的管理，涉及到非常多的问题。简单列了一下我们关注的问题。一个就是名字空间怎么划分和分布，分布力度多大，采用什么机制定位？第二，如何保障元数据操作的原子性，元数据的操作需要跨元数据服务器，由多个元数据的服务器共同完成操作。第三，如何提高元数据操作的并行度，针对同一个目录的修改操作，如创建删除，传统的系统里面，这样的系统没有办法运行。第四，如何管理元数据的缓存，充分利用内存来提高操作性能，最后就是元数据负载均衡，充分发挥每一个服务器的能力。介绍一下名字空间的划分的情况。

目前有三种方式，第一，就是子树划分，有一个图可以显示，把名字空间划分成多个子树，然后映射到各个服务器上，有动态子树划分和静态子树划分。需要系统管理员手工进行配置，决定哪些子树分配到哪些服务器上。如果需要迁移子树的时候，需要通过配置的方式才能完成迁移。动态划分的话，不需要人工敢于，可以自动的进行名字空间划分，自动进行映射和迁移。子树划分的方法，主要的问题在于容易出现负载不均衡，子树的力度通常比较多，元数据操作的并发度相对比较低，只能在子树之间进行并行。第二种方法是目录分片划分，也就是说把每一个目录都进行划分，划分成很多的分片，然后再把分片映射到不同的服务器。

大目录里面查找效率比较高，大目录查找，分解成两次，在更小的范围内进行的查找，同时由于把目录分布了，所以能够做到在目录内部进行并行操作，但是一个缺点，就是如果我的文件数量更大，比如万亿级的时候，效率也是不够高的。第三，就是文件划分，名字空间划分为单个文件，映射到不同服务器，映射机制就是采用映射表记录，也可以采用Hash  bloomfilter进行划分，邮电分布均衡，实现简单，缺点是消除了名字空间的局部性信息，这样给性能带来不利的影响。另外，扩展性也存在一定问题，增加或者删除元数据服务器的时候，可能需要对所有的文件进行重新的分布。针对上述的问题，提出一个改进，就是自适应的2级目录划分，另外，细粒度的并行，还有利用不同的数据结构的特点，组织元数据的缓存，对于这些数据结构进行分类的缓存。

第四，我们自己实现了自动的负载均衡机制，从而能够更好的利用所有元数据服务器处理的能力。节杀一下2级目录划分思想，第一级就是把分路划分成分片，尽可能分散到所有的服务器上，这样做的目的，是为了充分利用所有元数据服务器的聚合能力。第二级的话，是把分片进行分类，分片内部对分块进行分类，通过分块的分类，分片自动长大，直到长到一个上限。这种做法，是为了充分利用单个元数据服务器自身的处理能力。通过两级目录划分的话，在一个大目录里找文件，就是分解三次，在较小范围内的查找，首先是在目录内查找分片，然后在分片内查找分块，最后在分块内查找文件。两级划分都是采用根据文件的Hash值，直接定位所在的分篇和分块。

缓存主要的思想就是根据数据结构的特点进行缓存，将最常用的数据保存在缓存数据里。我们方法与单级目录划分的性能对比，其中红色的曲线是我们的系统，可以看到，在文件数量超过100万之后，我们这种方法的性能比单级目录划分都要高。这张图是扩展性的曲线，红色曲线是100万左右的性能，随着元数据的增长，文件创建的性能是线性增长，这个图是峰值的性能，有10亿个文件的时候，系统创建性能6到9万个每秒。

前面讲到了数据中心的应用，有些是需要对海量小文件高并发访问的。现有的分布式文件系统的话，是不能满足这样的需求，主要是因为在分布式系统里面，访问一个文件需要多次的磁盘IO，以及多次的网络来回，这样的话，访问一个文件，实际上需要的时间是非常长的。那么Facebook或者淘宝，自己开发了专业的存储系统，存储他们的图片。

另外，还有一些分布式的KVS的系统，谷歌的Bigtable也可以存储海量的小文件，现有的方法也不是很完美，专用的图片存储系统来说，问题在于适应性差，功能非常有限，适用范围很有限，上层软件相对来说比较复杂，操作数据库，又要操作文件存储系统。Bigtable底层依赖于分布式的系统。这些系统都是各自提供各自的接口，没有通用性，没有统一通用的接口。我们的目标就是首先有通用性，我们希望实现在文件系统一层，通过文件访问系统，都可以访问小文件。对于海量小文件高并发访问，要提高高的吞吐率，小文件访问的延迟要低，具有易用性和可靠性。这个地方大致列了我们主要的技术路线。扩展分布式文件系统的目录结构及我们是自动的把文件与元数据结合起来存储，把很多小文件自动聚合起来一起存储。目录组织上采用列存储和表结构的方式组织，大大减少磁盘IO的量和网络传输量，基于DEH来划分目录，还有处理层和存储层的分离，处理层充分利用内存缓存，存储层充分利用磁盘带宽，元数据操作的原子性。这张图是现在得到初步的结果。我们这个系统叫Pomegranate，是叫石榴，因为要管理很多的小文件，文件创建率可达18万个每秒，Lookup的速度41万个/秒。这张图是小文件的聚合带宽。浅蓝色是我们的系统，叫做石榴，在32个服务器的时候，小文件的聚合带宽达到1GB/s，也就是说每个服务器大概有30多兆b/s的系统，比OrangeFS高64倍。我主要讲的内容就这样。我讲的内容是文章里面的内容，是比较小的做文件系统的团队，成员都是一些硕士生和博士生。