|
通俗地讲，云计算就是把基础设施以服务的形式打包对外销售，它是一种商业模式，而其中的云存储是技术难点。可以从两个维度分析云存储系统的特 性：功能和可扩展性，这是一个“鱼和熊掌”不容易兼得的问题。不同的数据规模，不同的事务和一致性要求，不同的系统故障容忍度，都可能导致不同的存储系统 设计。国外的互联网巨头 Amazon、Google、Microsoft、Yahoo 都有各自的云存储系统，国内的淘宝也研发了自己的云存储系统 Oceanbase，并开始应用到联机事务处理 OLTP（On-line Transaction Processing）和联机分析处理 OLAP（On-line Analytical Processing）业务。 云存储系统数据结构 为了保证存储系统的可靠性，需要将数据复制为多份。当数据规模增加时，我们可能会对传统的数据库分库分表以水平扩展，很多企业还开发了各自的数 据库中间层以屏蔽分库分表规则。然而，在传统的分库/分表架构下，每一份数据只能为一组 Master-Slave 节点服务，这就导致同一组机器节点存放了完全相同的数据，当其中某个节点发生故障时，只能通过所在机器组中的节点进行故障恢复，这样的系统称为同构系统。 云存储系统一般指异构系统，每份数据可以被动态分配到集群中的任意一个节点，当某个节点发生故障时，可以将故障节点原有服务动态迁移到集群中的任何一台机器。只有实现系统异构才能发挥分布式集群的规模优势，减少集群运维成本，适应云存储系统数据量快速增长的需求。 数据结构决定了云存储系统的功能，云存储系统的数据结构主要有两种：分布式 Hash 表和分布式B+ 树，如图 1 所示。分布式 Hash 表通过比如一致性 Hash 的方式将数据分布到集群中的不同节点，数据随机分布，不支持范围查询；而分布式B+ 树的数据连续存放，支持范围查询，但是需要支持分裂和合并，实现相对较为复杂。
图 1 云存储系统分类图 常见的 Key-Value 系统的数据结构一般为分布式 Hash 表，只支持基本的 Put、Get 和 Delete 操作，比如 Amazon 的 Dynamo 和 S3 系统。而 Amazon Simpledb 按照 domain 进行数据划分，规定同一个 domain 数据量不能超过 10GB，从而可以存放到一个数据节点，用户只允许在同一个 domain 内部执行范围查询操作。Amazon 的云存储系统看起来不完美，但相当实用。 Google 的系统设计之初就强调可扩展性。从最初的 GFS 到 BigTable，再到后来的 Megastore、Percolator，Google 先将系统的可扩展性发挥到极致，以后再逐步加入分布式事务、SQL 支持等功能。这样的设计得益于 Google 强大的工程师团队和公司一直以来崇尚通用系统的文化。Google 的云存储分为两层：分布式文件系统 GFS 和分布式数据库系统 BigTable，GFS 是一个带有追加功能的分布式文件系统，BigTable 将事务的提交日志追加到 GFS 中做持久化。数据在 BigTable 内连续存储，逻辑上构成一棵分布式B+ 树，Megastore、Percolator 又在 BigTable 的基础上加入分布式事务、索引、SQL 支持等功能。Google 的系统设计比较贵族化，可以远观，但模仿前请三思，比如将系统分成多层可能会增加用户操作的延时，对工程师的设计编码能力提出了更高的要求。 Microsoft SQL Azure 是一个传统数据库厂商在云存储系统设计上给出的答案。当数据量增长时，必然要求牺牲部分功能来换取可扩展性，这对于 Microsoft 是不愿意看到的。Microsoft 直接在原有的关系型数据库 SQL Server 上进行分布式扩展，尽可能多地支持 SQL 功能，其功能非常丰富，但系统内部不支持 SQL Azure 实例的分裂和合并。因此，SQL Azure 内部也限制了单个 SQL Azure 实例允许的最大数据量，如 Business Edition 的最大数据量不超过 50GB。相比 Google 的系统，Microsoft 系统的扩展性较弱，但功能较强。 云存储系统的难点在于状态数据的迁移和持久化，状态数据也就是系统的事务提交日志。Google BigTable 通过分布式文件系统 GFS 持久化提交日志，Microsoft SQL Azure 直接将提交日志通过网络复制到数据的多个副本，而 PNUTS 通过 Yahoo!内部的分布式消息中间件 Yahoo! Message Broker 持久化提交日志。Yahoo!没有对外提供云存储服务，但这样的设计可扩展性也是相当不错的。 淘宝 Oceanbase 架构设计 淘宝 Oceanbase 是从 2010 年 5 月开始研发的，其定位是解决淘宝内部在线业务的云存储问题。我们在设计系统时，总是考虑现在及今后一段时间的需求。互联网业务大致可以分为 OLTP 和 OLAP 两类，对在线存储的需求简单归纳如下。
OLTP 和 OLAP 业务对性能的要求使我们必须采用分布式方案。另外，淘宝的业务发展迅猛，传统的分库/分表方法带来的扩容及运维成本太高，必须构建异构的云存储系统。通过 进一步分析在线业务，我们发现互联网在线存储业务有一个特点：数据量虽然很大，但新增数据量比较小，每天新增数据量基本在 1TB 之内。此外，淘宝的业务面临一些其他挑战，比如需要高效支持跨行跨表事务，需要支持两张几亿到几十亿条记录的大表进行联表操作。淘宝的海量数据以及复杂的 功能需求对存储系统的设计提出了新的挑战，关系型数据库在数据量上有点儿力不从心，而云存储系统又不能高效地支持复杂的功能要求。因此，需要融合关系型数 据库的功能和云存储系统的可扩展性这两个优点。 如何借鉴已有技术满足淘宝未来一段时间内的云存储需求？如果直接模仿国外的互联网巨头，比如模仿 GFS + BigTable，淘宝的团队确实有一定的经验。然而这样的系统在两年之内很难稳定，并且不能满足跨行跨表事务等复杂的功能需求。既然在线业务新增数据量 比较小，那是否可以把最新修改的数据和以前的数据分离呢？ 答案是肯定的。淘宝 Oceanbase 将数据分成动态数据和静态数据两部分：动态数据的数据量较小，侧重 TPS 和 QPS，采用集中式的方法存放到单个节点的高品质存储介质，如内存和 SSD；静态数据的数据量很大，侧重存储容量，采用分布式的方法将数据分布到多台普通 PC 服务器的磁盘或者 SSD。由于动态数据的存储介质成本较高，需要不断地将动态数据合并到静态数据中，从而分布到多台机器以实现分布式存储。 淘宝 Oceanbase 系统架构大致如图 2 所示。从图 2 可以看出，系统有以下几个主要模块。
图 2 Oceanbase 架构图
写事务只操作 UpdateServer，读事务需要同时读取 ChunkServer 和 UpdateServer。某些操作，比如 OLAP 分析型操作可能需要涉及多个 ChunkServer 上的数据，这时将引入一个新的 MergeServer 模块将请求拆分到不同的 ChunkServer，合并每个 ChunkServer 的返回结果后执行排序、分组、分页等操作。静态数据在 ChunkServer 中保存三份，UpdateServer 通过 Linux HA 的方式进行双机热备以保证可靠性。RootServer 的访问压力很小，一般可以和 UpdateServer 部署在相同节点上，并采用相同的 Linux HA 方式。Oceanbase 的 UpdateServer 在同一个 IDC 机房采用实时同步的方式保证强一致性，这意味着写事务只有等到主机和备机都操作成功后才返回客户端。Oceanbase 支持跨 IDC 机房的异步准实时热备，多个机房之间的数据延迟为秒级。 Oceanbase 的静态数据和 BigTable 类似，数据被分为几十到几百 MB 不等的子表，每个子表的磁盘存储格式为 SSTable，通过 bloom filter、block cache、key value cache 等方式进行优化。SSTable 支持根据 column group 按列存储，从而高效地支持 OLAP 分析。动态数据采用 copy-on-write 的方式实现了单机内存中的B+ 树，在单写多读的应用场景下不需要加锁。 Oceanbase 静态数据构成一棵分布式B+ 树，动态数据为单机B+ 树。与线下 MapReduce 批处理应用不同，在线存储应用的更新量一般比较小，动态数据服务器不会成为性能瓶颈。这也就意味着，淘宝 Oceanbase 用一种更为简便的方式在底层实现了和其他互联网巨头类似的B+ 树数据结构，并且能够高效地支持跨行跨表事务。当然，当数据量增长到万亿级或者数据更新更快时，需要考虑将动态数据服务器的方案由集中式修改为分布式。我 们也考虑过多 UpdateServer 方案的设计，但由于短期内看不到明确的需求，暂时没有实现，目前我们认为可以通过硬件的方法，比如万兆网卡、更好的 CPU、更大的内存和 SSD 来解决。 Oceanbase 还实现了一些分布式系统中常见的特性，比如自动负载均衡、在线修改 Schema、内置压缩解压缩等。另外，Oceanbase 系统里面没有随机写操作，因此天然适应 SSD 存储介质，很好地弥补了磁盘的 IOPS 不足这个问题。 Oceanbase 应用效果和经验 Oceanbase 首先应用在淘宝收藏夹并取得了明显的效果。淘宝收藏夹最初采用 MySQL 分库/分表的方式实现，通过使用 Oceanbase，机器数由原来的 16 台主加上 16 台备共 32 台减少到 12 台静态数据服务器加上 2 台动态数据服务器，大大节省了机器资源。另外，目前应用的很多问题在 Oceanbase 中是通过更好的架构来解决，单机层面基本没做优化，相信后续还有很大的提升空间。在这过程中，我们也积累了一些经验教训。
展望 Oceanbase 目前的主要工作是应用推广，根据应用的需求来逐步完善 Oceanbase 系统，实现互联网数据库的构想。我们已经开始和淘宝的业务团队开展了千万级数据秒级实时分析的 OLAP 项目。另外，Oceanbase 还在考虑整合分布式 Blob 存储系统。随着应用推广的深入和 Oceanbase 系统的优化，希望能在合适的时间进行数据库新基准 TPC-E的测试。 另外一个振奋人心的消息是：Oceanbase 将在合适的时间点开源。相信通过业界同仁一起努力，一定能够将云存储这个问题解决好！ 作者杨传辉，花名日照，淘宝存储系统专家，热衷于分布式存储和计算系统设计，对分布式系统理论和工程实践有比较深厚的理解。之前在百度作为核心成员主导或参与 MapReduce、BigTable 和分布式消息队列等底层基础设施架构工作。 |
|
|
