[[168032]]

 前言

這里說的并不是性能，因為我沒嘗試對比過(下文會有簡單的說明)，而是嘗試從某種更高一層次的的角度去看，為什么Spark SQL 是遠遠超越MPP SQL的。

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

MPP SQL 是 Spark SQL 的一個子集

Spark SQL 成為了一種跨越領域的交互形態(tài)

MPP SQL 是 Spark SQL 的一個子集

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

在實際業(yè)務中

探索類業(yè)務，比如KPI多維分析，用戶畫像查詢，數(shù)據(jù)科學家摸底數(shù)據(jù)等

運營類業(yè)務，比如報表(現(xiàn)在很多BI系統(tǒng)基本上完全基于SQL來構(gòu)建)，各種運營臨時統(tǒng)計需求

分析類業(yè)務，不過這個會比較淺顯。顯然，真實的的分析應該主要依托一些統(tǒng)計類，機器學習等技術的支持

運維類業(yè)務，比如實時查詢查看海量的系統(tǒng)日志等

MPP SQL 是有一定的性能優(yōu)勢的，從HAWQ,Impala 等都是基于MPP架構(gòu)的。然而僅限于此。這些功能Spark SQL 目前都已經(jīng)涵蓋了，MPP SQL能做的事情，Spark SQL都完成的很漂亮。

依托于Spark 自身的全平臺性(漂亮的DataSource API以及各個廠商的努力適配),Spark SQL 基本上可以對接任意多個異構(gòu)數(shù)據(jù)源進行分析和查詢。

關于性能可以再多說兩句：

得益于一些具有復雜存儲格式的文件的誕生，譬如CarbonData, Spark SQL 已經(jīng)實現(xiàn)海量數(shù)據(jù)的秒級查詢

Spark 自身通過Tungsten等項目的優(yōu)化(尤其是代碼自動生成)，速度越來越生猛，而JVM譬如GC帶來的問題則可以進一步通過off-heap的方式減少。

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

Spark SQL 成為了一種跨越領域的交互形態(tài)

Spark 通過使用DS(2.0統(tǒng)一了DF 和 DS，使用一套SQL引擎)極大的增強了交互語意，意味著你可以用SQL(DS)作為統(tǒng)一的交互語言完成流式，批處理，交互式查詢，機器學習等大數(shù)據(jù)領域常見場景。這在任何一個系統(tǒng)都是不多見的，也可見Spark團隊的抽象能力。

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

現(xiàn)在我們再回過頭來看我們常見的一些業(yè)務：

實時分析類業(yè)務

探索類業(yè)務

分析預測類業(yè)務

運營報表類業(yè)務

首先這些業(yè)務都可以使用Spark 來實現(xiàn)。其次統(tǒng)一的交互接口都是DS(DF/SQL),并且DS/SQL 是一套極度易用并且廣泛普及和接受的。

當然Spark 也不是一步就做到這點的，原來流式計算和批量計算就是兩套API, DF 和 DS 也是兩套API,后面經(jīng)過發(fā)展，Databricks 團隊也在積極思考和慢慢成長，經(jīng)過先前已經(jīng)有的積累，才做到現(xiàn)在的這一步。

所以本質(zhì)上DS/SQL 已經(jīng)成為除了RDD API 以外，另外一套通用的，統(tǒng)一的交互式API，涵蓋了流式，批處理，交互式查詢，機器學習等大數(shù)據(jù)領域。這也是我們***次達成這樣的統(tǒng)一，目前來看也僅在Spark平臺上得以實現(xiàn)，它是的大數(shù)據(jù)的使用和學習門檻進一步降低，功在千秋。

RDD VS DS/SQL

DS/SQL 是一套數(shù)據(jù)類型首先，操作種類受限的表達語言，意味著Spark 團隊可以做更好的性能優(yōu)化，也意味著門檻更低，在易用性和性能上都能取得良好的平衡。