在 PolarDB 存储计算分离的架构基础上我们研发了基于共享存储的MPP架构步具备了 HTAP 的能力，对一套 TP的数据支持两套执行引擎：

单机执行引擎用于处理高并发的 OLTPMPP跨机分布式执行引擎用于复杂的 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 架构的介绍，后续将会有更多实现上的细节分享，比如优化器、执行器、分布式一致性等，敬请期待。

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

原文链接：https://developer.aliyun.com/article/850234?utm_content=g_1000327188

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