Atlas: 百度云的K/V存储系统

百度最近在MSST 2015发布的一篇介绍百度云使用的K/V存储系统Atlas的论文,详细介绍了系统的设计理念和思路,内容丰富,干货很多,有兴趣的务必读一下论文。本文简要介绍一下系统的设计,抛砖引玉。

系统的特点

百度云盘为每个用户提供了2T的使用空间,在这些数据的特点有以下

  • 百度云94%的文件在[128KB-256KB]之间,所以atlas主要针对小文件存储
  • 百度云前面有CDN,到达atlas的请求基本都是随机访问,atlas是随机访问的存储引擎,不支持range操作

架构

对外系统暴露三个简单的接口:
API

Architecture
在设计上系统分为两层,上层PIS(Patch and Index),负责文件到文件块的映射和临时数据的写入。
下层RBS(Raid-like Block System)用来实际存储数据。
用户在使用时,首先访问PIS的元数据服务器,获取PIS的路由表。接着通过文件名进行hash,在路由表中找到对应的PIS服务器,向其发出请求。

PIS系统

PIS是系统的入口,它提供基于文件的三个接口Put, Get, Delete。同时负责存储文件到文件块的索引,和临时数据块。
在设计上,它采用中心化设计,分为Master节点和数据节点。由Master负责管理全局PIS的存活情况和系统路由,数据节点负责存储索引文件。
PIS
上图为PIS模块图,为了保证数据的强一致性,用户请求到达PIS时,它将首先生成该文件对应的ID,接着经由复制模块,将此文件复制到两个从节点。
当复制完成后,PIS将数据写入临时的Block中。每个Block最大为64MB。
接着在Index中,记录此文件ID在临时Block的位置的偏移和文件长度
一旦Block超过64MB,将会对该文件进行打包不再修改,并经由RBSClient传给RBS。

Index采用定长形式存储,引擎采用LevelDB。
它的每个Key是128位全局独立ID。Value是由三元组成(BlockId, Offset, Length)。分别对应文件块ID,块上的偏移和文件的大小。
由于每条记录都很小,LevelDB在执行Compaction操作的代价也较小。

RBS系统

RBS负责文件块的存储,它提供文件块的写入,删除和指定文件块偏移和长度的读取。
它同样采用中心化设计,中央节点维护RBS节点存活情况和文件块到RBS的映射,以及数据迁移和灾难恢复。

为了保证系统的高可用性和存储,采用Erasure Code编码,Erasure Code之前广泛使用在RAID系统中,算法要求每次需要提供4个大小相同的块,并为其两个新的块。从而保证对于6个文件块,任意丢失两个及以下的块系统的数据仍然能恢复。
在将64MB文件快写入RBS中时,会事先划分成8个8MB的文件,编码后形成新的4个8MB文件,存在12个RBS数据节点中。
为了方便寻找这12个文件,此前生成的BlockedId最后4位会是0,再此处将分别填上从1-12的ID。
RBS客户端发出写入请求时,会首先通过中心节点,询问可以写入文件块的服务器地址,接着直接对数据节点发出写入请求,写入成功后通知RBS中心服务器。
为了防止部分节点出现故障影响文件块的写入,在写入12个文件之前,RBS客户端会首先向RBS中央节点请求15个IP,当有节点失败时,尝试下一个。

数据的读取流程

数据的写入

数据的写入
上图为数据的写入流程,Atlas客户端首先计算文件名对应的哈希值,从而找到对应PIS数据块。接着写入PIS的临时Patch文件块。
当写满后转由RBS进行处理,它首先进行分块后,存储在多个RBS数据节点中。

数据的读取

数据的读取
上图为数据的读取流程,同写入一样,也首先需要计算哈希值,找到对应PIS数据块。
PIS将首先检查该文件是否在Patch文件块中,如果在则立即返回。
否则通过索引文件,找到对应的Block块,向RBS发出读取请求。

删除数据的回收

RBS不提供数据删除的接口,每个文件块一旦形成不得修改。Atlas的删除是离线的,它首先只修改PIS上的索引,标记其位删除。
在后台利用MapReduce框架定时离线扫描PIS索引块,运算得到文件块的使用容量,从中找出使用量不足设定值的文件块,默认为80%。
找到指定的文件块后,将有用数据重新发送请求到Atlas系统中,并删除原有文件块。

总结

Atlas采用双层架构将文件索引和文件块的存储隔离,上层PIS负责文件到文件块的索引,下层采用RBS负责大文件块的存储。
上述架构能更好的分配系统资源,PIS采用大内存磁盘容量较小的机器,RBS则可采用性能低CPU,小内存大存储的系统,采用arm存储增加了机架存储密度。
同时索引和数据的分离,使得Levledb在做Compaction时损失较小,后端数据的负载均衡,迁移也更容易。

相比淘宝的TFS系统介绍采用单层架构,它具有很大的优势。

  1. 由于TFS数据块内文件索引也存在于数据节点中,为了保证效率,需要确保这些索引在内存中。但是由于块中存储文件大小不一,索引块所需的空间也不一致,难于对机器所需的内存进行评估。
  2. 由于索引块的大小不一,采用Erasure Code时,为了确保对其将造成很多资源的浪费。
  3. 在数据迁移时,索引文件也需跟随着迁移。而索引文件将会影响用户的访问,造成了此处逻辑的复杂。
  4. 当用户范文数据块时,如果出错时,将首先需要使用ErasureCode恢复索引文件,接着再通过索引文件找到对应的磁盘文件,再使用ErasureCode恢复。
    ErasureCode需要4个机器的数据,那么在数据块出错时,此次访问将需要8次服务器之间的请求。
    为了解决该问题TFS将数据IDX信息特殊处理,不再使用ErasureCode,而是全部存储在各个节点。此处逻辑变得复杂。
  5. 由于TFS文件的元数据信息需去到各个数据节点获取,在使用Hadoop离线处理时,相比Atlas有差距。