flink血缘解析原理分析

血缘解析-程序执行流程图.png

参考dlink实现血缘解析程序流程图

1. parse阶段获取SqlNode：
   编写explainSqlRecord(String statement, ExplainDetail... extraDetails)方法，方法内部通过调用flink-table-planner-blink_2.11-1.13.6.jar里面的ParserImpl#parse(string statement)进行sql解析，会优先使用ExtendedParser进行解析策略选择，意在不用修改CalciteParser增加复杂性的前提下，让FlinkSql支持更多专用的语法; 但是对于标准sql则会使用CalciteParser#parse(String sql)进行解析，该方法内部会先创建Sql解释器，然后解析statement，parser.parserStmt()方法底层通过JavaCC生成的解析器去解析SQL将其解析成为语法树对象。

2. 验证阶段获取Operation对象：

对于经过parse阶段解析出的AST语法树结果需要进行有效性校验，SqlToOperationConverter.convert(planner, this.catalogManager, parsed)方法负责校验sql语句，并将其转为Operation。该方法内部首先会对解析后的SQL语法树进行校验。具体验证的方面主要包括以下两方面，1.表名、字段名、函数名是否正确，如在某个查询的字段在当前SQL位置上是否存在或有歧义；2.特定类型操作自身的合法性，如group by聚合中的聚合函数是否存在嵌套调用，使用AS重命名时，新名字是否是x.y的形式等。使用flinkPlanner.validate(sqlNode)方法会拿到校验后的SqlNode变量，会判断SqlNode的类型，采用不同的转换逻辑最终获得需要的Operation对象。

3. Rel阶段是获取逻辑执行计划：

rel阶段是将SqlNode组成的一棵抽象语法树转化为一棵由RelNode和RexNode组成的关系代数树，并且此阶段只处理DML与DQL，因为DDL实际上可以认为是对元数据的修改，不涉及复杂关系查询，也就不用进行关系代数转换来优化执行，所以也无需转换为表示，根据对应的SqlNode中保存的信息已经可以直接执行了。对于DML语句会执行converter.convertSqlQuery(validated),该方法内部会先创建出Rel转换器，由Calcite转换为Relation tree，最终生成一个PlannerQueryOperation。将Calcite转换成的reletional tree包装在其中，对于转换过程本身并不涉及很复杂的算法，大部分过程都是提取已有SqlNode节点中记录的信息，然后生成对应的RelNode和RexNode，并设置RelNode间的父子关系。

4. Translate阶段是获取到ObjectNode解析结果：

在Translate阶段，通过Blink Planner 的translateToRel、optimize、StreamGraph和ObjectNode四个阶段:将Operation转换成 ObjectNode。从operation开始，先将ModifyOperation通过translateToRel方法转换成Calcite RelNode逻辑计划树。在Explainer#translateObjectNode()方法内部可以会先将modifyOperations数组组装出来，然后通过PlannerBase#translate(modifyOperations)方法获取到Transformation数组。并将其作为参数传入ExecutorUtils#generateStreamGraph()方法获取到StreamGraph。在Executor#getStreamGraph()方法中通过使用JSONGenerator，ObjectMapper进行封装最后返回ObjectNode。然后通过TransGenerator(plan).translateTrans()获取ObjectNode里的节点信息最后组装成Trans数组，以便后续得到最终的实体对象LineageColumnGenerator。