為什麼說HADOOP擴展性優於MPP架構的關係型資料庫？

01-06

在大數據基礎架構選型時，經常聽到的一個說法是——「如果數據規模在TB級可以選擇MPP架構的關係型資料庫，如果數據規模上升到PB級則應該選擇HADOOP」。但事實上MPP架構的關係型資料庫與HADOOP的理論基礎是極其相似的，都是將運算分布到節點中獨立運算後進行結果合併。區別僅僅在於前者跑的是SQL，後者則是MapReduce程序。這個影響因素會在數據規模上升到一定程度後帶來引起性能差距嗎？有相關的對比研究證明這一點嗎？如果沒有，為什麼很少看到大型企業選擇MPP架構的關係型數據作為大數據平台的成功案例呢？（印象中好像只有ebay使用emc的GP這一個案例）是否完全是出於構建成本的考慮？還請各路大神指點迷津。

這個事情很難說清楚，我只能嘗試說一下。

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）

謝邀！你的問題應該是很多大數據用戶的共性問題。

MPP不適合PB級（其實有部分MPP號稱支持PB級），是因為它確實處理不了那麼大的數據量，它的擴展性只能到百級別，再多節點性能也無法提高了，擴展性限制了MPP處理的數據量。

HADOOP和MPP都是基於分散式PC伺服器，都是多節點並行計算，但軟體層面是有差別的，這決定了它們擴展性上的差別，也決定了處理的數據規模的差別。越是依賴一個中心管理的方案，擴展性越差。MPP雖然share-nothing，但還是繼承了資料庫系統的複雜中心的基因，比如要優化join策略；而hadoop沒有那麼重的「包袱」。

事實上，hadoop的計算框架經歷了MRv1到MRv2（Yarn）的變化，MRv2的擴展性又比MRv1提高了，因為MRv1時的JobTracker同時兼備資源管理和作業控制兩個任務，成為系統的一個最大瓶頸，MRv2把資源管理和作業控制分離，作業控制是和應用程序直接相關的，每個作業有一個作業控制進程管理，而資源管理是全局的，每個作業控制進程像資管管理申請資源。MRv2的中心（資源管理）變輕了，擴展性就提高了。

hadoop和MPP的差別並不是跑的SQL還是MR，跑什麼只是形式，是用戶使用習慣，不是擴展性的根本。事實上現在有很多sql on hadoop的方案，比如hive。從大的意義上說，MPP現在也能從HDFS獲取數據了，也是廣義上的sql on hadoop。

MPP賣得還可以呀，看似沒有HADOOP成功案例多，是宣傳的問題。你想啊，誰會宣傳MPP，那只有MPP廠商，多少用戶會滿意度如此高給MPP做廣告呢；而HADOOP，現在是時尚啊，哪個公司稍微用點、解決點問題都恨不得向全世界宣告呢。

作為資料庫行業的老兵，之前在IBM DB2做過內核研發，現在在大數據行業做分散式資料庫SequoiaDB，我來說說對MPP資料庫與Hadoop之間擴展能力的理解。

從本質上來說，Hadoop（這裡特指HDFS作為分散式文件系統，與Spark+Yarn作為分散式執行）與MPP資料庫從通訊機制上來看沒有本質的不同。原則上來說，當應用模式完全一樣的情況下，經過精心設計的MPP資料庫表的擴展性也可以達到上千節點。

兩者之間最大的區別在於對數據管理理念的不同。HDFS/Hadoop對於數據管理的理念是粗放型管理，以一個文件系統的模式，讓用戶根據文件夾的層級，把文件一股腦塞到一個分散式文件系統的大池子裡面。而當用這些數據的時候，也是以批處理為主，所以每個機器上的文件基本都要從頭到尾掃描一遍，所以也不存在太多的物理模型設計與邏輯模型設計。

而資料庫的本質在於數據管理，需要對外提供在線訪問、增刪改查等一系列操作。這類型的任務如果還使用粗放型的管理，儘管功能上可以實現但是性能上就會差很多了。譬如說，如果我們想在一大堆數據裡面挑揀出符合某個條件的數據，在Hadoop裡面會比較粗暴：在所有的機器裡面把所有文件從頭到尾掃一遍。而使用資料庫可以根據分區信息首先落到某個機器里，然後可以根據多維分區甚至落到某個文件上，之後再文件裡面的索引數據頁上使用樹形結構查詢，很快就可以定位到記錄本身。能夠做到這一切的前提是，資料庫有一套很完善的數據管理和分布體系，因此查詢、操作、更新、插入會非常直觀高效。

但是，有得必有失，資料庫能夠做到高效的原因是把這些數據通過相對複雜的層級、分類、索引給管理起來，而Hadoop則通過完全放棄這些限制，獲得了極大的自由度，但是喪失了對數據的管控能力。

