《Greenplum Database 的分布式查询优化-内核 + 分布式数据库（29页）.pdf》由会员分享，可在线阅读，更多相关《Greenplum Database 的分布式查询优化-内核 + 分布式数据库（29页）.pdf（29页珍藏版）》请在三个皮匠报告上搜索。

1、Greenplum Database 的分布式查询优化吕正华Pivotal Inc.内容安排Greenplum Database架构分布式查询计划和分布式执行器如何修改Planner生成分布式查询计划其他关于分布式查询计划的细节Greenplum Database架构Greenplum是多个Postgres实例(segment)构成的集群 一个segment作为Master,其余的是数据节点(也负责计算)Share Nothing架构,不同的segment直接没有数据共享Catalog在Master上是完整的,Segment上也维护一部分StandBy和Mirror也是segment,和Mas

2、ter,Primary在不同机器gp_segment_configuration维护了集群的架构信息Greenplum Database架构gp_segment_configuration为什么需要MPP架构MPP(Massively Parallel Processing)数据量太大,单机存不下,因此只能将数据分片存到不同机器数据量太大,期待靠并行计算提升性能,因此需要分布式执行 MPP数据库必须解决的问题数据分片策略(Greenplum支持hash,random,replicated)分布式查询计划(Locus,Motion)分布式执行器(Slice,Gang,Dispatch)简单的执行

3、策略在master上利用做出单机的查询计划,下发到各个segment执行Master汇总各segment结果会返回给客户端类似中间件,支持的查询比较简单(不涉及到跨segment数据连接)复杂查询(join,agg等)如汇总到单机执行效率太低分布式查询例子分布式执行器必然涉及到多组进程协同工作必须正确处理多组进程之间的数据通信分布式查询计划SPMD(single program,multiple data)查询计划切片查询计划能描述数据通信典型的Greenplun分布式执行流程分布式类型系统：locus分布式查询计划需要对数据分布建模Greenplum引入locus的概念基础表的scan pa

4、th的locus从分布策略中获取gp_distribution_policyMotion path可以改变locus类型locus可以看做是path的分布式意义下的类型在Postgres的Path结构里加了locus结构自底向上推理每个path的locusLocus的种类和具体例子Locus的推理cdbpathlocus_from_baserel(由gp_policy设置tablescan的locus)Catalog:entryTable distributed replicated:seggeneralTable distributed by(c1):hash locusTable dist

5、ributed randomly:strewn locuscdbpathlocus_from_exprs(构建hash locus)cdbpathlocus_from_subquery从subplan获取locus利用plan的flow信息Motion path会改变locusGather motion:变成singleQE或者entryRedistribute motion:变成hash,或改变分布键Broadcast motion:变成replicatedJoin涉及到最复杂的locus推理,是分布式查询计划的重中之重Policy示例Catalog没有policy,发现rangetable

6、是catalog,locus设为entryPath locus示例小结:分布式查询第一步构建基础设施LocusPolicyFlow开发的技术新增catalog在Postgres关键数据新增字段推理和维护新增字段Motion path and Join path核心代码在函数cdbpath_motion_for_join本质是在处理分布式关系代数通过motion促成局部信息完备,这样不用考虑跨segment的连接pgpgeneral strewn=strewngeneral hash=hash generate_series(1,5)a joint on a=t.c-t randomly dis

7、tsssBstrewn strewn=strewnbroadcast one patht join t on true-t randomly disthshRstrewn hash=hashredistributed one patht1 join t2 on t1.a=t2.a-t1 randomly dist-t2 hash dist on ahssRstrewn strewn=hashredistributed both patht1 join t2 on t1.a=t2.a-t1 randomly dist-t2 randomly distRhhhRhash hash=hashredi

8、stributed one patht1 join t2 on t1.a=t2.a and t1.b=1-t1 hash dist on(a,b)-t2 hash dist on(a,b)外连接和motion以left join为例说明问题,右值会补null左表不能呈现广播态(加广播motion,复制表,general等)但是左表可以重分布(重分布不产生duplicate值)111234seg0seg1seg21 left join 2,3,4Result plannode技巧未必只有motion才能改变locusGreenplum优化了Result plannode针对类广播locus(ge

9、neral等)如果需要重分布可以避免gather到singleQE再重分布Append path locus先将所有分片的locus视为随机分片(strewn locus)第一遍扫描推理表得出最终的locus类型如果是分片类型,第二遍扫描判断是否co-locate最终给每个subpath增添适合的motion path推理规则（按顺序）:有entry则全部entry;有singleQE则全部singleQEStrewn和广播类则gather成singleQE(这点有优化空间:利用result)General不改变其它locus类型相同的locus不产生新的locusRecursive CTE的

10、locus和motionRecursive CTE是包含两个子节点的plannode非递归部分用来初始化worktable递归部分的worktable有可能和别的表joinWorktable scan执行器依赖Recursive Union执行器的状态,因此这两个执行器节点不能跨进程(不能被motion切割)Worktable scan path的locus设置的与非递归部分的一致Worktable scan path和其他表join的时候不许在Worktable scan path上加motion非递归部分是复制表locus的话,必须转变成singleQE多阶段hash agg的代价模型Gr

11、eenplum的hash agg执行器支持spill和streamming模式Streamming:两阶段agg的查询计划,一阶段的hash表满了,将hash表的内容推送到下一阶agg,然后清空Group数目少,两阶段查询计划可以避免倾斜Group数目多,两阶段查询计划的第一个阶段存在无用功精准的代价模型至关重要Distinct数的分布式模型一阶段Hash表spill（或者streamming)的数量分布式环境下的distinct值一阶段hash表spill(streaming)数量估计得到查询计划后的工作对子查询的处理Update或delete语句的explicit motionUpdate

12、或delete如果涉及到plan qual底层查询可能涉及motionModifyTable执行节点只能找到本地tuple的CTID需要显示的motion物归原主更新分布键的查询计划Greenplum支持更新分布键(极少MPP数据库支持这个特性)引入的技术:split update总结基于Postgres planner设计的分布式查询优化器很大程度复用了Postgres的优化器代码引入plannode motion建模分布式计算的数据通信引入locus,flow,policy指导生成motion pathCo-locate分析很重要,消除不必要的motion提升性能分布式查询计划的代价模型很重要,和单机版不同得到plan后再进行一些善后工作