DAG vs. MPP vs MR

2019独角兽企业重金招聘Python工程师标准>>>

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

 

2、pipeline VS streaming
pipeline带来的好处就是每一批(一条、若干条或全部)数据的lantency低，各自并发可乱序，中间数据不容易膨胀。后来看了微软的一些论文和系统之后，特别是DataFlow论文的出现，让我看到了streaming的本质。streaming的数据有先天的属性：产生时间、系统处理时间。真正完备的streaming可以在编程模型上清晰地定义，何时或什么条件下要触发计算，迟到的数据需不需要及如何处理，放在那部分区间处理，如何对已输出结果做补偿。在这块，思想最先进的就是谷歌的DataFlow，它没有给出实现细节，但是把模型这层说的很清楚，真正统一了streaming和batch计算，微软的Trill也更早意识到了这点，只是论文层面没有DataFlow说的清晰(个人拙见)。

 

3、数据库领域新想法
Hyper： HyPer is a main-memory-based relational DBMS for mixed OLTP and OLAP workloads.，具体介绍见官方站点：http://www.hyper-db.de/，一大堆相关的论文 

X100： 未查到

C-Store/Vertica：  C-Store/Vertica databae ，介绍文档：http://vldb.org/pvldb/vol5/p1790_andrewlamb_vldb2012.pdf

DB2 BLU：DB2 10.5 BLU列式存储

 

那么MPP是什么？ MPP代表大规模并行处理，这是网格计算中所有单独节点参与协调计算的方法。 MPP DBMS是建立在这种方法之上的数据库管理系统。在这些系统中，您正在凝视的每个查询都会被分解为由MPP网格的节点并行执行的一组协调进程，它们的运行时间比传统的SMP RDBMS系统快得多。该架构提供给您的另一个优点是可扩展性，因为您可以通过向其中添加新节点轻松扩展网格。为了能够处理大量的数据，这些解决方案中的数据通常在每个节点只处理其本地数据的方式在节点（分片）之间分割。这进一步加快了数据的处理速度，因为为这种设计使用共享存储将是一个巨大的过度 - 更复杂，更昂贵，更少的可扩展性，更高的网络利用率，更少的并行性。这就是为什么大多数MPP DBMS解决方案是无共享的，并且可以在DAS存储上或在小型服务器之间共享的一组存储架上工作。这种方法被Teradata，Greenplum，Vertica，Netezza等类似解决方案所使用。所有这些都有专门为MPP解决方案开发的复杂而成熟的SQL优化器。所有这些都是可扩展的，内置语言和这些解决方案的工具集支持几乎任何客户的愿望，无论是地理空间分析，数据挖掘的全文搜索。所有这些都是封闭源复杂的企业解决方案（但FYI，Greenplum将在2015年第四季度开放采购）在这个行业多年，它们足够稳定地运行其用户的关键任务工作负载。

Paste_Image.png

 

Hadoop怎么样？这不是一个单一的技术，它是相关项目的生态系统，它的优缺点。最大的Pro是可扩展性 - 许多新组件出现（像Spark之前一样），并且它们与基础Hadoop的核心技术保持集成，这阻止了您的锁定，并允许进一步扩展集群用例。作为一个可以理解的事实，自己构建一个单独的技术的平台是一个很多工作，现在没有人手动，大多数公司都在运行像Cloudera提供的预建平台， Hortonworks。

Hadoop存储技术基于完全不同的方法。而不是基于某个键对数据进行分片，它将数据块分解为固定（可配置）大小的块，并在节点之间分割数据。这些块是大的，它们是只读的以及整体文件系统（HDFS）。为了简单起见，将小的100行表加载到MPP中将导致引擎根据表的密钥来划分数据，这样在一个足够大的集群中，每个节点将只存储一个行。相比之下，在HDFS中，整个小表将被写入单个块中，该块将被表示为datanode文件系统上的单个文件。

Paste_Image.png

 

接下来，集群资源管理呢？ 与MPP设计相反，Hadoop资源管理器（YARN）为您提供了更精细的资源管理 - 与MPP相比，MapReduce作业并不需要所有的计算任务并行运行，因此您甚至可以处理大量的 如果集群的其他部分被完全利用，则在单个节点上运行的一组任务中的数据。 它还具有一系列不错的功能，如可扩展性，支持长容器等。 但实际上它比MPP资源管理器慢，有时管理并发性好。

