[大数据]关于MySQLPostgreSQLImpalaSpark的执行计划-总结

执行/查询计划老外有三种叫法：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

创作打卡挑战赛

赢取流量/现金/CSDN周边激励大奖