如果我們回顧5年前會發現，那就是當時Hadoop不是大多數公司的選擇，特別是那些要求穩定和成熟的平台的企業。 在這一刻，選擇非常簡單：當您的分析數據庫的大小超過5-7 TB時，您只需啟動MPP遷移項目，並轉移到經過驗證的企業MPP解決方案之一。
沒有人聽說過“非結構化”數據 - 如果你要分析日志，只需用Perl / Python / Java / C解析它們並加載到分析數據庫中。 沒有人聽說過高速數據 - 只需使用傳統的OLTP RDBMS進行頻繁更新，並將其塊插入到分析DWH(數據倉庫)中。
但是隨着時間的流轉，“大數據”的流行語開始被廣泛使用，也在大眾媒體和社交網絡中傳播。 以下是“大數據”這個詞的google趨勢圖：
人們正在討論“三V”(大數據的3個維度)和處理這些巨大數據的方法。Hadoop已經從利基技術發展成為數據處理的一流工具之一，越來越受到更多的大公司的投入研發，通過啟動廣泛的Hadoop實現，或通過投資到其中一個Hadoop供應商，或通過自己成為一個Hadoop供應商。隨着Hadoop越來越受歡迎，MPP數據庫進入他們的下降趨勢。您可以看看Teradata股票的例子，在過去的3年中，他們不斷下滑，其主要原因是新玩家進入市場，而且是Hadoop。
所以關於“我是否應該選擇MPP解決方案或基於Hadoop的解決方案？”的問題，新來者的問題正在變得非常受歡迎。許多供應商正在將Hadoop定位為傳統數據倉庫的替代品，這意味着更換MPP解決方案。當Hadoop和MPP彼此離開並且集成在一個單一的解決方案中時，其中一些在消息傳遞和推動數據湖/數據中心概念方面更保守。
那么MPP是什么？ MPP代表大規模並行處理，這是網格計算中所有單獨節點參與協調計算的方法。 MPP DBMS是建立在這種方法之上的數據庫管理系統。在這些系統中，您正在凝視的每個查詢都會被分解為由MPP網格的節點並行執行的一組協調進程，它們的運行時間比傳統的SMP RDBMS系統快得多。該架構提供給您的另一個優點是可擴展性，因為您可以通過向其中添加新節點輕松擴展網格。為了能夠處理大量的數據，這些解決方案中的數據通常在每個節點只處理其本地數據的方式在節點（分片）之間分割。這進一步加快了數據的處理速度，因為為這種設計使用共享存儲將是一個巨大的過度 - 更復雜，更昂貴，更少的可擴展性，更高的網絡利用率，更少的並行性。
這就是為什么大多數MPP_DBMS解決方案是無共享的，並且可以在DAS存儲上或在小型服務器之間共享的一組存儲架上工作。這種方法被Teradata，Greenplum，Vertica，Netezza等類似解決方案所使用。所有這些都有專門為MPP解決方案開發的復雜而成熟的SQL優化器。所有這些都是可擴展的，內置語言和這些解決方案的工具集支持幾乎任何客戶的願望，無論是地理空間分析，數據挖掘的全文搜索。所有這些都是封閉源復雜的企業解決方案（但FYI，Greenplum將在2015年第四季度開放采購）在這個行業多年，它們足夠穩定地運行其用戶的關鍵任務工作負載。
Hadoop怎么樣？這不是一個單一的技術，它是相關項目的生態系統，它的優缺點。最大的Pro是可擴展性 - 許多新組件出現（像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引擎一樣，它們可以為您提供更低的延遲和更少的處理時間，而且可以降低可擴展性和較低的穩定性。
Spark_SQL是坐在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，並且仍然使用一個小型的50TBVertica集群，LinkedIn擁有一個巨大的Hadoop集群，並且仍然使用Aster_Data集群（由Teradata購買的MPP）。