本文共 5765 字,大约阅读时间需要 19 分钟。
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: intProject [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: intProject [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%的时间消耗,效果还是很明显的。
如果有什么错误的地方也欢迎大家指正。
转载地址:http://oinaz.baihongyu.com/