[[181274]]

今天介紹一篇文章，詳細闡述了Apache Spark 2.0突出的三大優點：更容易、更快速、更智能。

兩個月前，我們在Databricks上發布了Apache Spark 2.0的預覽版本。從下面的圖表可以看出，我們的10%的集群已經使用這個版本，同時客戶試用了其新功能，并向我們提供了反饋意見。

隨時間的推移各個不同版本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解析器和對子查詢(subqueries)的支持。現在，Spark 2.0已經可以運行TPC-DS的所有99個查詢，這99個查詢需要諸多的SQL：2003特性。因為SQL一直是Spark的主要接口之一，因此這些擴展功能大大降低了移植舊應用程序的工作量。

在程序化API方面，我們已經簡化了Spark的API：

統一Scala和Java中DataFrames和Datasets：從Spark 2.0開始，DataFrame只是Dataset of Row的類型別名。Dataset類同時支持類型化方法(例如map、filter，groupByKey)和非類型化方法(例如select、groupBy)。此外，這個新的組合型Dataset接口是用于結構化流(Structured Streaming)的抽象。

由于編譯時類型安全性在Python和R中并不是語言特性，因此Dataset的概念不適用于這些語言API。相反，DataFrame仍然是它們的主接口，并且類似于這些語言中的單節點數據幀概念。

SparkSession： 這是一個新的切入點，取代了舊的SQLContext和HiveContext。對于DataFrame API的用戶而言，Spark的一個常見的容易產生困惑的地方就是我們正在使用哪個“運行環境”。現在您可以使用SparkSession作為單一切入點，其同時涵括了SQLContext和HiveContext的功能。請注意，舊版本的SQLContext和HiveContext類仍然保持向后兼容性。

更容易、更高性能的累加器API(Accumulator API)：我們設計了一個新的累加器API(Accumulator API)，它具有更加簡潔的類型層次結構，并支持原語類型的專門化。舊版本的Accumulator API已經棄用，但仍然保留了向后兼容性。

• 基于DataFrame的機器學習API成為主要的ML API：在Spark 2.0中，spark.ml包及其“管道”API將成為主要的機器學習API。雖然原始spark.mllib包被保留，但未來的開發將集中在基于DataFrame的API上。
• 機器學習管道持久化：用戶現在可以利用Spark支持的所有編程語言保存和加載機器學習管道和模型。
• 以R語言編寫的分布式算法：增加對以R語言編寫的廣義線性模型(Generalized Linear Models，GLM)、樸素貝葉斯(Naive Bayes)、生存回歸(Survival Regression)和K均值(K-Means)的支持。

以R語言編寫的用戶定義函數(UDF)：增加對運行分區級別UDF(dapply和gapply)和超參數調整(lapply)的支持。

更快速：Apache Spark作為編譯器

根據我們2015年Spark調查報告顯示，91%的用戶認為性能是Apache Spark最為重要的考慮因素。因此，性能優化始終是我們Spark開發的重點。在我們開始規劃對Spark 2.0的性能改進之前，我們問了自己一個問題：雖然Spark已經相當快了，但是我們是否可以將其推向性能極限，使Spark 的運行速度再提升十倍呢?

帶著這個問題我們從根本上重新思考了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中新的Tungsten引擎的威力。Spark 1.6使用的表達式代碼生成技術同樣在今天的一些最先進的商業數據庫中采用，但是您可以看到，許多運算符在采用了“整段代碼生成”(whole-stage code generation)技術之后速度提升了一個數量級。

在本筆記本中，您可以看到“整段代碼生成”(whole-stage code generation)技術的威力，在這里我們在一臺機器上對10億條記錄進行Aggregation和Join操作。

那么在新的Tungsten引擎在端至端的查詢表現又會怎樣?我們比較了Spark 1.6和Spark 2.0在使用TPC-DS查詢的基本分析，如下圖所示：

除了“整段代碼生成”(whole-stage code generation)可以提高性能之外，Catalyst優化器方面也做了許多的工作，比如改進通用查詢優化(例如，為空性傳播(nullability propagation));還有一個新的矢量化Parquet解碼器，它使得Parquet的掃描吞吐量提高了3倍。

更智能：結構化流(Structured Streaming)

Spark Streaming在大數據領域第一次嘗試將批處理和流計算進行了統一。在Spark 0.7版本開始引入的第一個流式API稱為DStreams，它為開發者提供了幾項強大的特性：恰好一次的語義、大規模容錯、強一致性保證和高吞吐量。

然而，隨著數百個真實的Spark Streaming部署之后，我們發現，需要實時作出決策的應用程序通常需要不止一個流引擎。他們需要深度地將批處理堆棧和流處理堆棧進行整合;需要和外部存儲系統進行交互;以及需要應付業務邏輯變化的能力。其結果是，企業需要的不僅僅是一個流式引擎;相反，他們需要一個完整的堆棧，使他們能夠開發終端到終端的“持續應用程序”。

Spark 2.0通過一種稱為結構化流(Structured Streaming)的新API來處理這些使用案例。與現有的流系統相比，結構化流(Structured Streaming)主要做了以下三個方面的改進：

1、集成API與批處理作業。如需運行流計算，開發人員只需對DataFrame/Dataset API編寫一個批處理計算，然后Spark會自動遞增計算以便以流方式運行(即在數據進入時更新結果)。這種強大的設計意味著開發人員不必手動管理狀態、故障或保持應用程序與批處理作業同步。相反，流式作業總能給出與同一數據上的批處理作業相同的答案。

2、與存儲系統之間的事務交互。結構化流(Structured Streaming)能夠在整個引擎和存儲系統中保持容錯性和一致性，從而可以很容易地編寫應用程序，該應用程序能夠更新用于服務的實時數據庫，加入靜態數據或在存儲系統之間可靠地移動數據。

3、與Spark其余部分的豐富集成。結構化流(Structured Streaming)支持通過Spark SQL對流數據進行交互式查詢，對靜態數據進行連接，以及許多已經使用DataFrames的庫，同時讓開發人員構建完整的應用程序，而不僅僅是流管道。未來，期望與MLlib和其他庫實現更多的集成。

作為實現這一愿景的第一步，Spark 2.0附帶了一個初始的alpha版本的結構化流(Structured Streaming)，其擴展自DataFrame/Dataset API(令人驚訝的小!)。這個統一對現有的Spark用戶比較容易適應，因為這讓他們能夠充分利用Spark批量處理API知識來解決實時中的新問題。其它主要功能將包括支持基于事件時間的處理、亂序/延時數據、交互式查詢以及非流數據源和接收器的緊密集成。

此外，我們還更新了Databricks工作空間以支持結構化流(Structured Streaming)。例如，當啟動流查詢時，筆記本UI將自動顯示其狀態。

Streaming顯然是一個非常寬泛的話題，所以敬請多關注，以了解Apache Spark 2.0中的結構化流(Structured Streaming)的更多詳細信息。