Paste_Image.png

 

接下来是Hadoop的SQL接口。 在这里，您可以选择各种工具：可能是Hive在MR / Tez / Spark上运行，它可能是SparkSQL，它可能是Impala或HAWQ或IBM BigSQL，它可能与Splice Machine完全不同。 您有广泛的选择，很容易迷失在这样的技术中。

第一个选项是Hive，它是将SQL查询转换为MR / Tez / Spark作业并在集群上执行它们的引擎。 所有的工作都建立在相同的MapReduce概念之上，并为您提供了良好的群集利用率选项，并与其他Hadoop堆栈进行了良好的集成。 但是这些缺点也是很大的 - 执行查询的延迟很大，特别是对于表连接性能降低，没有查询优化器（至少现在），所以引擎执行你要求的内容，即使是最差的选项。 这张照片涵盖了过时的MR1设计，但在我们的上下文中并不重要：

Paste_Image.png

像Impala和HAWQ这样的解决方案位于这一优势的另一边，它们是Hadoop之上的MPP执行引擎，用于存储在HDFS中的数据。 与其他MPP引擎一样，它们可以为您提供更低的延迟和更少的处理时间，而且可以降低可扩展性和较低的稳定性。

Paste_Image.png

 

SparkSQL是坐在MapReduce和MPP-over-Hadoop方法之间的不同的野兽，试图获得最好的两个世界并有自己的缺点。 与MR类似，它将作业分成一组独立安排的任务，提供更好的稳定性。 像MPP一样，它尝试在执行阶段之间流式传输数据，以加快处理速度。 此外，它使用MPP（与其impalad和HAWQ段）熟悉的固定执行器概念来减少查询的延迟。 但它也结合了这些解决方案的缺点 - 不如MPP那么快，而不是像MapReduce那样稳定和可扩展。

当我分开覆盖所有的技术时，在这里把它放在一起：

比较项目 MPP Hadoop
平台开放 封闭和专有。对于某些技术, 通过互联网免费提供供应商和社区资源的完全开源
甚至不能为非客户下载文档
可扩展性 平均数十个节点，最大100-200 平均100个节点，可扩展至几千个节点
个节点
可处理数据 平均10TB,最大1PB 平均100TB, 多值1oPB
延迟 10-20毫秒 10-20秒
平均查询时间 5-7 秒 10-15 分钟
最大查询时间 1-2小时 1-2周
查询优化 拥有复杂的企业级优化器 没有优化器或优化器功能非常有限，有时甚至优化不是基于成本的
查询调试和分析 便于查看的查询执行计划、 OOM问题和Java堆转储分析，GC在群集组件上暂停，每个任务的单独日志给你很多有趣的时间
查询执行统计信息
说明性错误信息
技术价格 每个节点数十万美元 每个节点免费或高达数千美元
易用性 简单友好的SQL界面和简单可编译 SQL不完全符合ANSI标准，用户应该关心执行逻辑，底层数据布局。 函数通常需要用Java编写，编译并放在集群上
的数据库内功的数据库内置函数
目标用户 业务分析师 Java开发人员和经验丰富的DBA
单作业冗余 低，当MPP节点发生故障时作业失败 高，作业只有当节点管理作业执行失败时才会失败
最小数据集 任意 GB
最大并发性 十到数百个查询 多达10-20个job
技术可扩展性 仅使用供应商提供的工具 混搭
DBA技能等级要求 普通DBA 需要懂Java编程的高级RDBMSDBA
解决方案实施复杂性 一般 复杂

通过这些信息，您可以总结为什么Hadoop不能用作传统企业数据仓库的完全替代品，
但它可以用作以分布式方式处理大量数据并从数据中获得重要见解的引擎。 Facebook
拥有一个300PB的Hadoop，并且仍然使用一个小型的50TB Vertica集群，LinkedIn
拥有一个巨大的Hadoop集群，并且仍然使用Aster Data集群（由Teradata购买的MPP），
您可以继续使用此列表。

大数据Map Reduce 和 MPP数据库 的区别 

2018-09-07 14:39公司/大数据

原理的角度出发,map reduce其实就是二分查找的一个逆过程,不过因为计算节点有限,所以map和reduce前都预先有一个分区的步骤.

