Spark Sql

本文主要介绍SparkSQL的优化器系统Catalyst，其设计思路基本都来自于传统型数据库，并且和大多数当前的大数据SQL处理引擎设计基本相同（Impala、Presto、Hive（Calcite）等），所以经过本文的学习也能够基本了解全部其余SQL处理引擎的工做原理。

SQL优化器核心执行策略主要分为两个大的方向：基于规则优化（RBO）以及基于代价优化(CBO)，基于规则优化是一种经验式、启发式地优化思路，更多地依靠前辈总结出来的优化规则，简单易行且可以覆盖到大部分优化逻辑，可是对于核心优化算子Join却显得有点力不从心。举个简单的例子，两个表执行Join到底应该使用BroadcastHashJoin仍是SortMergeJoin？当前SparkSQL的方式是经过手工设定参数来肯定，若是一个表的数据量小于这个值就使用BroadcastHashJoin，可是这种方案显得很不优雅，很不灵活。基于代价优化就是为了解决这类问题，它会针对每一个Join评估当前两张表使用每种Join策略的代价，根据代价估算肯定一种代价最小的方案。

在介绍SQL优化器工做原理以前，有必要首先介绍两个重要的数据结构：Tree和Rule。相信不管对SQL优化器有无了解，都确定知道SQL语法树这个概念，不错，SQL语法树就是SQL语句经过编译器以后会被解析成一棵树状结构。这棵树会包含不少节点对象，每一个节点都拥有特定的数据类型，同时会有0个或多个孩子节点（节点对象在代码中定义为TreeNode对象）。在任何一个SQL优化器中，一般会定义大量的Rule（后面会讲到），SQL优化器会遍历语法树中每一个节点，针对遍历到的节点模式匹配全部给定规则（Rule），若是有匹配成功的，就进行相应转换，若是全部规则都匹配失败，就继续遍历下一个节点。

Catalyst工做流程

任何一个优化器工做原理都大同小异：SQL语句首先经过Parser模块被解析为语法树，此棵树称为Unresolved Logical Plan；Unresolved Logical Plan经过Analyzer模块借助于数据元数据解析为Logical Plan；此时再经过各类基于规则的优化策略进行深刻优化，获得Optimized Logical Plan；优化后的逻辑执行计划依然是逻辑的，并不能被Spark系统理解，此时须要将此逻辑执行计划转换为Physical Plan；为了更好的对整个过程进行理解，下文经过一个简单示例进行解释。