关于架构:PolarDB-for-PostgreSQL-内核解读-HTAP架构介绍

简介：在 PolarDB 存储计算拆散的架构根底上咱们研发了基于共享存储的 MPP 架构步具备了 HTAP 的能力，对一套 TP 的数据反对两套执行引擎：单机执行引擎用于解决高并发的 OLTP；MPP 跨机分布式执行引擎用于简单的 OLAP 查问，施展集群多个 RO 节点的算力和 IO 吞吐能力。

作者：北侠，阿里云高级技术专家，阿里云 PolarDB PostgreSQL 云原生数据库 HTAP 业务和技术负责人。

在 PolarDB 存储计算拆散的架构根底上咱们研发了基于共享存储的 MPP 架构步具备了 HTAP 的能力，对一套 TP 的数据反对两套执行引擎：

• 单机执行引擎用于解决高并发的 OLTP
• MPP 跨机分布式执行引擎用于简单的 OLAP 查问，施展集群多个 RO 节点的算力和 IO 吞吐能力

本文整顿自《开源学堂：PolarDB for PostgreSQL 内核解读 —— HTAP 架构介绍》直播分享。

存储计算拆散架构

首先咱们先来理解一下 PolarDB 的架构，从上图中能够看到，左侧是计算存储一体化，传统的数据库的存储是存在本地的。右侧是 PolarDB 存储计算拆散架构，底层是共享存储，能够挂任意多个计算节点。计算节点是无状态的，能够很好地做一个扩大，另外能够降低成本，比方用户能够扩大到 16 个节点，但底层存储还是一份存储（3 正本）。

分布式存储是比拟成熟的存储解决方案，自带存储的高可用，秒级备份，像 Ceph、PolarStorage，都是比拟成熟的存储解决方案。把社区单机的 PostgreSQL 数据库，间接跑在一个共享存储设备上，是不是能够认为是 PolarDB 呢？答案是不能够间接这么做，根本原因是在这套架构下有一份存储，然而计算节点有 N 个，计算节点之间须要协调。

存储计算拆散的架构须要解决的问题，首先是一致性问题，1 份存储 + N 份计算。第二，读写拆散，在这个架构上做低提早的复制。第三，高可用，解决怎么样去做疾速的复原。第四，IO 模型产生了变动，分布式文件系统是没有实现 cache，能够把省下来的内存间接给数据库的 BufferPool 应用。

HTAP 架构 – 存储计算拆散解决 AP 查问的挑战

在这个架构下，如果用户须要跑一些剖析型的查问，能够举个理论例子，比方像电信计费零碎，白天解决用户的充值、各种积分的结算，像这样的申请，都会带有 UserID，通过索引能够准确地定位到批改的页面。在早晨会跑一些批量的剖析，比方做对账，在不同的维度去统计省、市，统计整体的销售状况。存储计算拆散的架构在解决大查问上，把 SQL 通过读写拆散，将 SQL 动静地负载到负载较低的节点上。

这个节点在解决简单 SQL 时，PG 数据库具备单机并行的能力，尽管单机并行处理简单 SQL 比单机的串行有很大的晋升，但在单机并行下内存和 CPU 还是有肯定局限性，在这种架构下解决简单 SQL 只能通过 Scale Up 的形式来减速。也就是说如果发现 SQL 解决得比较慢，就只能减少 CPU，减少内存，找一个配置更高的机器来当只读节点。而且繁多节点来解决一个简单 SQL，是无奈施展出整个存储池大带宽的劣势。

因为分布式存储底层是有多个盘，每个盘都具备读写的能力。如果计算节点成为瓶颈，那么底层共享存储池，每个盘的能力是无奈施展的。另外一个问题，当只用一个节点来解决简单 SQL 时，其余节点有可能是闲暇的，因为通常 AP 的并发是很低的，有可能只是几个节点在跑一些固定的报表 SQL，而其余的节点是处于闲暇的状态，它的 CPU，内存还有网络也是没有方法利用起来的。

HTAP 架构 – 基于共享存储的 MPP

PolarDB 的解决方案是将多个只读节点连在一起，实现了基于共享存储的分布式的并行执行引擎，用户能够比拟灵便地来应用整个零碎。比方用某些节点来跑 TP 查问，代码门路就走到了单机查问。单机查问的益处是解决点查点写比拟快，因为它不波及到分布式事务，单机能够很快解决实现。当须要对简单 SQL 来做计算时，能够利用多个只读节点并行执行一个 SQL，即分布式的并行执行引擎 MPP 计划。

PolarDB 的 MPP 和传统数据库比方 Greenplum 这类基于分片的 MPP 是有本质区别。比方在某个工夫点发现分计算能力有余了，PolarDB 能够很快地减少只读节点的个数，而且此时整个底层的共享存储数据不须要去做重散布。用过 Greenplum 传统的 share nothing MPP 会晓得，扩容或缩容是十分大的运维动作。

PolarDB 是存储计算拆散的，计算节点是无状态的，能够通过迅速减少节点让计算能力变得更弱小。另外的益处是 TP 和 AP 能够做到物理隔离状态，保障用户在执行 TP 时不影响 AP，AP 也不影响 TP。

