Spark Sql JDBC实现 聚合、union、同数据源Join等下推
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
: +- *(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
+- *(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 执行结果如下：
缺点分析：
上图可以看出：
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
从优化后的物理执行计划可以看出，之前三次的JDBC 请求，已经合并为一次，并且之前内存计算的聚合，join 操作也一起下沉到了Sql 中了，两次的查询结果也完全一致。
可能小伙伴们会有疑问： 这不就是相当于把计算交给了数据源去做吗？ 是的，就是这样的。
个人觉得好处如下
-
节约了多次建立JDBC请求的时间。
-
如果表的数据量很大，节约了数据传输的网络和Io的时间。
-
移动计算，而非移动数据，数据在数据库本地有 索引，缓存等等数据库的优化夹持，计算并不比spark慢。
简单的性能测试：
说明： 由于是本地的数据库测试，并且数据量不是很大，可能优势并不是很明显。在生产环境下优化肯定成倍数提升。
结论
上面两幅图可以看出来优化了将近60%的时间消耗，效果还是很明显的。
如果有什么错误的地方也欢迎大家指正。