吐槽Spark,其實我看了半天沒看懂他在說啥。不過總體而言DataBricks公司目前很多的做法其實蠻合我的理念的。

前言

這裡說的並不是效能，因為我沒嘗試對比過（下文會有簡單的說明），而是嘗試從某種更高一層次的的角度去看，為什麼Spark SQL 是遠遠超越MPP SQL的。

Spark SQL 和  MPP SQL 其實不在一個維度上。簡而言之，

• MPP SQL 是 Spark SQL 的一個子集

• Spark SQL 成為了一種跨越領域的互動形態

MPP SQL 是 Spark SQL 的一個子集

MPP SQL 要解決的技術問題是海量資料的查詢問題。這裡根據實際場景，你還可以加上一些修飾詞匯，譬如秒級，Ad-hoc 之類。

在實際業務中

1. 探索類業務，比如KPI多維分析，使用者畫像查詢，資料科學家摸底資料等

2. 運營類業務，比如報表（現在很多BI系統基本上完全基於SQL來構建），各種運營臨時統計需求

3. 分析類業務，不過這個會比較淺顯。顯然，真實的的分析應該主要依託一些統計類，機器學習等技術的支援

4. 運維類業務，比如實時查詢檢視海量的系統日誌等

MPP SQL 是有一定的效能優勢的，從HAWQ,Impala 等都是基於MPP架構的。然而僅限於此。這些功能Spark SQL 目前都已經涵蓋了，MPP SQL能做的事情，Spark SQL都完成的很漂亮。

依託於Spark 自身的全平臺性(漂亮的DataSource API以及各個廠商的努力適配),Spark SQL 基本上可以對接任意多個異構資料來源進行分析和查詢。大家可參考我的一個簡略實現 。

關於效能可以再多說兩句：

• 得益於一些具有複雜儲存格式的檔案的誕生，譬如CarbonData, Spark SQL 已經實現海量資料的秒級查詢

• Spark 自身透過Tungsten等專案的最佳化(尤其是程式碼自動生成)，速度越來越生猛，而JVM譬如GC帶來的問題則可以進一步透過off-heap的方式減少。

所以 Spark SQL 和 MPP SQL在效能上的差距也會越來越小。

Spark SQL 成為了一種跨越領域的互動形態

Spark 透過使用DS（2.0統一了DF 和 DS，使用一套SQL引擎）極大的增強了互動語意，意味著你可以用SQL（DS）作為統一的互動語言完成流式，批處理，互動式查詢，機器學習等大資料領域常見場景。這在任何一個系統都是不多見的，也可見Spark團隊的抽象能力。

引言中的那篇文章其實是作者吐槽Spark 團隊對Spark core（RDD）那層關注太少了，所以開始發牢騷。

現在我們再回過頭來看我們常見的一些業務：

1. 實時分析類業務

2. 探索類業務

3. 分析預測類業務

4. 運營報表類業務

首先這些業務都可以使用Spark 來實現。其次統一的互動介面都是DS(DF/SQL),並且DS/SQL 是一套極度易用並且廣泛普及和接受的。

當然Spark 也不是一步就做到這點的，原來流式計算和批次計算就是兩套API, DF 和 DS 也是兩套API,後面經過發展，Databricks 團隊也在積極思考和慢慢成長，經過先前已經有的積累，才做到現在的這一步。

所以本質上DS/SQL 已經成為除了RDD API 以外，另外一套通用的，統一的互動式API，涵蓋了流式，批處理，互動式查詢，機器學習等大資料領域。這也是我們第一次達成這樣的統一，目前來看也僅在Spark平臺上得以實現，它是的大資料的使用和學習門檻進一步降低，功在千秋。

RDD VS DS/SQL

DS/SQL 是一套資料型別首先，操作種類受限的表達語言，意味著Spark 團隊可以做更好的效能最佳化，也意味著門檻更低，在易用性和效能上都能取得良好的平衡

作者：祝威廉
連結：