这套计划实际上是具备一套数据，像传统的一些计划反对两套，比方将 TP 的数据导出到另外一套 AP 的零碎外面，它的数据要拷贝一份，同步出过程数据的提早也是比拟大的。而且对资源是一种节约，比方白天跑 TP，早晨跑 AP，实际上两个集群只有一个集群在发挥作用。PolarDB 是提供一体化解决方案——在共享存储上用一套数据反对两套计算引擎，一个是单机引擎，一个是分布式并行的执行引擎。通过共享存储的个性，以及在读写节点之间的提早能够做到毫秒级。相比于传统的通过 TP 数据导到 AP 的零碎外面，数据新鲜度能够做到毫秒级的提早。

HTAP 架构原理

如何实现一个并行数据库？其核心思想是打算树中引入 Shuffle 算子，通过它能够屏蔽掉底层数据分布个性，实际上也是 MPP 的工作原理。

那么基于 PolarDB 共享存储会有什么变动？因为底层的数据是一个共享的状态，比方打算树理论是通过 A join B，并且对后果做 connt(*)。如果间接把 Greenplum 并行的模式，间接在 PolarDB 实现一套传统的 MPP，两个节点同时去执行 AB 的 join，因为 A 和 B 对于两个节点来说，是共享的，都能看到所有数据，这两个节点别离 join A 和 B 而后做统计记数，最终失去的记数是实在值的两倍。同时 A、B 解决的数据量并没有缩小，对整个过程没有起到减速的成果。

因而就要去解决怎么样对任何一个表做动静拆分的问题。须要做出并行算子的并行化，将原来 PG 数据库外面所有的 Scan 算子以及 index Scan 算子都做并行化。并行化是指能够依照一些固定的策略，逻辑上将任何一个表进行切分。切分之后，对于整个计划数的下层算子来说，是无奈感知底层是共享存储的。相似通过 Shuffle 算子来屏蔽数据分布特色，PolarDB 通过一系列 PXScan 并行化扫表算子，来屏蔽底层数据的共享特色。这就是 HTAP 架构上的原理。

从数据库的模块上来看，基于共享存储实现 MPP，须要做什么？

• 第一，分布式执行器。因为须要对所有的扫描算子做并行化。接着引入网络，因为数据要做交互，要做 Shuffle，还要引入打算治理。
• 第二，事务一致性。因为之前 PG 数据库的查问是局限于单机的，单机查问要通过 MVCC 的多版本的快照来做到事务的一致性。而当初则是把 SQL 扩散到不同的阶段去执行，不同的节点在回放主库数据的时候，是有快有慢的，须要去做一次性的管制，能力让所有的节点的数据都能集中于对立。
• 第三，分布式优化器。分布式优化器是基于社区的 GPORCA 做二次的架构扩大。GPORCA 优化器是模块化的设计。因为当初的底层数据没有分片，须要在优化器外面减少一些规定，以此来通知优化器，底层的数据是共享的个性。
• 第四，SQL 全兼容。如果要反对一种全新的执行模式，那么在 SQL 的规范外面，各个方面都要去做兼容。比方 Left join，在单机和分布式下办法是不一样的。如果间接将原生的 PG 社区的算子放到分布式，是有问题的，而且有些行为不合乎 SQL 规范。

HTAP – 执行器

HTAP 执行器就是通用 MPP 的做法了，整体上分成管制链路和数据链路。其中有两种角色，PX Coordinato 和 PX Worker。PX coordinator 去执行优化器的局部，而后产生一个分布式的计划数，再将打算进行切片散发进来。有可能散发到了 Polar DB 集群中其余 RO 节点，这些节点领有一个子计划数，通过数据链路，汇总到 PX Coordinator，最终将数据返回给客户。

HTAP – 弹性扩大

基于共享存储来做 MPP 有什么样的劣势？

第一，与传统基于 share nothing 的 MPP 相比，PolarDB 具备更好的弹性。在上图右侧局部，把整个 MPP 的执行门路上所依赖的状态，比方元数据的状态，以及每个 Worker 运行期的状态，都存在了共享存储上。将分布式计算的每个 worker，变成 Stateless。它的状态，一方面从共享存储上的读取，另外一方面来自协调者通过网络发送。这样能够做到无状态化的分布式的执行。就 PolarDB 而言，数据存到共享存储上，原数据存到共享存储的表外面。运行时的信息，比方 worker 被某个 SQL 连到 RO1 上，须要启动 8 个 worker 来工作，8 个 worker 散布到 RO2 和 RO3 上，4 个 worker 刚开始启动的时候是不晓得任何信息的，RO1 将这条 SQL 的相干信息，通过网络发送给 8 个 worker，这 8 个 worker 就能够去执行了。这就是做齐全弹性化 MPP 分布式引擎的思路。此时 Coordinator 节点就变成了无状态化。既能够把 RO1 当作中心化的协调节点，也能够把 RO2 当做协调节点，这就打消了传统 Greenplum 架构下的单点问题。

