課程大綱： .SparkSession的創建和使用API課程培訓
在Databricks創建一個新Apache Spark 2.0技術預覽版集群的工作流程截圖
由于Apache Spark 2.0的終發布版尚需幾周才能出爐，本技術預覽版旨在讓大家提前預覽一下新版的功能，一方面滿足大家的好奇心，一方面也便于我們在發布終版前多收集一些用戶反饋與bug報告。
現在我們來看看新的變化吧。
Spark 2.0：更簡單、更、更智能
更簡單：SQL與簡化的APISpark讓我們引以為豪的一點就是所創建的API簡單、直觀、便于使用，Spark 2.0延續了這一傳統，并在兩個方面凸顯了優勢：1）標準的SQL支持；2）統一數據框（DataFrame）/數據集API。
在SQL方面，我們已經對Spark的SQL功能做了重大拓展，引入了新的ANSI SQL解析器，并支持子查詢功能。Spark 2.0可以運行所有99個TPC-DS查詢（需求SQL：2003中的很多功能支持）。由于SQL是Spark應用所使用的主要接口之一，對SQL功能的拓展大幅削減了將遺留應用移植到Spark時所需的工作。
在編程API方面，我們簡化了API：
l在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手冊做些了解。
lSparkSession：這 是一個新入口，取代了原本的SQLContext與HiveContext。對于DataFrame API的用戶來說，Spark常見的混亂源頭來自于使用哪個“context”。現在你可以使用SparkSession了，它作為單個入口可以兼容兩 者。注意原本的SQLContext與HiveContext仍然保留，以支持向下兼容。
l更簡單、性能更佳的Accumulator API：我們設計了一個新的Accumulator API，不但在類型層次上更簡潔，同時還專門支持基本類型。原本的Accumulator API已不再使用，但為了向下兼容仍然保留。
l 基于DataFrame的機器學習API將作為主ML API出現：在Spark 2.0中，spark.ml包及其“管道”API會作為機器學習的主要API出現，盡管原本的spark.mllib包仍然保留，但以后的開發重點會集中在基于DataFrame的API上。
l機器學習管道持久化：現在用戶可以保留與載入機器學習的管道與模型了，Spark對所有語言提供支持。
lR語言的分布式算法：增加對廣義線性模型（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時，我們列出了在單核中處理單行數據所花費的時間（以十億分之一秒為單位），下面的表格證明了新一代Tungsten引擎的強大。Spark 1.6包含代碼生成技術（code generation）的使用，這一技術如今在一些的商業數據庫中也有運用，正如我們看到的那樣，使用了新whole-stage code generation技術后，速度比之前快了一個數量級。
更智能：結構化數據流作為個嘗試統一批處理與流處理計算的工具，Spark Streaming一直是大數據處理的。個流處理API叫做DStream，在Spark 0.7中初次引入，它為開發者提供了一些很強大的屬性，包括：只有一次語義，大規模容錯，以及高吞吐。
然而，在處理了數百個真實世界的Spark Streaming部署之后，我們發現需要在真實世界做決策的應用經常需要不止一個流處理引擎。他們需要深度整合批處理堆棧與流處理堆棧，整合內部存儲系 統，并且要有處理業務邏輯變更的能力。因此，各大公司需要不止一個流處理引擎，并且需要能讓他們開發端對端“持續化應用”的全棧系統。
有一種看法是將所有一切當作流數據，也就是說采用單一的編程模型來整合批數據與流數據。
在這種單一的模型中，有大量的問題出現。先，在接收到數據的時間進行處理非常困難，也很有局限性。其次，不同的數據分布、變動的業務邏輯與數據延 遲都增加了實際操作的挑戰性。再次，大多現有系統比如MySQL或者Amazon S3都不支持流處理，大多現有的機器學習算法在streaming設置中都不起作用。
Spark 2.0的結構化Streaming API是處理流數據的全新方式，源于“在流數據中計算的簡單方式就是不管它們是不是流數據”。這種實現來源于經驗：已經了解如何編寫靜態數據集（即 批數據）的程序員使用Spark強大的DataFrame/Dataset API所總結出來的經驗。結構化數據流的愿景就是利用Catalyst優化器找出：何時可以將靜態程序轉化為動態、無限數據的增量執行（即流處理）。當遇 到結構化數據，比如離散表或者infinite表格時，就可以簡單地運用流處理的方式。
作為這一愿景實現的步，Spark 2.0搭載了初始版本的結構化流處理API，這是一個附在DataFrame/Dataset API上的（超小）擴展包。統一之后，對現有的Spark用戶來說使用起來非常簡單，他們能夠利用在Spark 批處理API方面的知識來回答實時的新問題。這里關鍵的功能包括：支持基于事件時間的處理，無序/延遲數據，sessionization以及非流式數據 源與Sink的緊密集成。
加入高級會員獲得助教答疑
