程序员人生 网站导航

DAG vs. MPP

栏目:框架设计时间:2016-06-29 09:28:40

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的地方,大部份是散布式系统都要面临的问题,只是解决手段上有各种的侧重和常见的实现。

------分隔线----------------------------
------分隔线----------------------------

最新技术推荐