76、Spark SQL之工作原理剖析以及性能优化
原理剖析
执行计划
只要是在数据库类型的技术里面，比如传统的MySql、Oracle等，包括现在大数据领域的数据仓库，比如Hive，它的基本的SQL执行的模型，都是类似的，首先都是要生成一条SQL语句的执行计划
比如，select name from students => 从哪里去查询，students表，在那个文件里，从文件中查询哪些数据，比如说是name这个列，还有，查询时，是否对表中数据进行过滤和筛选，复杂的SQL，需要多表Join，此外还有，执行计划还涉及到如果扫描和利用索引
逻辑的执行计划
逻辑的执行计划，更多的是，偏向于逻辑，比如说，from table students => filter ...=>select name...
基本上，逻辑计划，都是采用Tree，树形结构的
优化的逻辑计划
如传统的Oracle数据库，通常会生成多个执行计划，然后，有一个优化器，针对多个计划，选择一个最好的计划，而Spark SQL这的优化，指的是，刚生成的执行计划中，有些地方的性能使显而易见的不好，比如
有一个SQL语句 select name from (select ... from ...) where ... = ...，此时，在执行计划解析出来的时候，还是按照它原封不动的样子，来解析可以执行的计划的，但是Optimizer，在这里，就会对执行计划进行优化，比如说，发现where条件，其实可以放到子查询里面，这样，子查询的数据量大大变小，可以优化执行速度，此时，可能就会变成这样，select name from (select ... from ... where ... = ...)
物理计划
物理计划，就是非常“接地气”的计划了，就是说，已经知道从哪个文件读取什么数据，从那几个文件中读取，如何进行关联等
性能优化
- 设置Shuffle过程中的并行度：spark.sql.shuffle.partitions（SQLContext.setConf()）
- 在Hive数据仓库建设过程中，合理设置数据类型，比如能设置为INT的，就不要设置为BIGINT。减少数据类型导致的不必要的内存开销。
- 编写SQL时，尽量给出明确的列名，比如select name from students。不要写select *的方式。
- 并行处理查询结果：对于Spark SQL查询的结果，如果数据量比较大，比如超过1000条，那么就不要一次性collect()到Driver再处理。使用foreach()算子，并行处理查询结果。
- 缓存表：对于一条SQL语句中可能多次使用到的表，可以对其进行缓存，使用SQLContext.cacheTable(tableName)，或者DataFrame.cache()即可。Spark SQL会用内存列存储的格式进行表的缓存。然后Spark SQL就可以仅仅扫描需要使用的列，并且自动优化压缩，来最小化内存使用和GC开销。SQLContext.uncacheTable(tableName)可以将表从缓存中移除。用SQLContext.setConf()，设置spark.sql.inMemoryColumnarStorage.batchSize参数（默认10000），可以配置列存储的单位。
- 广播join表：spark.sql.autoBroadcastJoinThreshold，默认10485760 (10 MB)。在内存够用的情况下，可以增加其大小，概参数设置了一个表在join的时候，最大在多大以内，可以被广播出去优化性能。
- 钨丝计划：spark.sql.tungsten.enabled，默认是true，自动管理内存。
最有效的，其实就是第四点、缓存表和广播join表，也是非常不错的！