Spark SQL 字段血缘在 vivo 互联网的践行
发布时间：2022-05-24 14:24:30 所属栏目：大数据 来源：互联网
导读：字段血缘是在表处理的过程中将字段的处理过程保留下来。为什么会需要字段血缘呢? 有了字段间的血缘关系，便可以知道数据的来源去处，以及字段之间的转换关系，这样对数据的质量，治理有很大的帮助。 Spark SQL 相对于 Hive 来说通常情况下效率会比较高，对
|
字段血缘是在表处理的过程中将字段的处理过程保留下来。为什么会需要字段血缘呢? 有了字段间的血缘关系，便可以知道数据的来源去处，以及字段之间的转换关系，这样对数据的质量，治理有很大的帮助。 Spark SQL 相对于 Hive 来说通常情况下效率会比较高，对于运行时间、资源的使用上面等都会有较大的收益。 SparkSessionExtensions是比较重要的一个类，其中定义了注入规则的方法，现在支持以下内容： 【Analyzer Rules】逻辑计划分析规则 【Check Analysis Rules】逻辑计划检查规则 【Optimizer Rules.】 逻辑计划优化规则 【Planning Strategies】形成物理计划的策略 【Customized Parser】自定义的sql解析器 【(External) Catalog listeners catalog】监听器 在以上六种可以用户自定义的地方，我们选择了【Check Analysis Rules】。因为该检查规则在方法调用的时候是不需要有返回值的，也就意味着不需要对当前遍历的逻辑计划树进行修改，这正是我们需要的。 而【Analyzer Rules】、【Optimizer Rules】则需要对当前的逻辑计划进行修改，使得我们难以迭代整个树，难以得到我们想要的结果。 复制 class ExtralSparkExtension extends (SparkSessionExtensions => Unit) { override def apply(spark: SparkSessionExtensions): Unit = { //字段血缘 spark.injectCheckRule(FieldLineageCheckRuleV3) //sql解析器 spark.injectParser { case (_, parser) => new ExtraSparkParser(parser) } 注意到我们也实现了一个自定义的SQL解析器，其实该解析器并没有做太多的事情。只是在判断如果该语句包含insert的时候就将 SQLText(SQL语句)设置到一个为FIELD_LINE_AGE_SQL，之所以将SQLText放到FIELD_LINE_AGE_SQL里面。因为在 DheckRule 里面是拿不到SparkPlan的我们需要对SQL再次解析拿到 SprkPlan，而FieldLineageCheckRuleV3的实现也特别简单，重要的在另一个线程实现里面。 这里我们只关注了insert语句，因为插入语句里面有从某些个表里面输入然后写入到某个表。 （编辑：济南站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