以“升舱”之名，谈谈云原生数据仓库AnalyticDB的核心技术

背景

说到升舱，我们首先想到的是飞机经济舱升级到商务舱、头等舱。阿里云企业级云原生数据仓库AnalyticDB（以下简称ADB）[1]在帮助以金融机构为主的行业数字化转型和传统数仓升级项目中，也引用了“升舱（仓）”这个概念。

长期以来，企业级数据仓库构建主要以Teradata、Oracle、DB2、Vertica、Greenplum等为主，这些系统一方面功能完备，稳定可靠，另一方面成本高，部分有专用硬件限制，同时需要应对业务几何级数据量规模增长。以Hadoop生态为代表的的大数据系统主要解决了数据分析的大规模数据量问题，在功能完备性，易用性和维护性上与这些传统数仓相比，还是有差距。所以大部分金融机构都是在保留已有MPP数仓核心业务的基础上，尝试部署Hadoop系统用于创新业务探索，同时解决数据增长带来的成本问题。

近年来，一方面国外涌现出了以AWS Redshift，Snowflake，Google BigQuery，Azure Synapse为代表的云原生数仓（公共云形态），有对传统数仓和Hadoop系统线下形态的替代和革命之势。另一方面随着上述传统数仓大厂在国内技术市场投入的减少，叠加政策等因素，同时金融、运营商等行业面临数据规模增长，数字化转型，和传统数仓升级需求，需要选型下一代数据管理和分析系统，另外由于国内外市场和政策的区别，我国金融、运营商、政务等行业的数仓构建，主要以混合云为主。

在此背景下，企业级云原生数据仓库AnalyticDB提出了升舱计划，旨在承担和帮助金融、运营商、政务等行业构建下一代数据管理和分析系统，以应对不断增长的数据规模，业务数字化转型，和传统数仓替换升级需求。7月19日，“千仓万库，轻云直上——阿里云数据库升舱计划实战峰会”即将在线上召开。

产品介绍

整体架构

AnalyticDB PostgreSQL版（简称ADB）在开源Greenplum[2]和PostgreSQL[3]基础上进行自主研发，语法层面对两者保持兼容，功能层面为开源Greenplum超集，同时兼容大部分Oracle、Teradata语法与功能，支持业务应用以尽可能少的改造工作量对已有数仓业务进行迁移升级。其整体架构如下图：

图1 整体架构

ADB由协调节点和计算节点两大组件构成，协调节点负责全局事务管理，全局元数据存储，SQL解析，重写，优化，执行计划生成与调度，计算节点主要包含执行引擎和存储引擎，其中执行引擎既支持Greenplum/PostgreSQL功能强大的原生引擎，又支持数据分析场景性能优化的自研向量化引擎，多态化存储引擎则支持本地行存堆表、列存压缩表，和外部表，以及基于存储计算分离架构下的云原生表。协调节点和计算节点通过双副本保障高可用，同时通过水平和垂直扩展提供计算和存储资源的线性扩容。

ADB与阿里云生态系统高度集成，支持以OSS为备份存储介质的分布式一致性备份恢复（包括全量和增量备份），同时支持通过DBS备份到NAS，HDFS等第三方存储介质。对于存储在OSS上的ORC，Parquet，JSON，CSV格式用户数据，和MaxCompute上的用户表和分区，支持并行高速并行导入加载到本地，或者通过列过滤、谓词下推直接对OSS上的数据进行数据湖分析。在云原生架构形态下，云原生表则在计算节点本地则只有缓存数据（计算节点无状态化），全量数据存储在低成本的OSS上。

使用场景与生态集成

上面描述了ADB的整体架构和内部组件，传统数仓迁移替换，或者构建下一代数据管理分析系统，除了要具备高可用易扩展的分布式系统架构和功能完备性能出众的内核引擎外，还需要有开放的生态集成和管理工具配套。下图从数据同步，到数据加工，再到数据查询分析，端到端描述了ADB在数据处理各个阶段的生态集成，配套工具和场景支持能力。

图2 使用场景与生态集成

1、数据同步阶段，数据通过实时写入或批量加载方式入库，形成ODS（Operational Data Model）层。典型的数据源包括：MySQL/SQL Server/PostgreSQL/Oracle等OLTP业务数据库，业务App产生的实时数据，在OSS/MaxCompute/Hadoop上的归档或原始数据，以及来自Kafka/Flink等的流式数据。ADB通过MVCC，两阶段提交(2PC)，和全局事务管理(GTM)机制提供分布式事务能力(默认隔离级别Read Committed)，同时在实时写入场景支持Upsert覆盖写(Insert on Conflict，功能等同于Oracle的Merge Into)，批量导入场景支持外表，文件，自定义程序输出等多种并行高速加载。

2、数据加工阶段，在库中对ODS层数据进行加工，形成CDM（Common Data Model）和ADS（Application Data Service）层，典型操作包括INSERT INTO SELECT, CREATE TABLE AS等。

3、数据查询分析阶段，按业务需求对库中数据进行查询分析，或供下游系统消费处理，典型的查询分析场景包括交互式分析，BI报表，数据类业务应用等。ADB既通过存储引擎索引排序等特性支持高并发低延时的多维度点查范围查场景，也通过向量化执行引擎，CBO自适应优化器，列式存储支持大数据量多表关联聚合的复杂分析场景。

