前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Greenplum内核揭秘之执行引擎

Greenplum内核揭秘之执行引擎

原创
作者头像
小徐
修改2020-06-08 14:41:03
1.2K0
修改2020-06-08 14:41:03
举报
文章被收录于专栏:GreenplumGreenplum

Greenplum内核揭秘之执行引擎

目录

Greenplum内核揭秘之执行引擎 1

目录 1

1 执行器介绍 2

1.1 什么是执行器 2

1.2 PlanNode(执行计划节点) 2

1.3 PlanTree(执行计划树) 2

1.3 执行模型 3

1.3.1 迭代模型(Pipeline模型,Pull方式) 3

1.3.2 向量化模型(VECTORIZATION Model) 3

1.3.3 PUSH执行模型 4

1.3.4 PUSH模型的优势 4

1.3.5 GPDB使用的模型 5

1.4 GPDB 执行器面临更大的挑战 5

1.4.1 MPP架构的设计 5

1.4.2 Shared-Nothing 进行数据传输 6

1.4.3 新的执行节点MONTION 6

1.4.4 包含Motion的执行计划树 7

2 并行化PLAN 8

2.1 并行计划PLAN示意图 8

2.2 实例相亲案例 9

2.2.1 单身男女都居住在户籍所在地 9

2.2.2 单身女在户籍所在地,单身男在外地 9

2.2.3 单身男女随机分布在全国各地 10

2.2.4 相亲策划思路 10

2.3 GPDB采用的分布情况 10

2.3.1 Locus信息 10

2.3.2 通过Motion来打破物理上的隔离 11

2.3.3 GPDB优化器在对MOTION评估 11

2.3.4 分布式Join 11

3 Dispatcher 13

3.1 GPDB执行器面对的问题 13

3.2 dispatcher分配QE资源 13

3.3. dispatcher功能分发任务 14

3.4 dispatcher功能协调控制 14

3.5 典型的dispatcher程序 14

4 Interconnect 15

4.1 Motion的内部实现是Interconnect 15

4.2 Interconnect Layout实现 15

4.3 UDPIFC线程模型 16

4.4 可能有新的Interconnect类型 16

1 执行器介绍

1.1 什么是执行器

执行器是处理一个由执行计划节点组成的树,并返回查询结果

1.2 PlanNode(执行计划节点)

本质上就是数据处理

1.3 PlanTree(执行计划树)

如以下所示的Query查询树

Seq Scan : 原发性的扫描节点

Hash/Hash Join : 非原发性扫描节点

1.3 执行模型

1.3.1 迭代模型(Pipeline模型,Pull方式)

每一个执行节点实现一个next函数,并遵循:

1、每一次调用,返回一个tuple或者返回NULL

2、实现一个循环,每次调执行子节点的next函数作为输入并处理

优点: 易懂,资源使用少,通用性好

缺点: 迭代次数多,代码局部性差,CPU cacheline不友好

1.3.2 向量化模型(VECTORIZATION Model)

和迭代模型一样,每一个执行节点实现一个next函数,区别在于每一次迭代,执行节点返回一组tuple, 而非一个tuple

优点: 减少迭代次数,可以利用新的硬件特性如SIMD,单次更多的tuple对列存友好(可以利用压缩特性等)

1.3.3 PUSH执行模型

每一个执行节点定义两个函数

1、produce函数: 对原发性扫描节点,该函数名副其实,产生数据,并调用上层节点的consume函数,对非原发性扫描节点,produce函数更像一个控制函数,用于调用节点的produce函数,快速定位到数据源头。

3、consume函数:被下层节点调用,接受子节点数据进行处理,然后调用父节点的consume函数消费本节点的数据。

1.3.4 PUSH模型的优势

下层驱动模型相对容易转换成由数据驱动的代码:

for each tuple t1 in R1

materialize t in hash table of HTAB(A=B)

for each tuple t2 in R2

If t2.b == HTAB(A=B)[t1.a]

output(t1,t2)

好处一: 上层的操作变成本节点的一个算子,增加了代码的局部性

好处二: 这样的代码更方便进一步转换成一个纯计算代码,例如使用LLVM优化

