1. Hadoop 的神話正在破滅

IBM leads BigInsights for Hadoop out behind barn. Shots heard

IBM has announced the retirement of the basic plan for its data analytics software platform, BigInsights for Hadoop.

The basic plan of the service will be retired in a month, on December 7 of this year.

“IBM把BigInsights for Hadoop牽到牧棚后面，只聽一聲槍響…”

這個是前不久英國知名媒體The Register對IBM 產(chǎn)品BigInsights產(chǎn)品下線的報道。

BigInsights 是IBM在Apache Hadoop上增加了不少IBM分析技術(shù)能力后形成的一個大數(shù)據(jù)分析產(chǎn)品。 在面臨近乎2年的前途未卜的窘境之后，IBM終于決定將其關(guān)閉。

無獨有偶，前不久Gartner的一篇文章也指出 “70%以上的部署未能天線的業(yè)務(wù)價值…”

是怎么了呢?

我們從DBMS數(shù)據(jù)庫管理系統(tǒng)的角度，來剖析下常見產(chǎn)品的能力：RDBMS，MPP，Hadoop，NoSQL以及NewSQL。 這幾類產(chǎn)品對數(shù)據(jù)處理的能力各有什么樣的特點?

2. 常見幾種數(shù)據(jù)技術(shù)比較

我們首先試圖對這個被第一濫用的名詞來統(tǒng)一一下概念。按照Gartner的說法，大數(shù)據(jù)具備以下幾個特征(3個V)：

Volume： 數(shù)據(jù)量夠大
Velocity: 數(shù)據(jù)訪問并發(fā)夠高，夠?qū)崟r
Variety： 數(shù)據(jù)的類型多

從另一方面講，大數(shù)據(jù)也是數(shù)據(jù)，對常規(guī)數(shù)據(jù)的管理離不開我們熟悉的ACID事務(wù)性來保證對數(shù)據(jù)操作時候的原子性，一致性，隔離性和持久性。有了這個幾個衡量標準以后，我們可以來對上述幾個產(chǎn)品列表比較一下。

在這里根據(jù)4個維度給幾種流行的數(shù)據(jù)庫管理技術(shù)打分，以5分制為例，5分即最高分，表明具備最佳能力。1分為最低分，表明相對而言能力最弱。其實最近已經(jīng)有類似于TiDB或者CockroachDB的NewSQL產(chǎn)品出現(xiàn)，但是數(shù)據(jù)庫軟件是最為復(fù)雜的軟件之一， 因為它要滿足各種應(yīng)用的使用場景。如果歷史是面鏡子，那么最少還要3年左右這些NewSQL的表現(xiàn)才能被足夠的評測。所以這里我們暫時略過。

下面我們來解讀一下各種數(shù)據(jù)庫的得分原因。

3. 關(guān)系型數(shù)據(jù)庫

RDBMS全稱關(guān)系型數(shù)據(jù)庫(Relational Database Management System)是歷史最悠久的數(shù)據(jù)庫類型。關(guān)系型數(shù)據(jù)庫以O(shè)racle，SQLServer，MySQL，PostgreSQL等為代表，是我們最熟悉的數(shù)據(jù)庫。特點是：

單機架構(gòu)限制，處理數(shù)據(jù)量有限, 通常在小幾個TB以下(得分2)
受事務(wù)之累，并發(fā)不高，但是通常是毫秒級響應(yīng)(得分3)
嚴謹?shù)年P(guān)系模型，無法處理非結(jié)構(gòu)化數(shù)據(jù)(得分1)
事務(wù)性強，無與倫比(得分5)

4. MPP 數(shù)倉

