Shark，Spark SQL，Spark上的Hive以及Apache Spark上的SQL的未来

随着Spark SQL和Apache Spark effort（HIVE-7292）上新Hive的引入，我们被问到了很多关于我们在这两个项目中的地位以及它们与Shark的关系。在今天的Spark峰会上，我们宣布我们正在结束Shark的开发，并将我们的资源集中到Spark SQL，这将为现有Shark用户提供一个超棒的Shark的功能。特别是，Spark SQL将提供来自Shark 0.9服务器的无缝升级路径以及与一般Spark程序集成的新功能。

SQLon Spark的未来

Shark

当Shark项目在3年前开始时，Hive（在MapReduce上）是SQL on Hadoop的唯一选择。Hive将SQL编译为可扩展的MapReduce作业，并且可以使用各种格式（通过其SerDes）。然而，它的性能并不理想。为了以交互方式运行查询，组织部署昂贵，专有的企业数据仓库（EDW）和刚性、冗长的ETL管道。

Hive和EDW之间性能的鲜明对比导致了业界的巨大争论，质疑了一般数据处理引擎的查询处理的固有缺陷。许多人认为SQL的交互性需要（即EDW）构建的昂贵的专用运行时为其的查询处理。Shark成为Hadoop系统中第一个交互式SQL，是唯一一个基于一般运行时（Spark）构建的。它表明，Hive缓慢的缺陷是根本的，一个通用引擎，如Spark可以结合两个世界的最好的引擎：它可以和EDW一样快，以及和Hive / MapReduce一样优秀。

你为什么要关心这个看似学术的辩论？由于企业正在寻找能在企业环境中给予他们优势的方法，正在采用超越SQL提供的简单的汇总和向下钻取功能的技术。在通用运行引擎时之上构建SQL查询引擎可以统一许多不同的强大模型，例如批处理，流式处理，机器学习。它使数据科学家和工程师能够更快地使用更复杂的方法。Shark的想法很快被接受，甚至启发了加速Hive的一些主要工作。

从Shark到Spark SQL

Shark构建在Hive代码库上，并通过交换Hive的物理执行引擎部分来实现性能提升。虽然这种方法使Shark用户加快了Hive查询，但Shark继承了Hive的一个庞大，复杂的代码库，使得难以优化和维护。当我们开始推动性能优化的极限并将复杂的分析与SQL集成时，我们受到为MapReduce设计的遗留的限制。

正是由于这个原因，我们正在结束Shark作为一个单独的项目的开发，并将所有的开发资源移动到Spark的一个新组件Spark SQL上。我们正在将我们在Shark中学到的东西应用到Spark SQL，从底层设计到利用Spark的力量。这种新方法使我们能够更快地进行创新，最终为用户提供更好的体验和能力。

对于SQL用户，Spark SQL提供了最先进的SQL性能并保持与Shark / Hive的兼容性。特别是，像Shark一样，Spark SQL支持所有现有的Hive数据格式，用户定义的函数（UDF）和Hive Metastore。有了将在Apache Spark 1.1.0中引入的功能，Spark SQL在TPC-DS性能上击败Shark几乎一个数量级。

对于Spark用户，Spark SQL成为操纵（半）结构化数据的力量，以及从提供结构的源（如JSON，Parquet，Hive或EDW）中提取数据。它真正统一了SQL和复杂的分析，允许用户混合和匹配SQL和更高级的分析的命令性编程API。

对于开源黑客，Spark SQL提出了一种创新的，优雅的构建查询规划器的方法。在这个框架下添加新的优化是非常容易的。我们已经完全被开源社区所展示的Spark SQL的支持和热情所淹没，这主要是由于这种新的设计。仅仅三个月后，超过40个贡献者已经贡献了代码。谢谢。

Hiveon Spark项目（HIVE-7292）

虽然Spark SQL正在成为SQL on Spark的标准，但我们意识到许多组织已经在Hive上进行了投资。然而，许多这些组织也渴望迁移到Spark。Hive社区提出了一个新的计划，将Spark添加为Hive的替代执行引擎。对于这些组织，这项工作将为他们提供一个清晰的路径将执行迁移到Spark。我们很高兴与Hive社区合作并提供支持，为最终用户提供流畅的体验。

总之，我们坚信Spark SQL不仅是SQL的未来，而且还是在Spark上的结构化数据处理的未来。我们会努力工作，将在接下来的几个版本中为您带来更多体验。对于具有传统Hive部署的组织，Hive on Spark将为他们提供一条清晰的Spark路径。