
Nebula Graph 源码解读系列 |Scheduler 和 Executor 两兄弟
上篇我们讲述了 Query Engine Optimizer 部分的内容,在本文我们讲解下 Query Engine 剩下的 Scheduler 和 Executor 模块。
>>>>概述
在执行阶段,执行引擎通过 Scheduler(调度器)将 Planner 生成的物理执行计划转换为一系列 Executor,驱动 Executor 的执行。
Executor,即执行器,物理执行计划中的每个 PlanNode 都会对应一个 Executor。
>>>>源码定位
调度器的源码在 src/scheduler 目录下:
Scheduler 抽象类定义了调度器的公共接口,可以继承该类实现多种调度器。
目前实现了 AsyncMsgNotifyBasedScheduler 调度器,它基于异步消息通信与广度优先搜索避免栈溢出。
执行器的源码在 src/executor 目录下:
>>>>执行过程
首先,调度器从执行计划的根节点开始通过使用广度优先搜索算法遍历整个执行计划并根据节点间的执行依赖关系,构建它们的消息通知机制。
执行时,每个节点收到它的所依赖的节点全部执行完毕的消息后,会被调度执行。一旦自身执行完成,又会发送消息给依赖自己的节点,直至整个计划执行完毕。
每个 Executor 会经历 create-open-execute-close 四个阶段:
create
根据节点类型生成对应的 Executor。
open
在 Executor 正式执行前会做一些初始化操作,以及慢查询终止和内存水位的判断。
Nebula 支持手动 kill 掉某个查询语句的执行,因此每个 Executor 执行前需要检查下当前执行计划状态。若被标记为 killed ,则终止执行。 每个 Query 类型的 Executor 执行前,还需要检查当前系统所占用内存是否达到内存水位。若达到内存水位,则终止执行,这能在一定程度上避免 OOM。
execute
Query 类型的 Executor 的输入和输出都是一张表(DataSet)。Executor 的执行基于迭代器模型:每次计算时,调用输入表的迭代器的 next() 方法,获取一行数据,进行计算,直至输入表被遍历完毕。计算的结果构成一张新表,输出给后续的 Executor 作为输出。
如果当前 Executor 的输入表不会被其他 Executor 作为输入时,这些输入表所用的内存会在执行阶段被 drop 掉,减小内存占用。
close
Executor 执行完毕后,将收集到的一些执行信息如执行时间,输出表的行数等添加到 profiling stats 中。 用户可以在 profile 一个语句后显示的执行计划中查看这些统计信息。
以上,源码解析 Query Engine 相关的模块就讲解完毕了,后续将讲解部分特性内容。
本文转载自公众号nebula graph community
