背景

2015年7月，PetaData分布式数据库开放了低成本存储体系，随后便服务了天象等多个大数据业务，这些业务存量数据在数百T，日新增10T，新增数据大多是秒级监控数据，既要数据实时可见，又要支持多维度低延迟查询，还要大幅降低成本。

在PetaData第一代低成本存储体系中，融合了ApsaraDB团队多年的技术积累，包括方寸山分布式框架、MySQL TokuDB存储引擎、低成本机型等技术，最极限的一个业务，使用了少量sata盘机型满足了存量400T+，日新增数据10T+的更新需求，以及热数据查询毫秒级，冷数据查询亚秒级的查询需求。

随着业务的不断发展，第一代存储体系面对P级存量、日新增百T的数据业务，已经力不从心，PetaData不断探索，开发出了第二代低成本存储体系，本文将从多个角度进行介绍。

存储架构

  • 整体外观

    PetaData利用数据sharding的思想，将业务数据分布在多个MySQL实例上，这些MySQL实例是ApsaraDB团队为PetaData深度订制的存储引擎，实例间share nothing，从而支持水平扩展。整套系统运行在全新设计的软硬件一体资源容器中，并配套开发了改进的运维体系。

图1. PetaData数据分区

图中的关键技术包括分布式、单机存储引擎、迁移、软硬件结合等部分。

  • 分布式

在分布式层，PetaData利用了分库分表的思想来支持数据sharding，数据被切分到若干数据库分库上，在MySQL的物理迁移和多主复制基础上开发了快速扩容。

  1. 数据分区 数据分区是大数据的普遍策略，PetaData的数据入口Proxy，将用户的请求路由到各个存储分区上，以达到性能的线性扩展。

    图2. PetaData数据分区

    由于数据分区间share nothing，对于一些多分区更新和查询会有一定的限制，这主要从两个方面弥补：多分区的更新通过分布式事务来支持，多分区的查询通过计算引擎来支持。

  2. 数据扩容

    传统分库分表中间件，在数据扩容时，需要将所有数据整体做逻辑导出导入，整体开销很大，为了避免影响用户业务，也要将多个源分区产生的增量更新，复制到目标分区上，这对于单复制通道的数据库极为复杂，甚至可能要分时复用复制通道。

    PetaData将扩容分为全量迁移和增量复制二个阶段：在全量迁移阶段，使用MySQL的物理迁移，在分区间直接拷贝存储引擎的数据文件，大幅提升全量迁移的性能；在增量复制阶段，使用MySQL的多主复制，以供单个分区从多个分区复制增量数据，避免分时复用带来的复杂性；整个扩容方案干净而高效。

  3. 异步聚合

    第二代架构下，PetaData在Proxy处支持了异步聚合能力，用户session的更新请求，送入每个存储分区的异步队列后便返回，由异步刷写线程存储分区递送请求，用户的session可以快速发出下一批请求，从而与异步刷写线程的工作时序重叠起来，既提升了吞吐量，也降低了写rt。

    异步刷写线程，也可以将同个分区的写请求，打包成一个请求，送入存储分区，减少存储分区的事务开销，有效提升存储分区的吞吐率，异步聚合并不兼容传统数据库的隔离级别定义。

    在存储分区压力过大，异步线程来不及刷写时，异步写会退化为同步写，此时用户session会暂时阻塞在单次的写请求上，此时rt会增大，也代表着存储分区带宽打满了。

  • 单机存储引擎

PetaData的单机存储引擎，使用了MySQL-TokuDB引擎，该引擎支持事务，写性能强劲，压缩比高，非常适合大数据业务场景。

