共计 5417 个字符，预计需要花费 14 分钟才能阅读完成。
在 3 月 2 日的阿里云开源 PolarDB 企业级架构发布会上，阿里云 PolarDB 内核技术专家严华带来了主题为《PolarDB HTAP 详解》的精彩演讲。在 PolarDB 存储计算拆散架构的根底上，咱们研发了基于共享存储的 MPP 分布式执行引擎，解决了单条 SQL 执行时无奈利用其它节点计算资源、无奈施展共享存储池的 IO 大带宽的问题，同时提供了弹性计算，弹性扩大的保障，使得 PolarDB 初步具备了 HTAP 的能力。本议题次要介绍 PolarDB HTAP 的性能个性和关键技术。
直播回顾视频：https://developer.aliyun.com/…
PDF 下载：https://developer.aliyun.com/…
以下依据发布会演讲视频内容整顿：
一、背景
很多 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/P…