缺点:个人理解,通用性不强,可能只能局部优化

1.3.5 GPDB使用的模型

GPDB使用的是迭代模型,但是GPDB正在积极探索向量模型和PUSH模型

1.4 GPDB 执行器面临更大的挑战

1.4.1 MPP架构的设计

Greenplum使用的是MPP(Massive Parallel Process)架构的设计

1.4.2 Shared-Nothing 进行数据传输

1.4.3 新的执行节点MONTION

新的执行节点采用MONTION,是一个并行化的执行节点

1.4.4 包含Motion的执行计划树

2 并行化PLAN

2.1 并行计划PLAN示意图

2.2 实例相亲案例

2.2.1 单身男女都居住在户籍所在地

策略

各省的部分单独自办相亲会,将本省的适龄单身男女组织到相亲场地相亲,并将结果返回总部。

2.2.2 单身女在户籍所在地,单身男在外地

策略1

各省的部分单独办相亲会

1、首先每个省的单身男青年找出来,并将他们通过火车派送到原户籍坐在地

2、然后每个省接待这些男青年,并在本省找出女单身女青年,对他们进行相亲

策略二:

各省的部分自办相亲会

1、首先找到本省所有适龄单身女青年,并为其买好34个省份的车票,每个省份都去一趟

2、然后每个省接待这些单身女青年。并安排其与生活在本省的男青年相亲,找出户籍一直的相亲。

2.2.3 单身男女随机分布在全国各地

策略1:

在总部举办相亲会,各省把单身男女通过火车派送到总部,总部接待并安排相亲,这个成本会很大。

策略2:

各分部举办相亲会:

1、首先各省找出居住在本省的适龄单身男,并按户籍派送到相应的省。

2、然后各省找出居住在本省的适龄单身女,并按户籍派送到相应的省。

3、最后各省接待全国归来的男女,进行相亲。

2.2.4 相亲策划思路

1、人多力量大的原则,尽量利用各省的部分

2、首先分析当前男女的区域分布

3、必要时使用交通工具来打破地域的限制

2.3 GPDB采用的分布情况

每一张普通表都有数据分布信息

1、键值分布

2、随机分布

3、复制分布

2.3.1 Locus信息

代码语言:javascript
复制
GPDB数据分布的内部表示
CdbLocusType_Entry(访问系统表等)
CdbLocusType_SingleQE(limit等)
CdbLocusType_General(generate_series(1,10)等)
CdbLocusType_SegmentGeneral(复制表)
CdbLocusType_Hashed(键值表等)
CdbLocusType_Strewn(随机表等)
数据集合都有数据分布状态,hashjoin后的数据集合也需要有数据分布的信息

2.3.2 通过Motion来打破物理上的隔离

代码语言:javascript
复制
1、Redistribute Motion
2、Gather / Gather Merge Motion
3、Broadcast Motion
4、Explict Redistribute Motion 

2.3.3 GPDB优化器在对MOTION评估

代码语言:javascript
复制
评估点:
1、生成新的数据集合时
a.Join path 生成时,参考cdbpath_motion_for_join函数
b.group path 生成时,参考create_grouping_paths函数
c.subplan的mpp优化时,参考cdbllize_decorate_subplans_with_motions函数
d........
2、对已有数据集合进行INSERT/UPDATE/DELETE操作时
 参考create_modifytable_path - > adjust_modifytable_subpaths

2.3.4 分布式Join

3 Dispatcher

3.1 GPDB执行器面对的问题

有了分布式PLAN,一堆计算资源怎么分配调度和执行起来?

QD : master 提供的计算资源

QE : segment提供的计算资源

3.2 dispatcher分配QE资源

AllocatwGang()

GANG 大小分配灵活

最小一个

一般为segment的个数

甚至可以大于segment的个数(一个segment为一个gang分配多于一个的QE资源)

QE资源闲置以后可以被后续查询使用(或者闲置一段时间后被清楚)

3.3. dispatcher功能分发任务

代码语言:javascript
复制
CdbDispatchPlan Plan + SliceTable
CdbDispatchCommand
CdbDispatchDtxProtocolCommand
CdbDispatchUtilityStatement