因此，Hadoop號稱擁有強大的擴展能力，支持上千節點，也是因為使用這種粗放型的管理方式，只要簡單地增加物理機就可以擴大hadoop的存儲空間。而對於資料庫來說，任何對於集群的改變都涉及到拓撲結構的變更，也可能會涉及到不同機器之間數據的遷移，因此當集群中機器數量多的時候，依然維護複雜的數據管理模型會造成維護成本大幅度上升。例如，在一個1000台機器的集群裡面增加100台機器，Hadoop可以簡單地添加100個機器即可，其他對於數據塊的遷移和平衡會在後台自動完成；而對於資料庫來說，添加100個機器如果需要涉及到數據重新平衡的話，需要對每個分區的記錄進行重新散列，並且將需要遷移的數據拷貝到目標機器。在這個過程當中，數據的一致性，事務的一致性等因素都需要考慮，因此其設計複雜度和維護難度要遠遠高於粗放的HDFS。

談Hadoop與MPP的擴展性的時候，需要具體分析一下，是什麼決定了擴展性？（這裡只談技術，不談產品）

實際上有以下幾個因素：

1. 數據同步機制：傳統通訊機制及Hadoop通訊機制，傳統通訊機制大家都比較熟悉了，同是基於socket的，基於傳統的同步或非同步通訊的，如coresync協議，能夠保證數據的強一致性。另外就是基於hadoop的zookeeper的，保證元數據的一致性的。傳統方式擴展性當然很低了，集群中每個節點都要管理同步信息，上規模後就會形成網路風暴。而zookeeper會建立單獨的機制去管理同步數據（專門的去做專門的事情），自然擴展性就會非常高。但是現在技術分類界限越來越模糊，某些MPP資料庫現在已經引入了zookeeper技術，因此擴展性也可以擴展到上千節點，數據量可以達幾個PB。

2. 數據模型：MPP資料庫屬於關係型資料庫，一個完整的關係模型分散到多台物理節點上去做管理，因此對於DML操作、強事務型操作，MPP資料庫壓力很大，規模上來以後，DML操作的性能基本無法接受，而對於DQL操作，就沒有太大影響，因為數據相對不動，因此無修改數據，對於數據模型的維護來講，成本非常小。所以說，對於MPP分析類的資料庫（只查詢），擴展性影響不大。而相反，事務型MPP資料庫，擴展性就很差了。Hadoop是非關係型資料庫，不涉及太多的數據模型維護工作，因此擴展性很高。
以上，總體上來說，如果對比Hadoop與MPP資料庫的擴展性，還是需要提前限定一定的條件的。

大家在架構層面說的比較多，但是有一點大家沒有過多提及，就是性能和應用場景。選擇GPDB的人很多的時候是因為需要使用類SQL的場景，在這樣的場景前提下hadoop就很麻煩，雖然hive的上層可以幫助解決一部分問題，但是性能和複雜度都不夠，也就是說在這樣的場景下，我個人認為以GPDB為代表的MPP是有很大優勢的，而且從性能看這種場景下的複雜sql查詢和計算，量級在PB上的不是很多。

最新的blog:Apache HAWQ: Next Step In Massively Parallel Processing

其中很犀利點出GPDB的痛點，磁碟故障引起的節點性能下降和並發限制，這是目前GP繞不過去的坎，但是hawq很聰明取了hadoop和mpp的各自優點，我看好hawq的架構設計，只是目前缺少大量的實際真實案例來支撐它，相信過不了幾年（如果持續發展的話），hawq會更好，我對hadoop架構優於mpp架構保留意見，我的意見是兩種會融合，類似hawq就是很好的例子，你說它是hadoop架構還是mpp架構？我堅信這種融合架構會變得越來越就好。

個人淺薄愚見。

本人很幸運兩者都接觸過，所以解答一下希望能幫助你，有什麼不對的地方還請指出。