二分查找要求数据是排序好的,所以Map Reduce之间会有一个shuffle的过程对Map的结果排序. Reduce的输入是排好序的.

https://blog.csdn.net/dreamy_lin/article/details/81391859

MR分而治之的策略和数据库行业中另一种数据库 Massively Parallel Processor 即大规模并行处理数据库(典型代表 AWS Redshift 和 Teradata 以及微软的 Azure SQL Data Warehouse)有什么区别呢?

MPP的思路简单粗暴,把数据分块,交给不同节点储存, 查询的时候各块的节点有独立的计算资源分别处理,然后汇总到一个leader node(又叫control node),具体的优化和传统的关系型数据库很相似,涉及到了索引,统计信息等概念. MPP有shared everything /Disk / Nothing之别.

举例来说说区别:

比如一张销售表,其中有一列产品类别,现在要知道各个产品类别的销量.

类别a1类别a2类别b3类别b1类别c4

MR处理方法:在map阶段,对每个hdfs的block统计各个类别销量,然后shuffle根据类别列排序,reduce阶段合并

MPP处理方法:每个block有单独的计算节点统计各个类别销量,汇总结果到leader node, leader做个合并,在这个案例里就是做几次加法

可以看到在这个场景中MPP的效率绝对比MR高的多,因为省去了shuffle排序的过程.其他步骤都很相似.

在实际应用中的确MPP有更高的效率,所以对于结构化的大数据, MPP至今仍是首选.

MR 或者 Spark胜过MPP的地方在于非结构化的数据处理上, 比如大量日志文件或者大量tweet。

或者在一些复杂的算法应用上MR或Spark的可编程性显得更加灵活. Hadoop复杂的ecosystem对于复杂情况有着更好的应对,而对于结构化的大数据,要是出一些纯统计数字的报表的话, Hadoop有点虎落平阳被犬欺的感觉。

一些大公司的架构也是MPP和Hadoop两者兼具的。既有用MPP处理传统的BI报表业务,又有使用Hadoop做一些深入分析的应用。未来MPP和hadoop能否融合起来,是一个值得观察的发展方向。

Shared Everything:一般是针对单个主机，完全透明共享CPU/MEMORY/IO，并行处理能力是最差的，典型的代表SQLServer

Shared Disk：各个处理单元使用自己的私有 CPU和Memory，共享磁盘系统。典型的代表Oracle Rac，它是数据共享，可通过增加节点来提高并行处理的能力，扩展能力较好。其类似于SMP（对称多处理）模式，但是当存储器接口达到饱和的时候，增加节点并不能获得更高的性能 。

Shared Nothing：各个处理单元都有自己私有的CPU/内存/硬盘等，不存在共享资源，类似于MPP（大规模并行处理）模式，各处理单元之间通过协议通信，并行处理和扩展能力更好。典型代表DB2 DPF和hadoop ，各节点相互独立，各自处理自己的数据，处理后的结果可能向上层汇总或在节点间流转。

我们常说的 Sharding 其实就是Share Nothing架构，它是把某个表从物理存储上被水平分割，并分配给多台服务器（或多个实例），每台服务器可以独立工作，具备共同的schema，比如MySQL Proxy和Google的各种架构，只需增加服务器数就可以增加处理能力和容量。

首先MPP 必须消除手工切分数据的工作量。这是MySQL 在互联网应用中的主要局限性。

另外MPP 的切分必须在任何时候都是平均的，不然某些节点处理的时间就明显多于另外一些节点。

对于工作负载是不是要平均分布有同种和异种之分，同种就是所有节点在数据装载的时候都同时转载，异种就是可以指定部分节点专门用来装载数据（逻辑上的不 是物理上） ， 而其他所有节点用来负责查询。 Aster Data 和Greenplum 都属于这种。

两者之间并没有明显的优势科研，同种的工作负载情况下，需要软件提供商保证所有节点的负载是平衡的。 而异种的工作负载可以在你觉得数据装载很慢的情况下手工指定更多节点装载数据。区别其实就是自动化和手工控制，看个人喜好而已。

另外一个问题是查询如何被初始化的。 比如要查询销售最好的10件商品，每个节点都要先计算出自己的最好的10件商品，然后向上汇总，汇总的过程，肯定有些节点做的工作比其他节点要多。

