spark-sql字段级血缘关系实现

1.背景：

血缘关系非常重要，因为有了字段间的血缘关系，便可以知道数据的来源去处，以及字段之间的转换关系，这样对数据的质量，治理有很大的帮助。

Spark SQL 相对于 Hive 来说通常情况下效率会比较高，对于运行时间、资源的使用上面等都会有较大的收益。所以考虑将采用MapReduce引擎执行的sql进行迭代，以spark引擎执行。但同时也需要实现字段血缘的功能。hive血缘关系实现较为简单，攻略也比较多，这spark血缘关系攻略较少，这里提供一种解析思路。

2.需求：

在使用spark引擎执行sql时，将表与表，字段与字段的血缘信息解析出来，可视化展示。

3.思路：

使用QueryExecutionListener对spark进行监听，读取出sparkplan(物理计划)，解析其中包含的血缘关系，将血缘关系导入neo4j，spring-boot写接口，前端请求返回表的血缘关系。

4.实现：

QueryExecutionListener：监听和用于分析spark-sql执行过程中的的一些指标

The interface of query execution listener that can be used to analyze execution metrics.

trait QueryExecutionListener {
  @DeveloperApi
  def onSuccess(funcName: String, qe: QueryExecution, durationNs: Long): Unit

  @DeveloperApi
  def onFailure(funcName: String, qe: QueryExecution, exception: Exception): Unit
}

class SparkListenerTest extends QueryExecutionListener{

  override def onFailure(funcName: String, qe: QueryExecution, exception: Exception): Unit = {

  }

  override def onSuccess(funcName: String, qe: QueryExecution, durationNs: Long): Unit = {
    val sparkPlanJson: String = qe.sparkPlan.prettyJson

  }
}

了解一下整个sql在spark中的解析过程

sql —(ANTLR4) —> AST —(Spark AstBuilder) —> Unresolved LogicalPlan —  (Catalog) —>  Resolved LogicalPlan  — (Optimizer) —> Optimized LogicalPlan — (SparkPlanner) —> PhysicalPlan(SparkPlan) —(prepareForExecution) —> ExecutionPlan(PhysicalPlan)

QueryExecution可以获取到的信息如下：

logicalPlan: 逻辑计划并不知道如何执行，比如不知道表的类型(hive还是hbase)，如何获取数据(jdbc还是读取hdfs)，数据分布是什么样的(bucketed还是hashDistrobuted)，这时就需要将逻辑计划树转换成物理计划树，获取真实的物理属性

sparkPlan：就是刚刚提到的物理计划树，这里我们监听获取sparkplan的Json信息

这段JSON获取目标表的所有信息

 table和database

 第一个Project包含了目标表的信息和血缘信息(下面说)，其中projectList就是表中的字段信息，第一个Project就是insert into xxx 的 xxx(目标表target)