简介：在 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 架构的介绍，后续将会有更多实现上的细节分享，比方优化器、执行器、分布式一致性等，敬请期待。

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