在3月2日的阿里云开源 PolarDB 企业级架构发布会上，阿里云 PolarDB 内核技术专家严华带来了主题为《PolarDB HTAP详解》的精彩演讲。在PolarDB存储计算分离架构的基础上，我们研发了基于共享存储的MPP分布式执行引擎，解决了单条SQL执行时无法利用其它节点计算资源、无法发挥共享存储池的IO大带宽的问题，同时提供了弹性计算，弹性扩展的保障，使得PolarDB初步具备了 HTAP 的能力。本议题主要介绍PolarDB HTAP的功能特性和关键技术。
直播回顾视频：https://developer.aliyun.com/topic/PolarDB_release
PDF下载： https://developer.aliyun.com/topic/download?id=8353
以下根据发布会演讲视频内容整理：
一、背景
很多PolarDB 的用户都有 TP 和 AP 共用的需求，他们白天使用 PolarDB处理高并发的 TP 请求，晚上 TP 流量下降、机器空闲后继续使用 PolarDB 进行 AP 的报表分析。但是，即使这样，依然没有最大化利用空闲机器资源。
因为原生的 PolarDB PG 系统在处理复杂的 AP 查询时会遇到两大挑战：首先，单个 SQL 在原生 PG 执行引擎下只能在单个节点上执行，无论是单机串行还是单机并行，都无法利用其他节点的 CPU memory 等计算资源，只能纵向 Scale Up，不能横向 Scale Out ；其次，PolarDB 底层是存储池，理论上 IO 吞吐是无限大的。而单个 SQL 在原生 PG 执行引擎下只能在单个节点上执行，受限于单个节点的 CPU 和 memory 的瓶颈，无法充分发挥存储侧大 IO 带宽的优势。
为了解决用户实际使用中的痛点，PolarDB 决定做 HTAP。 当前业界HTAP的解决方案主要有以下三种：
① TP 和 AP 在存储计算上都分离，能够实现TP和AP完全隔离，互不影响。但实际使用中会存在一些问题。首先，TP的数据需要导入到AP系统中，会存在一定的延迟，导致时效性不高；其次需要增加冗余的 AP 系统，总成本也会增加；第三，增加了一套 AP 系统后，运维难度也会增加。
② TP 和 AP 在存储计算上都共享，这样可以做到成本最小化，资源利用最大化，但仍然存在两点问题。首先，由于计算共享， AP 查询和 TP 查询同时运行时或多或少会存在相互影响；其次，当 AP 查询比重增大时，系统需要扩计算节点存储，因此需要重分布，导致无法快速弹性Scale Out。
③ TP 和 AP 在存储上共享，在计算上分离。PolarDB 是存储计算分离架构，因此天然支持此方案。
二、原理
基于 PolarDB 存储计算分离的架构。我们研发了分布式 MPP 执行引擎，提供了跨机并行执行、弹性计算弹性扩展的保证，使得 PolarDB 初步具备了 HTAP 的能力。
上图右是 PolarDB HTAP 的架构图。底层是池化了的共享存储，TP 和 AP 共享一套存储数据，在降低成本的同时能提供毫秒级的数据新鲜度，还提供了快速扩容计算节点的能力，这也是 PolarDB HTAP 第一个特性。
上层是读写分离的计算节点。PolarDB 具备两套执行引擎来处理 HTAP 查询，其中单机执行引擎在读写节点上进行处理高并发的 TP 查询，分布式 MPP 执行引擎在只读节点上处理复杂的 AP 查询，TP和 AP 的查询天然进行了物理隔离，解耦了 TP 和 AP 的计算环境，杜绝了 CPU 和 memory 的相互影响，这是 PolarDB HTAP 的第二大特性：TP/AP物理隔离 。
PolarDB HTAP 的第三大特性是 Serverless 弹性扩展，消除了传统 MPP 数据库 coordinate 的单点限制，可以在任何一个只读节点上发起 MPP，可以弹性调整 MPP 节点范围以及单机并行度，同时支持 Scale Out、Scale Up 。此处的弹性调整是及时生效的，并不需要进行数据重分布。
消除倾斜是 PolarDB HTAP 的第四大特性。PolarDB HTAP 在充分考虑 PG BufferPool 亲和性的基础上，能够消除数据倾斜和计算倾斜，实现能者多劳的调度。
PolarDB HTAP 原理的核心是分布式 MPP 执行引擎，它是典型的火山引擎。 AB 两张表先做 join 再做聚合输出，这也是 PG 单机执行引擎的执行流程。
在传统的 MPP 执行引擎中，数据被打散到不同的节点上，不同节点上的数据可能具有不同的分布属性，比如哈希分布、随机分布、复制表分布等。传统的 MPP 执行引擎会针对不同表的数据分布特点，在计划中插入算子来保证上层算子对数据的分布特征无感知。
PolarDB 是共享存储架构，底层共享的数据可以被各个计算节点全量访问。如果使用传统的 MPP 执行引擎，每个 Worker 都会扫描全量数据，会产生重复的数据，同时也没有起到扫描时分治加速的效果，并不算真正意义上的 MPP 引擎。
因此，在在 PolarDB 分布式 MPP 执行引擎中，我们借鉴了火山模型论文的思想，对所有扫描算子进行并发处理，引入了PxScan算子来屏蔽共享存储。PxScan算子将 share-storage 的数据映射为 share-nothing 的数据，通过 Worker之间的协调，将目标表划分为多个虚拟分区数据块，每个 Worker 扫描各自虚拟分区数据块，从而实现了跨机分布式并行scan。
PxScan算子扫描出来的数据会通过 shuffle 算子来重分布，再在每个 Worker 上如同执行单机一样，按照火山模型来执行。
以上就是PolarDB 分布式 MPP 执行引擎的核心：shuffle 算子屏蔽数据分布，PxScan 算子屏蔽共享存储。
传统 MPP 只能在指定节点发起 MPP 查询，因此每个节点上都只能有单个 Worker 扫描一张表。为了支持云原生下 serverless弹性扩展的需求，我们引入了分布式事务一致性保证。
首先，任意选择一个节点作为 coordinator节点，它的 ReadLSN 会作为约定的 LSN，从所有 MPP 节点的快照版本号中选择最小的版本号作为全局约定的快照版本号。通过 LSN 的等待回放和 Global Snaphot 同步机制，确保在任何一个节点发起 MPP 查询时，数据和快照均能达到一致可用的状态。
为了达到 serverless 的弹性扩展，我们还基于共享存储的特点，将 coordinator节点全链路上各个模块需要的外部依赖都放至共享存储上。各个 Worker 节点运行时需要的参数也会通过控制链路从 coordinator 节点同步过来，从而使 coordinator 节点和 Worker 节点全链路无状态化。
基于以上两点设计，PolarDB的弹性扩展具备了以下几大优势：
① 任何节点都可以成为coordinator 节点，解决了传统 MPP 数据库 coordinator 的节点单点问题。
② PolarDB 可以横向 Scale Out （算力弹性扩展），也可以纵向 Scale Up （单机并行度弹性扩展），并且弹性扩展是及时生效的，不需要重分布数据。
③ 允许业务有更多的弹性调度策略，不同的业务阈可以运行在不同的节点集合上。如上图右侧所示，业务域 SQL 1 可以选择 RO1 和 RO2 节点来执行 AP 查询，业务域 SQL 2 可以选择使用RO3 和 RO4 节点来执行 AP 查询。两个业务域使用的计算节点可以实现弹性调度。
倾斜是传统 MPP 固有的问题，其原因主要是数据分布倾斜和数据计算倾斜。数据分布倾斜通常由数据打散不均衡导致，在 PG 中还会由于大对象 toast 表存储引入一些不可避免的数据分布不均衡问题；计算倾斜通常由于不同节点上并发的事务、 buffer 、网络、 IO 抖动导致。倾斜会导致传统 MPP 在执行时的木桶效应。
PolarDB 设计实现了自适应扫描机制。如上图右所示，采用coordinator节点来协调Worker节点询问的工作模式。在扫描数据时，coordinator节点会在内存中创建一个任务管理器，根据扫描任务对 Worker 节点进行调度。coordinator节点内部分为两个线程，data线程主要负责服务数据链路、收集汇总元组，control线程负责服务控制链路、控制每一个扫描算子的扫描进度。
扫描块的 Worker 能够扫描多个数据块，实现能者多劳。比如上图中 RO1 与RO3 的 Worker 都各自扫描了4个数据块， ROI2由于计算倾斜可以扫描更多数据块，因此它最终扫描了 6 个数据块。
PolarDB 自适应扫描机制还考虑了 PG BufferPool 的亲和性，保证每个 Worker 尽量扫描固定的数据块，从而最大化命中BufferPool中的缓存，降低 IO 开销。
三、功能特性
经过持续迭代的研发，目前 PolarDB HTAP 在支持 Parallel Query 上支持的功能特性主要有五大部分：
① 基础算子全支持。不仅包括 scan 类算子、Join类、聚合类，还包括 SubqueryScan、HashJoin 等。
② 共享存储算子优化。包括 shuffle 算子共享、ShareSeqScan 共享、 ShareIndexScan等。其中ShareSeqScan 共享、 ShareIndexScan共享是指在大表 join 小表时，小表采用类似于复制表的机制来减少广播开销，进而提升性能。
③ 分区表支持。不仅包括对Hash/Range/List三种分区方式的完整支持，还包括对多级分区静态裁剪、分区动态裁剪的支持。除此之外，PolarDB 分布式 MPP 执行引擎还支持分区表的Partition Wise Join。
④ 并行度弹性控制。包括全局级别、表级别、会话级别、查询级别的并行度控制。
⑤ Serverless 弹性扩展。不仅包括任意节点发起 MPP、MPP 节点范围内的任意组合，还包括集群拓扑信息的自动维护，以及支持共享存储模式、主备库模式、三节点模式。
既然是 HTAP ，则必然不能缺少对 DML 的 MPP 支持。基于 PolarDB读写分离架构和 HTAP serverless 弹性扩展的设计， PolarDB parallel DML支持一写多读、多写多读两种特性。一写多读是指在 RO节点上有多个读 Worker ，但在 RW节点上只有一个写 Worker ；多写多读是指在 RO 节点上有多个读 Worker ，在 RW节点上也有多个写 Worker 。多写多读场景下，读的并发度和写的并发度是完全解耦的。不同的特性适用不同的场景，用户可以根据自己的业务特点来选择不同的PDML功能特性。
PolarDB 分布式 MPP执行引擎，不仅可以用于 query 和 DML ，还可以用于索引构建加速。ALTP业务中有大量的索引，而索引创建过程大约有 80% 的时间消耗在排序和构建索引页上，20%消耗在写索引页上。如右上图， PolarDB 利用 RO 节点进行数据分布式 MPP 加速排序，采用流程化的技术来构建索引页，采用批量写入技术来提高索引页的写入速度。
目前构建索引加速这一特性中，PolarDB 已经对常用 B 树索引的普通创建以及 B 树索引的在线创建两种功能进行了支持。
通过上图与PolarDB原生的单机并行进行对比，可以看出分布式MPP的优势所在。我们使用线上 PolarDB 16g 和 256g 内存的 16 个 RO 实例，搭建了 1 TB 的 TPCH 环境进行测试对比。相比单机并行，分布式 MPP 并行充分利用了所有 RO 节点的计算资源和底层共享存储 RO 带宽，从根本上解决了前文提到的 HTAP 挑战。在 TPCH 22 条 SQL 中，有 3 条 SQL 加速了 60 多倍，19条 SQL 加速了 10 多倍，平均加速 23 倍。此外，我们也测试了弹性扩大给计算资源带来的变化。通过增加 CPU 总核数，从 16 核增加到 128 核， TPCH 的总运营时间线性提升，每一个 SQL 也呈线性提升，这也验证了 PolarDB HTAP serverless 弹性扩展的特性。
测试中发现,当 CPU 的总核数增加到 256 核时，性能提升并不大。原因是此时 PolarDB 共享存储的 IO 带宽已经打满，成为了瓶颈。这也从侧面说明了 PolarDB 分布式 MPP 执行引擎的计算能力是非常强的。
此外，我们将 PolarDB 的分布式 MPP 与传统数据库的 MPP 进行了对比，同样使用 16g 和 256g 内存的 16 个节点。 1 TB 的 TPCH 数据在保持与传统 MPP 数据库相同的单机并行度为 1 的情况下，PolarDB的性能是传统 MPP 数据库的90%。其中最本质的原因是传统 MPP 数据库的分布默认是哈希分布，当两张表的joinkey 是各自的分布键时，可以不用 shuffle 直接进行 Local Wise Join 。而 PolarDB 底层是共享存储池， PxScan 并行扫描出来的数据等价于随机分布，必须 shuffle 重分布后才能像传统 MPP 数据库一样进行后续的处理。因此, TPCH 涉及到表join时， PolarDB 相比传统 MPP 数据库多了一次网络 shuffle 的开销。
PolarDB分布式 MPP 能够进行弹性扩展，数据不需要重分布。因此在这有限的 16 台机器上执行 MPP 时，PolarDB 还可以继续扩展单机并行度，充分利用机器的资源；当 PolarDB的单机并行度为 8 时，它的性能是传统 MPP 数据库的 5-6 倍；当 PolarDB单机并行度呈线性增加时，PolarDB总的性能也呈线性增加，只需要修改配置参数，即可及时生效。
针对PolarDB HTAP 对构建索引加速特性的支持，我们也进行了性能测试。在 500 GB 的数据量下，当索引的字段有1、2、4个时，分布式 MPP 并行相比单机并行构建索引性能提升了5倍左右；当构建索引的字段增加到8个时，性能提升了4倍左右。
（完）
资料分享：
PolarDB 的源码仓库地址：https://github.com/ApsaraDB/PolarDB-for-PostgreSQL
