开发者学堂课程【PolarDB for PostgreSQL 开源人才初级认证培训课程：云原生 HTAP】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1077/detail/15558
云原生 HTAP
内容介绍：
一、简介
二、 PolarDB 云原生 HTAP 背景
三、阿里云官网文章架构详解
一、简介
本期阿里云学堂主要讲解 PolarDB 云原生 HTAP ，主要负责 PolarDB 云原生 HTAP 相关功能的开发，本次的讲解也主要是参考官网上的制作文章。官网就是这里面 PolarDB 的一个官网，在这里面架构解读中点进去，就可以看到 PolarDB 的架构的详解，
在特性实践中我们也包含了使用 PolarDB HTAP 加速 TPC-H 的一个使用说明。
二、 PolarDB 云原生 HTAP 背景
1、PolarDB 云原生 HTAP 的背景。
知道 PolarDB PG 是云原生的一个数据库，它主要体现在它是一个存储计算分离的一个架构，在存储上可以根据用户的需要，弹性扩充存储节点，在计算上面也可以根据用户的计算需求弹性扩展用户的计算节点。但是如果只是使用原生的 PolarDB PG 来处理 TP 的场景，那么在处理 AP 场景查询的时候，就会遇到两个挑战。第一个挑战就是说单机的 PG ，它只支持单机的一个串行跟单机的并行。它不支持多机查询、跨机查询，这样的话，它就没办法发挥多个计算节点 CPU 和 MEM ，就不能横向的 scale out ，大查询只能单机的 scale up ，也就是说必须增加 CPU 和 mem 的一些实例规格。然后第二个就是说原生的 PG 直接报到 PolarDB 上面，它没办法充分发挥共享存储池的一个大吞吐能力，因为它只能利用到它一个单机计算节点上的一个能力。
2、业界应该怎么解决：
业界根据 TP 、 AP 在存储和计算上是否共享分离的一个维度来分的话，可以有三种，第一种就是说 TP 、 AP 在存储计算上都分离，也就说是两套系统 TP 系统跟 AP 系统。 TP 的数据需要导入到 AP 的系统中，然后延迟性也不高，同时的话，它也会容易增加了冗余的两份存储，增加了一个存储的成本，第三点，就是它两套系统也会增加了运维的难度。然后第二种思路的话，第二种解决方案就是 TP 、 AP 在存储和计算上都共享。但因为它们存储价值共享，也就是说是 TP 、 AP 在查询时或多或少都会有些影响，然后然后同时受限于TP查询，当 AP 的比重在增大的时候没办法弹性地 Scale out ，它同样也只能在单机上面去调整自己的 cpu 跟 mem
然后第三个方案也就是说 TP 、 AP 在存储上共享、在计算分离，也就是 PolarDB 云原生 HTAP 的方案。
PolarDB 云原生 HTAP 的方案，整体架构就是这样的：
它底层是由共享存储池，然后上面是多个计算节点，这里面就包含了一个读写节点和多个 RO 节点。由于 TP 和 AP 是共享一套存储，因此它减少了存储成本，可以提高查询的一个时效性，能提供毫秒级的数据新鲜度。第二个就是说由于 tp 跟 ap 是 tp 的查询，是 RO 节点跟 RW 节点上面。而ap查询的话，是现在部分的 RO 节点上面，因此可以实现 tp 跟 ap 的物理隔离，杜绝了 CPU 跟 mem 的相互影响。第三个特点就是具备一个 Severless 的一个弹性扩展，这个弹性扩展是指可以在任何一个 RO 节点上来发起这个分布式 MPP 的一个查询，可以弹性调整 MPP 执行节点的范围，可以这4个节点进行 MPP 查询，也可以这2个也可以这1个。然后第三个能力就是说 scale up ，就是可以弹性调整单机 MPP 的一个单机并行度，例如 MPP 在这个只读节点上，可以让它并读41、42、45、40都可以。然后第4个特点，云原生 HTAP 特点就是消除了倾斜，消除了数据的存储倾斜和计算倾斜，然后同时在咨询过程中也能充分考虑到 PG Buffer Pool 的亲和性，这个就是整体的一个架构和一个技术特点。
三、阿里云官网文章架构详解
1、解释分析：
回到官网那个文章，官网上面已经有详细说明，架构详解这里一一解读一下。
PolarDB 这个架构原理，因为 PolarDB 底层存储是在不同节点上是共享的，因此不能像传统 MPP 一样去扫表，在原来的单机经营上面，然后支持了 MPP 分布式执行引擎，也可以叫跨机执行引擎。同时对 Shared-Storage 进行了优化。基于 Shared-Storage 的 MPP 是业界首创，它的原理是:借助 Shuffle 算子屏蔽数据分布，借助 ParallelScan 算子屏蔽共享存储。以下图为例，
这是一个典型的火山模型，扫描 a 表，再扫描 b 表，进行 join ，最后做一个聚合输出。那么在 PolarDB 上 MPP 是怎么样的？对 a 表和 b 表进行了一个虚拟的分区，然后在两个只读节点上，会有 worker ，这里是默认配置的，每个节点起的有 worker 去扫。那么在左边的这个只读节点上，它会扫描a表的把握 watch 1,右边的这个节点上的这个worker它的扫描a表的 watch 2，然后 b 表也是如此。那么通过 a 1和 a 2的虚拟表，然后共同扫描，就可以屏蔽一个共享存储。然后其实通过算子的一个分发之后分发到上层，通过 Hash Join 就已经屏蔽了一个数据的分布。这个就是一个基础的架构原理，然后也可以看到它的主要特点就是说引入了 Shuffle 和 scan ，这是它的一个基本原理，然后要产生上述的一个执行计划，那么肯定要需要一个优化器，这里基于社区的 GPORCA 优化器扩展了能感知共享存储特性的 Transformation Rules 。使得能够探索共享存储下特有的 Plan 空间，比如:对于一个表在 PolarDB 中既可以全量的扫描，也可以分区域扫描，这个是和传统 MPP 的本质区别。就像上面这个图，这里指的 a 表其实是按照分片扫描来的。但是这里面的 b 表其实如果是个小表，那么可以做一个全表扫描，然后然后每一个子节点，都会扫描 b 的全量数据，然后构建一个 Hash 表，那么扫描b表的数据就不需要进行下发到各个节点上面。
下面这张图中就是 PolarDB 内核与 GPORCA 优化器的适配部分，灰色的部分就是做的一些扩展，其他部分就是 GPORCA 卡原有的一些部分。
除此还对4类算子进行了一个并行化，
其中具有典型代表的就是 Sescan 的算子的并行化。为了最大限度
的利用存储的大 IO 带宽，在顺序扫描时，按照4 M B 为单位做逻辑切分，将 IO 尽量打散到不同的盘上，达到所有的盘同时提供读服务的效果。这样做还有一个优势，就是每个只读节点只扫描部分表文件，那么最终能缓存的表大小是所有只读节点的 BufferPool 总和。
然后那么下面的图中，通过增加只读节点，1个 IO ，2个 IO ，3
个 IO ，通过增加只读节点，发现扫描的性能线性线性提升30倍。
同时打开 Buffer ，就是打开数据的一个缓存，发现扫描时间也能从37分钟能降到3.75秒，提升了600倍。这个也就是数据亲和性的一个特点一个好处。
然后第三个，一个原理解释，就是消除了数据倾斜。已知倾斜是传统 MPP 固有的问题，它主要包含两方面，一方面是一个存储的的倾斜，在PolarDB中，大对象的是通过heap表关联TOAST表，无论对哪个表切分，都无法达到均衡，因为不知道实际存的数据是是有多大量的。第二个就是执行时的倾斜，不同只读节点的事务、buffer、网络、IO 负载抖动，没办法保持都是一样的，所以也会存在一个计算倾斜。以上两点会导致分布执行时存在长尾进程，就像木桶效应，肯定会有一个短板执行的最慢的一个。为了解决这个问题，支持了一个动态扫描。
通过在协调节点内部分成分成两个线程： Data 线程 DataThread 和控制线程 ControlThread ， Data 线程负责收集数据的元组，然后控制线程来控制每个算子扫描的进度每个算子来控制每个节点上 scan 算子扫描的进度， scan 算子在扫描下1个块的数据的时候，会向 qc 节点去进行请求查询，从而获得下一个扫描目标块，然后这样，就能保证扫描块的工作进程，能扫描更多的逻辑数据分片，这个过程中需要考虑 Buffer 的亲和性，由于是动态的一个分配。尽量也在维护 Buffer 的亲和性，另外每个算子的上下文存储也都在各个 worker 私有内存中,协调节点不存储表达相关信息。也做过测试，在出现大对象时，静态扫描会出现数据倾斜。例如一个 RO ,三个 RO ，6个 RO ，按照切分的执行时间是这样的，但当使用动态扫描的时候，发现 RO 扩展的时候扫描时间也是在线性增加的，并没有说因为 RO 节点增多带来的数据倾斜严重这样的问题。
最后一点就说明那个 SQL 级别这个弹性扩展。那利用数据共享的特点，还可以支持云原生下极致弹性的要求:把 Coordinator 全链路上各个模块所需要的外部依赖存在共享存储上，这样每个节点都可以看到相同的一个数据，同时 worker 全链路上需要的运行时参数通过控制链路从 Coordinator 同步过来，使 Coordinator 和 worker 无状态化，任何一个节点都可以作为协调节点。因为确定了控制节点之后，然后控制节点在协调节点去拿到相关的一个控制信息。这样就会带来好处，就是 SQL 任何只读节点都可以成为协调节点，解决了协调节点单点的一个问题。第二个就是一个 SQL 可以在任何一个节点上，起任一数量的 worker 数目，因为这里面的 worker 可以单机上也有 worker ，一个SQL能在任意节点上启动任意worker 数目，达到算力能SQL级别弹性扩展，也允许业务有更多的调度策略：不同业务域同时跑在不同的节点集合上。比如4个只读节点，可以让业务域 SQL 值利用一个只读键建立2，可以让业务域2利用节点3和节点4。这样可以提供用户更多的选择。
最后再提到怎么来保证事务一致性，多个计算节点数据一致性通过等待回放和 globalsnapshot 机制来完成。等待回放保证所有worker 能看到所需要的数据版本同步，而 globalsnapshot 保证了选出一个统一的可读版本。然后主要流程就是用户这个发过来生存计划之后，我们确定了好了协调节点之后协调节点会广播 ReadLSN ,每个 worker 节点会等待回放到 ReadLSN 上面，同时结束之后，会获取各自的 Snapshot ，通过序列化，发给那个协调节点，协调节点汇总所有 worker ，选出最小的一个snapshot，通过广播发给各个节点，同时再去广播执行计划数，从而可以保证每个 worker 看到相同的数据和相关的块照，然后开始执行。
使用1TB的TPCH进行了测试，首先对比了 PolarDB 新的分布式并行和单机并行的性能:有3个 SQL提速60倍，19个SQL提速10倍以上;
同时也尝试增加了CPU合作从从并行度1、2、4、8核，也就是说核从16~128。发现22条均是能线性提升的。
然后回到这个例子，回到官网上有一个使用 PolarDB 云原生 HTAP 来加速 TPCH 查询的这个文章来说明，这里就按照这个步骤来一步步的去演示。
2、实践：
⑴首先更新一下镜像，在一个开发机上跟一个镜像。
输入： docker pull polardb / polardb _ pg _ local _ instance : htap
然后启动 doker
输入：docker run - it -- cap - add - SYS _ PTRACE -- privileged -
true -- name polardb _ pg _ htap polardb / pol
启动完之后，看一下，现在实例是否会引起来
输入 ps xf ,实例引起来了
尝试连接，输入 psql - h / home / postgres / tmp _ master _ dir
_ polardb _ pg _1100 _ bld
连接成功，连接上读写节点，现在没有数据
现在按要求造 TPCH 的数据
输入 git clone https :// github . com / qiuyuhang / tpch - dbgen .git
先克隆 TPCH 的工具，
然后编译代码，输入： cd tpch - dbgen
编完之后就产生数据量小一点，这种简单一点，输入 ./ dbgen -s 1
产生1 G TPCH 数据:
数据产生完，导入建表语句，输入 psql - h / home / postgres / tmpmasterdirpolardb _ pg _ 1100 _ bld - f dss . ddl
检查表已经建立完成
建立完成后导入数据
\ copy nation from ‘ nation . tbl ' DELIMITER ‘ I ';
\ copy region from ‘ region . tbl ' DELIMITER ‘ I ';
\ copy supplier from ‘ supplier . tbl ' DELIMITER ‘ I ';
\ copy part from ‘ part . tbl ' DELIMITER ‘ I ';
\ copy partsupp from ‘ partsupp . tbl ’ DELIMITER ‘ I ';
\ copy customer from ‘ customer . tbl ’ DELIMITER ‘ I ';
\ copy orders from ‘ orders . tbl ’ DELIMITER ‘ I ';
\ copy lineitem from ‘ lineitem . tbl ’ DELIMITER ‘ I ';
完成之后， PX 是跨机、分布式置引擎，以 PX 为例，开启每张表的最大并行数，对创建的表的最大力度来进行限制，这里面只要大于一，就可以表示是可以支持 MPP 查询。
输入： alter table nation set ( px _ workers =100);
alter table region set ( px _ workers =100);
alter table supplier set ( px _ workers =100);
alter table part set ( px _ workers =100);
alter table partsupp set ( px _ workers =100);
alter table customer set ( px _ workers =100);
alter table orders set ( px _ workers =100);
alter table lineitem set ( px _ workers =100);
看一下表的数据
⑵先执行单机并行的一个引擎
输入\ timing ,执行如下命令，开启计时。
输入 set max _ parallel workers _ per gather - 2；并行度设置为2
输入\ i queries / q18 . explain . sql
看一下 Q 18 的计划，这个就是使用单机并行来执行 TPCH 的一个查询， Q 18的一个计划
也可以执行 SQL ，输入 postgres =#\i queries / q18 . sql
可以看到执行时间为12秒，可能开发机性能好一点
⑶执行 PolarDB 引擎，打开 PX 开关，输入 set polar _ enable _ px = on ;
将单机并行度设置为1，输入 set polar _ px _ dop _ per _ node 1;
然后输入 \ i queries / q18 . explain . sql ，看一下执行计划
产生 PolarDB PX Optimizer，说明已经产生执行计划
可以观察到这个执行计划特点与单机执行时不同
这是并行度为1的情况下的计划，输入 postgres =#\i queries / q18 . sql
观察引擎执行效果，发现尽管并行度为1，实际两个 worker 工作，这使得只花费5秒就读取了数据， Q 18执行完成
但单机并行时也使用2个 worker 工作，却花费12秒。
当然这里面的对比，其实是在开发机中是共享使用的，所以性能不太准，感兴趣可以在自己的一个物理机上面，然后自己去测试。
同样也可以私下把并行度调成2，输入 set polar _ px _ dop _ per _ node = 2;试一下效果。
执行计划发生变化，协调节点4:1，也就是4个 worker 在工作数据汇总到1个节点上，
输入 \ i queries / q18 . sql
执行效果如下：
发现当并行度调整为2的时候，执行时间已经变成了三秒，时间差不多有一倍的提升。
同样也可以私下调试并行度为4的情况，输入set polar _ px _ dop _ per _ node =4;
还有一些 PolarDB 执行过程中的一些观察点，例如可以测试不同的连通性。
