標題：後 Hadoop 時代的大資料技術思考：資料即服務

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%以上的Hadoop部署未能天線的業務價值…”

Hadoop大資料是怎麼了呢？

我們從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驗證，最終確定合適的方案。

宣告：作者為MongoDB從業人員，雖然文章儘可能從技術的角度探討問題，難免有偏頗之處。

作者：唐建法，MongoDB官方首席架構師，Mongoing中文社群聯合發起人。返回搜狐，檢視更多

責任編輯：