SparkSql 是架构在 Spark 计算框架之上的分布式 Sql 引擎，使用 DataFrame 和 DataSet 承载结构化和半结构化数据来实现数据复杂查询处理，提供的 DSL可以直接使用 scala 语言完成 Sql 查询，同时也使用 thriftserver 提供服务化的 Sql 查询功能。
上篇
1.SparkSql
SparkSql 是架构在 Spark 计算框架之上的分布式 Sql 引擎，使用 DataFrame 和 DataSet 承载结构化和半结构化数据来实现数据复杂查询处理，提供的 DSL可以直接使用 scala 语言完成 Sql 查询，同时也使用 thriftserver 提供服务化的 Sql 查询功能。
SparkSql 提供了 DataSource API ，用户通过这套 API 可以自己开发一套 Connector，直接查询各类数据源，数据源包括 NoSql、RDBMS、搜索引擎以及 HDFS 等分布式文件系统上的文件等。和 SparkSql 类似的系统有 Hive、PrestoDB 以及 Impala，这类系统都属于所谓的" Sql on Hadoop "系统,每个都相当火爆，毕竟在这个不搞 SQL 就是耍流氓的年代，没 SQL 确实很难找到用户使用。
2.连接查询和连接条件
Sql中的连接查询(join)，主要分为内连接查询(inner join)、外连接查询(outter join)和半连接查询(semi join)，具体的区别可以参考wiki的解释。
连接条件(join condition)，则是指当这个条件满足时两表的两行数据才能"join"在一起被返回，例如有如下查询：
其中的"LT.id=RT.idAND LT.id>1"这部分条件被称为"join中条件"，直接用来判断被join的两表的两行记录能否被join在一起，如果不满足这个条件，两表的这两行记录并非全部被踢出局，而是根据连接查询类型的不同有不同的处理，所以这并非一个单表的过滤过程或者两个表的的“联合过滤”过程;而where后的"RT.id>2"这部分被称为"join后条件"，这里虽然成为"join后条件"，但是并非一定要在join后才能去过滤数据，只是说明如果在join后进行过滤，肯定可以得到一个正确的结果，这也是我们后边分析问题时得到正确结果的基准方法。
3.谓词下推
所谓谓词(predicate)，英文定义是这样的：A predicate is a function that returns bool (or something that can be implicitly converted to bool)，也就是返回值是true或者false的函数，使用过scala或者spark的同学都知道有个filter方法，这个高阶函数传入的参数就是一个返回true或者false的函数。
但是如果是在sql语言中，没有方法，只有表达式。where后边的表达式起的作用正是过滤的作用，而这部分语句被sql层解析处理后，在数据库内部正是以谓词的形式呈现的。
那么问题来了，谓词为什么要下推呢? SparkSql中的谓词下推有两层含义，第一层含义是指由谁来完成数据过滤，第二层含义是指何时完成数据过滤。要解答这两个问题我们需要了解SparkSql的Sql语句处理逻辑，大致可以把SparkSql中的查询处理流程做如下的划分：
SparkSql首先会对输入的Sql语句进行一系列的分析(Analyse)，包括词法解析(可以理解为搜索引擎中的分词这个过程)、语法分析以及语义分析(例如判断database或者table是否存在、group by必须和聚合函数结合等规则);之后是执行计划的生成，包括逻辑计划和物理计划。其中在逻辑计划阶段会有很多的优化，如果你对大数据开发感兴趣，想系统学习大数据的话，可以加入大数据技术学习交流扣群：522数字189数字307获取学习资源，对谓词的处理就在这个阶段完成;而物理计划则是RDD的DAG图的生成过程;这两步完成之后则是具体的执行了(也就是各种重量级的计算逻辑，例如join、groupby、filter以及distinct等)，这就会有各种物理操作符(RDD的Transformation)的乱入。
能够完成数据过滤的主体有两个，第一是分布式Sql层(在execute阶段)，第二个是数据源。那么谓词下推的第一层含义就是指由Sql层的Filter操作符来完成过滤，还是由Scan操作符在扫描阶段完成过滤。
上边提到，我们可以通过封装SparkSql的Data Source API完成各类数据源的查询，那么如果底层数据源无法高效完成数据的过滤，就会执行全局扫描，把每条相关的数据都交给SparkSql的Filter操作符完成过滤，虽然SparkSql使用的Code Generation技术极大的提高了数据过滤的效率，但是这个过程无法避免大量数据的磁盘读取，甚至在某些情况下会涉及网络IO(例如数据非本地化存储时);如果底层数据源在进行扫描时能非常快速的完成数据的过滤，那么就会把过滤交给底层数据源来完成(至于哪些数据源能高效完成数据的过滤以及SparkSql又是如何完成高效数据过滤的则不是本文讨论的重点，会在其他系列的文章中介绍)。
那么谓词下推第二层含义，即何时完成数据过滤则一般是在指连接查询中，是先对单表数据进行过滤再和其他表连接还是在先把多表进行连接再对连接后的临时表进行过滤，则是本系列文章要分析和讨论的重点。
4.内连接查询中的谓词下推规则
假设我们有两张表，表结构很简单，数据也都只有两条，但是足以讲清楚我们的下推规则，两表如下，一个lefttable,一个righttable：
4.1.Join后条件通过AND连接
先来看一条查询语句：
这个查询是一个内连接查询，join后条件是用and连接的两个表的过滤条件，假设我们不下推，而是先做内连接判断，这时是可以得到正确结果的，步骤如下：
左表id为1的行在右表中可以找到，即这两行数据可以"join"在一起
左表id为2的行在右表中可以找到，这两行也可以"join"在一起
至此，join的临时结果表(之所以是临时表，因为还没有进行过滤)如下：
然后使用where条件进行过滤，显然临时表中的第一行不满足条件，被过滤掉，最后结果如下：
来看看先进行谓词下推的情况。先对两表进行过滤，过滤的结果分别如下：
然后再对这两个过滤后的表进行内连接处理，结果如下：
可见，这和先进行join再过滤得到的结果一致。
4.2.Join后条件通过OR连接
再来看一条查询语句：
我们先进行join处理，临时表的结果如下：
然后使用where条件进行过滤，最终查询结果如下：
如果我们先使用where条件后每个表各自的过滤条件进行过滤，那么两表的过滤结果如下：
然后对这两个临时表进行内连接处理，结果如下：
表格有问题吧，只有字段名，没有字段值，怎么回事?是的，你没看错，确实没有值，因为左表过滤结果只有id为1的行，右表过滤结果只有id为2的行，这两行是不能内连接上的，所以没有结果。
那么为什么where条件中两表的条件被or连接就会出现错误的查询结果呢?分析原因主要是因为，对于or两侧的过滤条件，任何一个满足条件即可以返回TRUE，那么对于"LT.value = 'two' OR RT.value = 'two' "这个查询条件，如果使用LT.value='two'把只有LT.value为'two'的左表记录过滤出来，那么对于左表中LT.value不为two的行，他们可能在跟右表使用id字段连接上之后，右表的RT.value恰好为two，也满足"LT.value = 'two' OR RT.value = 'two' "，但是可惜呀可惜，这行记录因为之前的粗暴处理，已经被过滤掉，结果就是得到了错误的查询结果。所以这种情况下谓词是不能下推的。
但是OR连接两表join后条件也有两个例外，这里顺便分析第一个例外。第一个例外是过滤条件字段恰好为Join字段，比如如下的查询：
在这个查询中，join后条件依然是使用OR连接两表的过滤条件，不同的是，join中条件不再是id相等，而是value字段相等，也就是说过滤条件字段恰好就是join条件字段。大家可以自行采用上边的分步法分析谓词下推和不下推时的查询结果，得到的结果是相同的。
我们来看看上边不能下推时出现的情况在这种查询里会不会出现。对于左表，如果使用LT.value='two'过滤掉不符合条件的其他行，那么因为join条件字段也是value字段，说明在左表中LT.value不等于two的行，在右表中也不能等于two，否则就不满足"LT.value=RT.value"了。这里其实有一个条件传递的过程，通过join中条件，已经在逻辑上提前把两表整合成了一张表。
至于第二个例外，则涉及了SparkSql中的一个优化，所以需要单独介绍。
4.3.分区表使用OR连接过滤条件
如果两个表都是分区表，会出现什么情况呢?我们先来看如下的查询：
此时左表和右表都不再是普通的表，而是分区表，分区字段是pt，按照日期进行数据分区。同时两表查询条件依然使用OR进行连接。试想，如果不能提前对两表进行过滤，那么会有非常巨量的数据要首先进行连接处理，这个代价是非常大的。但是如果按照我们在2中的分析，使用OR连接两表的过滤条件，又不能随意的进行谓词下推，那要如何处理呢?SparkSql在这里使用了一种叫做“分区裁剪”的优化手段，即把分区并不看做普通的过滤条件，而是使用了“一刀切”的方法，把不符合查询分区条件的目录直接排除在待扫描的目录之外。
我们知道分区表在HDFS上是按照目录来存储一个分区的数据的，那么在进行分区裁剪时，直接把要扫描的HDFS目录通知Spark的Scan操作符，这样，Spark在进行扫描时，就可以直接咔嚓掉其他的分区数据了。但是，要完成这种优化，需要SparkSql的语义分析逻辑能够正确的分析出Sql语句所要表达的精确目的，所以分区字段在SparkSql的元数据中也是独立于其他普通字段，进行了单独的标示，就是为了方便语义分析逻辑能区别处理Sql语句中where条件里的这种特殊情况。
下篇
本篇主要介绍的是--外连接查询中的谓词下推规则，这相比内连接中的规则要复杂一些，不过使用简单的表格来进行分析也是可以分析清楚的。先上表：
我们以左外连接查询为例，先总结规矩如下:
接下来对这个表格中的规则进行详细的分析。
1.左表join后条件下推
查询语句如下：
前文有提到，对于join后条件，如果放在join操作后执行，是可以作为正确结果进行比对的。那么先对两表进行左连接，结果如下：
然后使用LT.id>1这个join后条件进行过滤，结果如下：
来分析一下LT.id>1下推到左表进行数据过滤的结果,经过LT.id>1过滤后，左表变为：
此时再和右表进行左连接，左表id为2的行，在右表中能找到id为2的行，则连接结果如下：
可见，两种处理方法结果一致。条件下推过滤了左表整整50%的数据(相当牛，虽然只过滤了一条)。究其原因，是因为在SparkSQL中，把以上的查询解析成了如下的子查询：
这是一个非相关子查询，即完全可以先完成子查询，再完成父查询，子查询在查询过程中和外部查询没有关联关系。
2.左表join中条件不下推
查询语句如下：
来看看不下推的情况下计算出的正确结果，join过程如下：
第一步：左表id为1的行在右表中能找到相等的id，但是左表的id为1，是不满足第二个join条件(LT.id>1)的，所以左表这一条相当于没有和右表join上，所以左表的值value保留，而右表的value为null(你没满足join中条件没join上还把你的值保留，给我搞个空值?没办法，就是这么任性)。
第二步：左表id为2的行在右表中能找到，而且左表id为2的行的id大于1，两个join条件都满足，所以算是和右表join上了，所以左表和右表的value都保留。最终的查询结果如下：
那么如果把"LT.id>1"这个条件下推到做表，会得到什么结果呢?
首先左表经过"LT.id>1"过滤后，如下：
此时再和右表连接，左表id为2的行在右表中能找到，且满足"LT.id = RT.id AND LT.id > 1"这个join中条件，所以两表的value都被保留。左表中已经没有数据了，查询结束，查询结果如下：
这个查询结果和不下推的正确结果不一致，是个错误的结果，所以左表join中条件是不能下推进行数据过滤的。分析原因：主要是因为join中条件和join后条件对结果的处理方式不同，前者在不满足join条件时会保留一部分结果，而后者在不满足条件时任何东西都不保留。
3.右表join中条件下推
查询语句如下：
现在把RT.id>1这个右表join后条件下推，来过滤右表，过滤后如下：
然后左表再和右表进行左连接，流程如下：
第一步：左表id为1的行在右表中没有，此时左表值保留，右表为null;
第二步：左表id位2的行在右表中有，并且RT.id大于1，两个join条件都满足，则左表和右表的值都保留。查询结果如下：
那么如果不下推(为了得到正确结果)，来看看结果，流程如下：
第一步：左表id为1的行在右表中有，但是不满足第二个join条件，所以这行算是没join上，所以左表数据保留，右表为null;
第二步：左表id为2的行在右表中有，也满足第二个join条件，所以左右表的数据都保留。
可见，右表join中条件下推不下推，结果一样，所以，干吗不下推?可以过滤掉一半的数据呢。SparkSQL中的等价处理语句是：
可以看出，也是解析成了一个非相关子查询来处理的。
4.右表join中条件不下推
这个应该是最违反常规理解的查询了，查询语句如下：
首先来看，join后条件不下推的情况，流程如下：
第一步：左表id为1的行在右表中可以找到，但是此时仅仅满足join条件，在使用where条件判断这条连接后数据时，发现右表的id不满足RT.id>1的条件，所以这条join结果不保留(注意：这里是不保留，全都不保留，左表右表都不保留，要跟上边的没join上而右表的值保留为null的情况区别开，这也是关键所在);
第二步：左表id为2的行和右表id为2的行join上了，同时也满足RT.id>1的where条件。
这是一条符合语义的正确的查询结果。
好了，接下来看看右表join后条件下推的情况：
第一步：使用RT.id>1过滤右表，过滤后右表只剩一行id为2的行;
第二步：左表id为1的行在过滤后的右表中没有，此时左表值保留，右表值为null;
第三步：左表id为2的行在右表中有，此时左表值保留，右表值也保留。
结果如下：
很明显这其实是一个错误的结果。
总结
至此，左连接查询的四条规则分析完了。可以看出，在SparkSQL中对于外连接查询时的过滤条件，并不能在所有情况下都用来进行数据源的过滤，如果使用得当会极大的提升查询性能，如果使用不当，则会产生错误的查询结果，而这种错误结果又不易发觉，所以使用时要格外小心。
