从托管到原生，MPP 架构数据仓库的云原生实践

一 前言

Garner预测，到2022年，所有数据库中有75%将部署或迁移至云平台。另外一家权威机构IDC也预测，在2025年，超过50%的数据库将部署在公有云上，而中国则会达到惊人的70%以上。云数据库经过多年发展，经历从Cloud-Hosted （云托管）到 Cloud Native（云原生）模式的转变。

Cloud-Hosted：基于市场和业界的云需求，大部分厂商选择了云托管作为演进的第一步。这种模式将不再需要用户线下自建IDC，而是依托于云提供商的标准化资源将数据仓库进行移植并提供高度托管，从而解放了用户对底层硬件的管理成本和灵计划资源的约束。

Cloud-Native：然而随着更多的业务向云上迁移，底层计算和存储一体的资源绑定，导致用户在使用的过程中依然需要考量不必要的资源浪费，如计算资源增加会要求存储关联增加，导致无效成本。用户开始期望云资源能够将数据仓库进行更为细粒度的资源拆解，即对计算，存储的能力进行解耦并拆分成可售卖单元，以满足业务的资源编排。到这里，云原生的最大化价值才被真正凸显，我们不在着重于打造存算平衡的数据仓库，而是面向用户业务，允许存在大规模的计算或存储倾斜，将业务所需要的资源进行独立部署，并按照最小单位进行售卖。这一刻我们真正的进入了数据仓库云原生时代。

阿里云在2021云栖大会上，预告了全新云原生架构的数据仓库【1】。本文介绍了云原生数据仓库产品AnalyticDB PostgreSQL（以下简称ADB PG）从Cloud-Hosted到Cloud-Native的演进探索，探讨为了实现真正的资源池化和灵活售卖的底层设计和思考，涵盖内容包括产品的架构设计，关键技术，性能结果，效果实现和后续计划几方面。（全文阅读时长约为10分钟）

二 ADB PG云原生架构

为了让用户可以快速的适配到云数据仓库，目前我们采用的是云上MPP架构的设计理念，将协调节点和计算节点进行独立部署，但承载于单个ECS上，实现了计算节点存储计算一体的部署设计，该设计由于设计架构和客户侧自建高度适配，可快速并无损的将数仓业务迁移至云上，对于早期的云适配非常友好且满足了资源可平行扩展的主要诉求。

随着云原生的进一步演进，我们提供了全新的存算分离架构，将产品进一步拆分为服务层、计算层和共享存储层，架构图如下：

Master协调节点：保存全局的schema信息，并实现了全局事务管理；

行存引擎：用来保存元数据信息，这里的元数据信息主要指共享存储文件的可见性信息，包括两个部分：

• 一个是文件与表的关系
• 另外一个是被删除的数据的delete bitmap

基于行存我们可以继承PG的本地事务能力，在增删改查的同时，与PG的事务能力完全兼容；

本地缓存：通过引入存储团队的DADI来实现高性能的本地缓存，DADI全称是Alibaba Cloud Data Accelerator for Disaggregated Infrastructure，相比开源产品，性能有数量级的提升；

共享存储：我们借鉴了ClickHouse的一些关键设计，在存储层实现了一个基于MergeTree的行列混存，此外我们对共享存储基于文件接口做了一层统一访问接口，同时高度适配了OSS和HDFS 两种形态的分布式文件系统；

当我们在架构设计的时候，和同样源自Greenplum的HAWQ对比，HAWQ把元数据都保存在master，在每次写的时候，把修改的元数据带到master来更新，读的时候，先从master读取需要的元数据，然后在执行计划里面把元数据都带上，这样segment就能拿到对应的元数据， 同时segment可以完全无状态。

但是这个设计会带来2个核心问题：

1. 元数据膨胀导致master成为瓶颈。
2. 受限于元数据的性能，无法支持高并发的实时写入。

而我们不这样设计做的原因是我们希望在未来能够支持高并发的任务，ADB PG大概花了2年多的时间，将Greenplum的单点master架构拓展为multi-master，核心是为了解决高并发实时写入的问题，如果把元数据都保存在master上会带来如问题：

1. master上面的元数据存储和访问容易形成单点瓶颈
2. 需要对ADB PG的执行层做大量的重构，实现在执行计划里面把元数据都带上，这会急剧的增加查询计划本身的带宽，这个对于高并发的小查询非常不友好。

所以我们改进了架构，将元数据分散到segment，规避并实现了：

1. master的存储和读写都不会成为瓶颈
2. 无需对执行层做重构，将元数据分散减少单次查询的带宽压力。
3. 将segment上的元数据放到分布式kv上，解决扩缩容的元数据搬迁问题。

共享存储使用OSS的原因在于，随着单个用户业务数据不断增长，需要一个可持续发展的存储方案，而OSS的低存储成本，高可用性和数据持久性是最好的选择。

使用OSS的另外一个好处在于按需付费，用户不需要预制存储空间大小，存了多少数据，付多少钱，数据删除后即不再收费；ESSD云盘通常需要根据数据计算存储水位，无法做到将存储资源真正的按需供应，而且无法自动缩容，这些都违背了我们云原生的设计理念。但同时OSS的劣势在于RT:

为了解决OSS的RT问题，我们为计算节点配置了一定比例的本地盘，用来做访问加速。此外，我们设计了一个高性能的行列混存，借鉴了ClickHouse mergetree存储的核心思想，以有序为核心，文件内绝对有序，文件与文件大致相对有序，通过merge的异步操作，实现文件和并和排序，基于有序，我们在文件内设计了3层的统计信息，并做了