Apache Spark 2.0正式版釋出下載

原文：Introducing Apache Spark 2.0
作者： Reynold Xin、Michael Armbrust和Matei Zaharia
譯者：孫薇
責編：郭芮，CSDN編輯，關注大資料領域，另有CSDN Spark使用者微信群，請新增微信guorui_1118並備註實名+公司+職位申請入群。

以下為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的使用率

現在，我們來深入瞭解一下Apache Spark 2.0的新特性。

更簡單：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）的支援。

速度更快：用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有三個主要的改進：

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

Streaming很明顯是一個非常廣泛的話題，因此想要了解Spark 2.0中Structured Streaming的更多資訊，請關注本部落格。

結論

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