PolarDB for PostgreSQL（简称 PolarDB-PG）是一款阿里云自主研发的云原生关系型数据库产品，100% 兼容 PostgreSQL，高度兼容Oracle语法；采用基于 Shared-Storage 的存储计算分离架构，具有极致弹性、毫秒级延迟、HTAP 的能力和高可靠、高可用、弹性扩展等企业级数据库特性。同时，PolarDB 具有大规模并行计算能力，可以应对OLTP与OLAP混合负载。
在 PolarDB 存储计算分离的架构基础上我们研发了基于共享存储的MPP架构步具备了 HTAP 的能力，对一套 TP的数据支持两套执行引擎：
- 单机执行引擎用于处理高并发的 OLTP
- MPP跨机分布式执行引擎用于复杂的 OLAP 查询，发挥集群多个 RO 节点的算力和IO吞吐能力
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架构上的原理。
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 上，是可以动态调整的。
