Taobao分布式文件系统TFS简析

Taobao分布式文件系统TFS简析自主研发分布式文件系统TFS(TaobaoFileSystem)的消息早有耳闻，最初来自网络上的一篇报道（或称软文）－“深度揭秘淘宝自主研发的文件系统TFS”。因为个人研究兴趣和工作内容相关的缘故，对TFS产生了很大的兴趣，很是期待和关注。TFS前面一直传说大致在2010.09月进行开源发布，国庆前后未能跟进关注，节后蓦然发现TFS已经于2010.09.29在Taobao的开源平台发布了，。网络上大家都戏称，TFS对时间把握真是太到位了，Taobao言必行，在9月的最后一天兑现了自己的承诺。正如大家所说，国内自主研发的文件系统真是可谓凤毛麟角，开源的文件系统就更是罕见，我现在所知道是就是FastDFS和TFS。从这个意义上，Taobao的开源精神是很值得称道的。FastDFS的开发者余庆和LVS的开发者章文嵩都在Taobao工作，我想这两位开源高手应该对TFS有着较大的影响，再借助Taobao的实力和平台，TFS的未来非常值得开源界和存储界期待。TFS官方称“TFS（TaobaoFileSystem）是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统，其设计目标是支持海量的非结构化数据”。我个人花了点时间研究一下TFS的源码和相关技术文档，TFS与目前一些主流的开源分布式文件系统设计思想是相似的，如HDFS,MFS,KFS,Sector。TFS的高可扩展、高可用性是很好的，然而也存在一定不足，如通用性、用户接口、性能等方面。我这里粗略罗列一些自己认为TFS的不足之处，不当之处还请大家指正。1、通用性方面。TFS目前只支持小文件的应用，大文件应用是不支持的。对小图片、网页等几十KB内的数据存储非常适用，但对视频点播VOD、文件下载等应用暂时无法适用。2、性能方面。Client写文件是同步处理的，需要等所有dataserver写成功后才能返回，这很是影响性能。3、用户接口。TFS没有提供POSIX接口，提供的API也与标准接口不一致。另外，TFS有自己的文件命名规则，如果用户使用自定义的文件名，则需要自已维护文件名与TFS文件名之间的映射关系。4、代码方面。使用了C++实现，感觉相对臃肿一点，如果用纯C实现应该会简洁不少(可能我C中毒太深了)。代码注释基本没有，代码质量也不是很好。5、技术文档。官方有一些文档，但显然非常不够深入和全面。6、小文件优化。官方称针对海量小文件的随机读写访问性能做了特殊优化，现在只看到把众多小文件存放与一个Block中，这与Squid中的COSS原理相似。其他特殊优化措施未知，LOFS(Lostofsmallfiles)是个难点问题。揭秘淘宝自主研发的文件系统——TFS://作者崔康发布于2010年7月7日上午1时0分社区Java主题性能和可伸缩性,Linux,开放源代码,故事和案例分析标签开源软件,最佳实践,性能和扩展性目前，国内自主研发的文件系统可谓凤毛麟角。淘宝在这一领域做了有效的探索和实践，TaobaoFileSystem（TFS）作为淘宝内部使用的分布式文件系统，针对海量小文件的随机读写访问性能做了特殊优化，承载着淘宝主站所有图片、商品描述等数据存储。最近，淘宝核心系统团队工程师楚材（李震）在其官方博客上撰文（《TFS简介》，以下简称文章）简要介绍了TFS系统的基本情况，引起了社区的关注。文章首先概括了TFS的特点：完全扁平化的数据组织结构，抛弃了传统文件系统的目录结构。在块设备基础上建立自有的文件系统，减少EXT3等文件系统数据碎片带来的性能损耗。单进程管理单块磁盘的方式，摒除RAID5机制。带有HA机制的中央控制节点，在安全稳定和性能复杂度之间取得平衡。尽量缩减元数据大小，将元数据全部加载入内存，提升访问速度。跨机架和IDC的负载均衡和冗余安全策略。完全平滑扩容。当前，TFS在淘宝的应用规模达到“数百台PCServer，PB级数据量，百亿数据级别”，对于其性能参数，楚材透漏：TFS在淘宝的部署环境中前端有两层缓冲，到达TFS系统的请求非常离散，所以TFS内部是没有任何数据的内存缓冲的，包括传统文件系统的内存缓冲也不存在......基本上我们可以达到单块磁盘随机IOPS（即I/Opersecond）理论最大值的60%左右，整机的输出随盘数增加而线性增加。TFS的逻辑架构图1如下所示：图1.TFS逻辑架构图（来源：淘宝核心系统团队博客）楚材结合架构图做了进一步说明：1.TFS尚未对最终用户提供传统文件系统API，需要通过TFSClient进行接口访问，现有JAVA、JNI、C、PHP的客户端2.TFS的NameServer作为中心控制节点，监控所有数据节点的运行状况，负责读写调度的负载均衡，同时管理一级元数据用来帮助客户端定位需要访问的数据节点3.TFS的DataServer作为数据节点，负责数据实际发生的负载均衡和数据冗余，同时管理二级元数据帮助客户端获取真实的业务数据。文章发表以后，读者反响热烈，在评论中提出了各种问题与作者楚材进行技术交流，由此可见国内社区对自主研发文件系统的关注程度。为了让读者更深入地了解TFS的奥秘，InfoQ中文站针对TFS的来由、运行环境、扩展性、架构、发展规划及开源事宜等问题对楚材（李震）进行了专访。InfoQ：淘宝为何会选择自主研发文件系统？TFS(TaobaoFileSystem)，是淘宝自主研发的一套分布式文件系统，用于存储淘宝网主站的数据，例如商品图片、商品描述、交易快照、社区图片等等等等。这些数据的一个突出特点是单个文件尺寸较小，通常不大于1MB，但是数量巨大，传统的文件系统或者网络存储设备很难解决类似的问题。淘宝网最早采用NetApp提供的网络存储设备，但是在2006～2007年期间，由于数据量的急剧膨胀，我们面临着系统更新换代的压力，而由于应用连接数量和文件数量的限制，实际上简单的升级已经变得非常昂贵且得不偿失了。数据是淘宝应用的核心，在这方面我们需要提供更加安全、高效、廉价的解决方案，需要发展自己的技术，更加适应淘宝网自身的应用特性。经过评估，已有的一些开源分布式文件系统都无法完全满足我们需求。淘宝网也许是当时国内互联网最先遇到类似问题的公司，当然也可能是其他公司遇到但未进行相关的宣传，总之，当时并不像现在一样有一些相对可靠的开源系统可以选择。InfoQ：TFS系统的运行环境如何？在做TFS选型的时候，我们依照当时淘宝网使用的主流操作系统使用了REHL，并构建在LINUX的EXT3文件系统上。选择REHL的理由是开源操作系统，我们有更多的自由度，同时成本也更加节省。关于硬件平台，随着硬件的发展和我们认识的变化，经过了一个相对比较长的变迁。分布式文件系统对CPU的要求并不高，同时由于我们采用了一些特殊的手段，也使得系统元数据减少，那么对内存大小的要求也并不高了，所有的性能和成本瓶颈都集中在了磁盘IO上。我们所有硬件架构的演变也都体现在磁盘的使用方式上。最早我们使用SAS146G×6的磁盘进行存储，后来换成了SAS300G×6的磁盘，使用了RAID5机制，这也是当时硬件平台的主流。当我们积累了一定的经验并逐步对系统稳定性有了信心之后，这种方式就逐步落后了。RAID5机制的备份和我们已经在应用层实现的数据冗余功能重复，磁盘空间被大量浪费，RAID卡的工作原理也无法优化TFS更加注重随机IO的特性，最终我们去除了RAID卡，并使用多进程，每个进程管理一块磁盘的方式，充分发挥磁盘的随机读写性能。SAS300G×6的磁盘我们使用了一段时间，相对比较稳定，这让我们有信心使用更大容量的节点而不会过于担心服务器失效带来的数据迁移对系统性能的影响，当前TFS主要的机型使用SAS300G×12的磁盘配置。随着淘宝网前端的CDN越来越高效、稳定，到达TFS的请求流量也更加平缓，这让我们有可能对单个节点的服务能力做出更加可靠的规划，也可以使用更加廉价的存储设备，未来我们的主要存储节点将使用1TSATA×12甚至更大的磁盘设备，进一步降低成本。InfoQ：TFS的应用规模达到数百台PCserver和PB级数据量，其扩展性如何？架构上是如何保证的？在TFS中我们将大量的小文件合并成为一个大文件，类似GFS中Chunk的概念，而Chunk的定位信息我们称之为一级索引，而chunk内部具体的文件定位信息我们称之为二级索引，同时在TFS文件名称中包含这些索引信息，在用户写入一个文件之前，他必须向TFS系统申请一个文件名称。这种方式虽然在某些情况下显得不像传统文件系统那样灵活，但也给了我们系统更大的可扩展性。我们保证可以中心控制节点的内存可以支撑PB级别的一级索引，而二级索引仅需要针对单台数据量。这样，我们就避免了数据量膨胀带来的扩容难度。当存储容量出现不足，我们需要进行系统扩容的时候，可以根据数据增长情况进行规划，任意数量的加入提供相应存储的服务器。而这些新的存储服务器会向中心控制节点进行报告。而中心控制节点在有数据写入时，将根据已存储容量的百分比、系统当前负载等参数动态地分配写入的服务器。同时，在系统空闲时间段，中心控制节点也会根据当前的数据分布情况制定数据迁移计划，并逐步完成数据平衡。与此类似，当发生服务器崩溃时，中心控制节点也会进行数据迁移以保证足够的备份，同时也会进行数据均衡操作。这些操作都是自动进行的，不需要人工干预。这种方式在1000台以内的集群基本上能够工作良好，如果集群规模更大，中心控制节点可能会出现一些性能瓶颈，届时我们可以使用一个分布式集群来解决，相应已经比较成熟的技术方案现在已经比较多了。InfoQ:您在介绍TFS的特点时，多次提到“性能”这个关键词，请问对于一个文件系统来说，性能一般应该考虑哪些因素？目前，提高文件系统性能的通用方法有哪些？现在我们可以讨论一下TFS的性能考量的维度了。其实当前每个流行的分布式文件系统都有自己的侧重点，分别针对自己不同的应用场景。对于离线型的数据分析需求，由于数据总量巨大，底层分布式文件系统更加注重系统的整体吞吐率，为了适应当前流行的map_reduce模型，这一类的文件系统会将文件切成多份，分而治之。同时和上层的逻辑配合，采用大块顺序写入、读出的方式来提升性能，典型的代表就是Hadoop使用的HDFS。实际提供线上服务的分布式文件系统中，也根据服务类型的不同而采用差异化的存储方式，例如针对音、视频等相对比较大的文件，可能采用和离线应用相同的方式将文件切片并发读写访问，从而达到更高的传输速度。由于相同容量下文件数量比较少，甚至有可能完全实现类似传统文件系统的目录、权限等功能，而不会受到inode的限制。如果面临淘宝相同的海量小文件存储，这种方式就完全无法提供性能的支持了，inode数量的膨胀会很快吃掉大量的昂贵内存，如果要平衡成本将部分inode放入磁盘，面对基本上完全随机、没有热点的访问又无法保证寻址的效率，我们只能通过减少元数据的方式来解决这个问题。为什么说我们的TFS面临着完全随机、基本上没有热点的数据访问？在淘宝的数据部署中，TFS前端有两层更加靠近用户的缓存系统来保证用户展示页面的速度，最终到达TFS的请求大概只有总请求数量的2%左右，随着前端缓冲的效率不断提升，这个比例还会继续下降，我们可以想象一下是否仍然有热点数据存在。与此同时，淘宝网的业务特点决定了相对于读取请求，写入请求量不在一个数量级上，而修改操作量就更少，这就决定了我们使用进行随机修改、随机写入的方式来避免顺序写入不进行修改给随机读取带来的成本。不同的应用场景，不同的存储架构，不同的性能考量，有什么通用的性能优化手段吗？从我们的实践经验来看，