總結(jié)來說MR是一個編程模型，你可以用MR這個編程模型自己實現(xiàn)MPP所做的事。

MPP則是一種SQL的計算引擎。

“MR分而治之的策略” 和 “Massively Parallel Processor類型的數(shù)據(jù)庫” （即大規(guī)模并行處理數(shù)據(jù)庫，典型代表 AWS Redshift?和 Teradata?以及微軟的 Azure SQL Data Warehouse) 有什么區(qū)別呢?

MPP在數(shù)據(jù)存儲的時候就根據(jù)指定的分布方式交給不同節(jié)點儲存,?查詢的時候各塊的節(jié)點有獨立的計算資源分別處理,?然后匯總到一個leader?node(又叫control?node),?具體的優(yōu)化和傳統(tǒng)的關(guān)系型數(shù)據(jù)庫很相似,?涉及到了索引,?統(tǒng)計信息等概念. MPP有shared?everything /Disk / Nothing之別.

舉例來說說區(qū)別:

比如一張銷售表,?其中有一列產(chǎn)品類別,?現(xiàn)在要知道各個產(chǎn)品類別的總銷量.

類別a	1
類別a	2
類別b	3
類別b	1
類別c	4

MR處理方法:?在map階段, 將不同的類別的數(shù)據(jù)map到不同的slaver處理，在統(tǒng)計各個類別總銷量,?然后shuffle到?reduce節(jié)點階段生成結(jié)果。

MPP處理方法:?每個節(jié)點統(tǒng)計各自存儲的數(shù)據(jù)中各個類別總銷量,?匯總結(jié)果到leader?node,?leader做個合并,在這個案例里就是做幾次加法

可以看到在這個場景中MPP的效率絕對比MR高的多,?MPP的每個節(jié)點直接處理存儲在自身上的數(shù)據(jù)，而MR則有一個網(wǎng)絡(luò)分發(fā)的過程。

在實際應(yīng)用中的確MPP有更高的效率,?所以對于結(jié)構(gòu)化的大數(shù)據(jù), MPP至今仍是首選.?

正如開頭所說，MR的意義在于它是編程模型，相比MPP，它們能處理更加復(fù)雜的問題。

MR能自己開發(fā)Map、Reduce的代碼，不受SQL語法限制。相比于SQL屈指可數(shù)的幾個聚合函數(shù)（sum, avg, max, rank...），MR能隨心所欲地開發(fā)出各種處理數(shù)據(jù)的邏輯，把數(shù)據(jù)分布到不通的節(jié)點上去計算。

以下為轉(zhuǎn)載:

Shared Everything:一般是針對單個主機，完全透明共享CPU/MEMORY/IO，并行處理能力是最差的，典型的代表SQLServer

Shared Disk：各個處理單元使用自己的私有 CPU和Memory，共享磁盤系統(tǒng)。典型的代表Oracle Rac， 它是數(shù)據(jù)共享，可通過增加節(jié)點來提高并行處理的能力，擴展能力較好。其類似于SMP（對稱多處理）模式，但是當(dāng)存儲器接口達到飽和的時候，增加節(jié)點并不能獲得更高的性能?。

Shared Nothing：各個處理單元都有自己私有的CPU/內(nèi)存/硬盤等，不存在共享資源，類似于MPP（大規(guī)模并行處理）模式，各處理單元之間通過協(xié)議通信，并行處理和擴展能力更好。典型代表DB2 DPF和hadoop ，各節(jié)點相互獨立，各自處理自己的數(shù)據(jù)，處理后的結(jié)果可能向上層匯總或在節(jié)點間流轉(zhuǎn)。

我們常說的?Sharding 其實就是Share Nothing架構(gòu)，它是把某個表從物理存儲上被水平分割，并分配給多臺服務(wù)器（或多個實例），每臺服務(wù)器可以獨立工作，具備共同的schema，比如MySQL Proxy和Google的各種架構(gòu)，只需增加服務(wù)器數(shù)就可以增加處理能力和容量。

首先MPP 必須消除手工切分?jǐn)?shù)據(jù)的工作量。 這是MySQL 在互聯(lián)網(wǎng)應(yīng)用中的主要局限性。?
　　

另外MPP 的切分必須在任何時候都是平均的 ， 不然某些節(jié)點處理的時間就明顯多于另外一些節(jié)點。

對于工作負(fù)載是不是要平均分布有同種和異種之分，同種就是所有節(jié)點在數(shù)據(jù)裝載的時候都同時轉(zhuǎn)載，異種就是可以指定部分節(jié)點專門用來裝載數(shù)據(jù)（邏輯上的不 是物理上） ， 而其他所有節(jié)點用來負(fù)責(zé)查詢。 Aster Data 和Greenplum 都屬于這種。 兩者之間并沒有明顯的優(yōu)勢科研，同種的工作負(fù)載情況下，需要軟件提供商保證所有節(jié)點的負(fù)載是平衡的。 而異種的工作負(fù)載可以在你覺得數(shù)據(jù)裝載很慢的情況下手工指定更多節(jié)點裝載數(shù)據(jù) 。 區(qū)別其實就是自動化和手工控制，看個人喜好而已。?
　　?
　　