上面只是一个简单的单表查询，如果是两个表的连接查询，可能还会涉及到节点之间计算的中间过程如何传递的问题。 是将大表和小表都平均分布，然后节点计算的时候将得到的结果汇总（可能要两次汇总），还是将大表平均分布，小表的数据传输给每个节点，这样汇总就只需要一 次。 （其中一个特例可以参考后面给出的Oracle Partition Wise Join）。

两种执行计划很难说谁好谁坏，数据量的大小可能会产生不同的影响。

有些特定的厂商专门对这种执行计划做过了优化的，比如EMC Greenplum 和 HP Vertica。

这其中涉及到很多取舍问题，比如数据分布模式，数据重新分布的成本，中间交换数据的网卡速度，储存介质读写的速度和数据量大小（计算过程一般都会用临时表 储存中间过程）。

Hadoop与MPP之间的关系是什么?有什么区别和联系?

适用范围、应用领域分别是什么?

其实MPP架构的关系型数据库与Hadoop的理论基础是极其相似的，都是将运算分布到节点中独立运算后进行结果合并。个人觉得区别仅仅在于前者跑的是SQL，后者底层处理则是MapReduce程序。

但是我们会经常听到对于MPP而言，虽说是宣称也可以横向扩展Scale OUT，但是这种扩展一般是扩到100左右，而Hadoop一般可以扩展1000+，这也是经常被大家拿来区分这两种技术的一个说词。

这是为什么呢?其实可以从CAP理论上来找到一些理由。因为MPP始终还是DB，一定要考虑C(Consistency)，其次考虑 A(Availability)，最后才在可能的情况下尽量做好P(Partition-tolerance)。而Hadoop就是为了并行处理和存储设计的，所有数据都是以文件存储，所以优先考虑的是P，然后是A，最后再考虑C。所以后者的可扩展性当然好于前者。

以下几个方面制约了MPP数据库的扩展

1、高可用：MPP DB是通过Hash计算来确定数据行所在的物理机器(而Hadoop无需此操作)，对存储位置的不透明导致MPP的高可用很难办。

2、并行任务：数据是按照Hash来切分了，但是任务没有。每个任务，无论大小都要到每个节点去走一圈。

3、文件系统：数据切分了，但是文件数没有变少，每个表在每个节点上一定有一到多个文件。同样节点数越多，存储的表就越多，导致每个文件系统上有上万甚至十万多个文件。

4、网络瓶颈：MPP强调对等的网络，点对点的连接也消耗了大量的网络带宽，限制了网络上的线性扩展(想象一台机器可能要给1000台机器发送信息)。更多的节点并没有提供更高的网络带宽，反而导致每个组节点间平均带宽降低。

5、其他关系数据库的枷锁：比如锁、日志、权限、管理节点瓶颈等均限制了MPP规模的扩大。

但是MPP数据库有对SQL的完整兼容和一些事务处理功能，对于用户来说，在实际的使用场景中，如果数据扩展需求不是特别大，需要的处理节点不多，数据都是结构化数据，习惯使用传统RDBMS的很多特性的场景，可以考虑MPP如Greenplum/Gbase等。

但是如果有很多非结构化数据，或者数据量巨大，有需要扩展到成百上千个数据节点需求的，这个时候Hadoop是更好的选择。.

1. Hadoop是分布式计算平台，以hive应用为例，它的存储结构是HDFS，计算框架是MapReduce；MPP代表大规模并行处理，一个优点是可扩展性，数据在节点（分片）之间分割，每个节点只处理其本地数据。

2. hive跟mpp的存储模型不一样，hive用的hdfs，而mpp需要自己做切分，自己做切分就带来动态调整的问题，hdfs的扩展是通过元数据来做的，他有中心节点用来存元数据，在加入新的节点的时候，只需要修改元数据就可以了，所以hdfs的扩展能力是受到管理元数据那台机器的性能限制的，一般来说可以到10k这个规模，再向上就不行了。但是mpp通常采用的是没有中心节点的存储模型，比如hash，你每次增加节点的时候，都需要rehash，这样当规模到了几百台的时候，扩展能力就下来了。当然，现在可以把存储架在hdfs上，这样在存储上就没有太大区别了。

