原文鏈接：https://0x0fff.com/hadoop-vs-mpp/
最近，我聽到很多關(guān)于這個(gè)話題的討論。 同時(shí)，這是一個(gè)非常受歡迎的問題，客戶在“大數(shù)據(jù)”領(lǐng)域沒有太多的經(jīng)驗(yàn)。 事實(shí)上，我不喜歡這個(gè)模糊的流行詞，但這是客戶通常來找我們，所以我必須使用它。
如果我們回顧5年前會(huì)發(fā)現(xiàn)，那就是當(dāng)時(shí)Hadoop不是大多數(shù)公司的選擇，特別是那些要求穩(wěn)定和成熟的平臺(tái)的企業(yè)。 在這一刻，選擇非常簡單：當(dāng)您的分析數(shù)據(jù)庫的大小超過5-7 TB時(shí)，您只需啟動(dòng)MPP遷移項(xiàng)目，并轉(zhuǎn)移到經(jīng)過驗(yàn)證的企業(yè)MPP解決方案之一。 沒有人聽說過“非結(jié)構(gòu)化”數(shù)據(jù) - 如果你要分析日志，只需用Perl / Python / Java / C ++解析它們并加載到分析數(shù)據(jù)庫中。 沒有人聽說過高速數(shù)據(jù) - 只需使用傳統(tǒng)的OLTP RDBMS進(jìn)行頻繁更新，并將其塊插入到分析DWH(數(shù)據(jù)倉庫)中。
但是隨著時(shí)間的流轉(zhuǎn)，“大數(shù)據(jù)”的流行語開始被廣泛使用，也在大眾媒體和社交網(wǎng)絡(luò)中傳播。 以下是“大數(shù)據(jù)”這個(gè)詞的google趨勢(shì)圖：
人們正在討論“三V”(大數(shù)據(jù)的3個(gè)維度)和處理這些巨大數(shù)據(jù)的方法。 Hadoop已經(jīng)從利基技術(shù)發(fā)展成為數(shù)據(jù)處理的一流工具之一，越來越受到更多的大公司的投入研發(fā)，通過啟動(dòng)廣泛的Hadoop實(shí)現(xiàn)，或通過投資到其中一個(gè)Hadoop供應(yīng)商，或通過自己成為一個(gè)Hadoop供應(yīng)商。隨著Hadoop越來越受歡迎，MPP數(shù)據(jù)庫進(jìn)入他們的下降趨勢(shì)。您可以看看Teradata股票的例子，在過去的3年中，他們不斷下滑，其主要原因是新玩家進(jìn)入市場(chǎng)，而且是Hadoop。
所以關(guān)于“我是否應(yīng)該選擇MPP解決方案或基于Hadoop的解決方案？”的問題，新來者的問題正在變得非常受歡迎。許多供應(yīng)商正在將Hadoop定位為傳統(tǒng)數(shù)據(jù)倉庫的替代品，這意味著更換MPP解決方案。當(dāng)Hadoop和MPP彼此離開并且集成在一個(gè)單一的解決方案中時(shí)，其中一些在消息傳遞和推動(dòng)數(shù)據(jù)湖/數(shù)據(jù)中心概念方面更保守。
那么MPP是什么？ MPP代表大規(guī)模并行處理，這是網(wǎng)格計(jì)算中所有單獨(dú)節(jié)點(diǎn)參與協(xié)調(diào)計(jì)算的方法。 MPP DBMS是建立在這種方法之上的數(shù)據(jù)庫管理系統(tǒng)。在這些系統(tǒng)中，您正在凝視的每個(gè)查詢都會(huì)被分解為由MPP網(wǎng)格的節(jié)點(diǎn)并行執(zhí)行的一組協(xié)調(diào)進(jìn)程，它們的運(yùn)行時(shí)間比傳統(tǒng)的SMP RDBMS系統(tǒng)快得多。該架構(gòu)提供給您的另一個(gè)優(yōu)點(diǎn)是可擴(kuò)展性，因?yàn)槟梢酝ㄟ^向其中添加新節(jié)點(diǎn)輕松擴(kuò)展網(wǎng)格。為了能夠處理大量的數(shù)據(jù)，這些解決方案中的數(shù)據(jù)通常在每個(gè)節(jié)點(diǎn)只處理其本地?cái)?shù)據(jù)的方式在節(jié)點(diǎn)（分片）之間分割。這進(jìn)一步加快了數(shù)據(jù)的處理速度，因?yàn)闉檫@種設(shè)計(jì)使用共享存儲(chǔ)將是一個(gè)巨大的過度 - 更復(fù)雜，更昂貴，更少的可擴(kuò)展性，更高的網(wǎng)絡(luò)利用率，更少的并行性。這就是為什么大多數(shù)MPP DBMS解決方案是無共享的，并且可以在DAS存儲(chǔ)上或在小型服務(wù)器之間共享的一組存儲(chǔ)架上工作。這種方法被Teradata，Greenplum，Vertica，Netezza等類似解決方案所使用。所有這些都有專門為MPP解決方案開發(fā)的復(fù)雜而成熟的SQL優(yōu)化器。所有這些都是可擴(kuò)展的，內(nèi)置語言和這些解決方案的工具集支持幾乎任何客戶的愿望，無論是地理空間分析，數(shù)據(jù)挖掘的全文搜索。所有這些都是封閉源復(fù)雜的企業(yè)解決方案（但FYI，Greenplum將在2015年第四季度開放采購）在這個(gè)行業(yè)多年，它們足夠穩(wěn)定地運(yùn)行其用戶的關(guān)鍵任務(wù)工作負(fù)載。
Hadoop怎么樣？這不是一個(gè)單一的技術(shù)，它是相關(guān)項(xiàng)目的生態(tài)系統(tǒng)，它的優(yōu)缺點(diǎn)。最大的Pro是可擴(kuò)展性 - 許多新組件出現(xiàn)（像Spark之前一樣），并且它們與基礎(chǔ)Hadoop的核心技術(shù)保持集成，這阻止了您的鎖定，并允許進(jìn)一步擴(kuò)展集群用例。作為一個(gè)可以理解的事實(shí)，自己構(gòu)建一個(gè)單獨(dú)的技術(shù)的平臺(tái)是一個(gè)很多工作，現(xiàn)在沒有人手動(dòng)，大多數(shù)公司都在運(yùn)行像Cloudera提供的預(yù)建平臺(tái)， Hortonworks。
Hadoop存儲(chǔ)技術(shù)基于完全不同的方法。而不是基于某個(gè)鍵對(duì)數(shù)據(jù)進(jìn)行分片，它將數(shù)據(jù)塊分解為固定（可配置）大小的塊，并在節(jié)點(diǎn)之間分割數(shù)據(jù)。這些塊是大的，它們是只讀的以及整體文件系統(tǒng)（HDFS）。為了簡單起見，將小的100行表加載到MPP中將導(dǎo)致引擎根據(jù)表的密鑰來劃分?jǐn)?shù)據(jù)，這樣在一個(gè)足夠大的集群中，每個(gè)節(jié)點(diǎn)將只存儲(chǔ)一個(gè)行。相比之下，在HDFS中，整個(gè)小表將被寫入單個(gè)塊中，該塊將被表示為datanode文件系統(tǒng)上的單個(gè)文件。
接下來，集群資源管理呢？ 與MPP設(shè)計(jì)相反，Hadoop資源管理器（YARN）為您提供了更精細(xì)的資源管理 - 與MPP相比，MapReduce作業(yè)并不需要所有的計(jì)算任務(wù)并行運(yùn)行，因此您甚至可以處理大量的 如果集群的其他部分被完全利用，則在單個(gè)節(jié)點(diǎn)上運(yùn)行的一組任務(wù)中的數(shù)據(jù)。 它還具有一系列不錯(cuò)的功能，如可擴(kuò)展性，支持長容器等。 但實(shí)際上它比MPP資源管理器慢，有時(shí)管理并發(fā)性好。
接下來是Hadoop的SQL接口。 在這里，您可以選擇各種工具：可能是Hive在MR / Tez / Spark上運(yùn)行，它可能是SparkSQL，它可能是Impala或HAWQ或IBM BigSQL，它可能與Splice Machine完全不同。 您有廣泛的選擇，很容易迷失在這樣的技術(shù)中。
第一個(gè)選項(xiàng)是Hive，它是將SQL查詢轉(zhuǎn)換為MR / Tez / Spark作業(yè)并在集群上執(zhí)行它們的引擎。 所有的工作都建立在相同的MapReduce概念之上，并為您提供了良好的群集利用率選項(xiàng)，并與其他Hadoop堆棧進(jìn)行了良好的集成。 但是這些缺點(diǎn)也是很大的 - 執(zhí)行查詢的延遲很大，特別是對(duì)于表連接性能降低，沒有查詢優(yōu)化器（至少現(xiàn)在），所以引擎執(zhí)行你要求的內(nèi)容，即使是最差的選項(xiàng)。 這張照片涵蓋了過時(shí)的MR1設(shè)計(jì)，但在我們的上下文中并不重要：
像Impala和HAWQ這樣的解決方案位于這一優(yōu)勢(shì)的另一邊，它們是Hadoop之上的MPP執(zhí)行引擎，用于存儲(chǔ)在HDFS中的數(shù)據(jù)。 與其他MPP引擎一樣，它們可以為您提供更低的延遲和更少的處理時(shí)間，而且可以降低可擴(kuò)展性和較低的穩(wěn)定性。
SparkSQL是坐在MapReduce和MPP-over-Hadoop方法之間的不同的野獸，試圖獲得最好的兩個(gè)世界并有自己的缺點(diǎn)。 與MR類似，它將作業(yè)分成一組獨(dú)立安排的任務(wù)，提供更好的穩(wěn)定性。 像MPP一樣，它嘗試在執(zhí)行階段之間流式傳輸數(shù)據(jù)，以加快處理速度。 此外，它使用MPP（與其impalad和HAWQ段）熟悉的固定執(zhí)行器概念來減少查詢的延遲。 但它也結(jié)合了這些解決方案的缺點(diǎn) - 不如MPP那么快，而不是像MapReduce那樣穩(wěn)定和可擴(kuò)展。
當(dāng)我分開覆蓋所有的技術(shù)時(shí)，在這里把它放在一起：
比較項(xiàng)目 MPP Hadoop
平臺(tái)開放 封閉和專有。對(duì)于某些技術(shù), 通過互聯(lián)網(wǎng)免費(fèi)提供供應(yīng)商和社區(qū)資源的完全開源
甚至不能為非客戶下載文檔
可擴(kuò)展性 平均數(shù)十個(gè)節(jié)點(diǎn)，最大100-200 平均100個(gè)節(jié)點(diǎn)，可擴(kuò)展至幾千個(gè)節(jié)點(diǎn)
個(gè)節(jié)點(diǎn)
可處理數(shù)據(jù) 平均10TB,最大1PB 平均100TB, 多值1oPB
延遲 10-20毫秒 10-20秒
平均查詢時(shí)間 5-7 秒 10-15 分鐘
最大查詢時(shí)間 1-2小時(shí) 1-2周
查詢優(yōu)化 擁有復(fù)雜的企業(yè)級(jí)優(yōu)化器 沒有優(yōu)化器或優(yōu)化器功能非常有限，有時(shí)甚至優(yōu)化不是基于成本的
查詢調(diào)試和分析 便于查看的查詢執(zhí)行計(jì)劃、 OOM問題和Java堆轉(zhuǎn)儲(chǔ)分析，GC在群集組件上暫停，每個(gè)任務(wù)的單獨(dú)日志給你很多有趣的時(shí)間
查詢執(zhí)行統(tǒng)計(jì)信息
說明性錯(cuò)誤信息
技術(shù)價(jià)格 每個(gè)節(jié)點(diǎn)數(shù)十萬美元 每個(gè)節(jié)點(diǎn)免費(fèi)或高達(dá)數(shù)千美元
易用性 簡單友好的SQL界面和簡單可編譯 SQL不完全符合ANSI標(biāo)準(zhǔn)，用戶應(yīng)該關(guān)心執(zhí)行邏輯，底層數(shù)據(jù)布局。 函數(shù)通常需要用Java編寫，編譯并放在集群上
的數(shù)據(jù)庫內(nèi)功的數(shù)據(jù)庫內(nèi)置函數(shù)
目標(biāo)用戶 業(yè)務(wù)分析師 Java開發(fā)人員和經(jīng)驗(yàn)豐富的DBA
單作業(yè)冗余 低，當(dāng)MPP節(jié)點(diǎn)發(fā)生故障時(shí)作業(yè)失敗 高，作業(yè)只有當(dāng)節(jié)點(diǎn)管理作業(yè)執(zhí)行失敗時(shí)才會(huì)失敗
最小數(shù)據(jù)集 任意 GB
最大并發(fā)性 十到數(shù)百個(gè)查詢 多達(dá)10-20個(gè)job
技術(shù)可擴(kuò)展性 僅使用供應(yīng)商提供的工具 混搭
DBA技能等級(jí)要求 普通DBA 需要懂Java編程的高級(jí)RDBMSDBA
解決方案實(shí)施復(fù)雜性 一般 復(fù)雜
通過這些信息，您可以總結(jié)為什么Hadoop不能用作傳統(tǒng)企業(yè)數(shù)據(jù)倉庫的完全替代品，
但它可以用作以分布式方式處理大量數(shù)據(jù)并從數(shù)據(jù)中獲得重要見解的引擎。 Facebook
擁有一個(gè)300PB的Hadoop，并且仍然使用一個(gè)小型的50TB Vertica集群，LinkedIn
擁有一個(gè)巨大的Hadoop集群，并且仍然使用Aster Data集群（由Teradata購買的MPP），
您可以繼續(xù)使用此列表。