MPP，全稱Massive Parallel Processing數(shù)據(jù)庫，通常被用來實現(xiàn)企業(yè)的數(shù)據(jù)倉庫和ODS等需求。MPP的產(chǎn)生主要是用來解決關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)量管理能力的問題。MPP數(shù)據(jù)庫通過把數(shù)據(jù)進行分區(qū)分片，并分布到各個橫向擴展節(jié)點，并由調(diào)度節(jié)點進行統(tǒng)一管理計算。每一次你執(zhí)行查詢的時候，該查詢會被分解為多個子查詢并交付給每一個計算節(jié)點去做并行的查詢。這個架構(gòu)可以通過增加節(jié)點的方式來擴展容量。數(shù)據(jù)在MPP系統(tǒng)里是分片的(Sharded), 每個節(jié)點會存取自己本地的一部分數(shù)據(jù)。這個較之共享存儲(如Oracle RAC)方案來說又有不少性能上的優(yōu)勢。因此大部分MPP系統(tǒng)，如Teradata，Greenplum，Vertica等都采用了這種shared nothing及DAS 直掛存儲的架構(gòu)。一般來說MPP系統(tǒng)都具備完備且成熟的SQL優(yōu)化器，支持主流的SQL標準，包括地理分析，全文檢索以及數(shù)據(jù)挖掘功能。除了GP之外，幾乎所有的MPP系統(tǒng)都是閉源系統(tǒng)，并且一般都是和昂貴、復(fù)雜這些詞聯(lián)系在一起的。

圖片來源： Gregory Kesden

MPP理論上是可以無限橫向擴展的，但是實際上由于控制節(jié)點或協(xié)調(diào)節(jié)點的原因，往往很難超出一百左右的節(jié)點數(shù)量。所以VOLUME得分為4分而不是滿分。MPP系統(tǒng)上主要運行的是分析型的應(yīng)用場景，并發(fā)數(shù)往往較低，是為多節(jié)點并行分析能力而不是高并發(fā)能力優(yōu)化的，因此VELOCITY上得分為2分。MPP大致也是基于關(guān)系模型的，對非結(jié)構(gòu)化數(shù)據(jù)的處理上和RDBMS基本一樣無能為力，因此得分為1。

5. Hadoop

下一個出場的是Hadoop，按時間順序來排的話。 Apache Hadoop是2007年發(fā)布的開源軟件。Hadoop是基于Google 公開的MapReduce和HDFS技術(shù)研發(fā)而成的。它的最偉大之處就是讓企業(yè)能夠以非常廉價的x86服務(wù)器把大量的數(shù)據(jù)管理起來。在那之前，機構(gòu)需要購買機器昂貴的企業(yè)級存儲設(shè)備來管理海量數(shù)據(jù)。就從這一點上，Hadoop技術(shù)已經(jīng)為企業(yè)帶來了很大的價值。這個確實是Hadoop的強處所在。然而，Hadoop的弱點也是一籮筐：安全，數(shù)據(jù)管理，查詢速度，復(fù)雜等等。10年的發(fā)展，很多這些地方都已經(jīng)有了比較不錯的解決，唯有這個數(shù)據(jù)查詢速度依然是很多Hadoop部署的痛中之痛。這個性能低下的原因，是和HDFS，Hadoop用來存儲文件的機制，HDFS，分不開的。HDFS不支持索引，舉個例子來說，你想要在詞典里找一個不認識的生僻詞的發(fā)音和釋義，為了找到這個生僻詞，你可能需要翻遍整本詞典，因為你無法使用拼音來檢索。在HDFS里面找內(nèi)容都是通過掃描(SCAN)的方式，也即是從頭讀到尾來找到你想要的數(shù)據(jù)。可以想象這種操作的性能如何。

Hadoop的打分情況：

基于x86廉價服務(wù)器及低端存儲海量擴展，輕松支持 TB/PB級數(shù)據(jù)量，VOLUME得分5分
HDFS文件存儲系統(tǒng)對所有格式的數(shù)據(jù)照單全收，在VARIETY上面也盡得高分5分。
性能方面Hadoop毫不客氣的占了倒數(shù)第一，但是并發(fā)接入能力還是okay，所以給2分
ACID事務(wù)性更是八桿子打不著，得1分。

6. NoSQL數(shù)據(jù)庫

