以下為Databricks官網的發布新聞稿翻譯：

我們很榮幸地宣布，自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的使用率

現在，我們來深入了解一下的新特性。

更簡單：ANSI SQL與更合理的API

Spark讓我們引以為豪的一點就是所創建的API簡單、直觀、便于使用，Spark 2.0延續了這一傳統，并在兩個方面凸顯了優勢：

標準的SQL支持;
數據框(DataFrame)/Dataset (數據集)API的統一。

在SQL方面，我們已經對Spark的SQL功能做了重大拓展，引入了新的ANSI SQL解析器，并支持子查詢功能。Spark 2.0可以運行所有99個TPC-DS查詢(需求SQL：2003中的很多功能支持)。由于SQL是Spark應用所使用的主要接口之一，對SQL功能的拓展大幅削減了將遺留應用移植到Spark時所需的工作。

在編程API方面，我們合理化了API：

1、在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的相關信息，請參見相關筆記和文章。

2、SparkSession：這是一個新入口，取代了原本的SQLContext與HiveContext。對于DataFrame API的用戶來說，Spark常見的混亂源頭來自于使用哪個“context”。現在你可以使用SparkSession了，它作為單個入口可以兼容兩者，點擊這里來查看演示。注意原本的SQLContext與HiveContext仍然保留，以支持向下兼容。

3、更簡單、性能更佳的Accumulator API：我們設計了一個新的Accumulator API，不但在類型層次上更簡潔，同時還專門支持基本類型。原本的Accumulator API已不再使用，但為了向下兼容仍然保留。

4、基于DataFrame的機器學習API將作為主ML API出現：在Spark 2.0中，spark.ml包及其“管道”API會作為機器學習的主要API出現，盡管原本的spark.mllib包仍然保留，但以后的開發重點會集中在基于DataFrame的API上。

5、機器學習管道持久化：現在用戶可以保留與載入機器學習的管道與模型了，Spark對所有語言提供支持。查看這篇博文以了解更多細節，這篇筆記中也有相關樣例。

6、R語言的分布式算法：增加對廣義線性模型(GLM)、樸素貝葉斯算法(NB算法)、存活回歸分析(Survival Regression)與聚類算法(K-Means)的支持。

速度更快：用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優化的更多細節。

更智能：Structured Streaming

作為首個嘗試統一批處理與流處理計算的工具，Spark Streaming一直是大數據處理的領導者。首個流處理API叫做DStream，在Spark 0.7中初次引入，它為開發者提供了一些強大的特性，包括：只有一次語義，大規模容錯，以及高吞吐。

然而，在處理了數百個真實世界的Spark Streaming部署之后，我們發現需要在真實世界做決策的應用經常需要不止一個流處理引擎。他們需要深度整合批處理堆棧與流處理堆棧，整合內部存儲系統，并且要有處理業務邏輯變更的能力。因此，各大公司需要不止一個流處理引擎，并且需要能讓他們開發端對端“持續化應用”的全棧系統。

Spark 2.0使用一個新的API：Structured Streaming模塊來處理這些用例，與現有流系統相比，Structured Streaming有三個主要的改進：

與批處理作業集成的API：想要運行流數據計算，開發者可針對DataFrame/Dataset API編寫批處理計算，過程非常簡單，而Spark會自動在流數據模式中執行計算，也就是說在數據輸入時實時更新結果。強大的設計令開發者無需費心管理狀態與故障，也無需確保應用與批處理作業的同步，這些都由系統自動解決。此外，針對相同的數據，批處理任務總能給出相同的結果。

與存儲系統的事務交互： Structured Streaming會在整個引擎及存儲系統中處理容錯與持久化的問題，使得程序員得以很容易地編寫應用，令實時更新的數據庫可靠地提供、加入靜態數據或者移動數據。

與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會自動顯示其狀態。

Streaming很明顯是一個非常廣泛的話題，因此想要了解Spark 2.0中Structured Streaming的更多信息，請關注本網站。

結論

Spark的用戶最初使用Spark是因為它的易用性與高性能。Spark 2.0在這些方面達到了之前的兩倍，并增加了對多種工作負載的支持，請嘗試一下新版本吧。

詳情請咨詢！

客服熱線：023-66090381