第二，算力弹性扩大，在上图中有四个节点，它的业务外面波及到一些 SQL。这些 SQL 是简单的查问，能够到 RO1 和 RO2 下来查。另外一个业务域，能够把它的业务拆分成两局部，一部分业务能够跑到 RO3 和 RO4 上，是能够动静调整的。

PolarDB 性能体现

上图为 Polar DB 分布式并行性能和单机并行的性能的比照，第一张图显示了 TPCH 22 条 SQL 减速比，其中有三条 SQL 的减速比是超过 60 倍的，大部分 SQL 都是超过十倍以上的晋升。第二个测试将共享存储上 1TB 的 TPCH 的数据，16 个计算节点，通过减少 CPU 看性能体现如何。在第二张测试图中，从 16 core 到 256 core，基本上是线性晋升的体现，然而到 256core 就达到瓶颈。这是因为受限于存储带宽，如果减少带宽，整体的性能还会晋升。最下方的图外面显示了 22 条 SQL 在 16core 到 256core 的性能的体现，能够看到在 16core 到 128core 时是线性晋升的。

还有一组是 PolarDB 和 Greenplum 的比照。测试环境为雷同的硬件，16 个计算节点，1TB TPCH。从上图中能够看到 Greenplum 有 16core 和 16 个 CPU 在做 SQL 解决。在采纳雷同并行度时，PolarO 的性能是 Greenplum 的 89%。为什么在单核时 Polar 会达不到 Greenplum 的性能体现？这是因为数据在共享存储上是没有数据特色的，Greenplum 在建表的时候，数据默认做哈希分区，在两个表 join 时 join Key 和散布 Key 是一样的，不须要做数据的 Shuffle。而 Polar 只有一张表，这张表没有数据特色，是一个随机散布的数据格式。此时任何两个表去 join 的时候，都须要做一个 shuffle，因为网络因素，Polar 单核性能体现只能达到 Greenplum 的 89%。针对这个问题，咱们将通过 PG 的分区表的形式进行优化。

尽管 Polar DB 底层的数据是共享的，但依然能够以哈希的形式建一个分区表。这个时候能够将 Polar DB 的 HTAP MPB 的形式和 Greenplum 的形式对齐统一，这个性能实现之后，Polar 的单核性能和 Greenplum 就是一样的。图中红框局部咱们又进行了四组测试，Polar DB 反对计算能力弹性扩大，此时数据是不须要从新散布的。这是数据随机散布的益处，在做分布式执行引擎的时候，第一优先级思考的不是极致的性能，而是是零碎的扩展性，即当你的计算能力有余的时候，能够疾速减少节点来减速计算。

像 Greenplum 这类传统的 MPP 数据库，它的节点是固定，而 Polar 是无状态的，能够随时去做调整计算 CPU 数的。这组测试外面只须要调整一个 GUC 参数就能将 Polar 从 16core 变成 256core，算力线性扩大。

当 Polar DB 反对了 MPP 之后，还能做哪些事件？新上线的业务导入了大量的数据之后，须要做一些索引。其原理是先将数据进行排序，之后在内存里组织成一个索引页面，而后将这些页面间接写到盘上。如果 Polar DB 反对并行之后，玩法就不一样了，从上图中能够看到，通过节点 RO1、RO2 和 RO3，能够并行地到共享存储下来扫描数据，而后并行地在本地进行排序。排完序之后，将数据通过网络传给 RW 节点。RW 节点通过归并排序，将排序的数据，在内存外面组织成一个索引页，交给 btbuild 过程。在内存外面，通过索引页，去更新索引页之间的指向关系，来构建索引树的指令关系，而后开始写盘。

这个计划借助了多个节点的计算能力以及 RO 能力，在排序的阶段进行了减速。同时通过网络传给 MPP 的一个 QC 节点，即核心节点。这个节点再通过共享内存，发给 btbuild 过程。经测试应用 500G 的数据来建索引，性能能够晋升到五倍左右。

减速时空数据库

时空数据库是一个计算密集型的、用 RTree 索引的粗过滤。先通过 RTree，而后通过空间踩点定位到一个区域，在这个区域外面，再进一步准确的过滤。共享存储的 index scan 的过程，RTree 扫描，只能用 NestLoopIndex Join，因为是没有方法做哈希 join 的，这是因为 RTree 的二维空间没有方法做残缺的切分。对于时空的业务都是通过 NestLoopIndex Join，从一个表外面拿到一个数据，而后到另外一个表外面的 RTree 上扫描，这在 Greenplum 上是无奈做到的，因为它的索引树是被拆分的。然而在 PolarDB 外面，RTree 的索引树是共享状态，那么无论 worker 是在节点 1，还是在节点 2 上，在共享里存储理念里索引树都是残缺的。这个时候两个 worker 就能够间接用表面做协调的切分。因为它是计算密集型的，那么它的减速成果会更加的好。通过测试，在 80 CPU 的环境下，整体的晋升能达到 71 倍。

以上就是对于 HTAP 架构的介绍，后续将会有更多实现上的细节分享，比方优化器、执行器、分布式一致性等，敬请期待。

原文链接
本文为阿里云原创内容，未经容许不得转载。