专栏首页GreenplumGreenplum内核揭秘之执行引擎

Greenplum内核揭秘之执行引擎

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信息

GPDB数据分布的内部表示

CdbLocusType_Entry(访问系统表等)

CdbLocusType_SingleQE(limit等)

CdbLocusType_General(generate_series(1,10)等)

CdbLocusType_SegmentGeneral(复制表)

CdbLocusType_Hashed(键值表等)

CdbLocusType_Strewn(随机表等)

数据集合都有数据分布状态,hashjoin后的数据集合也需要有数据分布的信息

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

1、Redistribute Motion

2、Gather / Gather Merge Motion

3、Broadcast Motion

4、Explict Redistribute Motion

2.3.3 GPDB优化器在对MOTION评估

评估点:

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功能分发任务

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程序

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协议

本文分享自微信公众号 - 小徐的技术之路(xiaoxuBigdata),作者:小徐

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-06-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Greenplum内核揭秘之执行引擎

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

    小徐
  • Greenplum使用oralce_fdw连接oracle

    https://github.com/adam8157/oracle_fdw_greenplum

    小徐
  • Greenplum备份安全与高可用

    3.3.2 Back up an AO table if one of the following operations is performed

    小徐
  • CS224W-6-message passing and node classification 第1部分

    例子:反欺诈案例,一些节点是欺诈者,一些节点是合法客户,我们怎么找到其它的欺诈者和合法客户。

    Houye
  • redis 主从架构搭建及原理详解

    在redis主从架构中,Master节点负责处理写请求,Slave节点只处理读请求。对于写请求少,读请求多的场景,例如电商详情页,通过这种读写分离的操作可以大幅...

    CoderJed
  • 数据结构之(树)

    在计算机科学中,树(英语:tree)是一种非线性的抽象数据类型(ADT)或是实现这种抽象数据类型的数据结构,用来模拟具有树状结构性质的数据集合。它是由n(n>0...

    我是攻城师
  • ElasticSearch Client详解

    本文将重点探讨ElasticSearch Client的相关知识,主要关注TransportClient与Rest Client。Elasticsearch c...

    丁威
  • 使用jQuery UI的draggable和droppable完成拖拽功能--介绍

    第一部分--拖拽介绍 在https://code.csdn.net/2013ossurvey中最后一个开源项目就是zTree,一方面是因为自己看到有项目中使用了...

    八哥
  • 2020综述 深就是好?深度GNN中的Over-Smoothing

    在计算机视觉中,模型CNN随着其层次加深可以学习到更深层次的特征信息,叠加64层或128层是十分正常的现象,且能较浅层取得更优的效果;

    Houye
  • Science:人类睡眠中的神经电生理,血液动力学和脑脊液振荡的耦合

    睡眠对于认知和维持健康的大脑功能至关重要。神经活动中的慢波有助于记忆巩固,而脑脊液(CSF)有助于清除大脑中的代谢废物。这两个过程是否相关尚不清楚。波士顿...

    用户1279583

扫码关注云+社区

领取腾讯云代金券