由于存储结构导致计算模式不同，Hadoop采用Master-Slaves分配模式，单点故障时可以迅速把计算任务分配给其他节点，但是MPP一旦分配任务就不能调整，当某节点计算速度低下时，全部任务都要等待，所谓的木桶短板，当任务失败时导致整个计算的任务失败。

3. hive跟mpp的内存管理方式不大一样，mpp内存管理比较精细，他主要的想法是在每个机器上放个数据库，传统数据库的内存管理比较复杂，主要是内外存交互的东西，这样的架构决定了mpp在小数据量的时候，latency（启动延时）可以做的比较小，但是在大数据量的时候，throughput（吞吐量）做不上去。而hive的内存管理非常粗放，他后来就是mapreduce的job，mr的job是没有太多精细的内存管理的，他就是拼了命地scan，完了顶多就是个spill，这样的架构导致throughput很大，但是latency很高，当你集群规模很大的时候，你一般会追求很大的throughput，当数据量很大的时候，如果你用mpp那种传统的内存管理的话，大批量的计算反而会慢，而且更加占资源，所以vertica这种一开始就考虑了列式存储就是这个道理。

4.事务，你可以认为hive不支持传统意义上的那种高并发的事务，而mpp试图想要支持，一旦你要上分布式事务，基本上你的可扩展性就上不去了。hive的ddl是可以多个并发的，但是dml不行，而ddl他是通过传统的数据库去做的，所以这个也是个中心节点，dml不行的话，就决定了他可以在底层跑mr这么重粒度的东西，他跑的时候，会在整个表上面加一把大锁。

5.failover机制，hive的failover就是mr的failover，job挂掉了重新换机器跑就完了，但是mpp如果采用传统架构的话，他的计算是要attach到数据节点上去的，如果你规模上去，那么fail的可能性就上去了，这样如果你每次计算都有台机器挂了，你一挂，别人就要等你，而不是换台机器继续跑，那么这个也限制了可扩展性，当然，如果mpp在底层用了统一的存储，完了计算也可以到处转移，再想个办法把中间状态记录下来，也可以扩展（这个实际上就是sparksql）

6.从CAP理论上分析。因为MPP始终还是DB，一定要考虑C(Consistency)，其次考虑 A(Availability)，最后才在可能的情况下尽量做好P(Partition-tolerance)。而Hadoop就是为了并行处理和存储设计的，所有数据都是以文件存储，所以优先考虑的是P，然后是A，最后再考虑C。所以hadoop的可扩展性当然好于前者。

--------------------- 

Spark SQL 和 MPP SQL 其实不在一个维度上。简而言之，

• MPP SQL 是 Spark SQL 的一个子集
• Spark SQL 成为了一种跨越领域的交互形态

MPP SQL 是 Spark SQL 的一个子集

MPP SQL 要解决的技术问题是海量数据的查询问题。这里根据实际场景，你还可以加上一些修饰词汇，譬如秒级，Ad-hoc 之类。

在实际业务中

1. 探索类业务，比如KPI多维分析，用户画像查询，数据科学家摸底数据等
2. 运营类业务，比如报表（现在很多BI系统基本上完全基于SQL来构建），各种运营临时统计需求
3. 分析类业务，不过这个会比较浅显。显然，真实的的分析应该主要依托一些统计类，机器学习等技术的支持
4. 运维类业务，比如实时查询查看海量的系统日志等

MPP SQL 是有一定的性能优势的，从HAWQ,Impala 等都是基于MPP架构的。然而仅限于此。这些功能Spark SQL 目前都已经涵盖了，MPP SQL能做的事情，Spark SQL都完成的很漂亮。

依托于Spark 自身的全平台性(漂亮的DataSource API以及各个厂商的努力适配),Spark SQL 基本上可以对接任意多个异构数据源进行分析和查询。大家可参考我的一个简略实现 利用StreamingPro实现SQL-交互式查询。

关于性能可以再多说两句：

• 得益于一些具有复杂存储格式的文件的诞生，譬如CarbonData, Spark SQL 已经实现海量数据的秒级查询
• Spark 自身通过Tungsten等项目的优化(尤其是代码自动生成)，速度越来越生猛，而JVM譬如GC带来的问题则可以进一步通过off-heap的方式减少。

所以 Spark SQL 和 MPP SQL在性能上的差距也会越来越小。

 

转载于:https://my.oschina.net/hblt147/blog/3006042