3.4 dispatcher功能协调控制

cdbdisp_checkDispatchResult(等待模式)

等待模式

1、blocking 阻塞等待所有QEs完成执行或者出现异常

2、Non -blocking 检查所有QEs的状态,若QEs有异常则报错,否则立即返回

3、Finish 给所有活动的QEs发送QueryFinish消息提前结束任务,QE不报错

4、Cancel 给所有活动的QEs发送QueryCancel消息,终止任务。

3.5 典型的dispatcher程序

代码语言:javascript
复制
ds = cdbdisp_makeDispatcherState
primaryGang = AllocateGang(ds,GANGTYPE_PRIMARY_WRITER,segment)
cdbdisp_dispatchToGang(ds,primaryGang,-1)
cdbdisp_waitDispatchFinish(ds)
cdbdisp_checkDispatchResult(ds,DISPATCH_WAIT_NODE)
cdbdisp_getDispatchResults(ds,&qeError)
cdbdisp_destroyDispatcherstate(ds)

4 Interconnect

4.1 Motion的内部实现是Interconnect

sender和receiver之间通过网络在QE之间移动数据,在GPDB中,该网络模块叫做Interconnect

4.2 Interconnect Layout实现

UDPIFC 定义

1、GPDB 自己实现的一种RUDP(Reliable User Datagram Protocol)协议

2、基于UDP协议,为了支持传输可靠性,实现了重传,乱序处理,不匹配处理,流量控制等功能。

3、GPDB当初引入UDPIFC主要为了解决复杂OLAP查询在大集群中使用链接资源过多的问题。

4.3 UDPIFC线程模型

为什么使用线程模型?

1、UDPIFC在应用层保证传输的可靠性,需要单独的线程来保证传输可靠协议

2、QE在fork的时候呼启动一个udpifc线程,该线程服务该session所有将要可能的查询

3、udpifc线程接受所有发送给该QE的数据包并通过共享内存移交给主进程。

4、设计的函数

线程细节可参考rxThreadFunc函数

接受端逻辑可参考RecvTupleChunkFrom*函数

发送端逻辑可参考SendChunkUDPIFC

4.4 可能有新的Interconnect类型

QUIC协议

Proxy协议

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • Greenplum内核揭秘之执行引擎
  • 目录
  • 1 执行器介绍
    • 1.1 什么是执行器
      • 1.2 PlanNode(执行计划节点)
        • 1.3 PlanTree(执行计划树)
          • 1.3 执行模型
            • 1.3.1 迭代模型(Pipeline模型,Pull方式)
            • 1.3.2 向量化模型(VECTORIZATION Model)
            • 1.3.3 PUSH执行模型
            • 1.3.4 PUSH模型的优势
            • 1.3.5 GPDB使用的模型
          • 1.4 GPDB 执行器面临更大的挑战
            • 1.4.1 MPP架构的设计
            • 1.4.2 Shared-Nothing 进行数据传输
            • 1.4.3 新的执行节点MONTION
            • 1.4.4 包含Motion的执行计划树
        • 2 并行化PLAN
          • 2.1 并行计划PLAN示意图
            • 2.2 实例相亲案例
              • 2.2.1 单身男女都居住在户籍所在地
              • 2.2.2 单身女在户籍所在地,单身男在外地
              • 2.2.3 单身男女随机分布在全国各地
              • 2.2.4 相亲策划思路
            • 2.3 GPDB采用的分布情况
              • 2.3.1 Locus信息
              • 2.3.2 通过Motion来打破物理上的隔离
              • 2.3.3 GPDB优化器在对MOTION评估
              • 2.3.4 分布式Join
          • 3 Dispatcher
            • 3.1 GPDB执行器面对的问题
              • 3.2 dispatcher分配QE资源
                • 3.3. dispatcher功能分发任务
                  • 3.4 dispatcher功能协调控制
                    • 3.5 典型的dispatcher程序
                    • 4 Interconnect
                      • 4.1 Motion的内部实现是Interconnect
                        • 4.2 Interconnect Layout实现
                          • 4.3 UDPIFC线程模型
                            • 4.4 可能有新的Interconnect类型
                            领券
                            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档