Starrocks ShortCircuit短路径的调度

背景

本文基于Starrocks 3.3.5
在之前的Starrocks 的 ShortCircuit短路径中我们谈到过，基于点查的这种ShortCircuit短路径
在优化器上不会经过复杂的优化，更不会经过memo的CBO优化，这一点也是为什么点查会快。
而且在之前的文章中，也没说看到有规则判断点查必须是要求行存，实际中在Starrocks中列存和行列存储都是可以进行点查操作的（每个引擎不一样，当然效果也就不一样）.

结论

任何一个SQL计算存储引擎，有两个组件必然是有的：一个是 调度模块，另一个是 SQL优化模块
一个SQL被优化优化了以后（当然还有其他流程），就会由调度模块进行task的调度，这样才能进行实实在在的运行。
而且这里的调度分两种，一种是 Pipline调度，一种是MPP调度(Fragment执行模式),对于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的时间却比较多。