关于spark:Spark-SQL-字段血缘在-vivo-互联网的实践

一、背景

字段血统是在表处理的过程中将字段的处理过程保留下来。为什么会须要字段血统呢？

有了字段间的血缘关系，便能够晓得数据的起源去处，以及字段之间的转换关系，这样对数据的品质，治理有很大的帮忙。

Spark SQL 绝对于 Hive 来说通常状况下效率会比拟高，对于运行工夫、资源的应用下面等都会有较大的收益。

平台打算将 Hive 工作迁徙到 Spark SQL 上，同时也须要实现字段血统的性能。

二、后期调研

开发前咱们做了很多相干调研，从中得悉 Spark 是反对扩大的：容许用户对 Spark SQL 的 SQL 解析、逻辑打算的剖析和查看、逻辑打算的优化、物理打算的造成等进行扩大。

该计划可行，且对 Spark 的源码没有改变，代价也比拟小，确定应用该计划。

三、Spark SQL 扩大

3.1 Spark 可扩大的内容
SparkSessionExtensions 是比拟重要的一个类，其中定义了注入规定的办法，当初反对以下内容：

【Analyzer Rules】逻辑打算剖析规定【Check Analysis Rules】逻辑打算查看规定【Optimizer Rules.】逻辑打算优化规定【Planning Strategies】造成物理打算的策略【Customized Parser】自定义的 sql 解析器【(External) Catalog listeners catalog】监听器

在以上六种能够用户自定义的中央，咱们抉择了【Check Analysis Rules】。因为该查看规定在办法调用的时候是不须要有返回值的，也就意味着不须要对以后遍历的逻辑打算树进行批改，这正是咱们须要的。

而 【Analyzer Rules】、【Optimizer Rules】 则须要对以后的逻辑打算进行批改，使得咱们难以迭代整个树，难以失去咱们想要的后果。

3.2 实现本人的扩大

class ExtralSparkExtension extends (SparkSessionExtensions => Unit) {override def apply(spark: SparkSessionExtensions): Unit = {

    // 字段血统
    spark.injectCheckRule(FieldLineageCheckRuleV3)

    //sql 解析器
    spark.injectParser {case (_, parser) => new ExtraSparkParser(parser) }

  }
}