接上篇：https://developer.aliyun.com/article/1223066?spm=a2c6h.13148508.setting.32.44ec4f0eNvAByn
PolarDB中有4类算子需要并行化，其中Seqscan的算子的并行化极具代表性。
为了最大限度地利用存储的大IO带宽，在顺序扫描时，按照4MB为单位做逻辑切分，尽量将IO打散到不同的盘上，达到所有盘同时提供读服务的效果。该方案还有一个优势在于每个只读节点只扫描部分表文件，最终能缓存的表大小是所有只读节点的BufferPool总和。
上图可见，通过增加只读节点，扫描性能线性提升30倍。
打开buffer后，扫描时间从37min降至3.75s，提升了600倍。这也是数据亲和性的优势所在。
倾斜是传统MPP固有的问题，主要包含两方面：一方面是存储的倾斜，大对象通过heap内部表关联toast表时，因为无法确切地知道实际存储的数据量有多大，无论怎么切分，数据存储都有可能不均衡；另一方面是执行时的倾斜。不同只读节点上的事务、buffer、网络等会抖动，因此也会存在执行计算倾斜。
为了解决倾斜问题，我们支持了动态扫描。将协调节点内部分成DataThread和ControlThread，其中DataThread负责收集汇总元组，ControlThread负责控制每个扫描算子的扫描进度。
每个算子控制每个节点上scan算子的扫描进度，每个节点上scan算子再扫描下一个块的数据时会向QC节点进行请求查询，从而获得下一个扫描的目标块，使得扫描快的工作进程能多扫描逻辑的数据切片。
此外，尽管是冬天分配，过程中我们也尽量考虑了buffer数据亲和性。另外，每个算子的上下文均存储在各个worker的私有内存中，协调节点不存储表的相关信息。
上图可见，出现大对象时，静态扫描会出现数据倾斜，而使用动态扫描并没有因为 RO节点增多导致数据倾斜严重。
我们利用数据共享的特点，还可支持云原生下极致弹性的要求：将Coordinator全链路上各个模块所需要的外部依赖存在共享存储上，每个节点都可以看到相同的数据。同时worker全链路需要的运行时参数通过控制链路从Coordinator同步，使Coordinator和worker无状态化。任何节点都可以作为协调节点，确定了协调节点之后，控制节点再从协调节点获取相关的控制信息。
以上方式带来的好处在于：SQL的任何只读节点都可以称为协调节点，解决了协调节点单点的问题。其次，SQL可以在任何节点上起任意数量的worker，使算力达到SQL级别的弹性扩展，使得业务有更多的调度策略。
比如四个只读节点，可以让业务域1的SQL只利用只读节点1和只读节点2，业务域2的SQL利用节点3和节点4，为用户提供更多选择。
多个计算节点通过等待回放和globalsnapshot机制完成。等待回放能够保证所有需要的数据版本已经同步完成，globalsnapshot能够保证选取统一的可读版本。
主要流程如下：用户SQL发送后，生成计划并确定协调节点，协调节点会广播ReadLSN，每个worker节点等待回放到ReadLSN。结束之后获取各自的snapshot，通过序列化发送给协调节点。协调节点汇总所有worker，选出最小的snapshot并通过广播发给各个节点，再由广播执行计划树，从而可以保证每个worker能看到相同的数据、相同的快照和相同的plan，最终开始执行。
上图为使用1TB的TPCH进行的测试。
接下篇：https://developer.aliyun.com/article/1223064?groupCode=polardbforpg
