计算机领域的很多概念都存在一些传播上的“谬误”。
MPP这个概念就是其中之一。它的“谬误”之处在于,明明叫做“Massively ParallelProcessing(大规模并行处理)”,却让非常多的人拿它与大规模并行处理领域最著名的开源框架Hadoop相关框架做对比,这实在是让人困惑——难道Hadoop不是“大规模并行处理”架构了?
很多人在对比两者时,其实并不知道MPP的含义究竟是什么、两者的可比性到底在哪里。实际上,当人们在对比两者时,与其说是对比架构,不如说是对比产品。虽然MPP的原意是“大规模并行处理”,但由于一些历史原因,现在当人们说到MPP架构时,它们实际上指代的是“分布式数据库”,而Hadoop架构指的则是以Hadoop项目为基础的一系列分布式计算和存储框架。不过由于MPP的字面意思,现实中还是经常有人纠结两者到底有什么联系和区别,两者到底是不是同一个层面的概念。
这种概念上的含混不清之所以还在流传,主要是因为不懂技术的人而喜欢这些概念的大有人在,所以也并不在意要去澄清概念。“既然分布式数据库是MPP架构,那么MPP架构就等于分布式数据库应该也没什么问题吧。”于是大家就都不在意了。
不过,作为一个技术人员,还是应该搞清楚两种技术的本质。本文旨在做一些概念上的澄清,并从技术角度论述两者同宗同源且会在未来殊途同归。
到底什么是MPP架构?
MPP架构与Hadoop架构在理论基础上几乎是在讲同一件事,即,把大规模数据的计算和存储分布到不同的独立的节点中去做。
有人可能会问:“既然如此,为什么人们不说Hadoop是MPP(大规模并行处理)架构呢?”
关于这个问题嘛,请先问是不是,再问为什么。
在GreenPlum的官方文档中就写道:“Hadoop就是一种常见的MPP存储与分析工具。Spark也是一种MPP架构。”来看下面的图,更能体会到两者的相似性。
问:这是什么架构?
答:MPP架构。
相信了解过MPP架构的读者对这幅图不会陌生。也许在不同的分布式数据库产品中,节点角色的名称会有差异,但总体而言都是一个主节点加上多个从节点的架构。
但是,还可以有其他答案,比如MapReduce on Yarn:
这幅图或许大家有些陌生,但只不过是省略了资源调度的简化版MapReduce运行时架构罢了。
当然,还可以有更多答案,如Spark:
自然还可以是Flink:
有人可能会说,虽然直观上这些架构长得很像,但是MPP架构中的Master所负责的事情是不是与其他框架不一样?
那么,MPP架构的Master做的什么事呢?它会接收SQL语句,解析它并生成执行计划,将计划分发到各个节点。那么,这与SparkSQL有区别吗?不仅与Spark SQL没有区别,与其他任何Hadoop生态圈类似架构如Hive SQL、FlinkSQL都没有区别。对于非SQL的输入,逻辑也是一致的,只是没有了解析SQL的步骤,但还是会生成执行图分发到各个节点去执行,执行结果也可以在主节点进行汇总。
不仅是在计算上没有区别,存储架构上也没有区别。下面是HDFS的架构图:
所以回到最初说的那句话——MPP架构与Hadoop架构在理论基础上几乎是在讲同一件事,即,把大规模数据的计算和存储分布到不同的独立的节点中去做。上面的几幅架构图印证了这一点。
既然MPP架构与Hadoop架构本质上是一回事,那么为什么很多人还要将两者分开讨论呢?我们可能经常听到这样的话:“这个项目的架构是MPP架构。”这似乎有意在说:“这可不是Hadoop那一套哦。”
这就与MPP架构的历史有关系。虽然从理论基础上两者是一回事,但是MPP架构与Hadoop架构的发展却是走的两条路线。MPP架构虽然也是指的“大规模并行处理”,但是由于提出者是数据库厂商,所以MPP架构在很多人眼中就成了“分布式数据库”的代名词,它处理的也都是“结构化”的数据,常常作为企业数据仓库的解决方案。而Hadoop生态圈是根正苗红伴随着“大数据”兴起而发展起来的概念,它所要解决的是大规模数据量的存储和计算,它的提出者也并非数据库厂商,而是有着C端数据的互联网企业。因此Hadoop架构虽然也解决“大规模并行处理”,但没有了数据库那一套东西的限制,处理的也大多是“非结构化”的数据(自然在最初阶段也少了相关的优化)。当然,Hadoop生态圈也要考虑“结构化”的数据,这时Hive就成了Hadoop生态圈的数据仓库解决方案。但是,Hadoop、Spark等框架的理论基础与分布式数据库仍然是一样的。
广义上讲,MPP架构是一种更高层次的概念,它的含义就是字面含义,但是它本身并没有规定如何去实现。Hadoop相关框架和各个分布式数据库产品则是具体的实现。狭义上讲,MPP架构成了分布式数据库这种体系架构的代名词,而Hadoop架构指的是以Hadoop框架为基础的一套生态圈。
本文并不想仅仅从较高层次的架构设计来说明两者是一回事,这样还是缺乏说服力。下面,我们从分布式计算框架中最重要的过程——Shuffle——来展示两者更多的相似性。
数据重分区
Shuffle是分布式计算框架中最重要的概念与过程之一。在MPP架构(分布式数据库)中,这个数据重分区的过程与Hadoop相关框架在计算中的数据重分区过程也是一致的。
无论是HadoopMapReduce,还是Spark或Flink,由于业务的需求,往往需要在计算过程中对数据进行Hash分区,再进行Join操作。这个过程中不同的框架会有不同的优化,但是归根到底,可以总结为两种方式。
其中一种方式就是直接将两个数据源的数据进行分区后,分别传输到下游任务中做Join。这就是一般的“Hash Join”。
另一种方式是,当其中一个数据源数据较少时,可以将该数据源的数据分发到所有节点上,与这些节点上的另一个数据源的数据进行Join。这种方式叫做“BroadcastJoin”。它的好处是,数据源数据较多的一方不需要进行网络传输。
以上是Hadoop相关框架的实现。下面用一个具体的例子来看MPP架构对这一过程的思考。
在MPP架构中,数据往往会先指定分区Key,数据就按照分区Key分布在各个节点中。
现在假设有三张表,其中两张为大表,一张为小表:
很自然地,订单表会选择订单ID用做分区Key,产品表会选择产品ID作为分区Key,客户表会选择客户ID作为分区Key。给这些表中添加一些数据,并且执行一个查询语句:
首先,订单表要与客户表做Join,JoinKey是客户ID。这种操作在Hadoop生态圈的分布式计算框架中,相当于对两个表做了Hash分区的操作。不过由于客户表已经按照客户ID提前做好了分区,所以这时只需要对订单表做重分区。在MPP架构中,会产生如下的结果:
此时,订单表整个表的数据会发生重分区,由此产生网络IO。这种情况相当于Hadoop架构中的“Hash Join”。
接着,需要让结果与产品表按照产品ID做Join。这时,因为之前产生的结果的分区Key不是产品ID,看起来又需要将整个数据进行重分区。不过,注意到产品表是个小表,所以此时只需要将该表广播到各个节点即可。结果如下:
在这个过程中,就只有小表的数据发生了网络IO。这就相当于Hadoop架构中的“Broadcast Join”。
两者还有区别吗?
前文在MPP架构的概念、历史以及技术细节上与Hadoop架构做了对比,了解到了两者一些极为相似的地方,而且在广义上讲,Hadoop就是MPP架构的一种实现。
然而前文也讲到,由于传播上的谬误,现在人们说到MPP架构,主要指的是分布式数据库,它处理的是结构化的数据,而Hadoop生态圈是由“大数据”这套概念发展而来,最初处理的都是非结构化的数据。以此为出发点,两者到底在发展过程中产生了多大的区别呢?
对比的维度有很多,比如很多人会说,MPP架构的平台封闭、拥有成熟的人才市场,而Hadoop架构平台开放、人才专业培训较少等。但这些并不是本质的区别。这里还是以技术指标作为维度来进行对比。
技术角度上来讲,MPP产品最大的优势是作业运行时间更快。这不难理解,因为MPP产品处理的都是结构化数据,本身就是从数据库发展而来,拥有极为复杂的优化器对作业进行优化。这些优化器是各厂商最有价值的商业机密,自然是开源产品不能比的。不过另一个角度来看,这也是MPP产品相比于Hadoop相关产品不够灵活的地方——它只能处理结构化数据。
有人说MPP产品能够处理的数据量没有Hadoop架构大。这种说法并不准确。Hadoop架构之所以能处理更大量的数据,其中一个原因是硬件成本较低,扩展更加的方便。实际上,经过精心设计的MPP架构照样可以处理PB及以上级别的数据。有人说,MPP产品不能处理大规模数据,是因为元数据的量十分巨大。其实,同样的问题也存在于Hadoop相关框架中。另一方面,Hadoop相关框架能处理多大量的数据,与具体的实现有很大关系。如果拥有足够的资金可以对MPP产品进行扩展,而Hadoop相关产品我们又用基于内存的计算,那么,对比的结果一定是MPP产品能够应对更大的数据量。如果非要从数据量这一维度来做对比,可能反而是Hadoop相关产品对小数据量更有优势。比如想要存储一个极小的表,MPP产品也许会根据分区Key将其拆分到100个节点中去,而HDFS用一个文件块存储就够用了。
未来发展
前面讲到MPP产品对结构化数据的计算和存储都更有效率。其中一部分优化就包括了存储时的“列存储”技术,查询时的“CBO优化”等等。这些都是Hadoop生态圈一开始比较缺乏的技术。但是随着这些年的发展,这些技术早就融入到了Hadoop生态圈中,Hive、Spark框架的优化技术也越做越好,由此与MPP架构的技术差距也越来越小,甚至有覆盖的趋势。从最核心的技术上来看,两者未来只会越来越像。可以预测,Hadoop架构的市场会越来越大。
不过,分布式数据库产品在安全性等方面仍然提供着更成熟的解决方案,这是开源产品短时间内无法超越的。因此,“MPP架构”这个概念仍然会在政府、传统企业中长期占有一席之地。
戳这里,看该作者更多好文
本网站的文章部分内容可能来源于网络和网友发布,仅供大家学习与参考,如有侵权,请联系站长进行删除处理,不代表本网站立场,转载者并注明出处:https://www.jmbhsh.com/muyingyongpin/35707.html