打造千亿文件量级的大规模分布式文件系统

今天分享的主题是「百度沧海·存储」如何打造千亿文件量级的大规模分布式文件系统。分享内容主要分为三个部分：文件系统的基本概念；元数据服务建模和分析；CFS元数据服务架构。1文件系统的基本概念1.1什么是文件系统文件存储是大家在日常生活中经常遇到的一种存储形式，存在于每一台手机和电脑上。当我们打开电脑的文件浏览器，浏览目录查找、操作文件的时候，其实就是在操作文件系统。和其他存储形式相比，文件系统的最大特点是有一个层级目录树结这个结构长什么样子呢？下图是一个例子，我们可以将这个图翻转一下，看起来就像一颗不断生长的树。树中的每一个非叶子结点，都是一个目录，在目录下可以放更多的目录或文件。除了根目录，每个目录或文件都属于一个父目录。文件系统领域的权威标准是POSIX。POSIX是一个接口标准，规定了文件系统需要实现的接口的参数和行为，但是没有做实现上的约束。因此，在实现上不同的文件系统采用的方法和理论是千差万别的。这套标准存在一个不足：标准诞生的年代还没有出现大规模的分布式文件系统，因此对分布式文件系统面临的一些核心问题在标准中没有做出约束和规定。其中一个是多机一致性问题，当一个文件由多个客户端同时操作的时候，不同客户端看到的属性（权限、修改时间等）和数据是不是完全一致的，如果不完全一致这个不一致程度可以放松到什么程度。考虑到性能和实现难度，现实中没有一个文件系统能够做到100%兼容POSIX标准。从POSIX标准的兼容性上看，大致排序是：HDFS会比网络文件系统和分布式文件系统差一些，做的最好的是本地文件系统。HDFS对于大家来说是比较熟悉的，在大数据领域有广泛的应用。HDFS在POSIX语义上做了非常多的裁剪和修改，与原始的POSIX相比已经有了很大的变化，我们甚至可以将它看成一套独立于POSIX的文件系统标准。在这次的分享中，我们不用关注其中的差异，分析的过程和解决方案对包括HDFS在内的所有分布式文件系统都是适用的。1.2POSIX标准对文件系统的一些规定POSIX规定的接口可以分为三类。第一类是文件的操作，包括对文件的打开、关闭、读写等。第二类是对文件系统目录树本身做的操作，例如创建目录、删除目录、获取目录下所有子项等。第三类是对文件和目录树都适用的，例如获取属性的部分、修改属主、权限等，称为属性操作。一般我们把对目录树的操作和对属性的操作都统称为文件系统的元数据操作。在POSIX中对接口的行为有很多细致的规定。这里列举了一些实现过程中大家比较关注的点。因为时间原因，无法一一展开，挑两个点简单介绍下。一个是跟close相关的点。在原始的POSIX标准里，没有要求文件在c数据的持久化，也就是数据不强制落盘。这在分布式系统中会产生问题。我们来看一个典型的场景，业务的一个客户端写数据，其他客户端希望写数据的客户端完成写入后立即能读到数据。如果按照POSIX标准来实现的话，写数据的客户端写完文件close后，另一个客户端可能看到数据，也可能看不到数据，什么时候能看到取决于写客户端完成数据下刷的时机。这样的情况对很多业务来说是不可接受的。业界常用的的close前完成数据的下刷，以保证其他客户端再次op另一个有意思的点和遍历目录有关系。我们平时在电脑上使用ls查看一个目录下有哪有要求返回的子项是按照字母序排序好的。很多小伙伴可能比较困惑，因为实际上看1.3文件系统的发展历史单机的存储容量有限，另一个不足是单机面临数据可靠性的问题。当单机出现故障时，数据可能丢失，这在很多商业应用中是不可接受的。因此业界发展出第二个阶段的文件系统。这个阶段的特点是将磁盘从单机剥离出来做成带外的·第一类方案还是单机的形态，但是磁盘不在计算机和单机文件系统是没有差别的，主要保证了机器故障后数据还能马上被第二类方案主要是解决小规模场景下数据共享的问题。这类方案让同一组磁盘可以同时被不同的机器挂载，再运行OCFS2等多机共享文件系统，由这些文件系统做一致性的保障，即使不同客户端同时操作，也能保证数据的正确性。由于完全依赖文件系统的节点自己仲裁，这类方案在上述两种形态之外，企业和学术界注意到一个事实——大家在使用时需要的不是一组磁盘，而是文件系统的服务。于是诞生出直接提供文件·第三类方案NAS提供的是一种网络文件系统，以业界通用标准协议·第四类叫并行文件系统，专门针对HPC或AI这类有较高性能诉求的场办法很好发挥出文件系统和硬件本身的性能。并行文件系统则更优先考虑性能，提供私有协议的客户端，在软件栈上做了大量的优化，尽可能3.最后一个阶段是软件定义时代。在专用硬件时代，因为绝大多软硬件一体的方式，只有少数厂商有能力提供这样的产品，所以购买这种解决方案的成本非常高。随着Google、大量数据存储和处理的需求。这时候去购买专用的硬件成本太高，而且数据规模太大性能难以满足需求，所以最终大家来到了软件定义时代。这个时代的特件系统，而故障率较高的问题通过分布式理论的创新来解决，通常的做法是使大的规模，更低的成本，已经成为现在文件系统领域的主流做法。传统的厂1.4现代分布式文件系统的基本组成元数据服务负责维护文件系统的层级结构和属性信息。根据业务的实际需求，元性指标，分别是规模扩展性和性能扩展性。规模扩展性是说数据量在不中，文件系统能够满足业务对规模的需求。性能扩展性是说系统规模在不断扩大过程中，系统性能能否随之扩展符合增长预期。数据服务主要负责文件数据的存储和相关请求的处理。系统层面大家比较关注的一个技术问题是数据的布局——一个或多个文件的数据在文件系统中如何合理分布，以达到更好的均衡性和性能。具体到每个节点，大家还会关心单机引擎是怎么实现的，是对顺序读写比较友好的appendonly的方式，还是为了更好支持随机写，采取inp1.5元数据服务是影响文件系统规模的关键组件元数据服务位于整个服务的关键路径上。在进行所有数据操作前，都要找到对应的目录或文件，这时首先进行的就是元数据的操作。根据我们线上和业界的观察，在很多业务访问模式中，元数据操作的占比是很高的，特别地，系统的文件越小，元数据操做数据分布时，不会在数据之间产生依赖关系，容易打散到不同的节点上。对文件不同部分，可以进行进一步切成小分片打散。因此，数据服务更容易扩展到更多的节点上。但是元数据服务的层级结构，会带来不同目录和文件之间的父子依赖关系，使它因此，元数据服务是影响文件系统规模的关键组件，要2元数据服务建模和分析2.1元数据服务的抽象模型在进一步分析之前，我们对元数据服务做一个简单的抽象，让大家对这个服务的实现所有写操作都需要实现关联变更。关联变更是指在一个目录下创建或删除文件、子目录的时候，需要同步更改父目录属性，整个操作原子完成。这点比较重要是因为涉及举个简单的例子，更新父目录属性时，其中一个变更是父目录修改时间，这个修改时间很重要。为什么？当客户端浏览一个目录的时候，如果不能感系统造成非常大的处理压力；另一种方法是不实时拉取，但是需要忍受一段时间数据的错误或滞后，因为没有办法判断数据是否是最新的。有了修改时间之后，客户端如果在较短时间前已经访问过，缓存了一些结果，重新访问时，就有第三种选择，就是和后端目录做一下比对，如果修改时间没有变化，缓存结果就是有效的，可以直接使用。很显然，如果没有关联变更提供原子、同步更新修改时间的保证，第三种选择根rename是写操作中最复杂、最难优化的一个。其他操作只会涉rename可能会涉及到源和目的两个父目录。它还会对路径成环、空读操作在文件系统中分为点读和范围读两种。点读包括路径查找（到要操作的文件或目录。每一级查找都是一次lookup，查找结果是在文件系统中唯一代表一个文件或目录的编号，这个唯一编号叫inode，大部分系统里是一个64位字。通过inode可以进一步查询文件或目录的属性。范围读的主要应用则是目录遍2.2衡量元数据服务实现优劣的指标项第一个是扩展性。扩展性衡量文件系统可以扩展到多大规模，可以进一步细分为两个还是千亿。因为系统中文件的占比是最高的，所以这个指标也成为文件系统所能支持的文件数规模。第二个是性能扩展性，是指增加节点时候，整个系统元数据读写QPS是否能够根据规模的增长，做到近似线性关系，以及规模增长到哪个量级会达到极第二个是延时，很多对性能敏感的应用会关心单个请求，例如一个创建、读请求需要第三个是均衡性。均衡性是指元数据服务是否有能力把系统中的热点进行打散，让不同节点的处理压力大致均衡。如果不能很好做到这一点，上面提到的扩展性也无法做到很高的，因为根据木桶原理，整个系统的性能是由最短的板来决定的，处理能力最2.3元数据服务架构发展历史第一阶段以HDFS、GFS为代表，在整个系统中只有逻辑上单点的元数据服务，显然是没有任何扩展性和均衡性可言的。这类架构的优点也是单点架构，由于不涉及很复杂的多点协作，所以负载相对比较小的情况下，延时表现非常好，随着负载变大，延到了第二阶段，大家发现单点元数据服务无法满足系统要求，就自然想到扩展到多点，于是出现了耦合式分布式架构。这一代架构是在前一代基础上，通过哈希或者子树的方式，把文件系统不同部分放到不同的节Federation。这类系统规模可以做到百亿级没有跨节点有关。这类系统最大的缺点是文件或目录创建的时候就确定了位置，后续不能在线迁移。这就导致一旦节点上出现多个热点目录无法通过负载均衡的手段疏部的计算逻辑。当计算逻辑和存储耦合在一起时候，要在数据搬迁的过程中保证服务的连续性，就必须处理好计算过程中涉及到的状态的保存和恢复，这远比的数据复杂非常多，工程难度极高。这类系统的均衡问题一直是业界研究的热点，但第三个阶段的发展契机是分布式事务系统的成熟，发展出来和大数据存算分离类似的架构。大家发现利用分布式KV或NewSQL据的设计。这已经成为近几年非常大的一个技术趋势。在这个趋势下，包括分布式KV和NewSQL系统在内的分布式事务系统，在几乎所有的存储领域，的每个系统自行维护的元数据存储。同时，有了这样一类系统后，在上面去实现元数分布式事务系统已经在理论和工程上很好的解决了均衡性、规模等诸多问题，可以扩的第三阶段系统，在实践上已经能够做到千亿级规模。但是，这类系统也会有一个比较大的缺陷，就是它极度依赖底层分布式事务系统提供的事务能力，对于写操作而言不是非常高效的实现，性能上达不到文件系统领域很多业务的要求。除了写性能比较3CFS元数据服务架构3.1元数据服务的关键问题对于在云上构建大规模分布式系统而言，从规模角度上，刚才提到的第三阶段分离式架构是最理想的，但是其他方面并不能满足现实业务的要求，所以百度智能云的文件存储CFS在这个架构基础上，又做了一些改进，让整个系统达到比较好的状3.2一个文件创建的例子在前面整个元数据服务的建模中，我们提到关联变更是一个非常关键的问题，这里进首先需要读目录本身，并对目录上锁(②);在系统中插入f2文件的记录(③);根据关联变更的要求，更新A目录的属性(④);整个操作完成后，对A目录解锁，以及commit整个操作(⑤)。上锁过程是为了保证整个操作是原子完成的，在整个过程中没有其他操作能够读到正在进行的脏数据。可以看到，上锁的时间几乎和整个请求的处理时间一样，临界区非如果尝试把锁去掉会有什么后果呢？我们看一个并发的例子。在目录下创建两个文斥机制，就会导致这两个操作分别写下了children=1的错误结果。这个错误会产生一这个状态违背了文件系统层级目录要求，产生了孤儿节点。从这个例子可以看到，锁3.3CFS的核心思路：对分离式架构进行无锁化改造的。在文件系统里，这会导致跟该目录相关的所有操作都需要做很重的排队。百度智能云的文件存储CFS对这个问题的解决思路，和我们去优化一段代码中大的临界区是布局，将冲突的范围缩小到很小的范围——一个元数据分片的粒度上；然后，进一步将冲突范围从单条或多条记录缩小到字段级别；最后，在前面两个操作的基础上，成功地将元数据代理层消除掉了，将分离式架构做的比较差的点优化到和耦合式架构一3.4优化数据布局CFS首先在架构上对这两部分做了分离，把每个目录项的两个部分分开存储的attr记录和子项的id记录。如果在元数据分片上做亲和处理，把目录项在实现上，我们将这两种数据混排在同一张数据库表中，以<父目录inode,名字>为主符，不会出现在文件或目录的名字中，因此不会产生冲突和混淆。这样表示之后，父目录的attr和它的子项id的表示可以统一到<id,name>这种形式，在数据分布上续的。再配合以id范围来划分元数据分片的规则，就可以达到将关联变更涉及到的数在这基础上，我们又观察到，文件在整个系统中是比较特殊的。首先，文件下面不会再有子项。其次，文件的元数据操作和数据操作的频率有关联，做数据读写时候，就会伴随文件属性操作。基于这个观察，我们在布局上做的另一件事情是把所有的文件属性，从元数据服务中拆出来，和数据服务放在一起。数据服务的规模一般都要远比元数据服务大，通过这个调整，在降低元数据服务压力的同时，我们让文件的元数据操作处理能力变得更调整完数据布局之后，我们在操作顺序上也做了一些调整，让临界区真正缩小到分片据分片上创建id记录，同时更改父目录属性。做路径查找时候，是从id记录开始一级一级往下查找，都是先id记录后attr记录，刚好修改操作查询操作顺序是完3.5单分片原语在元数据系统这一层抽象出两个通用的机制，将整个记录的冲突缩小到字段范围。这两个机制称为DeltaApply和Last-w加1，可以直接整合到加2的操作。Last-w来的数据覆盖之前的数据。通过这两个机制，我们可以把原来在单分片上有冲突的3.6移除元数据代理层优化完数据布局，引入单分片原语后，实际上已经实现了让整个执行路径无锁化的目我们进一步发现，经过这些优化后，在分离式架构里，元数据代理层存在的意义不是化成事务请求；第二个是做一些冲突的处理，使放行到底层分布式事务系统的冲突更小。经过前面两步优化，鉴于冲突在整个系统层面已经不存在了，可以让客户端去做杂，不详细展开）会由一个单独的服务承担，其他请求全部由客户端直接发起。这样3.7CFS整体架构经过上面的铺垫，现在我们可以很容易推导出百度智能云的文件存储CFS采取构。在这个架构里，客户端ClientLib承载了绝大多数POSIX语义处理的操作的所有rename操作，会由一个单独的rename服务来处理，这个服务会对r操作做适当的排序，防止系统中出现成环、孤儿节点等badcase。除此之外，其他所3.8测试数据从这一页