Shark, Spark SQL, Hive on Spark, 以及SQL on Apache Spark的未来

随着Spark SQL的引入和新的Hive on Apache Spark方向的努力（HIVE-7292），许多人询问我们在这两个项目中的位置，以及它们与Shark的关系。在今天的Spark峰会上，我们宣布，我们停止了Shark的开发，并会专注于Spark SQL，它将提供Shark特性的超集，以便于现有的Shark用户继续使用。Spark SQL提供了从Shark 0.9的无缝升级，以及一些诸如通用Spark程序的集成等新特性。

Shark

三年前Shark项目开始的时候，Hive（on MapReduce）是SQL on Hadoop的唯一选择。Hive把SQL编译成可扩展的MapReduce作业，而且可以支持多种格式（通过它的SerDes）。但是其性能并不理想。为了交互式地执行查询，许多公司部署了昂贵的专用企业数据仓库（EDWs），这需要严格的、冗长的ETL流程。

Hive和EDWs之间的性能对比在工业界引起了关于在通用数据处理引擎上进行查询处理的内在缺陷的巨大争论。许多人认为SQL交互需要一个昂贵的专用系统用于查询处理（如EDWs）。Shark成为了一种较早的交互式SQL on Hadoop系统，而且是唯一一种基于通用运行环境（Spark）构建的。它表明了所有导致Hive慢的缺陷都不是根本性的，像Spark这样的通用引擎就能同时达到两方面的要求：和EDW一样快，和Hive/MapReduce一样可扩展。

为什么你应该关注这个看似比较学术的争论呢？各种组织都在寻找能给它们带来商业优势的方法，它们使用了很多超出SQL提供的上卷和下钻能力的技术。基于通用环境构建一个SQL查询引擎统一了许多不同的、强大的模型，例如batch、streaming、机器学习。这使得数据科学家和工程师能够更快的执行更复杂的方法。Shark的观点很快被接受了，甚至催生了Hive的一些重要改进。

从Shark到Spark SQL

Shark基于Hive源码构建，并通过替换Hive的物理执行引擎获得了性能上的提升。虽然这种方法让Shark用户能更快的执行Hive查询，但是Shark从Hive继承了大量复杂的源码，因而导致难以优化和维护。随着我们逐步逼近性能优化的极限和集成复杂的SQL分析，我们被那些按照MapReduce设计的遗产所束缚。

正因为如此，我们停止了Spark作为一个单独项目的开发，并把所有的开发资源转向Spark SQL，Spark的一个新组件。我们借鉴了Shark的经验用到Spark SQL中，并重新设计以更好了利用Spark。这种新途径让我们更快的创新，最终为用户交付更好的体验。

对于SQL用户，Spark SQL提供了最先进的SQL性能并兼容Shark/Hive。像Shark一样，Spark SQL支持所有的Hive数据格式，用户定义函数（UDF），和Hive metastore。Spark1.1.0引入新的特性后，TPC-DS performance中，Spark SQL性能比Shark高一个数量级。

对于Spark用户，Spark SQL成为了处理（半）结构化数据和诸如JSON、Parquet、Hive或EDWs等有模式的数据源的细腰（narrow-waist）。它确实统一了SQL和复杂分析，允许用户混合SQL和更多编程API以实现高级分析。

对于开源黑客，Spark SQL提供了一种新的简洁的方法去构建查询计划。在这个框架下添加新的优化很简单。我们已经完全被开源社区对于Spark SQL的热情所折服，多亏这个新设计。仅仅三个月，就有40多为贡献者提交了代码。谢谢。

Hive on Spark（HIVE-7292）

虽然Spark SQL逐渐成为SQL on Spark的标准，但是我们知道许多组织已经使用了Hive。这里面也有很多公司想迁移到Spark。Hive社区提出了一个新举措，这样能使Spark作为Hive的一个可选执行引擎。对于上述组织，参照上述引文可以把执行引擎迁移到Spark。我们很高兴能与Hive社区一起为用户提供更平顺的体验。

总之，我们坚信Spark SQL会是基于Spark的SQL和结构化数据处理的未来。我们将努力工作，并在随后几个releases带来更多特性。对于有遗留Hive部署的公司，Hive on Spark会为他们提供支持。

英文原文：发表于2014年7月1日
Shark, Spark SQL, Hive on Spark, and the future of SQL on Apache Spark