作为欢聚团体旗下品牌，BIGO以后的业务涵盖直播，短视频和社交，目前曾经服务于寰球150个国家4亿用户。BIGO的产品业务个性决定了其对海量小文件的存储需要，如内容审核截图，用户社交沟通过程中发送的小文件，用户的头像等。目前BIGO每天会新增约几十亿个小文件，占用约30TB存储空间。对于海量小文件存储，如何在保障高性能的同时升高存储的老本，成为BIGO存储团队必须解决的问题。
01海量小文件存储的挑战
为了解决海量小文件的存储问题，必须采纳分布式存储，目前分布式存储次要采纳两种架构：集中式元数据管理架构和去中心化架构。
(1)集中式元数据架构：
典型的集中式元数据架构的分布式存储有GFS，HDFS，MooseFs等。其采纳的典型架构如下图1所示：
此架构次要蕴含3个局部：
1)客户端：次要用于提供拜访分布式存储系统的接口；
2) 元数据服务器：次要用于寄存分布式存储系统的命名空间和文件的一些元数据信息。
3)存储服务器： 次要负责存储文件的具体数据。
应用集中式的元数据管理的形式，其次要长处如下：
1) 元数据的操作性能高： 存储系统的命令空间和文件的元数据都寄存在元数据服务器上，元数据操作如list directory和create file等元数据的操作性能会比拟高；
2) 扩容时不须要数据迁徙：元数据服务器上寄存有所有文件的地位信息，在集群须要扩容减少新的节点时，这些地位信息不须要变动，因而集群在扩容时不须要进行数据迁徙。
其次要毛病如下：
1) 元数据节点是瓶颈：客户端在拜访文件数据之前通常都须要到元数据节点上查问文件的地位信息，因而元数据节点不可避免地成为了整个零碎的性能瓶颈。
2) 文件的数量受限：为了进步性能，元数据节点中的数据个别都会保留到内存中，而元数据节点的内存不是有限增长的。
基于以上毛病，集中式的元数据管理形式十分不适宜于海量小文件的存储。
(2) 去中心化架构：
为了解决集中式元数据架构的问题，去中心化架构的分布式存储产生，典型的去中心化分布式存储有GlusterFs，Ceph等。其采纳的典型的架构如下图2所示：
此架构次要蕴含3个局部：
1) 客户端： 次要用于提供拜访分布式存储系统的接口。
2) 存储服务器：次要负责存储文件的具体数据和元数据。
去中心化架构没有独自的元数据节点去保留文件的命名空间和元数据，元数据仍然存储在存储节点上，文件的寻址个别采纳DHT(一致性HASH)的形式计算。此架构个别会将多个存储节点进行逻辑分组，组内复制保证数据可靠性，因而会有可选的核心端服务器保留整个集群的存储节点以及分组信息。例如Ceph应用Ceph monitor保留整个集群的成员和状态信息(不保留文件信息)，而GlusterFs抉择将这些信息寄存在所有的存储节点上。
应用去中心化的的形式，其次要长处如下：
1)无单点的性能瓶颈： 没有独自的元数据节点，客户端能够间接通过Hash的形式寻址文件，间接到存储节点上拜访。
2) 文件的数量简直不受限制： 没有独自的元数据节点，实践上文件的数量不受核心端节点容量的限度。
3) 读写性能更高： 读写申请不必到元数据节点上寻址而采纳Hash计算的形式，实践上性能更高。
从以上长处能够得进来中心化的架构还是比拟适宜海量小文件的存储。因为GlusterFs的存储节点采纳Linux本地文件系统存储数据，没有对小文件的读写进行优化，而Ceph从Jewel版本开始引入BlueStore存储引擎，对海量小文件的读写有较大的优化，因而咱们抉择应用Ceph存储海量小文件。
Ceph绝对其余的分布式存储更适宜海量小文件的存储，但还是有几个问题待解决：
1) Index数据量太大：海量小文件会导致bucket index中的数据量增长过快，从而导致bucket index须要常常resharding，而在bucket index resharding过程中会阻塞读写申请，对于大多数不须要list bucket的场景，此问题能够通过应用indexless bucket解决。对于必须bucket index的场景，减少了程序散布的bucket index优化解决方案，此计划不在本文的探讨范畴内，会在前面的文章中进行介绍。
2) 扩容时须要数据迁徙：Ceph在数据扩容的过程中，须要对文件的地位进行从新哈希，并会带来大量的数据迁徙操作，数据迁徙过程中会带来微小的性能损耗。同时海量小文件的数据迁徙会消耗较长的工夫，如果在此过程中磁盘故障或机器故障，数据恢复的工夫将不确定，会带来极大的数据安全危险。
3) 存储效率问题：Ceph默认的最小调配单元为64KB，而以后小文件的均匀size为15KB。为了进步存储效率，能够将最小调配单元调整为4KB(读写性能会随之升高)。当应用纠删码的形式存储存储小文件，如(4+2)的纠删码，此时文件的最小调配单元变为6 * 4KB = 24KB。为了进步存储效率而采纳纠删码的形式存储小文件，反而更加节约存储资源。
为了解决Ceph存储海量小文件的问题，须要设计一个满足以下指标的零碎：
1) 高性能：分布式存储系统须要承载终端用户的读写需要，低延时地满足用户对数据的存取需要，是任何分布式存储系统的重要指标。
2) 扩容时防止大量的数据迁徙： 防止大量的数据迁徙操作减少对存储系统的负载，从而影响存储系统对终端用户的服务质量，也是该零碎设计的重要指标。
3) 放慢故障复原速度： 机器故障或磁盘故障会导致数据迁徙，海量小文件导致故障复原迟缓，故障复原的工夫越长，在此期间其余机器或磁盘产生故障的概率越大，数据失落的危险越大，因而放慢故障的复原速度也是零碎设计的指标之一。
4) 晋升存储效率： 海量的小文件会占用大量的存储资源，同时大量的文件通过一段时间后就会变成冷数据，如何晋升存储效率升高存储老本也是零碎设计的指标之一。
02零碎设计
目前业界解决海量小文件存储次要有以下的解决几种优化形式：
1) 硬件优化： 海量小文件的读写申请，瓶颈个别在机械硬盘上。硬件优化次要是采纳反对随机读写的SSD硬盘代替机械硬盘，能够显著进步海量小文件的读写性能。然而思考到老本因素，在数据量很大的状况下SSD硬盘个别只会在零碎做作为Cache存在。
2) 文件元数据管理优化：分布式存储系统中文件的元数据蕴含文件的地位信息，文件的size，创立工夫等。在读写小文件之前，都须要先失去文件的元数据信息，例如须要失去文件的地位信息能力到对应的存储节点上读写文件数据，只有拿到文件的size能力晓得须要读取数据的长度。为了减小拜访元数据的开销，应该尽量减少元数据的数量，元数据的数量越少，cache命中率越高，性能越高。
3) 小文件合并成大文件： 通过将大量的小文件合并成一个大文件，能够显著缩小文件的数量，也就缩小了元数据的数量，元数据的查问会更快。对于大文件机械硬盘能够做到程序读写，能够显著升高硬盘的负载。
本零碎联合以上的形式设计了一种基于双层存储池的小文件合并优化计划解决Ceph海量小文件存储的问题，其零碎设计如下图3所示：
零碎分为两级存储池，别离是高性能SSD正本存储池和大容量(正本/EC)存储池。能够配置不同的存储策略，将不同bucket或不同size的文件写到不同的存储池上。对于海量小文件优先写到高性能存储池中，这样能够保障小文件读写的高性能。
而后通过配置策略，开启合并性能将高性能存储池中的小文件合并成大文件存储到大容量存储池中。当大容量存储池中的闲暇空间有余时，减少新的存储节点创立新的大容量存储池，而不是对已有的存储池进行扩容，这样能够防止大量的数据迁徙操作对终端用户的读写申请产生影响。
对于大容量存储池，能够通过EC形式存储，晋升已合并的文件的存储效率。因为存储的是大文件，最小调配单元能够调整的比拟大，如：128KB，这样能够减小BlueStore中的元数据的数量，晋升性能。
03
对于以上的零碎设计，在具体实现上次要蕴含以下几个关键问题。
3.1 小文件的合并形式
将大文件看做一个Volume，每个小文件占其中的一个局部空间，如下图4所示：
将小文件程序的追加到Volume中，每个小文件在Volume中分成3个局部：
1) Header： 保留文件的一些元数据信息，如文件名，文件size，文件的校验信息，在Volume中的offset。
2) Data： 小文件的理论数据内容。
3) Footer： 保留固定的magic，做校验用。
3.2 数据从高性能存储池迁徙到大容量存储池
将数据从高性能存储池迁徙到大容量存储的具体形式，如下图5所示：
存储网关的操作日志会记录以后存储网关上的操作，操作日志依照bucket和工夫寄存，迁徙工具能够依照不同的bucket策略（如提早迁徙的工夫距离）去读取以后bucket的操作日志文件。具体的迁徙流程可分成4个步骤：
1) 读取操作日志： 依据bucket的迁徙策略，读取操作日志文件并解析每个操作，失去文件的名称和一些操作信息。为了反对并行的迁徙，能够将文件名通过hash形式放到多个队列中。
2) 读取文件内容： 从队列中的失去待处理的文件名，从高性能存储池中读取文件的数据。
3) 小文件数据写到大容量存储池： 从大容量存储池中申请一个Volume，将以后的小文件追加到Volume中，依照Header，Data，Footer的程序迁徙文件。
4) 删除高性能存储池中的文件数据： 删除高性能存储池中的文件数据，只是将数据清空，保留文件的元数据信息，并在元数据中增加以后小文件在Volume中的地位信息，不便前面读取数据时的检索。
3.3 文件读取
在文件的数据被迁徙到大容量存储池后，存储网关读取数据的流程也会随之变动，如下图6所示：
此时文件的数据内容存储在大容量存储池中，文件的元数据和文件内容的地位信息寄存在高性能存储池中，因而在读取数据内容之前，存储网关要先到高性能存储池中读取文件的地位信息。从读取流程上看，绝对于间接在大容量存储池中存储小文件减少了一次网络往返的开销，然而该计划有以下几个长处：
1) 大量的热数据曾经在高性能存储池中实现了读取操作，迁徙到大容量存储中的个别是冷数据，读取的申请会少很多。
2) 文件元数据的读取还是在高性能存储池中进行的，性能绝对间接在大容量存储池中好很多。
3) 该计划大容量存储池BlueStore的调配单元较大，BlueStore的元数3.4文件的删除和空间回收
文件的删除须要删除文件的数据内容和文件的元数据两个局部，文件的元数据在高性能存储池中寄存能够间接删除，而文件的数据内容只是大容量存储池中Volume的一部分，不能间接删除回收存储空间，因而将文件的删除和空间回收离开进行。
在服务终端用户的删除申请时，在Volume中找到对应的文件Header，并写入一个删除标记，示意文件曾经删除不能拜访，并批改以后Volume的无效size信息(理论存在的文件的size总和)，后续作为开始空间回收的判断根据。如下图7所示：
假如红色的Header示意以后的文件曾经被标记为删除。依据空间回收策略，如无效空间绝对Volume存储空间的占比小于50%，表明曾经删除的空间占比超过50%，此时须要对Volume进行Compaction操作，办法如下：
1) 扫描整个Volume外面的每个文件，如果曾经删除间接跳过这个文件。
2) 如果是没有被删除的文件，将文件的内容追加到新的Volume中，并批改高性能存储池中文件的元数据，批改地位信息从新指向新Volume中的地位。
3) 整个Volume扫描实现，无效文件迁徙结束后，删除以后的Volume大文件。
除了文件删除操作，文件批改操作也须要回收老的数据内容占用的空间，采纳相似的办法。在解决批改的操作日志时，将旧数据内容的Header标记为删除，在后续Compaction操作时回收这部分数据空间。
04评估
为了验证此设计方案的优化成果，在雷同的网络环境上搭建了两套分布式存储系统：
优化前零碎：
1) 3台服务器，每台部署5个机械硬盘存储节点，最小调配单元4KB。
2) 在15个存储节点上创立一个大容量3正本存储池。
优化后零碎：
1) 3台服务器，每台部署5个机械硬盘存储节点和一个SATA SSD存储节点，最小调配单元64KB。
2) 在15个存储节点上创立一个大容量3正本存储池，在3个SATA SSD存储节点上创立一个高性能3正本存储池。
3) 设置高性能存储池中的小文件在写入2小时后，主动迁徙到大容量存储池中，大容量存储池中的volume size默认为4MB。
能够从以下几个方面评估该设计方案的优化成果：
4.1热数据的读写性能
在海量小文件数据还没有迁徙到大容量存储池之前的性能比拟。
(1) 写入性能：
如下图8所示，别离在多种不同并发状况下写入1000万20KB文件的性能测试后果：
因为高性能存储池采纳的存储硬件是SATA SSD，尽管高性能存储池只有3个存储节点，大容量存储池有15个存储节点，优化后零碎的写入QPS仍然达到优化前的3倍。
(2) 读取性能：
如下图9所示，别离在多种不同并发状况下读取1000万 20KB文件的性能测试后果：
能够看到优化后零碎的读取QPS绝对优化前进步20%~30%，没有达到写入的优化成果次要是存储节点缓存的作用。
4.2冷数据的读取性能
数据在高性能存储池中写入后，依照策略数据变冷会迁徙到大容量存储池中，优化前和优化后(小文件合并之后)的读取性能比照后果如下图10所示：
因为小文件合并之后，文件的读取须要先到高性能存储池中读取元数据，而后到大容量存储池中读取文件的数据，实际上多通过了一次网络RTT，因而会导致肯定的读取性能降落，从后果看读取QPS降落了约12%。后续零碎会采纳性能更好的NVME SSD搭建高性能存储池进行测试。
4.3存储效率晋升
在优化后的零碎中，在小文件合并前与合并后，存储资源的应用状况如下图11所示：
合并前最小存储单元是64KB，因而一个20KB的文件也须要占用64KB的存储空间，而且是3正本，因而不算元数据须要的存储空间是：64KB * 3 * 10000000 = 1831GB。
合并之后的Volume size是4MB，1个20KB的文件，只须要占据20KB的数据存储空间加上大量元数据的存储空间，因而不算元数据须要的存储空间是：20KB * 3 * 10000000 = 572GB。
因而合并之后的存储效率是合并之前存储效率的3倍多。
4.4故障复原速度
同样的1000万文件，下线1个存储节点，此时会导致数据迁徙复原数据，齐全采纳默认的配置，优化前和优化后消耗的数据恢复工夫如下图12所示：
因为优化后大容量存储池中只寄存大文件，因而其复原速度比拟快，从后果看优化后的故障复原速度是优化前的16倍。
05论断
本文剖析了应用Ceph存储海量小文件的挑战和一些问题，并从硬件优化，元数据管理优化和小文件合并优化几个层面思考并设计实现了一套基于双层存储池的小文件合并优化分案，通过比拟能够发现新计划在读写性能，存储效率以及故障复原速度上都有较大的晋升。
发表回复