先前在读过 Spark RDD 的论文后，我从 MIT 6.824 的课程笔记中了解到，RDD 在 Apache Spark 中已经不那么常用，开发重心渐渐转移到了 Spark SQL 的 DataFrame API 上。在我第一次实习的时候其实也有读过 Spark SQL 的论文，那这次就重新读读这篇论文，总结一下吧。

我的上一个系列的 Spark 源码解析已经完结了一段时间了。当时我出于实习工作的需要阅读了 SparkSQL 以及 Spark REPL 的源代码，并顺势写下了那个系列的源码解析文章。但读 Spark 源代码怎么能只读那些外围插件的源代码呢？于是我又开一个新坑了。

在之前的文章中，我们已经了解了 SparkSQL 把 SQL 语句变为 SparkJob 的过程。这个过程我们只是做了一个 Overview，具体不同的语句会变为怎样的 Job 我们并未一一列举。实际上列举起来是一件相当大工程的事。

在那么多的 SQL 操作中，有那么一个操作十分常用，但又十分耗时，那就是 Join 操作。在这篇文章里，我们将深入探讨 SparkSQL 会对不同的 Join 做出怎样的操作。

在上一篇文章中，我们详细讲解了 SparkSQL 如何一步一步地将用户输入的 SQL 语句变为 LogicalPlan 再变为 PhysicalPlan。
至此，这个流程本身的内容已经全部讲完了，因此接下来的文章我们将脱离这个主要流程，去讲解 SparkSQL 的其他常用功能。

在今天的这篇文章中，我们先从 SparkSQL 的 DataFrame Cache 机制开始讲起。

在之前的 SparkSQL Catalyst 源码解析中，我大致的讲解了 SparkSQL 的执行流程，用户输入的 SQL 语句如何一步一步地变为 Logical Plan 再变为 Physical Plan，再执行成为结果 RDD。上一个系列旨在抛砖引玉，该流程中的每个重要部件如 Parser 、 Analyzer 、Optimizer 、 Planner 等仅仅讲解了它们是如何管理和运行一些列的 rule，但并未仔细讲解每一个 rule 的功能。

接下来的内容旨在更深入地研究这些被上一个系列所遗漏的细节实现，同时还会在之后考虑解析 SparkSQL 的 UDF 注册以及 cache 表功能。

那么作为进阶篇的第一篇，我们就先从 SparkSQL Parser 开始。

在上一篇文章中，我们详细了解了 SparkSQL 如何利用 Analyzer 和 Optimizer，一步一步将 Unresolved Logical Plan 变为 Analyzed Logical Plan 再变为 Optimized Logical Plan。到了这一步，Logical Plan 的生命历程就走到了终点。

在这篇文章中，我将开始讲解 SparkSQL 如何通过 Planner 将 Optimized Logical Plan 变为 Physical Plan，再变为结果 RDD。

在上一篇文章中，我们详细了解了 SparkSQL 中特殊的 TreeNode 们以及核心类 LogicalPlan，完整理解了整个执行计划树的组成。

在这篇文章中，我将开始讲解 Unresolved Logical Plan 如何通过 Analyzer 转变为 Analyzed Logical Plan，再通过 Optimizer 转变为 Optimized Logical Plan。

在上一篇文章中，我们了解了 SparkSQL 如何将各式语句分别委派到三个不同的 Parser 中进行解析，并返回一个 Unresolved Logical Plan。

在这篇文章中，我打算在讲解 Analyzer 之前先为大家讲解一下 Spark 里的 LogicalPlan 数据结构。

在上一篇文章中，我们了解了 SparkSQL 查询的基本执行过程，并了解到 SQLContext 的内部类 QueryExecution 包含了整个执行过程的每一个执行步骤。

在这篇文章中，我将开始讲解 SQL 语句如何通过 Parser 转变为 Unresolved Logical Plan。

我的上一个系列的 SparkSQL 源码解析已经完结了一段时间了。当时我出于实习工作的需要阅读了 SparkSQL HiveThriftServer 以及 Spark Scala Interpreter 的源代码，并顺势写下了那个系列的源码解析文章。但读 SparkSQL 源代码怎么能只读那些外围插件的源代码呢？于是我又开一个新坑了。