为了解决过多依赖 Hive
的问题, SparkSQL
使用了一个新的 SQL
优化器替代 Hive
中的优化器, 这个优化器就是 Catalyst
, 整个 SparkSQL
的架构大致如下
1.API
层简单的说就是Spark
会通过一些API
接受SQL
语句2.收到
SQL
语句以后, 将其交给Catalyst
,Catalyst
负责解析SQL
, 生成执行计划等
3.Catalyst
的输出应该是RDD
的执行计划4.最终交由集群运行
Step 1 : 解析 SQL
, 并且生成 AST
(抽象语法树)
Step 2 : 在 AST
中加入元数据信息, 做这一步主要是为了一些优化, 例如 col = col
这样的条件, 下图是一个简略图, 便于理解
score.id → id#1#L
为score.id
生成id
为 1, 类型是Long
score.math_score → math_score#2#L
为score.math_score
生成id
为 2, 类型为Long
people.id → id#3#L
为people.id
生成id
为 3, 类型为Long
people.age → age#4#L
为people.age
生成id
为 4, 类型为Long
Step 3 : 对已经加入元数据的 AST
, 输入优化器, 进行优化, 从两种常见的优化开始, 简单介绍
谓词下推
Predicate Pushdown
, 将Filter
这种可以减小数据集的操作下推, 放在Scan
的位置, 这样可以减少操作时候的数据量
- 列值裁剪
Column Pruning
, 在谓词下推后,people
表之上的操作只用到了id
列, 所以可以把其它列裁剪掉, 这样可以减少处理的数据量, 从而优化处理速度- 还有其余很多优化点, 大概一共有一二百种, 随着
SparkSQL
的发展, 还会越来越多, 感兴趣的同学可以继续通过源码了解, 源码在org.apache.spark.sql.catalyst.optimizer.Optimizer
Step 4 : 上面的过程生成的 AST
其实最终还没办法直接运行, 这个 AST
叫做 逻辑计划
, 结束后, 需要生成 物理计划
, 从而生成 RDD
来运行
- 在生成`物理计划`的时候, 会经过`成本模型`对整棵树再次执行优化, 选择一个更好的计划
- 在生成`物理计划`以后, 因为考虑到性能, 所以会使用代码生成, 在机器中运行
可以使用 queryExecution
方法查看逻辑执行计划, 使用 explain
方法查看物理执行计划
也可以使用 Spark WebUI
进行查看
总结:
SparkSQL
和RDD
不同的主要点是在于其所操作的数据是结构化的, 提供了对数据更强的感知和分析能力, 能够对代码进行更深层的优化, 而这种能力是由一个叫做Catalyst
的优化器所提供的
Catalyst
的主要运作原理是分为三步, 先对SQL
或者Dataset
的代码解析, 生成逻辑计划, 后对逻辑计划进行优化, 再生成物理计划, 最后生成代码到集群中以RDD
的形式运行
今天的文章calcite 优化器_网络优化器分享到此就结束了,感谢您的阅读。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/64890.html