##Spark 2.0技術預覽:更容易、更快速、更智能

Spark 2.0技術預覽:更容易、更快速、更智能 http://mp.weixin.qq.com/s?src=3&timestamp=1489882744&ver=1&signature=-LS6H-vrac6i3XboPuWS7DIZbErZ1pZLNU4i22lYrINrlgg6LzhUj-bXJiqiI3kkEckGErxy0saUvLo9eKQuSJumzTaAM2SiMQwjqc7aEXn37-I8a0WkPpTeudXI*20Jz7usg941uTAq13I7wdXvyW7q1LTexteMcEMdQxUhg=

在過去的幾個月時間里,我們一直忙于我們所愛的大數據開源軟件的下一個主要版本開發工作:Apache Spark2.0。Spark 1.0已經出現了2年時間,在此期間,我們聽到了贊美以及投訴。Spark 2.0的開發基于我們過去兩年學到的:用戶所喜愛的我們加倍投入;用戶抱怨的我們努力提高。本文將總結Spark 2.0的三大主題:更容易、更快速、更智能。更深入的介紹將會在后面博客進行介紹。
  我們很高興地宣布Apache Spark 2.0技術預覽今天就可以在Databricks Community Edition中看到,該預覽版本是構建在branch-2.0基礎上。當啟動了集群之后,我們可以簡單地選擇Spark 2.0 (branch preview)
來使用這個預覽版,如下所示:


然而最終版的Apache Spark 2.0發行將會在幾個星期之后,本技術預覽版的目的是基于branch-2.0上提供可以訪問Spark 2.0功能。通過這種方式,你可以滿足你的好奇心;而且我們可以在發行最終版的Spark 2.0之前就可以獲取到用戶的反饋和Bug報告。
現在讓我們來看看Spark 2.0最新的進展:



文章目錄 [hide]
1 更容易的SQL和Streamlined APIs

2 更快:Spark作為編譯器

3 更加智能:Structured Streaming

4 總結

1

更容易的SQL和Streamlined APIs

Spark 2.0主要聚焦于兩個方面:(1)、對標準的SQL支持(2)、統一DataFrame和Dataset API。
  在SQL方面,Spark 2.0已經顯著地擴大了它的SQL功能,比如引進了一個新的ANSI SQL解析器和對子查詢的支持。現在Spark 2.0已經可以運行TPC-DS所有的99個查詢,這99個查詢需要SQL 2003的許多特性。因為SQL是Spark應用程序的主要接口之一,Spark 2.0 SQL的擴展大幅減少了應用程序往Spark遷移的代價。
  在編程API方面,我們對API進行了精簡。
  1、統一Scala和Java中DataFrames和Datasets的API:從Spark 2.0開始,DataFrame僅僅是Dataset的一個別名。有類型的方法(typed methods)(比如:map, filter, groupByKey)和無類型的方法(untyped methods)(比如:select, groupBy)目前在Dataset類上可用。同樣,新的Dataset接口也在Structured Streaming中使用。因為編譯時類型安全(compile-time type-safety)在Python和R中并不是語言特性,所以Dataset的概念并不在這些語言中提供相應的API。而DataFrame仍然作為這些語言的主要編程抽象。
  2、SparkSession:一個新的切入點,用于替代舊的SQLContext和HiveContext。對于那些使用DataFrame API的用戶,一個常見的困惑就是我們正在使用哪個context?現在我們可以使用SparkSession了,其涵括了SQLContext和HiveContext,僅僅提供一個切入點。需要注意的是為了向后兼容,舊的SQLContext和HiveContext目前仍然可以使用。
  3、簡單以及性能更好的Accumulator API:Spark 2.0中設計出一種新的Accumulator API,它擁有更加簡潔的類型層次,而且支持基本類型。為了向后兼容,舊的Accumulator API仍然可以使用。
  4、基于DataFrame的Machine Learning API可以作為主要的ML API了:在Spark 2.0中, spark.ml包以其pipeline API將會作為主要的機器學習API了,而之前的spark.mllib仍然會保存,將來的開發會聚集在基于DataFrame的API上。
  5、Machine learning pipeline持久化:現在用戶可以保存和加載Spark支持所有語言的Machine learning pipeline和models。
  6、R的分布式算法:在R語言中添加支持了Generalized Linear Models (GLM), Naive Bayes, Survival Regression, and K-Means。

2

更快:Spark作為編譯器

