     .SparkSession的創(chuàng)建和使用API課程培訓

在Databricks創(chuàng)建一個新Apache Spark 2.0技術(shù)預覽版集群的工作流程截圖

由于Apache Spark 2.0的終發(fā)布版尚需幾周才能出爐，本技術(shù)預覽版旨在讓大家提前預覽一下新版的功能，一方面滿足大家的好奇心，一方面也便于我們在發(fā)布終版前多收集一些用戶反饋與bug報告。

現(xiàn)在我們來看看新的變化吧。

Spark 2.0：更簡單、更、更智能

更簡單：SQL與簡化的APISpark讓我們引以為豪的一點就是所創(chuàng)建的API簡單、直觀、便于使用，Spark 2.0延續(xù)了這一傳統(tǒng)，并在兩個方面凸顯了優(yōu)勢：1）標準的SQL支持；2）統(tǒng)一數(shù)據(jù)框（DataFrame）/數(shù)據(jù)集API。

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

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

l在Scala/Java中統(tǒng)一了DataFrames與Dataset：從Spark 2.0開始，DataFrames只是行（row）數(shù)據(jù)集的typealias了。無論是映射、篩選、groupByKey之類的類型方法，還是 select、groupBy之類的無類型方法都可用于Dataset的類。此外，這個新加入的Dataset接口是用作結(jié)構(gòu)化數(shù)據(jù)流 （Structured Streaming）的抽象，由于Python和R語言中的編譯時類型（compile-time type-safety）不屬于語言特性，數(shù)據(jù)集的概念無法應用于這些語言API中。而DataFrame仍是主要的編程抽象，在這些語言中類似于單節(jié)點 DataFrames的概念，可以查看數(shù)據(jù)集API手冊做些了解。

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

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

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

l機器學習管道持久化：現(xiàn)在用戶可以保留與載入機器學習的管道與模型了，Spark對所有語言提供支持。

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

速度更快：用Spark作為編譯器根據(jù)我們2015年對Spark的調(diào)查，91%的用戶認為對Spark來說，性能是為重要的。因此，性能優(yōu)化一直是我們在開發(fā)Spark時所考慮的重點。在開始Spark 2.0的規(guī)劃前，我們思考過這個問題：Spark的速度已經(jīng)很快了，但能否突破極限，讓Spark達到原本速度的10倍呢？

帶著這個問題，我們切實考慮了在構(gòu)建Spark物理執(zhí)行層面時的方式。如果深入調(diào)查現(xiàn)代的數(shù)據(jù)引擎，比如Spark或者其他MPP數(shù)據(jù)庫，我們會發(fā) 現(xiàn)：CPU循環(huán)大多都做了無用功，比如執(zhí)行虛擬函數(shù)調(diào)用，或者向CPU緩存或內(nèi)存讀取/寫入中間數(shù)據(jù)；通過減少CPU循環(huán)中的浪費來優(yōu)化性能，一直是我們 在現(xiàn)代編譯器上長時間以來的工作重點。

Spark 2.0搭載了第二代Tungsten引擎，該引擎是根據(jù)現(xiàn)代編譯器與MPP數(shù)據(jù)庫的理念來構(gòu)建的，它將這些理念用于數(shù)據(jù)處理中，其主要思想就是在運行時使 用優(yōu)化后的字節(jié)碼，將整體查詢合成為單個函數(shù)，不再使用虛擬函數(shù)調(diào)用，而是利用CPU來注冊中間數(shù)據(jù)。我們將這一技術(shù)稱為“whole-stage code generation”。

在測試、對比Spark 1.6與Spark 2.0時，我們列出了在單核中處理單行數(shù)據(jù)所花費的時間（以十億分之一秒為單位），下面的表格證明了新一代Tungsten引擎的強大。Spark 1.6包含代碼生成技術(shù)（code generation）的使用，這一技術(shù)如今在一些的商業(yè)數(shù)據(jù)庫中也有運用，正如我們看到的那樣，使用了新whole-stage code generation技術(shù)后，速度比之前快了一個數(shù)量級。

更智能：結(jié)構(gòu)化數(shù)據(jù)流作為個嘗試統(tǒng)一批處理與流處理計算的工具，Spark Streaming一直是大數(shù)據(jù)處理的。個流處理API叫做DStream，在Spark 0.7中初次引入，它為開發(fā)者提供了一些很強大的屬性，包括：只有一次語義，大規(guī)模容錯，以及高吞吐。

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

有一種看法是將所有一切當作流數(shù)據(jù)，也就是說采用單一的編程模型來整合批數(shù)據(jù)與流數(shù)據(jù)。

在這種單一的模型中，有大量的問題出現(xiàn)。先，在接收到數(shù)據(jù)的時間進行處理非常困難，也很有局限性。其次，不同的數(shù)據(jù)分布、變動的業(yè)務邏輯與數(shù)據(jù)延 遲都增加了實際操作的挑戰(zhàn)性。再次，大多現(xiàn)有系統(tǒng)比如MySQL或者Amazon S3都不支持流處理，大多現(xiàn)有的機器學習算法在streaming設置中都不起作用。

Spark 2.0的結(jié)構(gòu)化Streaming API是處理流數(shù)據(jù)的全新方式，源于“在流數(shù)據(jù)中計算的簡單方式就是不管它們是不是流數(shù)據(jù)”。這種實現(xiàn)來源于經(jīng)驗：已經(jīng)了解如何編寫靜態(tài)數(shù)據(jù)集（即 批數(shù)據(jù)）的程序員使用Spark強大的DataFrame/Dataset API所總結(jié)出來的經(jīng)驗。結(jié)構(gòu)化數(shù)據(jù)流的愿景就是利用Catalyst優(yōu)化器找出：何時可以將靜態(tài)程序轉(zhuǎn)化為動態(tài)、無限數(shù)據(jù)的增量執(zhí)行（即流處理）。當遇 到結(jié)構(gòu)化數(shù)據(jù)，比如離散表或者infinite表格時，就可以簡單地運用流處理的方式。

作為這一愿景實現(xiàn)的步，Spark 2.0搭載了初始版本的結(jié)構(gòu)化流處理API，這是一個附在DataFrame/Dataset API上的（超小）擴展包。統(tǒng)一之后，對現(xiàn)有的Spark用戶來說使用起來非常簡單，他們能夠利用在Spark 批處理API方面的知識來回答實時的新問題。這里關(guān)鍵的功能包括：支持基于事件時間的處理，無序/延遲數(shù)據(jù)，sessionization以及非流式數(shù)據(jù) 源與Sink的緊密集成。