关于MySQL,PostgreSQL,Impala,Spark的执行计划-总结

最新推荐文章于 2024-05-06 09:34:29 发布

荒野求思

最新推荐文章于 2024-05-06 09:34:29 发布

阅读量1.1k

点赞数

分类专栏：大数据文章标签： postgresql mysql spark

本文链接：https://blog.csdn.net/qq_31807385/article/details/124675667

版权

大数据专栏收录该内容

25 篇文章 9 订阅

订阅专栏

执行/查询计划老外有三种叫法：Execution plan/query explanation paln/query plan¹。这个概念起源于关系型数据库，后来开源OLAP引擎同样follow了RDB的传统，实现了查询计划

⚠️：执行计划是优化器/执行器打算访问数据的步骤，所以实际并没有真的执行

1-MySQL 执行计划

下图是MySQL的执行计划²的例子

在这里插入图片描述

实践中，ref_or_null类型看到的还是比较少的；为什么无须回表的index的要劣于range？举个🌰 goods_name字段上有索引，对于 select goods_name from goods where goods_name like '%果%'，即便有索引，且无须回表，但是还需要全索引扫描的

MySQL更加详细执行计划输出³，Oracle官网有详细的描述，可前往查看

2-PostgreSQL执行计划

在这里插入图片描述

上图是PostgreSQL的执行计划⁴的例子，①图和②图的区别是②中增加了analyze参数，该参数会触发当前查询实际执行；③号图中的执行计划可以缩略为④号图，类似编程语言中的函数调用

在这里插入图片描述

关于PostgreSQL中的 seq_scan,index_scan,bitmap scan⁵：

1️⃣seq_scan：全表扫描 when select a LOT of data from a table

2️⃣index_scan: Index Only Scan when select a handful of rows

3️⃣bitmap scan : too much row for an index scan to be efficient but too little for a sequential scan，如下图：

PostgreSQL的执行计划输出，PostgreSQL官网⁶⁷有详细的描述，可前往查看

3-impala执行计划

关于impala本身，你必须知道它是一个MPP SQL引擎。impala的执行计划官网上描述的很少，全是俗媚的描述性内容，参考意义不大，阅读impala paper⁸，观看cloudera出品的教学视频⁹ 是一个更上头的操作，要区分impala的execution plan和execution profile，前者是未执行就可获知，后者需要执行后才能获取

3.1-impala SQL查询流和impala逻辑视图

下图中上半部分来于视频，下半部分来自于论文

在这里插入图片描述

就上图做以下几点说明：

1️⃣ 从SQL查询流中可看出，客户端提交的SQL会被Impala前台编译为执行计划，再交给impala后台执行，最后将查询结果/查询简介返回给客户端

2️⃣ 从Impala逻辑视图中看出，impala逻辑上分为3个模块(虚线圈出)：元数据模块+执行模块+存储模块

3️⃣ 上图的下半部分展示了一个SQL在impala的整个生命周期(序号标记了整个生命周期)

3.2-impala执行计划的2个阶段

在这里插入图片描述

上图(上半部分来源于视频，下半部分来源于论文)展示了Impala的执行计划分为2个阶段，

🅰️single node plan : 单机上的执行计划

🅱️distributed node plan : 分布式执行计划，全局内哪些查询是并行的，哪些是需要数据交换(exchance)的

可以看到distributed plan相对于single plan增加了Exchange，这是因为如果数据分布在不同的节点上，我们需要使用使用类似Grace Hash Join的方式使得相同的key去往同一个节点，这个类似Hive/Spark中shuffle的行为，在impala中标记为exchange，在Spark中也被标记为exchange

4-Spark执行计划

Spark中SQL(DataSet，DataFrame，Cypher)的解析，分析，优化等都是由Catalyst¹⁰¹¹完成的，下图是Catalyst的逻辑视图

在这里插入图片描述

1️⃣Catalyst会生成多个physical plan，但是最终会选择根据Cost Model(执行时间、资源消耗等)一个

2️⃣Adaptive Query Execution是Spark3.0的功能，Catalyst会在计划执行时收集统计信息，如果发现更好的计划，可以在运行时改变执行计划

以上就是关于执行计划的一个不深不浅的描述，欢迎吐槽，欢迎关注公众号：stackoverflow

🔞Reference

query plan wiki : https://en.wikipedia.org/wiki/Query_plan ↩︎
mysql query plan : https://www.youtube.com/watch?v=9K26Wb84f50 ↩︎
mysql explain output format: https://dev.mysql.com/doc/refman/8.0/en/explain-output.html ↩︎
postgresql query plan : https://www.youtube.com/watch?v=Mll5SqR4RYk&t=632s ↩︎
seq_scan,inde_scan,bitmap_scan: https://www.cybertec-postgresql.com/en/postgresql-indexing-index-scan-vs-bitmap-scan-vs-sequential-scan-basics/ ↩︎
postgresql explain output format : https://www.postgresql.org/docs/10/using-explain.html | ↩ ↩︎
postgresql performance tuning: https://www.postgresql.org/docs/8.1/performance-tips.html ↩︎
impala parper : http://www.cidrdb.org/cidr2015/Papers/CIDR15_Paper28.pdf ↩︎
impala tutorial of cloudera : https://www.youtube.com/watch?v=J0n-yORrmcU ↩︎
spark execution video : https://www.youtube.com/watch?v=YgQgJceojJY&list=WL&index=1&t=334s ↩︎
spark execution blog : https://medium.com/datalex/sparks-logical-and-physical-plans-when-why-how-and-beyond-8cd1947b605a ↩︎