Starrocks ShortCircuit短路径的调度
背景
本文基于Starrocks 3.3.5
在之前的Starrocks 的 ShortCircuit短路径中我们谈到过，基于点查的这种ShortCircuit短路径
在优化器上不会经过复杂的优化，更不会经过memo的CBO优化，这一点也是为什么点查会快。
而且在之前的文章中，也没说看到有规则判断点查必须是要求行存，实际中在Starrocks中列存和行列存储都是可以进行点查操作的（每个引擎不一样，当然效果也就不一样）.
结论
任何一个SQL计算存储引擎，有两个组件必然是有的：一个是 调度模块，另一个是 SQL优化模块
一个SQL被优化优化了以后（当然还有其他流程），就会由调度模块进行task的调度，这样才能进行实实在在的运行。
而且这里的调度分两种，一种是 Pipline调度，一种是stagebyStage调度
对于Starrocks来说，默认是前者，也就是 Pipeline调度,而且调度的模式不一样，任务并行度的设置也不一样：
当设置 set enable_pipeline_engine = true(默认) 时，影响并行度的参数是 pipeline_dop 当设置 set enable_pipeline_engine = false 时，影响并行度的参数是 parallel_fragment_exec_instance_num
而对于点查来说，直接跳过调度层级（由于是查询，几乎不会有其他的计算），直接再BE获取数据即可。
而如果是行存的话，直接通过PK获取一行数据，
如果是列存的话，通过PK，因为一行数据是存储崽不通的列chunk（Column Chunk）中，所以会通过多轮的数据获取，之后再组装成一行数据，所以消耗的时间就多了。
分析
先说说数据流：
StmtExecutor.execute||\/
StatementPlanner.plan||\/
handleQueryStmt||\/
DefaultCoordinator.startScheduling
这里的startScheduling 方法就是fragemnt任务的调度：
@Override
public void startScheduling(boolean needDeploy) throws Exception {try (Timer timer = Tracers.watchScope(Tracers.Module.SCHEDULER, "Pending")) {QueryQueueManager.getInstance().maybeWait(connectContext, this);}if (isShortCircuit) {execShortCircuit();return;}try (Timer timer = Tracers.watchScope(Tracers.Module.SCHEDULER, "Prepare")) {prepareExec();}try (Timer timer = Tracers.watchScope(Tracers.Module.SCHEDULER, "Deploy")) {deliverExecFragments(needDeploy);}// Prevent `explain scheduler` from waiting until the profile timeout.if (!needDeploy) {queryProfile.finishAllInstances(Status.OK);}
}
可以看到 如果是短路径的话（也就是点查），直接进入到execShortCircuit 方法，从而调用ShortCircuitHybridExecutor.exec方法，这里就直接向BE请求数据了，
反观，如果不是短路径，则还会经过
prepareExec
deliverExecFragments
两个阶段,
这里包括DAG的构建，fragment的具体Deploy（具体哪个BE上分配哪些Task），以及等待部署成功等等，这些都是要需要时间的。
所以说如果一个query过来的话，不是点查，但是SQL查询比较简单的话，也许真正查询的时间少，但是在调度Fragment的时间却比较多。