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牽到牧棚后面，只聽(tīng)一聲槍響…”

這個(gè)是前不久英國(guó)知名媒體The Register對(duì)IBM 產(chǎn)品BigInsights產(chǎn)品下線的報(bào)道。

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

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

是怎么了呢?

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

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

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

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

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

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

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

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

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

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

4. MPP 數(shù)倉(cāng)

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

圖片來(lái)源： Gregory Kesden

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

5. Hadoop

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

Hadoop的打分情況：

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

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

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

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

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

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

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

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

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

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

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

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

9. MongoDB vs. HBase

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

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

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

因?yàn)檫@些原因，HBase只能在真的是超級(jí)大量數(shù)據(jù)的場(chǎng)景下才值得去忍受著種種不便去使用。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11. 結(jié)語(yǔ)

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

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