根據以往的調查,91%的用戶認為Spark的最重要的方面就是性能,結果性能優化在Spark開發中都會看的比較重。
  Spark 2.0中附帶了第二代Tungsten engine,這一代引擎是建立在現代編譯器和MPP數據庫的想法上,并且把它們應用于數據的處理過程中。主要想法是通過在運行期間優化那些拖慢整個查詢的代碼到一個單獨的函數中,消除虛擬函數的調用以及利用CPU寄存器來存放那些中間數據。我們把這些技術稱為"整段代碼生成"(whole-stage code generation)。
  為了有個直觀的感受,我們記錄下在Spark 1.6和Spark 2.0中在一個核上處理一行的操作時間(單位是納秒),下面的表格能夠體現出新的Tungsten engine的威力。
primitive
Spark 1.6
Spark 2.0

filter
15ns
1.1ns

sum w/o group
14ns
0.9ns

sum w/ group
79ns
10.7ns

hash join
115ns
4.0ns

sort (8-bit entropy)
620ns
5.3ns

sort (64-bit entropy)
620ns
40ns

sort-merge join
750ns
700ns

那么在新的Tungsten engine在端至端的查詢表現又會咋樣?我們比較了Spark 1.6和Spark 2.0在使用TPC-DS的基本分析,如下圖:



  除了whole-stage code generation可以提高性能,Catalyst方面也做了許多的工作,比如通用查詢優化;還有一個新的矢量Parquet 解碼器,它使得Parquet的掃描吞吐量提高了3x。

3

更加智能:Structured Streaming

Spark Streaming在大數據領域第一次嘗試將批處理和流計算進行了統一。在Spark 0.7開始引入的第一個streaming API稱為DStream,它為開發者提供了幾個強大的特性:僅一次的語義,大規模容錯和高吞吐量。
  然而,隨著數百個真實的Spark Streaming部署后,我們發現,需要實時作出決策應用通常需要不止一個流引擎。他們需要深度地將批處理和流處理進行整合;需要和外部存儲系統整合;以及需要應付業務邏輯變化的能力。其結果是,企業需要的不僅僅是一個流引擎;相反,他們需要一個完整的堆棧,使他們能夠開發終端到終端的“持續的應用程序”。
  一些人認為我們可以把所有的東西看作流。也就是說,提供一個編程模型,將批處理數據和流數據進行整合。
  這個單一的模型有幾個問題:首先,當數據到達時,對它進行操作將會變得非常難而且這會有許多限制性。其次,不同的數據分布,不斷變化的業務邏輯和數據的延遲都增加了獨特的挑戰。第三、大多數現有系統中,例如MySQL或Amazon S3中,不表現得像一個流;而且許多算法在流數據上無法工作。
  Spark 2.0的Structured Streaming APIs是一種新穎的流處理方式。它的實現源于最簡單地計算流數據的答案是不要想象它是一個流(這句話不太好翻譯,自己看英文:the simplest way to compute answers on streams of data is to not having to reason about the fact that it is a stream)。這個真理來源于我們的經驗。結構化數據流的愿景是利用Catalyst優化器來發現什么時候可以透明的將靜態的程序轉到增量執行的動態工作或者無限數據流中。當我們從這個數據結構的角度來看到我們的數據,這就簡化了流數據。
  作為實現這一愿景的第一步,Spark 2.0附帶了一個最初版本的Structured Streaming API(擴展自DataFrame/Dataset API),這個統一對現有的Spark用戶比較容易適應,因為這讓他們能夠充分利用Spark batch API知識來解決實時中的問題。這里主要功能將包括支持基于event-time的處理、亂序/延時數據、sessionization以及非流數據sources和sinks的緊密集成。
  Streaming顯然是一個非常寬泛的話題,所以敬請關注databricks的博客對于Spark 2.0的Structured Streaming介紹,其中將會包括那些將會在此版本實現,哪些將會在未來版本實現。

4

總結

Spark用戶最初轉向Spark的原因是因為它的易用性和性能。Spark 2.0將付出雙倍的努力來擴展它以使得它支持更廣泛的workloads,我們希望你喜歡我們已經做的工作,并期待著您的反饋。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,002評論 6 542
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,400評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事?!?“怎么了?”我有些...
    開封第一講書人閱讀 178,136評論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,714評論 1 317
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,452評論 6 412
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,818評論 1 328
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,812評論 3 446
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,997評論 0 290
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,552評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,292評論 3 358
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,510評論 1 374
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,035評論 5 363
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,721評論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,121評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,429評論 1 294
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,235評論 3 398
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,480評論 2 379

推薦閱讀更多精彩內容