千呼万唤始出来：Apache Spark2.0正式发布

咱们很荣幸地宣布，自7月26日起Databricks开始提供Apache Spark 2.0的下载，这个版本是基于社区在过去两年的经验总结而成，不但加入了用户喜好的功能，也修复了以前的痛点。

本文总结了Spark 2.0的三大主题：更简单、更快速、更智能，另有Spark 2.0内容的文章汇总介绍了更多细节。

两个月前，Databricks发布了Apache Spark 2.0的技术预览版，以下表所见，目前咱们有10%的集群都在使用这个版本，根据客户使用新版的经验及反馈意见，新版得以发布，Databricks很开心能成为Spark 2.0的首个商业供应商。

随着时间推移，各版本Apache Spark的使用率

 如今，咱们来深刻了解一下Apache Spark 2.0的新特性。

1、更简单：ANSI SQL与更合理的API

Spark让咱们引觉得豪的一点就是所建立的API简单、直观、便于使用，Spark 2.0延续了这一传统，并在两个方面凸显了优点：

1. 标准的SQL支持；
2. 数据框（DataFrame）/Dataset （数据集）API的统一。

在SQL方面，咱们已经对Spark的SQL功能作了重大拓展，引入了新的ANSI SQL解析器，并支持子查询功能。Spark 2.0能够运行全部99个TPC-DS查询（需求SQL：2003中的不少功能支持）。因为SQL是Spark应用所使用的主要接口之一，对SQL功能的拓展大幅削减了将遗留应用移植到Spark时所需的工做。

在编程API方面，咱们合理化了API：

• 在Scala/Java中统一了DataFrames与Dataset：从Spark 2.0开始，DataFrames只是行（row）数据集的typealias了。不管是映射、筛选、groupByKey之类的类型方法，仍是select、groupBy之类的无类型方法均可用于Dataset的类。此外，这个新加入的Dataset接口是用做Structured Streaming的抽象，因为Python和R语言中编译时类型安全（compile-time type-safety）不属于语言特性，数据集的概念没法应用于这些语言API中。而DataFrame还是主要的编程抽象，在这些语言中相似于单节点DataFrames的概念，想要了解这些API的相关信息，请参见相关笔记和文章。
• SparkSession：这是一个新入口，取代了本来的SQLContext与HiveContext。对于DataFrame API的用户来讲，Spark常见的混乱源头来自于使用哪一个“context”。如今你可使用SparkSession了，它做为单个入口能够兼容二者，点击这里来查看演示。注意本来的SQLContext与HiveContext仍然保留，以支持向下兼容。
• 更简单、性能更佳的Accumulator API：咱们设计了一个新的Accumulator API，不但在类型层次上更简洁，同时还专门支持基本类型。本来的Accumulator API已再也不使用，但为了向下兼容仍然保留。
• 基于DataFrame的机器学习API将做为主ML API出现：在Spark 2.0中，spark.ml包及其“管道”API会做为机器学习的主要API出现，尽管本来的spark.mllib包仍然保留，但之后的开发重点会集中在基于DataFrame的API上。
• 机器学习管道持久化：如今用户能够保留与载入机器学习的管道与模型了，Spark对全部语言提供支持。查看这篇博文以了解更多细节，这篇笔记中也有相关样例。
• R语言的分布式算法：增长对广义线性模型（GLM）、朴素贝叶斯算法（NB算法）、存活回归分析（Survival Regression）与聚类算法（K-Means）的支持。

2、速度更快：用Spark做为编译器

根据咱们2015年对Spark的调查，91%的用户认为对Spark来讲，性能是最为重要的。所以，性能优化一直是咱们在开发Spark时所考虑的重点。在开始Spark 2.0的规划前，咱们思考过这个问题：Spark的速度已经很快了，但可否突破极限，让Spark达到本来速度的10倍呢？

带着这个问题，咱们切实考虑了在构建Spark物理执行层面时的方式。若是深刻调查现代的数据引擎，好比Spark或者其余MPP数据库，咱们会发现：CPU循环大多都作了无用功，好比执行虚拟函数调用，或者向CPU缓存或内存读取/写入中间数据；经过减小CPU循环中的浪费来优化性能，一直是咱们在现代编译器上长时间以来的工做重点。