一般大型銀行和互聯網機構的數據量很容易達到PB級別，而這兩類機構用到的恰恰是題主說到的Hadoop框架和MPP框架，在國內用的比較多的MPP框架就是EMC（前不久被DELL收購了好傷心啊）公司的greenplum分散式資料庫，首先說明這兩類架構都是非常優秀的分散式數據架構，當然互聯網公司用的比較多的是Hadoop而金融機構用的多的是greenplum，至於為什麼他們這麼選後面一一道來，我先說說兩者的區別，以及為什麼greenplum能實現PB級的運算，Hadoop的mapreduce擅長於批量運算，HDFS會把很大的數據塊分割成64MB或者128MB的文件塊分發給不同的數據節點運算，也就是分而治之的辦法，具體過程上面的大神都說過了，我就不再細說了，但MPP架構說的比較少我就以greenplum為例說一下它的原理：greenplum最早是一家獨立的分散式資料庫公司，當然它的底層不是原創的，其實greenplum就是一堆postgresql堆積起來的，postgresql是加州大學伯克利分校開發的一種關係型資料庫，也是很NB的，不過它並不是為分散式而創建的只是greenplum這個中把開源的postgresql拿過來用的，正所謂站在巨人的肩膀上。greenplum主要有master控制節點和segment數據節點組成當然中還有網路層，master的功能很簡單就是接受查詢命令，生成查詢計劃，給segment節點分發查詢計劃然後就等著接受segment的結果就好了，這個過程很想Hadoop的namenode和datanode的功能，不過兩者有個區別就是master是客戶端連接segment的唯一通道，它不能繞開master直接連接segment，而Hadoop中客戶端是可以直接連接datanode得的。所以他們的原理很相似就是解決了傳統資料庫最大的問題I/0讀取的瓶頸，至於greenplum為什麼能實現PB級計算啦，就在於它的master只是控制功能沒有任何計算功能，所以它不會成為整個系統的瓶頸，所以理論上來說你增加segment計算節點的數量可以實現計算能力的指數增長，而且有個問題，一般greenplum會和EMC的硬體捆綁銷售（大家不用懷疑EMC在高端存儲上的性能，IBM跟他比也是小弟弟），所以它是在大型計算伺服器上運行的，這個比Hadoop在普通機上運行更穩定更強，當然你要不差錢，在實際應用中只要伺服器數量夠，greenplum在特有的GPload載入的那速度可是杠杠的，絕對秒殺一眾oracle、mysql，這兒沒有黑它們的意思，畢竟greenplum是專業的數據倉庫工具，強調的就是載入讀取性能。而對於兩者的選擇，一般銀行會選擇greenplum作為數據倉庫的環境，而互聯網會選擇Hadoop，為什麼啦，簡單說就是不差錢、和直接責任人，第一，不差錢，greenplum單純的軟體EMC甚至可以直接送給你而且還包安裝噢，前提是你得買它的存儲伺服器，大家有興趣可以搜搜這家公司，他們做的高端存儲基本壟斷國內各大銀行，就一個字貴，但是它穩定，國內的浪潮做的也挺好，但是跟它比還是差了一大截，銀行系統是對穩定性要求最高的機構，你不能像Hadoop一樣隔三差五的就給我打版本，而且版本各種bug，其次就是銀行不用開源的原因是出了問題找不到責任人啊，這個問題大家可以參考宇宙第一大行前年發生的宕機時間，IBM就背黑鍋了。先寫這些吧。

個人沒有這方面的經驗。但是我覺得吧，傳統的資料庫產生的時代，數據量遠遠沒有現在這麼大。

大量數據存入磁碟，大量數據讀出的時候，自然就慢了。只有多節點協同才能提供高並發性。

擴展性依賴於數據的切分及存儲方式，依賴於計算的劃分方式。

從數據來說，Hadoop中數據直接存放在HDFS，數據按塊切分，存儲也不和節點綁定，因此擴展很容易。而MPP資料庫數據一般hash切分，並且切分之後的數據和節點綁定，因此擴展節點必須rehash，擴展性相對較差。

從計算來說，你說的hadoop應該指得是MR這類計算，計算都很容易切分成小的單元，也容易把計算放到切分好的數據上。MPP資料庫要進行關係運算，因此是對關係運算運算元的切分，運算過程中，會涉及到大量數據的移動，比如join計算，一般都需要rehash，因此擴展性相對較差。

PS，HBase和MPP資料庫對比更接近些。

hadoop 和 mpp 的本質區別是：什麼時候解決 data locality的問題

hadoop 的思路是每次計算的時候解決，mpp的思路是載入的時候解決。

理解了這個概念就理解為啥hadoop 擴展容易了。

另外沃爾瑪和ebay都有幾千節點的teradata 集群，數據量早就過pb了

題主說的HADOOP擴展性優於MPP應該是指分析類應用，而不是OLTP類應用。

我理解對於分析類查詢，MPP擴展性弱於HADOOP有兩點原因

（1）從存儲引擎看，傳統的MPP資料庫不支持數據動態擴容，即在增加數據節點，數據重分布的過程中，需要對被擴容表加ddl鎖，禁止讀寫。典型如GreenPlum資料庫http://greenplum.org/docs/admin_guide/expand/expand-redistribute.html

這對於PB級別的數據，是無法接受的。

（2）從查詢引擎看，由於資料庫支持索引，查詢性能應該優於HADOOP。但是對於PB級別的數據，無法給所有維度的查詢建立索引，主要靠全表掃描。因此對於複雜查詢，MPP並不比HADOOP特別是現在的SPARK方案體現出優勢，而且架不住Hadoop集群機器多。

當然，MPP資料庫也在發展中，主要互聯網大廠的MPP（MySQL和PostgreSQL）都提供了動態擴容，比如基於GreenPlum的阿里雲HybridDB。

樓上說的已經很到位了，歸根結底還是對數據的理念不同。兩者的目標不同，當然功能也就有所差異。Hadoop 是粗放式管理，每次查詢都是粗暴的全行掃描。

另外MPP 資料庫，比如Teradata/Netezza，還是有很多大企業用的。尤其是對於查詢、分析需求比較多的場景。從個人經歷來看，Hadoop 作為底層數據存儲，ETL後放入Teradata 供分析師使用是比較常見的情景。