利用SparkSQL Logical Plan Parse 打造大数据平台SQL诊断利器

前言

对一个开源项目来说,虽然各种卷,动不动去深入研究源码啥的,但是没有真正去参与开发的话,了解里头的原理又少那么点感觉。实际情况来说很少机会去参与源码的改造吧,这里我提供一些思路,就是基于源码倒腾一些小工具,这样子有作用而且加深那些原理的理解!
利用我们的源码,打造一款SQL的扫描工具~~

原理篇

Spark被大家津津乐道的经典SQL解析流程

  1. Sql语句经过Antlr4解析,生成Unresolved Logical Plan
  2. analyzer与catalog进行绑定(catlog存储元数据),生成Logical Plan;
  3. optimizer对Logical Plan优化,生成Optimized LogicalPlan;
  4. SparkPlan将Optimized LogicalPlan转换成 Physical Plan;
  5. prepareForExecution()将 Physical Plan 转换成 executed Physical Plan;
  6. execute()执行可执行物理计划,得到RDD;

利用SparkSQL Logical Plan Parse 打造大数据平台SQL诊断利器_第1张图片

需求分析

当然,对一个数据分析平台来说,能够到提交SQL其实是比较后面的一步了,实际sql可能是下面的样子

/**
这里是注释
**/

set mapreduce.input.fileinputformat.split.maxsize=128000000;
set hive.exec.reducers.bytes.per.reducer=200000000;  --参数部分

insert overwrite table dwd_user_dd partition (dt='${dt}')
select id,name,age from user where dt='${bizdate}' ;

====step:1====

--后续一堆乱七八糟的

平台把这么一坨sql解析成可以执行的SQL的话需要多做一些事情:

  1. 把注释去掉
  2. 替换参数数据
  3. 执行参数
  4. 提交

因为提交SQL的时候也是需要申请Driver的资源的,如果有点语法错误什么的,资源紧张的情况下,需要等蛮久才执行出来报错。
这个其实是大问题,尤其是资源紧张这个事情,大部分同学都发现平台资源就没有不紧张的时候吧,顶多是300%变成100%的使用,也就个变化空间。我们的目标便是搞一个SQL扫描的小工具,在提交之前就检测出来,提升效率。

有问题的sql应该在一开始的的时候就禁止用户提交,举例说明:

规则 内容
禁止用户建库 禁用create database
禁止用户删库 禁止drop database
禁止用户建正式表 正式表由平台方统一建立,不允许create table xxx
禁止用删除正式表 正式表不允许删除 drop table table xxx
禁止在SQL中指定队列 用户不允许指定队列,平台统一调控
不能用INSERT OVERWRITE写入临时库的table 临时表不允许长周期

类似的规则其实很多,比如说禁止全量扫描大表,之类的,这个是按照实际需求来。
可能有同学会很疑惑,
1、为什么建表这种事情都要控制。
一般来说正式的表要求流程规范,而且需要有比较完整的描述信息,那么直接的etl语句中不允许的 ,正式表的话有数仓的流程规范,类似dwd/dws这种取名规范,所以在实际的开发中也需要做限制。
2、hive之类的不是有权限控制么,为什么还需要单独校验
几方面原因,首先上面提到了sql语句是不希望用户提交,所以这个环节还没到执行阶段呢,其次,类似数仓的规范,hive其实做不到的,集团内部的建表规范是个性化定制的,hive只能在一个用户权限范围内去禁止建表之类的,但是对于哪些表名禁止,这个就无能为力了

思路分析

正常的SQL解析是需要走文法那套的,Antlr4也是可以的,只是这样子又从入门到放弃了,利用SparkSQL自己的API就可以做,我们只需要把Master指向lcoal就可以

 public static SparkSession spark = SparkSession.builder()
            .appName("sql parser")
            .master("local[*]")
            .enableHiveSupport()
            .getOrCreate();
public static SessionState sessionState = spark.sessionState();

生成 Unresolved Logical Plan

Unresolved Logical Plan我们直接做转化就可以得到:

 public static LogicalPlan mkPlan(String sql) throws ParseException {
        return sessionState.sqlParser().parsePlan(sql);
    }

来个实际的例子 :

CREATE TABLE `student`(
  `stu_id` int, 
  `name` string, 
  `sex` string, 
  `age` int, 
 cls_id int )
 PARTITIONED BY ( 
  `dt` string COMMENT ' day partitioned')
  
CREATE TABLE `class_inf`(
  `cls_id` int, 
  `cls_name` string 
 )
 PARTITIONED BY ( 
  `dt` string COMMENT ' day partitioned')

生成表之后我们用前面的代码直接生成Unresolved Logical Plan,

