随着sparksql和apachespark上新的Hive（Hive-7292）的引入，我们被问到了很多关于我们在这两个项目中的位置以及它们与Shark的关系。在今天的Spark峰会上，我们宣布我们将结束Shark的开发，并将把我们的资源集中在Spark SQL上，它将为现有的Shark用户提供一个Shark的超集功能。特别是Spark SQL将提供Shark 0.9服务器的无缝升级路径和与通用Spark程序集成等新功能。鲨鱼当Shark项目3年前启动时，Hive（在MapReduce上）是Hadoop上SQL的唯一选择。Hive将SQL编译成可伸缩的MapReduce作业，并且可以使用各种格式（通过它的serde）。然而，它的表现并不理想。为了以交互方式运行查询，组织部署了昂贵的专有企业数据仓库（EDWs），这些数据仓库需要严格而冗长的ETL管道。Hive和EDWs在性能上的巨大反差导致了业界对通用数据处理引擎查询处理固有缺陷的巨大争论。许多人认为SQL交互性需要一个昂贵的、专门为查询处理而构建的运行时（即EDWs）。Shark成为Hadoop系统上最早的交互式SQL之一，也是唯一一个建立在通用运行时（Spark）之上的SQL。它证明了使蜂巢变慢的所有缺陷都不是根本原因，像Spark这样的通用引擎可以兼收并蓄：它可以像EDW一样快，并且可以像Hive/MapReduce一样缩放。你为什么要关心这场看似学术的争论？当组织正在寻找让他们在业务中占据优势的方法时，他们正在使用SQL提供的简单的上卷和下钻功能之外的技术。在一般运行时之上构建SQL查询引擎可以统一许多不同的、强大的模型，例如批处理、流式处理、机器学习。它使数据科学家和工程师能够更快地使用更复杂的方法。Shark的想法很快就被采纳了，甚至激发了一些加速蜂巢的重大努力。从Shark到Spark SQLShark构建在Hive代码库上，通过替换Hive的物理执行引擎部分实现了性能改进。虽然这种方法使Shark用户能够加速他们的配置单元查询，但Shark从Hive继承了一个庞大而复杂的代码库，这使得优化和维护变得非常困难。当我们开始推进性能优化的边界，并将复杂的分析与SQL集成时，我们受到为MapReduce设计的遗留问题的限制。正是因为这个原因，我们结束了Shark作为一个单独项目的开发，并将我们所有的开发资源转移到Spark SQL中，Spark中的一个新组件。我们将在Shark中学习到的东西应用到Spark SQL中，从一开始就是为了利用Spark的力量而设计的。这种新方法使我们能够更快地创新，最终为用户提供更好的体验和能力。对于SQL用户，Spark SQL提供了最先进的SQL性能，并保持与Shark/Hive的兼容性。特别是，与Shark一样，sparksql支持所有现有的配置单元数据格式、用户定义函数（UDF）和配置单元元存储。由于apachespark1.1.0将引入一些特性，sparksql在TPC-DS性能上几乎比Shark高出一个数量级。对于Spark用户来说，sparksql成为了操作（半）结构化数据以及从提供模式的源（如JSON、Parquet、Hive或EDWs）中摄取数据的窄腰带。它真正地统一了SQL和复杂的分析，允许用户混合和匹配SQL和更重要的编程api来进行高级分析。对于开源黑客来说，sparksql提出了一种新颖、优雅的构建查询规划器的方法。在这个框架下添加新的优化非常容易。开源社区对sparksql的支持和热情让我们完全不知所措，这在很大程度上要归功于这种新的设计。仅仅过了三个月，就有40多个贡献者为它贡献了代码。谢谢您。星火上的蜂巢项目（Hive-7292）虽然sparksql正在成为Spark上SQL的标准，但我们确实意识到许多组织已经在Hive上进行了投资。然而，许多这样的组织也渴望迁移到Spark。Hive社区向该项目提出了一个新的计划，将Spark作为Hive的替代执行引擎。对于这些组织来说，这项工作将为他们将执行迁移到Spark提供一条清晰的路径。我们很高兴与蜂巢社区合作，为最终用户提供流畅的体验。总之，我们坚信Spark SQL不仅是SQL的未来，也是Spark结构化数据处理的未来。我们正在努力工作，并将在接下来的几个版本中为您带来更多。对于拥有遗留配置单元部署的组织，Spark上的Hive将为它们提供一条清晰的Spark路径。免费试用Databricks。今天就开始吧