最近在做一個數據倉庫遷移的項目，目前在前期階段，所以學習一下MPP架構的概念。
目前項目組想要替換掉的是Teradata所提供的一個MPP架構的數據倉庫，所以做數據倉庫遷移。遷移目標為南大通用所提供的GBASE。
對於MPP架構網上的資料較少，開源的有Greenplum這幾天在看。由於之前做大數據的時候一直是在做Hadoop那一套，所以想先看一下兩個架構的區別與聯系。
這兩種架構有區別又可以聯系在一起。但是本質的思想還是不同的，各有千秋吧。不能說哪一種更好用什么的。目前來看就是價格的因素，Teradata真的是太貴了，大型機構都有些受不了。
下面是找的一些材料：
材料1：
在最近的時間里，我聽到了很多關於該主題的討論。同樣，這是一個非常受歡迎的問題，是由在“大數據”領域經驗不足的客戶提出的。實際上，我不喜歡這個含糊不清的流行語，但這就是客戶通常會來找我們的原因，因此我必須使用它。
如果回頭看5年前，那是大多數公司都不選擇Hadoop的時候，尤其是對於那些要求穩定和成熟平台的企業而言。那時，選擇非常簡單：當分析數據庫的大小超過5-7 TB時，您只需啟動一個MPP遷移項目，然后遷移到一種成熟的企業MPP解決方案中。沒有人聽說過“ 非結構化 ”數據–如果您要分析日志，只需使用Perl / Python / Java / C ++對其進行分析並加載到分析DBMS中即可。沒人聽說過高速數據 –只需使用傳統的OLTP RDBMS進行頻繁的更新，然后將其分塊以插入到分析DWH中即可。
但是隨着時間的流逝，“大數據”這個流行詞開始在空中傳播，在大眾媒體和社交網絡中也開始流行。這是“ 大數據 ” 的google趨勢圖：
人們正在討論“ 三個V ”以及處理這些海量數據的方法。Hadoop已從利基技術發展成為一種用於數據處理的頂級工具，通過開始廣泛的Hadoop 實施或通過投資 Hadoop供應商之一，或通過 自己成為 Hadoop供應商。隨着Hadoop越來越流行，MPP數據庫開始下降。您可以以Teradata 股票為例，在過去三年中，它們一直在下跌，其主要原因是新參與者進入了他們的市場，而Hadoop是。
因此，新人提出的關於“我應該選擇MPP解決方案還是基於Hadoop的解決方案？”的問題變得非常流行。許多供應商都將Hadoop定位為傳統數據倉庫的替代品，這意味着這是MPP解決方案的替代品。當Hadoop和MPP彼此分開並集成到一個解決方案中時，其中一些在消息傳遞和推進Data Lake / Data Hub概念方面更為保守。
那么什么是MPP？MPP代表大規模並行處理，當網格的所有單獨節點都參與協調計算時，這是網格計算中的方法。MPP DBMS是基於此方法構建的數據庫管理系統。在這些系統中，您正在注視的每個查詢被分解為由MPP網格的節點並行執行的一組協調過程，從而以比傳統SMP RDBMS系統更快的速度運行計算。這種體系結構為您提供的另一個優勢是可伸縮性，因為您可以通過在網格中添加新節點來輕松擴展網格。為了能夠處理大量數據，這些解決方案中的數據通常按每個節點僅處理其本地數據的方式在節點之間拆分（分片）。這進一步加快了數據的處理速度，因為將共享存儲用於這種設計將是一個巨大的矯kill過正-更復雜，更昂貴，可伸縮性更低，網絡利用率更高，並行性更低。這就是為什么大多數MPP DBMS解決方案都是不共享的，並且不能在DAS存儲或在小型服務器組之間共享的一組存儲架上工作的原因。Teradata，Greenplum，Vertica，Netezza和其他類似解決方案都采用了這種方法。它們都具有專門為MPP解決方案開發的復雜而成熟的SQL優化器。所有這些都可以通過內置語言進行擴展，並且圍繞這些解決方案的工具集幾乎可以滿足任何客戶的需求，無論是地理空間分析，數據挖掘的全文本搜索。它們都是開源的復雜企業解決方案（但僅供參考，開源於 2015年第4季度），在該行業已經存在多年了，它們足夠穩定，可以運行用戶的關鍵任務工作負載。
Hadoop呢？這不是一項單獨的技術，而是一個相關項目的生態系統，它有其優點和缺點。最大的優點是可擴展性–出現了許多新組件（如一段時間前的Spark），並且它們與基礎Hadoop的核心技術保持集成，從而避免了鎖定並允許進一步擴展集群用例。作為一個缺點，我可以說一個事實，那就是，您自己要構建單獨技術的平台是一項艱巨的工作，並且現在還沒有人手動進行，大多數公司都在運行由Cloudera和Hortonworks。
Hadoop存儲技術基於完全不同的方法。它不是根據某種密鑰來分片數據，而是將數據分塊為固定大小（可配置）的塊，然后在節點之間進行拆分。這些塊很大，它們以及整個文件系統（HDFS）都是只讀的。簡而言之，將小的100行表加載到MPP中將使引擎根據表的鍵來分片數據，這樣，在足夠大的集群中，每個節點僅存儲一個節點的可能性就很大。行。相反，在HDFS中，整個小表將寫入單個塊中，該塊將表示為datanode的文件系統上的單個文件。
接下來，集群資源管理如何？與MPP設計相比，Hadoop資源管理器（YARN）為您提供了更細粒度的資源管理–與MPP相比，MapReduce作業不需要並行運行所有計算任務，因此您甚至可以處理大量的任務。如果完全利用了群集的其他部分，則在單個節點上運行的一組任務中的數據。它還具有一系列不錯的功能，例如可擴展性，對長壽命容器的支持等。但是實際上，它比MPP資源管理器慢，有時在管理並發性方面不那么好。
接下來是Hadoop的SQL接口。在這里，您有各種各樣的工具：它可能是Hive在MR / Tez / Spark 上運行，它可能是SparkSQL，它可能是Impala或HAWQ或IBM BigSQL，它可能與Splice Machine完全不同。您擁有廣泛的選擇，並且很容易迷失這種技術。
第一個選擇是Hive，它是將SQL查詢轉換為MR / Tez / Spark作業並在集群上執行的引擎。所有作業均基於相同的MapReduce概念構建，並為您提供了良好的群集利用率選項以及與其他Hadoop堆棧的良好集成。但是缺點也很大-執行查詢的延遲大，尤其是對於表聯接的性能較低，沒有查詢優化器（至少目前是這樣），因此即使是最糟糕的選擇，引擎也可以執行您要求的操作。這張圖片涵蓋了過時的MR1設計，但在我們的背景下並不重要：
諸如Impala和HAWQ之類的解決方案處於這一優勢的另一端，它們是Hadoop之上的MPP執行引擎，可處理HDFS中存儲的數據。與其他MPP引擎一樣，它們可以為您提供更低的延遲和更短的查詢處理時間，但代價是可伸縮性和穩定性較低。
SparkSQL是介於MapReduce和基於MPP-over-Hadoop的方法之間的另一種野獸，它試圖兼顧兩者，並有其自身的缺點。與MR相似，它將工作分解為一組單獨計划的任務，以提供更好的穩定性。與MPP一樣，它嘗試在執行階段之間流式傳輸數據以加快處理速度。它還使用MPP熟悉的固定執行程序概念（帶有impalad和HAWQ段）來減少查詢的延遲。但是它也結合了這些解決方案的缺點–速度不如MPP，不如MapReduce穩定和可擴展。
當我分別介紹所有技術時，在此表將所有內容匯總在一起：
有了所有這些信息，您就可以得出結論，為什么Hadoop不能完全替代傳統企業數據倉庫，而可以用作分布式處理大量數據並從數據中獲得重要見解的引擎。Facebook安裝了300PB Hadoop，但他們仍使用小型50TB Vertica群集，LinkedIn擁有龐大的Hadoop群集，仍使用Aster Data群集（Teradata購買的MPP），您可以繼續使用此列表。
材料2：
1. hadoop(hive)跟mpp的本質區別是什么，這個有的時候界限很模糊，比如說存儲，如果我把ｍｐｐ的存儲架在hdfs上，那存儲模型就沒有區別了，所以以下我打算還是用比較傳統的認知來作區別。
2. hive跟mpp的存儲模型不一樣，hive用的hdfs，而mpp需要自己做切分，自己做切分就帶來動態調整的問題，hdfs的擴展是通過元數據來做的，他有中心節點用來存元數據，在加入新的節點的時候，只需要修改元數據就可以了，所以hdfs的擴展能力是受到管理元數據那台機器的性能限制的，一般來說可以到10k這個規模，再向上就不行了。但是mpp通常采用的是沒有中心節點的存儲模型，比如hash，你每次增加節點的時候，都需要rehash，這樣當規模到了幾百台的時候，擴展能力就下來了。當然，現在可以把存儲架在hdfs上，這樣在存儲上就沒有太大區別了。
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）。
上述材料均來自知乎，想閱讀原文的小伙伴請到知乎去搜索。