关闭

DAG vs. MPP

标签: DAGMPP
5965人阅读 评论(0) 收藏 举报
分类:

DAG vs. MPP

Native Design

MPP每个Segment高度对称(symmetric),狭义MPP storage各个Segment自己管理,自己备份,涉及某数据相关的query必定会落到某个Segment上,有concurrency和straggler的问题存在。

MPP天然有很优秀的Compiler和Optimizer,包括local runtime环境是数据库,解析、优化、codegen、执行一气呵成。Segment内有良好的二级资源管理和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执行节点一般是合并好或者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易用(一般是Dataflow风格),层次上很清晰地可以接上不同的DSL以及编程模型,本地执行理论上也可以挂载不同的执行引擎,数据可以来自不同存储引擎,job之间可以存在数据复用。

Hybrid

当然我们看到的系统都已经不再是狭义的DAG和MPP了。HAWQ架DFS的做法、Spark SQL做的优化工作都已经是DAG和MPP之间的一种hybrid实现了。

抛开上面说的几点,从master-slave架构、meta如何管理、task如何调度下发、query资源如何监控和隔离、数据shuffle是pipeline还是block、push还是pull等等都是不影响系统本身design的地方,大部分是分布式系统都要面临的问题,只是解决手段上有各种的侧重和常见的实现。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:732666次
    • 积分:9287
    • 等级:
    • 排名:第2043名
    • 原创:158篇
    • 转载:1篇
    • 译文:5篇
    • 评论:237条