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同享。
MPP竖切，直统统完成Task的构造，每一个Segment收到的是较为完全的sub-query。
DAG横切，节点合并(包括Spark的窄依赖和Stage)是优化手段，理论上不同Node的tasks要分散到不同计算进程上。最优的条件下，如Spark 2.0 whole-stage-codegen，是理论上把SQL优化到MPP那样的极致。
MPP全局的compiler、optimizer到本地履行数据库，理论上是DAG速度的上限。
DAG履行节点1般是合并好或codegen好的fn，起task的时候load user lib，固然灵活性上看也能够挂数据库。
DAG能运算的条件就是storage是同享的。而且job之间的数据复用也很自然。
狭义MPP的storage是借助每一个Segment自己的数据库做的。广义MPP，如HAWQ，通过DFS解这个问题，同时解了由于本来只有某个segment才能履行query的concurrency问题，也解了straggler问题。
MPP的核心是优化器和本地履行这块，背靠于数据库的积累。
DAG，我认为不能说核心是甚么，由于它不像MPP的核心那样细腻。我只能说优势是灵活性、易用性。从这个角度看，乃至MPP能不能用DAG实现我觉得都是可以讨论的，由于DAG本身API易用(1般是Dataflow风格)，层次上很清晰地可以接上不同的DSL和编程模型，本地履行理论上也能够挂载不同的履行引擎，数据可以来自不同存储引擎，job之间可以存在数据复用。
固然我们看到的系统都已不再是狭义的DAG和MPP了。HAWQ架DFS的做法、Spark SQL做的优化工作都已是DAG和MPP之间的1种hybrid实现了。
抛开上面说的几点，从master-slave架构、meta如何管理、task如何调度下发、query资源如何监控和隔离、数据shuffle是pipeline还是block、push还是pull等等都是不影响系统本身design的地方，大部份是散布式系统都要面临的问题，只是解决手段上有各种的侧重和常见的实现。