Spark Sql JDBC实现 聚合union同数据源Join等下推

Posted 2021-05-11 郭朝阳@

Spark Sql JDBC实现 聚合、union、同数据源Join等下推

简单熟悉下Spark Sql 处理JDBC数据源数据

spark Sql处理JDBC数据源的代码比较简单，大家可以自行阅读官网使用demo。

个人觉得比较鸡肋的地方

单元测试如下：
说明： emp，dept是通过spark 读取mysql的同一个库的两张表

  test("selectSubQuery"){
    val sql =
      """
        |select *
        |from   emp where id > (select min(a.id) from emp a join dept b on a.deptId =b.id)
        |""".stripMargin
    val frameResult = session.sql(sql)
    frameResult.explain(true)
    frameResult.show()
  }

查看执行计划

== Parsed Logical Plan ==
'Project [*]
+- 'Filter ('id > scalar-subquery#34 [])
   :  +- 'Project [unresolvedalias('min('a.id), None)]
   :     +- 'Join Inner, ('a.deptId = 'b.id)
   :        :- 'SubqueryAlias a
   :        :  +- 'UnresolvedRelation [emp], [], false
   :        +- 'SubqueryAlias b
   :           +- 'UnresolvedRelation [dept], [], false
   +- 'UnresolvedRelation [emp], [], false

== Analyzed Logical Plan ==
ID: int, NAME: string, JOB: string, MGR: int, HIREDATE: date, SAL: decimal(20,2), COMM: decimal(20,2), DEPTID: int
Project [ID#12, NAME#13, JOB#14, MGR#15, HIREDATE#16, SAL#17, COMM#18, DEPTID#19]
+- Filter (id#12 > scalar-subquery#34 [])
   :  +- Aggregate [min(id#12) AS min(id)#36]
   :     +- Join Inner, (deptId#19 = id#6)
   :        :- SubqueryAlias a
   :        :  +- SubqueryAlias emp
   :        :     +- Relation[ID#12,NAME#13,JOB#14,MGR#15,HIREDATE#16,SAL#17,COMM#18,DEPTID#19] JDBCRelation(emp) [numPartitions=1]
   :        +- SubqueryAlias b
   :           +- SubqueryAlias dept
   :              +- Relation[ID#6,NAME#7,LOC#8] JDBCRelation(dept) [numPartitions=1]
   +- SubqueryAlias emp
      +- Relation[ID#12,NAME#13,JOB#14,MGR#15,HIREDATE#16,SAL#17,COMM#18,DEPTID#19] JDBCRelation(emp) [numPartitions=1]

== Optimized Logical Plan ==
Filter (isnotnull(id#12) AND (id#12 > scalar-subquery#34 []))
:  +- Aggregate [min(id#12) AS min(id)#36]
:     +- Project [ID#12]
:        +- Join Inner, (deptId#19 = id#6)
:           :- Project [ID#12, DEPTID#19]
:           :  +- Filter isnotnull(deptId#19)
:           :     +- Relation[ID#12,NAME#13,JOB#14,MGR#15,HIREDATE#16,SAL#17,COMM#18,DEPTID#19] JDBCRelation(emp) [numPartitions=1]
:           +- Project [ID#6]
:              +- Filter isnotnull(id#6)
:                 +- Relation[ID#6,NAME#7,LOC#8] JDBCRelation(dept) [numPartitions=1]
+- Relation[ID#12,NAME#13,JOB#14,MGR#15,HIREDATE#16,SAL#17,COMM#18,DEPTID#19] JDBCRelation(emp) [numPartitions=1]

== Physical Plan ==
*(1) Filter (ID#12 > Subquery scalar-subquery#34, [id=#64])
:  +- Subquery scalar-subquery#34, [id=#64]
:     +- *(6) HashAggregate(keys=[], functions=[min(id#12)], output=[min(id)#36])
:        +- Exchange SinglePartition, ENSURE_REQUIREMENTS, [id=#60]
:           +- *(5) HashAggregate(keys=[], functions=[partial_min(id#12)], output=[min#46])
:              +- *(5) Project [ID#12]
:                 +- *(5) SortMergeJoin [deptId#19], [id#6], Inner
:                    :- *(2) Sort [deptId#19 ASC NULLS FIRST], false, 0
:                    :  +- Exchange hashpartitioning(deptId#19, 200), ENSURE_REQUIREMENTS, [id=#45]
:                    :     +- *(1) Scan JDBCRelation(emp) [numPartitions=1] [ID#12,DEPTID#19] PushedFilters: [*IsNotNull(DEPTID)], ReadSchema: struct<ID:int,DEPTID:int>
:                    +- *(4) Sort [id#6 ASC NULLS FIRST], false, 0
:                       +- Exchange hashpartitioning(id#6, 200), ENSURE_REQUIREMENTS, [id=#51]
:                          +- *(3) Scan JDBCRelation(dept) [numPartitions=1] [ID#6] PushedFilters: [*IsNotNull(ID)], ReadSchema: struct<ID:int>
+- *(1) Scan JDBCRelation(emp) [numPartitions=1] [ID#12,NAME#13,JOB#14,MGR#15,HIREDATE#16,SAL#17,COMM#18,DEPTID#19] PushedFilters: [*IsNotNull(ID)], ReadSchema: struct<ID:int,NAME:string,JOB:string,MGR:int,HIREDATE:date,SAL:decimal(20,2),COMM:decimal(20,2),D...

执行结果如下：

缺点分析：

上图可以看出：
1.spark 总共进行了三次JDBC 连接进行查询请求。
2.聚合，join没有进行下沉，增加了内存计算的复杂度。

再次说明下，单元测试中的查询请求，比较简单，
就是查询同一个库的两张表格，会进行三次访问数据库，并且没有做到聚合和join的下沉（spark 目前支持了 谓词下推，列裁剪，常量累加等优化），频繁的查库和数据的网络Io比较消耗时间。

优化操作

这里的优化主要使用的是Spark 提供的扩展接口Extensions，优化spark 的RBO和CBO规则。这里的原理和细节比较复杂，下篇文章描述。

优化后的执行计划

== Parsed Logical Plan ==
'Project [*]
+- 'Filter ('id > scalar-subquery#34 [])
   :  +- 'Project [unresolvedalias('min('a.id), None)]
   :     +- 'Join Inner, ('a.deptId = 'b.id)
   :        :- 'SubqueryAlias a
   :        :  +- 'UnresolvedRelation [emp], [], false
   :        +- 'SubqueryAlias b
   :           +- 'UnresolvedRelation [dept], [], false
   +- 'UnresolvedRelation [emp], [], false

== Analyzed Logical Plan ==
ID: int, NAME: string, JOB: string, MGR: int, HIREDATE: date, SAL: decimal(20,2), COMM: decimal(20,2), DEPTID: int
Project [ID#12, NAME#13, JOB#14, MGR#15, HIREDATE#16, SAL#17, COMM#18, DEPTID#19]
+- Filter (id#12 > scalar-subquery#34 [])
   :  +- Aggregate [min(id#12) AS min(id)#36]
   :     +- Join Inner, (deptId#19 = id#6)
   :        :- SubqueryAlias a
   :        :  +- SubqueryAlias emp
   :        :     +- RelationV2[ID#12, NAME#13, JOB#14, MGR#15, HIREDATE#16, SAL#17, COMM#18, DEPTID#19] nameString
   :        +- SubqueryAlias b
   :           +- SubqueryAlias dept
   :              +- RelationV2[ID#6, NAME#7, LOC#8] nameString
   +- SubqueryAlias emp
      +- RelationV2[ID#12, NAME#13, JOB#14, MGR#15, HIREDATE#16, SAL#17, COMM#18, DEPTID#19] nameString

== Optimized Logical Plan ==
RelationV2[ID#47, NAME#48, JOB#49, MGR#50, HIREDATE#51, SAL#52, COMM#53, DEPTID#54] nameString

== Physical Plan ==
*(1) Scan org.apache.spark.sql.execution.datasources.v2.jdbc.JDBCScan$$anon$1@237c8718 [ID#47,NAME#48,JOB#49,MGR#50,HIREDATE#51,SAL#52,COMM#53,DEPTID#54] PushedFilters: [], ReadSchema: struct<ID:int,NAME:string,JOB:string,MGR:int,HIREDATE:date,SAL:decimal(20,2),COMM:decimal(20,2),D...

从优化后的物理执行计划可以看出，之前三次的JDBC 请求，已经合并为一次，并且之前内存计算的聚合，join 操作也一起下沉到了Sql 中了，两次的查询结果也完全一致。

可能小伙伴们会有疑问： 这不就是相当于把计算交给了数据源去做吗？ 是的，就是这样的。

个人觉得好处如下

1. 节约了多次建立JDBC请求的时间。

2. 如果表的数据量很大，节约了数据传输的网络和Io的时间。

3. 移动计算，而非移动数据，数据在数据库本地有 索引，缓存等等数据库的优化夹持，计算并不比spark慢。

简单的性能测试：
说明： 由于是本地的数据库测试，并且数据量不是很大，可能优势并不是很明显。在生产环境下优化肯定成倍数提升。

结论

上面两幅图可以看出来优化了将近60%的时间消耗，效果还是很明显的。

如果有什么错误的地方也欢迎大家指正。