NoSQL數(shù)據(jù)庫是一個爭議頗多的話題。首先是NoSQL陣營參差不齊，有以Redis為代表的KeyValue類型，專長于極短響應(yīng)時間及很高的單機并發(fā)能力，適合于緩存、用戶會話等場景。 有以寬表列族為模型的HBase、Cassandra，對IoT海量數(shù)據(jù)持續(xù)寫入場景有不錯支持，但是使用起來比較不友好。有以圖關(guān)系模型的Neo4J，專注于復(fù)雜關(guān)系搜索。ElasticSearch 則以搜索起家，在奠定了搜索市場后也視圖小覷數(shù)據(jù)庫的大蛋糕。而具有JSON文檔模型的MongoDB可以說是NoSQL里面的不折不扣的龍頭老大。JSON像XML一樣富有表達性，同時又不像XML那樣繁瑣，用過的程序員基本都說好。由于各種NoSQL數(shù)據(jù)庫差異太大，很難拿出一個抽象模型來代表NoSQL，我們下面就用DBEngines上面持續(xù)多年排名NoSQL第一的MongoDB來說事。

MongoDB 在很多方面和Hadoop有相似之處：都是基于x86的分布式數(shù)據(jù)庫，都是schema-on-read，支持結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)類型等等。以至于很多人都以為MongoDB就是和Hadoop一樣用來做大數(shù)據(jù)分析場景。事實上MongoDB的一貫定位都是OLTP數(shù)據(jù)庫，以聯(lián)機交易為主要適用場景，如IoT，CMS，Customer data，以及Mobile/Web等低延遲交互式應(yīng)用。MongoDB的擴展能力可以支持PB級別的數(shù)據(jù)量(百度云)以及每秒百萬+的混合讀寫并發(fā)處理能力(Adobe)。 正因為如此它在VOLUME、VELOCITY、及VARIETY上面都獲得了較高的得分(分別為4，5，5分)。它的短板就是事務(wù)性，ACID四項中，Atomicity 目前可以支持文檔級別的的原子性。一個文檔可以很復(fù)雜，但是針對單個文檔內(nèi)所有寫操作，包括子文檔，可以享受原子性的保證。MongoDB不支持多文檔或者多集合之間的原子性，但是由于文檔模型下多表操作已經(jīng)轉(zhuǎn)換成為單表操作，所以對多表原子性的需求已經(jīng)大大降低。Consistency一致性方面，MongoDB默認只使用主節(jié)點做讀和寫來保證數(shù)據(jù)的讀寫一致性。Isolation 上MongoDB支持到了第二級別：提交讀(Read Committed)。 Durability持久性反而是MongoDB的強項，一份數(shù)據(jù)會被準實時的同步到其他節(jié)點上，從而很大限度上保證了數(shù)據(jù)的不丟失性。所以在事務(wù)上給了MongoDB 2分。

7. Hadoop：局限于大數(shù)據(jù)分析場景

如果我們用一個雷達圖來表示各類數(shù)據(jù)庫的能力，我們可以直觀的看到各種技術(shù)的覆蓋面。面積越大，則表示可以適用的場景越多。

我們發(fā)現(xiàn)Hadoop其實覆蓋的面積并不是最大的，雖然大家之前都被教育過這個龐大的生態(tài)系統(tǒng)可以包治百病。現(xiàn)在我們可以開始理解一些為什么Gartner會說有70% Hadoop用戶感覺到并沒有獲得期望價值。Hadoop其實擅長的就是對海量數(shù)據(jù)的離線分析(Offline Analytical)，HDFS這個文件系統(tǒng)的設(shè)計就決定了這一點。這種技術(shù)特性適合用來做趨勢分析，用戶行為挖掘，機器學習，風險控制，歷史數(shù)據(jù)留存等一系列分析場景，用來輔助商業(yè)決策。

但是企業(yè)今天對數(shù)據(jù)的需求，何止是分析型一種?

8. NoSQL： 操作型大數(shù)據(jù)之首選

