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

发布于 2022-4-15 16:52
浏览
0收藏

 

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

  • 单机执行引擎用于处理高并发的 OLTP
  • MPP跨机分布式执行引擎用于复杂的 OLAP 查询,发挥集群多个 RO 节点的算力和IO吞吐能力


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

 

存储计算分离架构

PolarDB for PostgreSQL 内核解读 :HTAP架构介绍-开源基础软件社区

首先我们先来了解一下 PolarDB 的架构,从上图中可以看到,左侧是计算存储一体化,传统的数据库的存储是存在本地的。右侧是 PolarDB 存储计算分离架构,底层是共享存储,可以挂任意多个计算节点。计算节点是无状态的,可以很好地做一个扩展,另外可以降低成本,比如用户可以扩展到16个节点,但底层存储还是一份存储(3副本)。

 

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

 

存储计算分离的架构需要解决的问题,首先是一致性问题,1份存储+N份计算。第二,读写分离,在这个架构上做低延迟的复制。第三,高可用,解决怎么样去做快速的恢复。第四,IO 模型发生了变化,分布式文件系统是没有实现cache,可以把省下来的内存直接给数据库的 BufferPool 使用。

 

HTAP 架构 - 存储计算分离处理AP查询的挑战

PolarDB for PostgreSQL 内核解读 :HTAP架构介绍-开源基础软件社区

在这个架构下,如果用户需要跑一些分析型的查询,可以举个实际例子,比如像电信计费系统,白天处理用户的充值、各种积分的结算,像这样的请求,都会带有 UserID,通过索引可以精确地定位到修改的页面。在晚上会跑一些批量的分析,比如做对账,在不同的维度去统计省、市,统计整体的销售情况。存储计算分离的架构在处理大查询上,把 SQL 通过读写分离,将 SQL 动态地负载到负载较低的节点上。

 

这个节点在处理复杂 SQL 时,PG 数据库具备单机并行的能力,虽然单机并行处理复杂 SQL 比单机的串行有很大的提升,但在单机并行下内存和 CPU 还是有一定局限性,在这种架构下处理复杂 SQL 只能通过 Scale Up 的方式来加速。也就是说如果发现 SQL 处理得比较慢,就只能增加 CPU,增加内存,找一个配置更高的机器来当只读节点。而且单一节点来处理一个复杂SQL,是无法发挥出整个存储池大带宽的优势。

 

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

 

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

PolarDB for PostgreSQL 内核解读 :HTAP架构介绍-开源基础软件社区

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 架构原理

PolarDB for PostgreSQL 内核解读 :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架构上的原理。

PolarDB for PostgreSQL 内核解读 :HTAP架构介绍-开源基础软件社区

从数据库的模块上来看,基于共享存储实现MPP,需要做什么?

  • 第一,分布式执行器。因为需要对所有的扫描算子做并行化。接着引入网络,因为数据要做交互,要做Shuffle,还要引入计划管理。
  • 第二,事务一致性。因为之前 PG数据库的查询是局限于单机的,单机查询要通过 MVCC 的多版本的快照来做到事务的一致性。而现在则是把 SQL 分散到不同的阶段去执行,不同的节点在回放主库数据的时候,是有快有慢的,需要去做一次性的控制,才能让所有的节点的数据都能集中于统一。
  • 第三,分布式优化器。分布式优化器是基于社区的GPORCA做二次的架构扩展。GPORCA优化器是模块化的设计。因为现在的底层数据没有分片,需要在优化器里面增加一些规则, 以此来告诉优化器,底层的数据是共享的特性。
  • 第四,SQL 全兼容。如果要支持一种全新的执行模式,那么在SQL的标准里面,各个方面都要去做兼容。比如 Left join,在单机和分布式下方法是不一样的。如果直接将原生的PG社区的算子放到分布式,是有问题的,而且有些行为不符合SQL标准。


HTAP - 执行器

PolarDB for PostgreSQL 内核解读 :HTAP架构介绍-开源基础软件社区

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

 

HTAP - 弹性扩展

PolarDB for PostgreSQL 内核解读 :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 性能表现

PolarDB for PostgreSQL 内核解读 :HTAP架构介绍-开源基础软件社区

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

PolarDB for PostgreSQL 内核解读 :HTAP架构介绍-开源基础软件社区

还有一组是 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,算力线性扩展。

PolarDB for PostgreSQL 内核解读 :HTAP架构介绍-开源基础软件社区

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

 

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

 

加速时空数据库

PolarDB for PostgreSQL 内核解读 :HTAP架构介绍-开源基础软件社区

时空数据库是一个计算密集型的、用 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业务和技术负责人。

 

文章转自公众号:阿里云数据库

收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