Presto為什麼比Spark SQL快？

1樓：讀位元組

Spark SQL屬於MMP架構的嗎？

第乙個問題：Presto作為SQL查詢引擎是乙個純記憶體的計算引擎，它對記憶體的優化近乎於一種極致的追求。Presto的架構主要是主從式，主節點是coordinator負責SQL的優化和執行計畫分配，同時還負責整個集群的記憶體管理，這點是其為什麼如此快的重要原因。

例如：乙個查詢Query需要消耗12G的記憶體，你有三颱work負責查詢，每個work的記憶體都是32GB，coordinator經過計算後，得出每個節點有6G就差不多了（4G執行，2G備用）。那麼這個Query 即便重複執行5次約等於每個work付出30G記憶體，Presto照樣敢一起執行，所以它快。

但是假如乙個Query需要消耗100GB的記憶體，這就超過了整個集群的記憶體了，那麼Presto的coordinator就直接卡掉這個查詢，防止記憶體溢位。多個查詢之和若超出集群記憶體總量就排隊。所以它是這麼玩的。

反過來看Spark SQL，它主要在集群中的每個計算節點的Executor程序中進行記憶體管理，因此它的記憶體管理主要還是為了優化當前計算節點的效能而設計的，不同於Presto搞了個主從架構專門控制集群記憶體。Spark SQL的架構還是基於Spark，Spark的分布式架構又基於Hadoop Yarn（或者Mesos），作為Yarn不管你內部的記憶體效率，只關心將你的任務成功的分發到不同階段的節點上去完成。

例如：Spark SQL生成優化後的物理計畫若分成10個task去做，安排在3個Executor程序去建立task並管理，每台Executor在管理task的記憶體時，也許有的task比較費記憶體，有的task就不需要那麼費，Executor發現自己記憶體不夠，就緩衝到磁碟去做。所以Spark也會出現記憶體與磁碟的I/O交換，那麼這個速度就不明顯了。

因此Presto的主從架構是從集群整體上的記憶體情況，對進行中的查詢進行定時監控，優化排程，將最大將耗記憶體的查詢，排程給work節點配置的最大記憶體量去使用，大概在堆記憶體的10%。但是Spark還是單靠每個節點自己的Executor程序來解決記憶體與磁碟的平衡問題。

但是資料量太大的查詢尤其是還存在複雜的關聯的全量資料集處理，Spark大多數情況還是比Presto快，一方面因為Presto遇到這種情況，主要就是對查詢的分解、分批、排隊。但是Spark就能充分利用MPP架構的能力，多任務分配到切分後的多資料塊，先調入計算處理，大不了記憶體和磁碟一起用。

另一方面Presto傾向於計算與儲存分離的架構，每個work並不知道是不是從本地拿資料，只是根據查詢要求來做，大多數情況都是遠端呼叫資料，但是Spark還是計算與儲存結合的架構，每個task可以和rdd的乙個分割槽做對應，那麼spark對rdd的分布式資料節點分配也會盡量按照就近原則進行，作為複雜的連線操作，盡量多的在本地處理，速度肯定比遠端讀取或者混洗（shuffle）要快很多。

第二個問題Spark SQL，它本質上包含了海量資料的平行計算（MPP），比MPP架構要更高階，因為通過DataFrame，對不同的資料來源進行了統一的高層次抽象。這個是比傳統MPP要有優勢，例如Impala就是類似於傳統MPP的架構，它就只是針對性HDFS和HBase。但是Spark SQL可以根據DF這種高層次的抽象，接入更多的資料來源，最終作為schema RDD（還是資料集的抽象）進入到Spark實現並行任務執行，可以說在MPP的基礎上，將抽象進行到底。

我正在寫大資料查詢引擎的系列文章：

可以先了解兩篇：

大資料平台的SQL查詢引擎有哪些（中 Impala VS Presto ）？

大資料平台的SQL查詢引擎有哪些（中 Spark SQL)？

Presto為什麼比Spark SQL快？

Hadoop和Spark有什麼區別

有什麼關於 Spark 的書推薦？

請問spark和hive是什麼關係？

其他用戶還看了：