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 產品BigInsights產品下線的報道。

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

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

是怎么了呢?

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

2. 常見幾種數據技術比較

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

Volume： 數據量夠大
Velocity: 數據訪問并發夠高，夠實時
Variety： 數據的類型多

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

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

下面我們來解讀一下各種數據庫的得分原因。

3. 關系型數據庫

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

單機架構限制，處理數據量有限, 通常在小幾個TB以下(得分2)
受事務之累，并發不高，但是通常是毫秒級響應(得分3)
嚴謹的關系模型，無法處理非結構化數據(得分1)
事務性強，無與倫比(得分5)

4. MPP 數倉

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

圖片來源： Gregory Kesden

MPP理論上是可以無限橫向擴展的，但是實際上由于控制節點或協調節點的原因，往往很難超出一百左右的節點數量。所以VOLUME得分為4分而不是滿分。MPP系統上主要運行的是分析型的應用場景，并發數往往較低，是為多節點并行分析能力而不是高并發能力優化的，因此VELOCITY上得分為2分。MPP大致也是基于關系模型的，對非結構化數據的處理上和RDBMS基本一樣無能為力，因此得分為1。

5. Hadoop

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

Hadoop的打分情況：

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

6. NoSQL數據庫

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

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

7. Hadoop：局限于大數據分析場景

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

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

但是企業今天對數據的需求，何止是分析型一種?

8. NoSQL： 操作型大數據之首選

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

操作型大數據的兩大關鍵技術需求：數據量大，響應迅速及時。

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

9. MongoDB vs. HBase

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

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

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

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

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

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

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

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

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

10. 后Hadoop時代： 數據即服務

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

匯聚來自各個獨立隔離系統的客戶、行銷、生產等數據，提供360度統一視圖
海量的性能擴展來應付日益增加的數據量及業務需求
提供秒級數據API 服務來驅動實時面板和快速應用開發
大規模減少ETL流程，降低成本

這種方案應該充分企業已經投入的Hadoop體系架構，但是在此之上鋪設一個以低延遲高并發支持靈活API為特色的DaaS(Data as a Service)數據即服務層。

數據即服務就是一種操作型大數據平臺的具體體現。這種基于MongoDB的架構的優勢在于：

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

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

降低的成本：數百萬歐元的Coherence及Oracle商業授權的節省
簡化的技術棧：一套方案已經支持了數十個數據應用
開發加速：新應用上線時間從12個月到數個星期

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

11. 結語

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

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