SparkSQL 前讲篇（十三）

Spark SQL概述

  新的开始，也是新的高度，结束了SparkCore，现在我站在巨人的肩上，总结一下Spark SQL。先说一下，在SparkSQL对于算子可能不会再从源码详细的说，因为SparkCore和SparkSQL在算子上有很多相同之处，原理也是大同小异，熟悉了SparkCore的算子，那么Spark SQL算子也是相差无几，我们主要是对特殊存在的算子以及特殊的数据结构进行介绍。那，我们开始了？

一、Spark SQL 发展。

  Spark SQL主要是将数据转换为结构化的数据，然后进行处理操作，spark的前身，也就是父辈是MapReduce,但是因为性能局限、使用场景，Spark揭竿而起，逐渐发展壮大。

1.1 HDFS -> Hive

  由于Hadoop在企业生产中的大量使用，HDFS上积累了大量数据，为了给熟悉RDBMS但又不理解MapReduce的技术人员提供快速上手的工具，Hive应运而生。Hive的原理是将SQL语句翻译成MapReduce计算。

1.2 Hive -> Shark

  但是，MapReduce计算过程中大量的中间磁盘落地过程消耗了大量的I/O，降低了运行效率，为了提供SQL-on-Hadoop的效率，Shark出现了。

  Shark是伯克利AMPLab实验室Spark生态环境的组件之一，它修改了Hive中的内存管理、物理计划和执行三个模块，使得SQL语句直接运行在Spark上，从而使得SQL查询的速度得到10-100倍的提升。

1.3 Shark-> Spark SQL

  2014年6月1日，Shark项目和SparkSQL项目的主持人Reynold Xin宣布：停止对Shark的开发，团队将所有资源放sparkSQL项目上，至此，Shark的发展画上了句话。Reynold在其微博上发出了下面这段话：

为什么Shark会死呢？Databricks在其官网上给出了答案

Shark built on the Hive codebase and achieved performance improvements by swapping out the physical execution engine part of Hive. While this approach enabled Shark users to speed up their Hive queries, Shark inherited a large, complicated code base from Hive that made it hard to optimize and maintain. As we moved to push the boundary of performance optimizations and integrating sophisticated analytics with SQL, we were constrained by the legacy that was designed for MapReduce.

随着Spark的发展，Shark对于Hive的太多依赖制约了Spark的One Stack rule them all的方针，制约了Spark各个组件的相互集成，同时Shark也无法利用Spark的特性进行深度优化，所以决定放弃Shark，提出了SparkSQL项目。

随着Shark的结束，两个新的项目应运而生：Sp