我們說大數(shù)據(jù)的價值體現(xiàn)方式有不僅僅是分析型，還有一種同樣重要的就是在線操作型(Online Operational)。 在線操作型(Online Operational)數(shù)據(jù)場景則是我們耳熟能詳?shù)钠髽I(yè)機構(gòu)日常生產(chǎn)的交易數(shù)據(jù)，如用戶，表單，訂單，庫存，客服，營銷等。這些數(shù)據(jù)使用的特點就是交互型，低響應(yīng)延遲。原來這些系統(tǒng)數(shù)據(jù)各自為營的時候普通關(guān)系型數(shù)據(jù)庫可以處理，但是在大數(shù)據(jù)時代當我們需要把這些操作型數(shù)據(jù)，甚至包括5年內(nèi)所有數(shù)據(jù)都要提供出來供用戶快速訪問的時候，或者當傳統(tǒng)大型企業(yè)突然要面向數(shù)百上千萬最終用戶的移動APP訪問需求的時候(如銀行業(yè)，航空業(yè)等)，這些就需要一個在線大數(shù)據(jù)解決方案來實現(xiàn)了。 而Hadoop大生態(tài)系統(tǒng)號稱是大數(shù)據(jù)問題大包大攬， 但是動到交互式查詢或者更新的時候就捉襟見肘了。Hive， Hbas， Impala等一系列解決方案也都未能有效解決對數(shù)據(jù)活用的迫切需求。

操作型大數(shù)據(jù)的兩大關(guān)鍵技術(shù)需求：數(shù)據(jù)量大，響應(yīng)迅速及時。

從這兩個維度可以看出，以MongoDB或者HBase之類的 NoSQL更加適合用來做操作型大數(shù)據(jù)平臺的場景。

9. MongoDB vs. HBase

事實上HBase正式作為一個NoSQL通常是Hadoop生態(tài)系統(tǒng)里用來支持操作型大數(shù)據(jù)的實時讀寫需求的。可惜HBase 是個扶不起的劉阿斗，跟著Hadoop的大旗沾了不少光，用起來問題一堆：

原生不支持二級索引，只能通過主鍵訪問。社區(qū)實現(xiàn)的二級索引功能支持和數(shù)據(jù)更新有時延，導致頭疼的一致性問題

寬表模型概念拗考，難于理解并且要求實現(xiàn)建模，不夠靈活
數(shù)據(jù)類型低級，只支持比特流，開發(fā)很不友好
支持程序語言種類少(Java,Thrift, RESTful API)
集群結(jié)構(gòu)復(fù)雜，有8種不同類型節(jié)點
無一致性快照功能
需要定時compact，對持續(xù)讀寫場景影響很大

因為這些原因，HBase只能在真的是超級大量數(shù)據(jù)的場景下才值得去忍受著種種不便去使用。

和HBase相比，MongoDB也有一些自己的不足：

多表事務(wù)還在研發(fā)中，導致對原子性要求較高需要回滾的時候只能通過變通手段來實現(xiàn)，增加了開發(fā)復(fù)雜度(所有NoSQL基本都不支持事務(wù))

常為讀性能優(yōu)化而鼓勵冗余，但是又不提供這些冗余數(shù)據(jù)變化時候的自動同步
但是MongoDB在取悅開發(fā)者，提高開發(fā)效率上可是做的淋漓盡致：

支持數(shù)十種程序語言
有最大的開發(fā)社區(qū)
JSON文檔模型是個程序員都懂，API式管理數(shù)據(jù)庫，非常自然
支持二級索引，關(guān)系型數(shù)據(jù)庫的復(fù)雜查詢基本都能支持
MEAN stack，全JS開發(fā)
無須ORM，減少服務(wù)層和持久化層的摩擦
動態(tài)模型，無須顯式建模，適合快速開發(fā)
傻瓜式水平擴展

正是這些原因，DBTA 2017年的“讀者最喜歡的數(shù)據(jù)庫”里面，MongoDB傲視群雄，奪得了桂冠。

10. 后Hadoop時代： 數(shù)據(jù)即服務(wù)