另外一個問題是查詢?nèi)绾伪怀跏蓟摹?比如要查詢銷售最好的10件商品，每個節(jié)點都要先計算出自己的最好的10件商品，然后向上匯總，匯總的過程，肯定有些節(jié)點做的工作比其他節(jié)點要多。

上面只是一個簡單的單表查詢，如果是兩個表的連接查詢，可能還會涉及到節(jié)點之間計算的中間過程如何傳遞的問題。 是將大表和小表都平均分布，然后節(jié)點計算的時候?qū)⒌玫降慕Y(jié)果匯總（可能要兩次匯總），還是將大表平均分布，小表的數(shù)據(jù)傳輸給每個節(jié)點，這樣匯總就只需要一 次。 （其中一個特例可以參考后面給出的Oracle Partition Wise Join） 。 兩種執(zhí)行計劃很難說誰好誰壞，數(shù)據(jù)量的大小可能會產(chǎn)生不同的影響。 有些特定的廠商專門對這種執(zhí)行計劃做過了優(yōu)化的，比如EMC Greenplum 和 HP Vertica 。 這其中涉及到很多取舍問題，比如數(shù)據(jù)分布模式，數(shù)據(jù)重新分布的成本，中間交換數(shù)據(jù)的網(wǎng)卡速度，儲存介質(zhì)讀寫的速度和數(shù)據(jù)量大小（計算過程一般都會用臨時表 儲存中間過程）。?

轉(zhuǎn)載部分的原文鏈接:

Shared Everything和share-nothing區(qū)別_seteor的專欄-CSDN博客

數(shù)據(jù)倉庫技術(shù)中的MPP_fengyuruhui123的博客-CSDN博客_mpp數(shù)據(jù)倉庫

下面這段描述了MPP(Azure Data Warehouse)中怎么把一張大表分布到各個節(jié)點上(Dedicated SQL pool (formerly SQL DW) architecture - Azure Synapse Analytics | Microsoft Docs):?

Hash-distributed tables(轉(zhuǎn)者注:?在可能經(jīng)常要filter或join的列上用hash來分布)

A hash distributed table can deliver the highest query performance for joins and aggregations on large tables.

To shard data into a hash-distributed table, SQL Data Warehouse uses a hash function to deterministically assign each row to one distribution. In the table definition, one of the columns is designated as the distribution column. The hash function uses the values in the distribution column to assign each row to a distribution.

The following diagram illustrates how a full (non-distributed table) gets stored as a hash-distributed table.

• Each row belongs to one distribution.
• A deterministic hash algorithm assigns each row to one distribution.
• The number of table rows per distribution varies as shown by the different sizes of tables.

There are performance considerations for the selection of a distribution column, such as distinctness, data skew, and the types of queries that run on the system.

Round-robin distributed tables (轉(zhuǎn)者注:?純隨機分布)

A round-robin table is the simplest table to create and delivers fast performance when used as a staging table for loads.

A round-robin distributed table distributes data evenly across the table but without any further optimization. A distribution is first chosen at random and then buffers of rows are assigned to distributions sequentially. It is quick to load data into a round-robin table, but query performance can often be better with hash distributed tables. Joins on round-robin tables require reshuffling data and this takes additional time.

Replicated Tables?(轉(zhuǎn)者注:?這就類似hadoop中的分布式緩存)

A replicated table provides the fastest query performance for small tables.

A table that is replicated caches a full copy of the table on each compute node. Consequently, replicating a table removes the need to transfer data among compute nodes before a join or aggregation. Replicated tables are best utilized with small tables. Extra storage is required and there are additional overheads that are incurred when writing data which make large tables impractical.

The following diagram shows a replicated table. For SQL Data Warehouse, the replicated table is cached on the first distribution on each compute node.

下面在這篇文章里對MR的解釋很好,?從原理的角度出發(fā),?map?reduce其實就是二分查找的一個逆過程,?不過因為計算節(jié)點有限,?所以map和reduce前都預(yù)先有一個分區(qū)的步驟.?二分查找要求數(shù)據(jù)是排序好的,?所以Map Reduce之間會有一個shuffle的過程對Map的結(jié)果排序. Reduce的輸入是排好序的.

大數(shù)據(jù)數(shù)據(jù)庫：MPP vs MapReduce_Dreamy_LIN的博客-CSDN博客_mpp數(shù)據(jù)庫

總結(jié)

以上是生活随笔為你收集整理的大数据Map Reduce 和 MPP数据库 的区别的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。