Presto 由Stage到Task的旅程
前言
在presto中有Query，Stage，Task，Pipeline，Driver，Operator等等的概念，他们一生二，二生三，三生万物，构成了presto整个DAG的脉络。这里只对Stage与Task进行展开，大体讲述了以下几个问题：
- Stage的创建
- Task的创建
- Stage与Task的对应关系
- Task的状态感知
Stage的诞生
Stage是逻辑执行计划在分析引擎中的直接体现。如何将Query划分成多个Stage是在生成逻辑执行计划时确定的，这篇文章不做展开。在Stage的诞生中，有一个举足轻重的类叫SqlQueryScheduler，在这个类实例化时调用createStages方法生成了整个查询的Stage，可以看到createStages方法是一个递归调用的方法，这个方法是一个树的先序遍历的实现，也就是这个方法先序遍历了整个逻辑执行计划，根据逻辑执行计划的stage划分生成了一个又一个Stage。
可以在上图(1)中看到createStages方法中根据root plan先生成了root stage，之后图(2)遍历root plan的各个子节生成各个plan节点对应的stage。
Task的诞生
有了Stage，也就是有了SqlStageExecution的实例，就需要SqlStageExecution向RemoteTask转化了，因为只有RemoteTask才可以分配到多个节点上进行计算。这时候有两个很重要的问题：
- 多个stage谁先生成task
- 一个stage生成几个task
首先是多个stage谁先生成task的问题，在Presto中由ExecutionPolicy介面决定，他有两个实现，分别是AllAtOnceExecutionPolicy和PhasedExecutionPolicy，具体使用哪种顺序是由execution_policy的配置决定的。AllAtOnceExecutionPolicy和PhasedExecutionPolicy的区别见下文《presto中AllAtOnce与Phased的区别》;
对于一个stage生成几个task的问题，这个很明显presto中肯定是计划生育，计划生育的指标是多少，在presto中是根据stage的分工来的。在presto中虽然没有明确的概念，但是可以将Stage大致分成两种类型，一种是需要从数据源读数据的，另一种是不需要从数据源读数据的。
对于需要充数据源读数据的，需要根据具体的数据源类型来确定。
如果从connector中拿到的spilt是必须本地访问的，那么生成几个task就要取决于数据分布，必须在每一个有数据分布的节点上分配一个task。所以task数取决于数据分布的节点数。如果spilt可以远程访问。
如果从connector中拿到的spilt是远程访问的，就调用selectNodes介面，可以看到这个方法取决于limit和presto node个数的较小值。limit这里传入的是minCandidates，是一个在NodeSchedulerConfig里的配置，默认值是10。
对于不需要读源头数据的stage，presto中直接调用NodeSelector的selectRandomNodes方法。
在selectRandomNodes方法中直接调用了上图中的selectNodes方法，但是这里有几个要注意的，一个是includeCoordinator的含义，说明coordinator也是可以作为计算节点的。另一个是limit如何确定。
在这里limit的确定如图6，如果plan给的partitioning类型是SINGLE那么就是单节点，比如task 0.0就是单节点。如果类型是FIXED就是读取hash_partition_count的配置。
Task状态感知
在presto中Task要放在远程节点上执行。那么coordinator怎么能知道task是生是死，执行到了哪一步，以及如何ui上给用户展示task执行情况呢？其实presto封装了两个类，TaskInfoFetcher和ContinuousTaskStatusFetcher。其中TaskInfoFetcher是获取TaskInfo的，这个介面非常的重，涉及到巨大的json解析，所以presto中对于这个介面每100毫秒调用一次（如图7）
ContinuousTaskStatusFetcher只返回TaskStatus，非常的轻量，可以快速感知到task状态的改变。
结语
综上，在presto中，stage与task的对应关系需要根据stage的类型来确定，对于不同的stage会生成不同数量的task。
推荐阅读：