create table tmp_user_info 
as 
select x.stu_id,x.name,y.cls_name from 
( select  cls_id,stu_id,name,sex,age from  student  where dt='20211211' ) x 
left join 
(select  cls_id,cls_name from  class_inf  where dt='20211211') y 
on x.cls_id=y.cls_id
  String querysql="create table tmp_user_info as select x.stu_id,x.name,y.cls_name from ( select  cls_id,stu_id,name,sex,age from  student  where dt='20211211' ) x left join (select  cls_id,cls_name from  class_inf  where dt='20211211') y on x.cls_id=y.cls_id ";
        SparkDriver.spark.sql("use csdn");
        SessionState sessionState = spark.sessionState();
        LogicalPlan plan=  sessionState.sqlParser().parsePlan(querysql);
        System.out.println(plan);

执行结果如下:

'CreateTable `tmp_user_info`, org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe, ErrorIfExists
+- 'Project ['x.stu_id, 'x.name, 'y.cls_name]
   +- 'Join LeftOuter, ('x.cls_id = 'y.cls_id)
      :- 'SubqueryAlias x
      :  +- 'Project ['cls_id, 'stu_id, 'name, 'sex, 'age]
      :     +- 'Filter ('dt = 20211211)
      :        +- 'UnresolvedRelation `student`
      +- 'SubqueryAlias y
         +- 'Project ['cls_id, 'cls_name]
            +- 'Filter ('dt = 20211211)
               +- 'UnresolvedRelation `class_inf`

这个阶,我们可以得到以下的信息:

  1. 如果sql语法本身有错误,那么这个sql也是不可执行的,可以直接帮我们校验出来
  2. 这个阶段其实已经可以拿到我们扫描到我们执行相关的信息,我们其实可以针对信息做一些规则就可以

生成 Analyzed Logical Plan

 LogicalPlan  analyzer= sessionState.executePlan(plan).analyzed();
        System.out.println(analyzer);

结果如下:

CreateHiveTableAsSelectCommand [Database:csdn}, TableName: tmp_user_info, InsertIntoHiveTable]
+- Project [stu_id#18, name#19, cls_name#25]
   +- Join LeftOuter, (cls_id#22 = cls_id#24)
      :- SubqueryAlias x
      :  +- Project [cls_id#22, stu_id#18, name#19, sex#20, age#21]
      :     +- Filter (dt#23 = 20211211)
      :        +- SubqueryAlias student
      :           +- HiveTableRelation `csdn`.`student`, org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe, [stu_id#18, name#19, sex#20, age#21, cls_id#22], [dt#23]
      +- SubqueryAlias y
         +- Project [cls_id#24, cls_name#25]
            +- Filter (dt#26 = 20211211)
               +- SubqueryAlias class_inf
                  +- HiveTableRelation `csdn`.`class_inf`, org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe, [cls_id#24, cls_name#25], [dt#26]

未解析的计划解析一遍,就可以拿到进一步的执行信息。

遍历树

这个是控制台打印的结果,其实就是一颗逻辑解析树,我们直接画出来:
利用SparkSQL Logical Plan Parse 打造大数据平台SQL诊断利器_第2张图片
sql解析的结果本身也是树模型,那么我们怎么去扫描这棵树呢,这个时候得想到我们大学时候的 绿皮书了,“树的遍历深度优先搜索栈或者递归,广度优先搜索搞队列”~~
利用SparkSQL Logical Plan Parse 打造大数据平台SQL诊断利器_第3张图片
LogicalPlan 里面就是按照树状结构进行保存,我们引入一个队列,就可以把里面的节点全部看一遍,遍历三部曲,待访问节点入队列->访问队首节点->子节点再入队列,直到队列空:

 Queue<LogicalPlan> queue = new ArrayDeque<>();
        queue.offer(plan);

        while (!queue.isEmpty()) {
            //访问元素出队列
            LogicalPlan logicalPlan = queue.poll();
            System.out.println("logicalPlan->"+logicalPlan.getClass().getName());
            if (logicalPlan instanceof Project) {
                visitProject((Project) logicalPlan);
            }

            if(logicalPlan instanceof Join){
                visitJoin((Join) logicalPlan);
            }

            if(logicalPlan instanceof Filter){
                visitFilter((Filter) logicalPlan);
            }

            if(logicalPlan instanceof HiveTableRelation){
                visitScanHiveTable((HiveTableRelation) logicalPlan);
            }

            //子节点入队列
            List<LogicalPlan> childrenPlan = scala.collection.JavaConversions
                    .seqAsJavaList(logicalPlan.children());
            if (childrenPlan.size() != 0) {
                for (int i = 0; i < childrenPlan.size(); i++) {
                    queue.offer(childrenPlan.get(i));
                }
            }
        }

要注意的是LogicalPlan在定义的时候是一个抽象类来着,所以具体访问的时候我们需要根据类型转化,完成访问过程,LogicalPlan定义如下:

abstract class LogicalPlan
  extends QueryPlan[LogicalPlan]
  with AnalysisHelper
  with LogicalPlanStats
  with QueryPlanConstraints
  with Logging {

至于具体有哪些呢,我们可以用idea的子类工具查看一下
利用SparkSQL Logical Plan Parse 打造大数据平台SQL诊断利器_第4张图片
其实是在执行阶段的转换不一样的,因为我们并不需要全部都处理,暴力点的办法就直接打印出来,我在代码里面是有打印操作的,所以可以看到具体的实例:

logicalPlan->org.apache.spark.sql.catalyst.plans.logical.SubqueryAlias
logicalPlan->org.apache.spark.sql.catalyst.plans.logical.SubqueryAlias
logicalPlan->org.apache.spark.sql.catalyst.plans.logical.Project
logicalPlan->org.apache.spark.sql.catalyst.plans.logical.Project
logicalPlan->org.apache.spark.sql.catalyst.plans.logical.Filter
logicalPlan->org.apache.spark.sql.catalyst.plans.logical.Filter
logicalPlan->org.apache.spark.sql.catalyst.analysis.UnresolvedRelation
logicalPlan->org.apache.spark.sql.catalyst.analysis.UnresolvedRelation

增加校验规则

当我们可以拿到树的解析信息的时候,我们便可以把规则加到上面了,各种子逻辑特定处理就好了,我这里做一个限制建表的规则,我们前面代码有碰到建表的时候会提供一个方法去处理,我们前提假设,表名里面不包含temp的就不允许建表:

具体的方法实现如下:

  if(logicalPlan instanceof CreateHiveTableAsSelectCommand){
                    CatalogTable table = ((CreateHiveTableAsSelectCommand) logicalPlan).tableDesc();
                    Option<String> db = table.identifier().database();
                    System.out.println("本次建表库名是:"+db.get());
                    System.out.println("本次建表表名是:"+table.qualifiedName());
                    if (db.nonEmpty() && !db.get().contains("temp")) {
                        String qualifiedName = table.qualifiedName();
                        System.out.println("表名"+qualifiedName+"不符合建表规范,请检查");
                    }
                    
            }

我们重新执行刚才的语句,输出效果如下:

logicalPlan->org.apache.spark.sql.hive.execution.CreateHiveTableAsSelectCommand
本次建表库名是:csdn
本次建表表名是:csdn.tmp_user_info
表名csdn.tmp_user_info不符合建表规范,请检查

到这一步为止我们真正可以去做一个sql的校验工作了。

更加丰富的元数据扫描

因为Spark本来就需要利用这些元数据做一些优化,我们可以拿到的数据其实是非常丰富的,涉及表的数据格式,大小,join时候的类型,其实可以构建很丰富的规则的。另外一个场景来说,我们可以作为bad的sql的批量扫描处理,在公司内部是一个数据治理的利器。

Type: MANAGED
Provider: hive
Table Properties: [transient_lastDdlTime=1639296105]
Statistics: 9223372036854775807 bytes
Location: file:/D:/IdeaProject/spark-metrics/spark-warehouse/csdn.db/student
Serde Library: org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe
InputFormat: org.apache.hadoop.mapred.TextInputFormat
OutputFormat: org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat
Storage Properties: [serialization.format=1]
Partition Provider: Catalog
Partition Columns: [`dt`]
Schema: root
 |-- stu_id: integer (nullable = true)
 |-- name: string (nullable = true)
 |-- sex: string (nullable = true)
 |-- age: integer (nullable = true)
 |-- cls_id: integer (nullable = true)
 |-- dt: string (nullable = true)
)

后记

  1. SQL解析的核心这个可以用于生产的,实际生产还需要加上对平台注释和参数的设置,整个因为需要批量扫描和在线校验,所以也是进行了接口处理。
  2. 这个工具还有一个背景是校验哪些些SQL可以从hive切换成SparkSQL来着,所以被校验之后的sql其实可以直接平滑的切换
  3. Presto、ClickHouse等一些多元化引擎的场景接入,其实在解析阶段还需要进行改造
  4. 更复杂的倾斜,参数等场景也是有落地,当然需求永远不会有完结的时候,附上生产上的样子
    利用SparkSQL Logical Plan Parse 打造大数据平台SQL诊断利器_第5张图片
  5. 当然也是比较关键的一点,利用sparksql代码开发,这波操作相对也比较容易的,会对底层操作更加熟悉

我也是喜欢技术交流的,觉得不错的可以关注我一波,里头讨论很热闹的 ^^
利用SparkSQL Logical Plan Parse 打造大数据平台SQL诊断利器_第6张图片

你可能感兴趣的:(Spark,大数据,工具分享,big,data,spark)