來自兩位技術大牛的博弈：HBase或將制霸NoSQL？

　　眾所周知，對比傳統的關係型資料庫，NoSQL有著更為複雜的分類——鍵值、面向文件、列儲存、搜尋引擎等等。繁多的分類讓NoSQL有著更強的業務針對性，因此在效能上對比傳統關係型資料庫有著顛覆性的提升。然而這種針對性同樣給企業帶來了一定程度的困擾，比如專業工程師的培養/聘請、架構的變遷等，同時這種群雄割據的局面也不利於NoSQL的整體發展。通用、統一才能有更好的發展；隨著NoSQL的發展，我們似乎也越來越需要一種技術去開啟當下這個局面。

　　近日，MapR Technologies的首席資料工程師Michael Hausenblas與DataStax的聯合創始人兼CTO Jonathan Ellis針對這個問題展開了討論，並就“HBase是否能成為NoSQL領域的領導者”發表了不同的觀點。在看他們觀點之前，我們首先看一下為什麼會是HBase。

　　HBase及NoSQL現狀

　　HBase是Google BigTable的仿製品，當下最流行大資料處理平臺Apache Hadoop的一部分。高貴的血統無疑讓HBase備受關注，也給它帶來了更廣闊的發展空間。然則HBase的人氣究竟如何，我們不妨看一下 DB-Engines的資料庫人氣排行榜 ：

　　從最新的排行榜我們可以發現前10中只有一個NoSQL資料庫——MongoDB，而HBase排名第16，NoSQL領域第6，在列儲存資料庫中排名也只是第2，第1被Cassandra搶走。

　　上表是2013年1月份的部分排行，對比MongoDB、Cassandra這些人氣增長很快的資料庫，HBase的增長也並不突出。

　　如此看來即使HBase最後可以成為NoSQL領域的領軍者，這條成功路上也是遍地荊棘。長話短說，下面就看一下兩位資料領域佼佼者的不同看法，以下為譯文：

　　正方：Michael Hausenblas是MapR Technologies的首席資料工程師兼EMEA。在大規模資料整合研究和開發上有著豐富的經驗。他認為，基本上所有NoSQL解決方案都有著技術限制，而與Hadoop的整合將大幅度提高HBase的採用率。

　　HBase制霸將是個必然的結果，但是……

　　為了理解這個問題，我們必須和現狀集合起來。Martin Fowler及Mike Stonebraker都認為“混合持久化”才是王道，“同一個標準不可能適合所有人”。

　　因此這裡我說的制霸不是傳統資料庫過去10年內一直使用的市場份額的標準，而是“Apache HBase是不是擁有更廣泛的使用場景，以及是否比其它資料庫擁有一個更大的社群”。

　　我們可以大膽斷言的是：當下可供選擇的NoSQL技術已經超過100種（DB-Engines排行榜已收錄114個NoSQL資料庫），包括MongoDB、Riak、Couchbase、Cassandra等等。但是在這個大資料的時代，趨勢不再是專業的資訊持久化，而是大規模的多樣資料處理，因此即使是MongoDB如此流行的NoSQL也必將會被HBase超越。

　　為什麼？因為MongoDB有明顯的擴充套件性缺陷，而隨著Hadoop採用的快速增長，類似HBase這種內建的NoSQL解決方案在規模和人氣上都有著天生的市場優勢。HBase擁有不同方面巨大而多元化的社群，它連線著多個方面：使用者、開發者、多個商業供應商以及雲端的可用性——來自AWS最新的功能。

　　從兩個資料庫的歷史上看，HBase和Cassandra擁有很多相同之處。HBase於2007年在Powerset建立（後被微軟收購），開始是作為Hadoop的一部分，後來成為一個Top-Level-Project。Cassandra則是2007年起源於Facebook，開始是開源專案，後由Apache孵化，當下同樣是個Top-level-Project。不管是HBase還是Cassandra都是列儲存鍵值型別資料庫，都擁有良好的橫向可擴充套件性、健壯性和彈性，擅長處理巨大體積的資料。

　　但是他們在設計理念上卻有著天壤之別：Cassandra借鑑了許多Amazon DynamoDB系統的元素，使用最終一致模型，並且進行了寫入優化；而HBase克隆的是Google的BigTable，進行了讀取優化，並擁有強一致性。這裡HBase存在一個很有意思的強項就是——Facebook，Cassandra的製造者，使用HBase代替了Cassandra在他們內部使用。

　　從開發者角度上來看，HBase提供的強一致性會讓開發過程變得輕鬆。而這裡對於最終一致性存在的誤區就是：它改善的是寫入的速度——持續的寫操作可能會造成延遲，為了保持最終一致性付出了代價，卻沒有達到應有的效果。

