千呼萬喚始出來：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