Spark SQL是怎么发展起来的？

前言

本文隶属于专栏《1000个问题搞定大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和参考文献请见1000个问题搞定大数据技术体系

正文

Shark 是什么？有什么特点？

Spark SQL 的前身是 Shark ，即"Hive on Spark"，由 Reynold Xin 主导开发。

Shark 项目最初启动于 2011 年，当时 Hive 几乎算是唯一的 SQL-on-Hadoop 选择方案。

Hive 将 SQL 语句翻译为 MapReduce ，性能会受限于 MapReduce 计算模型，始终无法满足各种交互式 SQL 分析的需求，因此许多机构仍然依赖传统的企业数据仓库( EDW )。

Shark 的提出就是针对这种需求的，目标是既能够达到 EDW 的性能，又能够具有 MapReduce 的水平扩展功能。

Shark 建立在 Hive 代码的基础上，只修改了内存管理、物理计划、执行 3 个模块中的部分逻辑。

Shark 通过将 Hive 的部分物理执行计划交换出来(“swapping out the physical execution engine part of Hive")，

最终将 HiveQL 转换为 Spark 的计算模型，使之能运行在 Spark 引擎上，从而使得 SQL 査询的速度得到 10 ~ 100 倍的提升。

此外， Shark 的最大特性是与 Hive 完全兼容，并且支持用户编写机器学习或数据处理函数，对 HiveQL 执行结果进行进一步分析。

Shark 的缺陷

但是，随着 Spark 的不断发展， Shark 对 Hive 的重度依赖体现在架构上的瓶颈越来越突出。

一方面， Hive 的语法解析和查询优化等模块本身针对的是 MapReduce ，限制了在 Spark 系统上的深度优化和维护;

另一方面，过度依赖 Hive 制约了 Spark 的“One Stack Rule Them All”既定方针，也制约了技术校中各个组件的灵活集成。

Shark -> Spark SQL

在此背景下， Spark SQL 项目被提出来，由 Michael Armbrust 主导开发。

Spark SQL 抛弃原有 Shark 的架构方式，但汲取了 Shark 的一些优点，如内存列存储( In-Memory Columnar Storage )、 Hive 兼容性等，重新开发了 SQL 各个模块的代码。

由于摆脱了对 Hive 的依赖， SparkSQL 在数据兼容、性能优化、组件扩展方面都得到了极大的提升。

在 2014 年 7 月 1 日的 Spark 峰会上， Databricks 公司宣布终止对 Shark 的开发，将后续重点放到 Spark SQL 上。

Spark SQL 涌盖了 Shark 的所有特性，用户可以从 Shark 进行无缝升级，至此， Shark 的发展画上了句号。

Spark SQL 开始迎来蓬勃的发展阶段。

如今， Spark SQL 已经成为 Apache Spark 中最为活跃的子项目。

Spark SQL 的重要性

伴随着 Apache Spark 的发展，特别是最新的 Spark 3.x 版本发布后，Spark SQL 已经逐渐取代了 Spark Core 成为 Spark 生态的底层实现方式。