图3. PetaData使用的TokuDB存储引擎

  1. 异步更新

    TokuDB引擎的数据结构为缓冲B树，每个中间节点均带有更新缓冲，写入时无需将更新实时刷入叶节点，而是缓存在中间节点，然后整批向下层合并。整个过程因为事务WAL的存在，数据无需实时写盘，而redolog本身近乎顺序写，对sata盘亲和度很高，使得低成本机型有了很大的应用空间。

    最优情况下，写入根节点后，立刻返回。然后TokuDB的异步线程逐步将更新合并到叶节点，后续查询从叶节点取回数据；

    最差情况下，写入根节点后，进行唯一性检查，从磁盘取回页面数据并更新，写延迟增大。写返会后，立刻查询，此时只能由读过程负责合并，增大读延迟；

    第二代架构下，ApsaraDB团队先后为TokuDB增加了事务级并行复制等Patch，使得PetaData能适应更多的大数据场景。

  2. 压缩

    TokuDB的缓冲B树节点，页面为4M，内部支持压缩，即使带上索引，日常压缩比也通常高达4以上，这也变相地降低了大数据用户的成本。目前TokuDB支持的压缩算法，包括zlib、snappy等，用户可以根据需要进行选择，也可以支持快速的变更。

  • 迁移

  1. 流式全量/增量迁移

    ApsaraDB的传统迁移方案，需要先对数据库进行热备（热备的数据包括数据库完整的全量数据，以及热备全量数据过程中产生的增量更新），将热备出来的数据完整上传到外部后备存储后，在将热备导入目标机器上。整个过程耗时很长，也易受网络带宽限制。

    第二代架构下，ApsaraDB团队设计了新的流式迁移模型，将热备出来的全量数据，实时导入目标机器上，时间开销大幅缩减。为了避免在迁移热备数据时，过大的增量更新占满磁盘，热备过程中需要将binlog实时传递到外部后备存储，在热备完全进入目标机器后，再重放这部分binlog。此方案可以应对大全量、大增量的更新业务。

  • 软硬件结合

为了尽可能优化PetaData的存储体系，ApsaraDB团队也将硬件机型纳入到存储体系的范畴，PetaData也为低成本存储体系选择了更合适的硬件。

  1. 混合存储

    早在阿里去IOE时代，集团就考虑过ssd盘+sata盘组flashcache的混合存储方案，此方案在大部分场景下，既有ssd盘的访问性能，又有sata盘的容量，成本也较为可控。

    第二代架构下，PetaData选择了类似的混合存储方案，来进一步提升整体存储的性价比。新的混合存储更加稳定，且拥有更强的弹性。

  2. 万兆网络

    随着ApsaraDB数据库服务规模的扩大，网络带宽的需求愈发旺盛。PetaData的存储分区也处于这些数据库实例中。与ApsaraDB的其他关系型数据库产品不同，PetaData要解决高并发读写的问题，而读写一次数据，往往需要为外部运维、审计等功能成倍的放大读写请求，也会严重增请求的流量。

    第二代架构下，PetaData接入了万兆网络，更高的带宽，可以极大提升备份和迁移的速度，改进产品的副本恢复策略，提升SLA。

展望

PetaData定位为HTAP分布式数据库，所谓HTAP，即为Hybrid Transactional/Analytical Processing，使用一份数据同时支持OLTP在线事务与OLAP在线分析，为此，PetaData团队还在如下几个领域不断耕耘着：

  • 计算架构

PetaData支持的OLAP测试集包括TPC-H、TPC-DS等，并将OLAP业务划分为：

  1. 实时高并发类型：上万级qps，秒级rt，两阶段计算迭代可以完成，数据可预建模；

  2. 在线复杂分析类：个位数级qps，秒级到小时级rt，需多轮计算迭代可以完成，数据无法预建模；

这几类业务运行在一套计算引擎框架上，辅以列存索引加速计算性能，极大地扩展了PetaData的计算能力。

  • 分布式事务

PetaData在跨分区更新时，需要通过分布式事务来保证，PetaData的架构中，有分布式事务协调者，配合各个存储分区的事务引擎，共同支持了两阶段提交分布式事务。

结语

在新的存储体系下，PetaData进一步改进了系统的吞吐量和rt，降低了成本，以迎接百T日新增数据的时代。

融合了大数据技术的PetaData，已经不仅仅是一个数据库，而更像是一类综合数据服务容器，让用户将更多精力放在大数据本身上，而无需关注外围的成本、存储、计算、一致性、可用性、接口等问题，降低了大数据的门槛。

PetaData的技术团队，致力于数据服务容器本身的改进上，打造出精致的分布式数据库服务，以迎接未来大数据的挑战。