今天的企業(yè)在其數(shù)字化轉(zhuǎn)型、雙模IT及企業(yè)上云策略下，紛紛在重新審視企業(yè)的平臺級數(shù)據(jù)庫產(chǎn)品策略。企業(yè)已經(jīng)大手筆投入了大量的資源構(gòu)建基于Hadoop的數(shù)據(jù)湖，但是由于Hadoop本身特性所限，很多部署變成了 “數(shù)據(jù)垃圾堆”(Data Dump)，空有數(shù)據(jù)，但無法實現(xiàn)價值。企業(yè)真正需要的是一套在線操作型大數(shù)據(jù)解決方案可以滿足：

匯聚來自各個獨立隔離系統(tǒng)的客戶、行銷、生產(chǎn)等數(shù)據(jù)，提供360度統(tǒng)一視圖
海量的性能擴展來應(yīng)付日益增加的數(shù)據(jù)量及業(yè)務(wù)需求
提供秒級數(shù)據(jù)API 服務(wù)來驅(qū)動實時面板和快速應(yīng)用開發(fā)
大規(guī)模減少ETL流程，降低成本

這種方案應(yīng)該充分企業(yè)已經(jīng)投入的Hadoop體系架構(gòu)，但是在此之上鋪設(shè)一個以低延遲高并發(fā)支持靈活A(yù)PI為特色的DaaS(Data as a Service)數(shù)據(jù)即服務(wù)層。

數(shù)據(jù)即服務(wù)就是一種操作型大數(shù)據(jù)平臺的具體體現(xiàn)。這種基于MongoDB的架構(gòu)的優(yōu)勢在于：

除上述之外，基于分片機制的自動擴容的機制更可以支持數(shù)以百TB級的業(yè)務(wù)數(shù)據(jù)量;異構(gòu)數(shù)據(jù)庫實時同步工具可以把來自于數(shù)十個業(yè)務(wù)系統(tǒng)庫內(nèi)的數(shù)據(jù)同步到數(shù)據(jù)服務(wù)層，并提供秒級的數(shù)據(jù)一致;在同步過程中實現(xiàn)數(shù)據(jù)模型轉(zhuǎn)換，快速搭建服務(wù);批量方式或者連接器方式直接接受來自Hadoop集群的分析結(jié)果，如個性化標簽及推薦信息等，提高Hadoop的可操作性 等等優(yōu)勢。

RBS銀行在2015年就開始實施了這樣的DaaS架構(gòu)，短短兩年時間，RBS聲稱已經(jīng)獲得了以下的價值：

降低的成本：數(shù)百萬歐元的Coherence及Oracle商業(yè)授權(quán)的節(jié)省
簡化的技術(shù)棧：一套方案已經(jīng)支持了數(shù)十個數(shù)據(jù)應(yīng)用
開發(fā)加速：新應(yīng)用上線時間從12個月到數(shù)個星期

與此類似的成功案例還有巴克萊銀行，Vodafone電信公司等，均是在其數(shù)字化轉(zhuǎn)型中經(jīng)過審慎評估，選擇了操作性強，易用性高，分布式能力可靠的MongoDB作為其新一代數(shù)據(jù)服務(wù)平臺。

11. 結(jié)語

每一種技術(shù)都有它的應(yīng)用場景，在這篇文章里我們想要討論的是一種操作型大數(shù)據(jù)解決方案，所以我們花了不少筆墨在NoSQL并認為MongoDB是一個非常不錯的選擇。NewSQL或許會是一個潛在的選擇，如果不是因為現(xiàn)在它還沒發(fā)展成熟。況且，NewSQL對半結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)的需求支持估計也還是無法很好滿足， 所以我們拭目以待。

最后，在做一個大型決策的時候，我們要充分考慮到企業(yè)對技術(shù)能力的需求，把需求列出來，然后對照數(shù)據(jù)產(chǎn)品各自的長短板，有理論有方法的進行選型，并對最后2-3個選擇進行POC驗證，最終確定合適的方案。