产品形态与硬件平台

ADB除了在公共云提供国内和国际站的SaaS服务外，也通过阿里云飞天企业版(ApsaraStack)和敏捷版(DBStack)支持混合云输出，满足线下部署需求。

与部分传统数仓需要专有硬件平台不同，ADB本身支持x86通用硬件部署，同时也支持Arm架构，以及国产化鲲鹏平台，海光处理器，麒麟系统等。通用硬件和国产化平台的支持，也是金融等领域数仓升级的重要参考因素。

核心技术

通过上面概括性的产品介绍，我们对ADB的整体架构，使用场景与生态工具，产品形态与硬件平台支持有了基本了解。下面进一步深入到其在“升舱”项目中的部分硬核技术，包括自研向量化执行引擎，多态化存储引擎，基于代价的自适应优化器，租户间不同实例和租户内不同负载的资源隔离，以及存储计算分离形态的云原生架构。

向量化执行引擎

PostgreSQL在上世纪八十年代诞生时数仓分析OLAP场景尚未出现，其主要用于处理OLTP场景，执行引擎是Record-Oriented（Tuple-at-a-time）的火山模型，Greenplum在PostgreSQL基础上构建了MPP分布式数据库，在执行引擎层引入了Motion节点，使得集群中每个计算节点都能像单机PostgreSQL一样运行，共同完成由协调节点下发的SQL分布式执行计划，最终通过协调节点汇总返回查询结果，通过分布式并行执行大大提升了单机PostgreSQL的性能瓶颈。但在每个计算节点执行引擎内部，依然是PostgreSQL原生的Record-Oriented模型（即每个算子每次处理一条记录），该执行模型对与以点查或少数据量处理场景为主的TP场景没有问题，但对于以大数据量处理场景为主的OLAP场景，单条记录处理的开销较大，综合性能和效率较低。后期基于Postgres构建的数据分析系统，如Redshift，Vertica，Vectorwise（准确来说是基于Postgres的前身Ingres），都对PG原有执行引擎进行了替换改造，Redshift主要是基于Code Generation（JIT, Just-in-Time Compilation）和Vectorized Scan，Vectorwise则是纯粹的向量化执行。PostgreSQL 11也支持了表达式的JIT[4]，用以加速SQL中的表达式处理。

ADB在保留原生Greenplum/PostgreSQL引擎的同时，自研了Block-Oriented(Batch-at-a-time)向量化执行引擎，用于处理大数据量分析场景。下图以两边关联后做聚合的简单SQL为例，做了两者对比。

图3 执行模型：Record-Oriented V.S. Block-Orientend

对比Record-Oriented通过getNext()接口每次获取和处理一条记录，Block-Orientend模式通过getNextBlock()接口每次获取一批记录，同时每个执行算子综合运用向量化(Vectorization)[5]和即时编译(JIT)[6]技术，对这一批记录执行相同处理逻辑，从以下收益出发，获得更高效的资源使用，更快的执行性能：

• 每次读取和使用相同逻辑处理一批记录数据，能获得更高的CPU指令和数据缓存命中率[7]。
• 从一次函数调用处理一条记录，到一次函数调用处理一批数据，同时JIT则直接避免了函数调用，总体函数调用次数和开销[8]减少。
• 内存的分配回收，也从每条记录的分配回收，到每批记录的分配和回收，整体减少内存分配回收次数和碎片管理开销[9]。
• 在按批处理模型下，代码实现能更好地以向量化方式实现，一方面有利于CPU进行数据预取，另一方面尽可能减少程序的条件跳转（来自if...else...，switch等分支判断）和无条件跳转（来自函数调用），让CPU获得更好的指令流水线执行[10]，减少分支预测[11]失败，同时也有利于编译器生成SIMD[12]指令，提高执行效率。

下图分别展示了ADB Vectorization在分组聚合SQL场景进行算Hash，桶寻址，求Sum步骤的列式向量化执行示例，和JIT在扫描过滤SQL场景进行表达式计算的示例。

图4 Vectorization与JIT实现示例

向量化按批读取和处理的行为，在本批次中让需要处理的数据和处理指令都驻留在CPU L1/L2 Cache中，在缓存命中情况下性能为从内存读取的10~30倍[13]，同时对该批次数据进行相同指令的处理，也能让CPU更好的流水线执行，减少CPU Hazards[14]。JIT代码生成针对表达式处理场景，则直接避免了解释执行模式下的函数高频函数调用（Function Calls）。

多态化存储引擎

PostgreSQL原生存储引擎为堆表（Heap Table）[15]，主要为OLTP场景，核心组件包含默认8KB为单位行级MVCC的数据页Page，缓存管理器Buffer Manager，和预写日志WAL，以及以Btree为主的索引。Greenplum基于PostgreSQL构建了分布式数据库，主要为OLAP场景，在存储层主要做了如下技术改造：

1、协调节点新增全局元数据和全局事务状态管理，以支持分布式架构下在协调节点的事务管理，SQL解析和执行计划生成等需要读取元数据系统表的操作。

2、新增分布式架构下表的水平分布机制&#