　　基本上所有NoSQL解決方案都存在技術限制，比如會導致高延時的壓縮、無法自動分片、可靠性隱患以及節點故障轉移時間太長。而在MapR建立的企業版HBase中，我們提供了立即恢復、無縫分片以及高可用性，同時還剔除了壓縮。

　　最後，鑑於HBase與Hadoop生態系統的整合力度，它可以更好的與Hive、Pig等元件協作。

　　彙總，HBase必然制霸小規模寫入及大規模查詢的使用場景，而最近的一些創新提供的架構優勢也可以用於擺脫壓縮的困擾。

　　反方：Jonathan Ellis是初創公司DataStax的聯合創始人兼技術長，而DataStax是一家著名開源軟體公司。他認為HBase受眾多的缺陷困擾，比如：部署難、操作複雜、社群零散以及致命的架構缺陷。種種因素之下，HBase根本不具備成為領導者的資質。

　　NoSQL有著不同的專長，比如：某些領域HBase就無法與圖資料庫和文件資料庫匹敵；但是即使是列儲存資料庫中，HBase也不能獨佔鰲頭。導致HBase採用率一般的問題在於：可以通過投入巨量物理和人力解決的工程問題和無法彌補的天生架構缺陷。

　　工程問題

　　1.  運營的複雜並且容易發生故障

　　HBase的配置非常麻煩，最低的限度都需要包括Zookeeper ensemble、primary HMaster、secondary HMaster、RegionServers、active NameNode、standby NameNode、HDFS quorum journal manager及DataNodes。雖然配置可以自動化，但是如果無幫助下安裝難度太大，在故障發生時，你如何去尋找故障，比如：RegionServer失效或者一個 lower-level NameNode故障。使用HBase需求大量的專業知識——甚至是最簡單的監視；如果你需要定期的備份，那麼你可以去尋求上帝的幫助了！

　　2.  RegionServer故障轉移需要10到15分鐘

　　HBase將行分割到不同的region中，通過 RegionServer來管理。RegionServer存在單點故障，當它發生故障時，一個新的RegionServer必須被選舉出，而在可以投入之前，必須重新完成write-ahead日誌裡的內容。

　　3.  使用HBase開發是非常痛苦的。

　　HBase的API非常笨拙並且具有太強的Java特色，非Java客戶端只能委託給Thrit或者REST。對比起來，Cassandra Query Language則提供了多語言開發者都熟悉的體驗。

　　4.  HBase社群就是盤散沙

　　以Apache為主的社群是眾所周知的不穩定，Cloudera、Hortonworks以及其他高階使用者都是在閉門造車。相反開源的Cassandra社群各個機構間毫無派系，比如DataStax、Netflix, Spotify、Blue Mountain Capital等。

　　總的來說，HBase和其它NoSQL平臺間的差距越來越大。在我第一次評估的時候，HBase的工程進展可能會差Cassandra 6個月，而如今至少差2年。

　　架構缺陷

　　1.  Master-oriented的設計讓HBase失去了靈性

　　通過RegionServer master來路由所有讀寫操作意味著HBase喪失了資料中心的active/active非同步複製，你也不能在一個叢集的不同副本集中單獨的執行工作負載。想比之下，Cassandra的peer-to-peer複製卻允許與Hadoop的無縫整合，當你需求線性一致性，沒有ETL的Solr和Cassandra卻允許你少量使用輕量級事務。

　　2.  故障轉移意味著當機

　　許多應用甚至不能容忍1分鐘的當機，而這恰恰是HBase設計的固有問題，每個RegionServer都是個單點故障。然而一個分散式系統應該是在某個副本發生故障，我們不需要做特殊的恢復處理，系統仍然能正常運作。

　　3.  HDFS是主要為大體積檔案設計的流訪問系統

　　HBase建立於一個專為批處理優化的檔案系統，這直接導致了HBase的低效能。特別是讀取，尤其是使用SSD的情況。就像是30年前為準大資料負載設計、未優化B樹的傳統關係型資料庫引擎，HDFS並未做好主要設計目的與關鍵功能彌補上的平衡：

• 在同一個叢集中混合機械和固態硬碟，併為負載分配適當的硬碟型別
• 快照、增量備份和及時的恢復
• 壓縮流量以避免應用程式的峰值響應時間
• 動態的將請求路由到效能最高的副本上

　　HBase基於批處理的設計決定了它低下的效能，使其無法適應高速、隨機訪問負載，然而NoSQL運動的特性恰恰是這些，因此HBase永遠不可能制霸NoSQL領域。

　　英文來源： Big Data Debate: Will HBase Dominate NoSQL?