Spark 2.0搭载了第二代Tungsten引擎，该引擎是根据现代编译器与MPP数据库的理念来构建的，它将这些理念用于数据处理中，其主要思想就是在运行时使用优化后的字节码，将总体查询合成为单个函数，再也不使用虚拟函数调用，而是利用CPU来注册中间数据。咱们将这一技术称为“whole-stage code generation”。

在测试、对比Spark 1.6与Spark 2.0时，咱们列出了在单核中处理单行数据所花费的时间（以十亿分之一秒为单位），下面的表格列出了Spark 2.0的优化内容。Spark 1.6包含代码生成技术（code generation）的使用，这一技术现在在一些顶尖的商业数据库中也有运用，正如咱们看到的那样，使用了新whole-stage code generation技术后，速度比以前快了一个数量级。

在这篇笔记中能够查看其运用：咱们在单台机器上对10亿记录执行了aggregations和joins操做。

每行耗费（单线程）

这个新的引擎在执行端对端查询时是如何运做的？咱们使用TPC-DS查询作了些初步分析，以对比Spark 1.6与Spark 2.0：

除此以外，为了改进Catalyst optimizer优化器对诸如nullability propagation之类常见查询的效果，咱们还作了许多工做；另外还改进了矢量化Parquet解码器，新解码器的吞吐量增长了三倍。点击这里查看Spark 2.0优化的更多细节。

3、更智能：Structured Streaming

做为首个尝试统一批处理与流处理计算的工具，Spark Streaming一直是大数据处理的领导者。首个流处理API叫作DStream，在Spark 0.7中初次引入，它为开发者提供了一些强大的特性，包括：只有一次语义，大规模容错，以及高吞吐。

然而，在处理了数百个真实世界的Spark Streaming部署以后，咱们发现须要在真实世界作决策的应用常常须要不止一个流处理引擎。他们须要深度整合批处理堆栈与流处理堆栈，整合内部存储系统，而且要有处理业务逻辑变动的能力。所以，各大公司须要不止一个流处理引擎，而且须要能让他们开发端对端“持续化应用”的全栈系统。

Spark 2.0使用一个新的API：Structured Streaming模块来处理这些用例，与现有流系统相比，Structured Streaming有三个主要的改进：

1. 与批处理做业集成的API：想要运行流数据计算，开发者可针对DataFrame/Dataset API编写批处理计算，过程很是简单，而Spark会自动在流数据模式中执行计算，也就是说在数据输入时实时更新结果。强大的设计令开发者无需费心管理状态与故障，也无需确保应用与批处理做业的同步，这些都由系统自动解决。此外，针对相同的数据，批处理任务总能给出相同的结果。
2. 与存储系统的事务交互： Structured Streaming会在整个引擎及存储系统中处理容错与持久化的问题，使得程序员得以很容易地编写应用，令实时更新的数据库可靠地提供、加入静态数据或者移动数据。
3. 与Spark的其它组件的深刻集成： Structured Streaming支持经过Spark SQL进行流数据的互动查询，能够添加静态数据以及不少已经使用DataFrames的库，还能让开发者得以构建完整的应用，而不仅是数据流管道。将来，咱们但愿能有更多与MLlib及其它libraries的集成出现。

Spark 2.0搭载了初始alpha版的Strutured Streaming API，这是一个附在DataFrame/Dataset API上的（超小）扩展包。统一以后，对现有的Spark用户来讲使用起来很是简单，他们可以利用在Spark 批处理API方面的知识来回答实时的新问题。这里关键的功能包括：支持基于事件时间的处理，无序/延迟数据，sessionization以及非流式数据源与Sink的紧密集成。

咱们还更新了Databricks workspace以支持Structured Streaming。例如，在启动streaming查询时，notebook UI会自动显示其状态。

结论

Spark的用户最初使用Spark是由于它的易用性与高性能。Spark 2.0在这些方面达到了以前的两倍，并增长了对多种工做负载的支持，请尝试一下新版本吧。

 

文章转载自：http://geek.csdn.net/news/detail/91745?utm_source=tuicool&utm_medium=referral

英文原文地址：https://databricks.com/blog/2016/07/26/introducing-apache-spark-2-0.html