DAG vs. MPP

Native Design

MPP每一個Segment高度對稱(symmetric)，狹義MPP storage各個Segment自己管理，自己備份，觸及某數據相干的query一定會落到某個Segment上，有concurrency和straggler的問題存在。

MPP天然有很優秀的Compiler和Optimizer，包括local runtime環境是數據庫，解析、優化、codegen、履行1氣呵成。Segment內有良好的2級資源管理和Task調度，足夠細粒度且對query敏感(query隔離、內存使用監控等)。

DAG天然share storage，master能感知全局meta，所以才能單點schedule好task sets，并調和Executor之間的上下游數據shuffle、任務起停等進程。DAG每一個task從設計上有簡單、冪等等性質，可做task speculation的工作，乃至動態替換某個Node、更新其并發度。

DAG容易對不同存儲介質的數據做IO，目前場景的是在輸入和輸出節點，理論上各個計算節點可掛載不同存儲履行引擎，只要meta同享。

Task Schedule

MPP豎切，直統統完成Task的構造，每一個Segment收到的是較為完全的sub-query。

DAG橫切，節點合并(包括Spark的窄依賴和Stage)是優化手段，理論上不同Node的tasks要分散到不同計算進程上。最優的條件下，如Spark 2.0 whole-stage-codegen，是理論上把SQL優化到MPP那樣的極致。

OLAP Speed

MPP全局的compiler、optimizer到本地履行數據庫，理論上是DAG速度的上限。

DAG履行節點1般是合并好或codegen好的fn，起task的時候load user lib，固然靈活性上看也能夠掛數據庫。

Shared Storage

DAG能運算的條件就是storage是同享的。而且job之間的數據復用也很自然。

狹義MPP的storage是借助每一個Segment自己的數據庫做的。廣義MPP，如HAWQ，通過DFS解這個問題，同時解了由于本來只有某個segment才能履行query的concurrency問題，也解了straggler問題。

Core Aspects

MPP的核心是優化器和本地履行這塊，背靠于數據庫的積累。

DAG，我認為不能說核心是甚么，由于它不像MPP的核心那樣細膩。我只能說優勢是靈活性、易用性。從這個角度看，乃至MPP能不能用DAG實現我覺得都是可以討論的，由于DAG本身API易用(1般是Dataflow風格)，層次上很清晰地可以接上不同的DSL和編程模型，本地履行理論上也能夠掛載不同的履行引擎，數據可以來自不同存儲引擎，job之間可以存在數據復用。

Hybrid

固然我們看到的系統都已不再是狹義的DAG和MPP了。HAWQ架DFS的做法、Spark SQL做的優化工作都已是DAG和MPP之間的1種hybrid實現了。

拋開上面說的幾點，從master-slave架構、meta如何管理、task如何調度下發、query資源如何監控和隔離、數據shuffle是pipeline還是block、push還是pull等等都是不影響系統本身design的地方，大部份是散布式系統都要面臨的問題，只是解決手段上有各種的側重和常見的實現。