大資料的辯論：HBase 將主導 NoSQL 嗎?

HBase既提供了可伸縮性，又提供了共用與Hadoop相同的基礎設施的經濟性,但它的缺陷是否把後腿扯下來了呢? NoSQL專家擺好了辯論架式。


　　HBase是仿照谷歌BigTable的，是世界上最受歡迎的大資料處理平臺Apache Hadoop的一部分。 但這一血統能否擔保HBase在充滿競爭和快速發展的NoSQL資料庫市場中定會擔當一個主導的角色呢?


　　MapR公司的Michael Hausenblas 認為Hadoop的受歡迎程度與HBase的可伸縮性和一致性可確保成功。 日益增長的HBase社區將超過其他開源運動,並會克服一些還需進一步研究的技術問題。


　　在開源專案Cassandra的幕後支援供應商DataStax工作的Jonathan Ellis認為HBase需要克服的缺陷太多，而且內含于Hadoop的HDFS架構。 他說這些缺陷將永遠限制HBase適用于高速工作負載的專案。


　　請閱讀我們的兩個NoSQL專家不同的意見,然後在下面評論部分用你的意見參加辯論。


　　正方


　　Michael Hausenblas


　　EMEA,MapR技術公司的首席資料工程師


　　與Hadoop整合將推動被接受


　　這個問題的答案是一個清澈的「是的,但是...」


　　為了領會這個回答,我們需要退後一步,從語境上理解問題。 Martin Fowler在2011年和Mike Stonebraker在2005年都拿著「通曉多種語言的持久化」認為「一種尺寸不能適用于一切」。


　　因此,我要解釋問題中的「主導」不是在過去十年裡應用於關係資料庫的市場份額措施意義上的,而是沿著「Apache HBase是否會被使用在更廣泛的情況中和有一個比其他NoSQL資料庫更大的社區的支援?」 的主線來討論（有點狡辯的意味）。


考慮到現在有超過 100 個不同的NoSQL方案可供選擇，包括MongoDB, Riak, Couchbase, Cassandra 和許多許多其它方案，上面的觀點可以說是一個大膽的推斷。 但是在大資料時代，潮流正從專業的資訊存儲轉向大規模的異構資料處理，所以即使像MongoDB這樣的流行方案也會被HBase趕超。


　　為什麼? MongoDB有著顯而易見的可擴充性方面的問題，隨著Hadoop使用率的快速增長，能直接和Hadoop整合的NoSQL方案將會在規模和流行度上有明顯的優勢。 HBase擁有一個龐大而多樣的社區，它連接著各個方面: 使用者，開發者，多個商業銷售商，雲端可用性等等，比如最後一點是通過 Amazon Web Services (AWS)實現的。


　　在發展歷史上，HBase和Cassandra有許多相似之處。 HBase 由Powerset公司創建于2007年(該公司不久被Microsoft收購)，一開始它是Hadoop的一部分隨後成為一個頂級專案。 Cassandra最早由Facebook在2007年發起，是開源的，隨後成為Apache的孵化專案，目前已經成為一個頂級專案。 HBase和Cassandra都是多列的key-value資料存儲庫，擅長於接受和提供大資料集，同時具有橫向可擴充性，魯棒性和靈活性。


　　它們的架構在設計哲學上是有差異的: Cassandra從Amazon's DynamoDB系統中借用了許多設計項目，有一個最終一致性的模型並且優化了寫操作，而HBase是Google BigTable的克隆版， 優化了讀操作並且有強一致性。 關於HBase優越性的一個有趣的證據論點是， 作為Cassandra建立者的Facebook，已經在其內部使用HBase替代了Cassandra。


　　從一個應用開發者的角度來看，HBase更好，因為它提供了強一致性，讓生活變得更容易。 關於最終一致性的一個錯誤理解是它提高了寫入速度: 假如有一個持續的寫操作的阻塞，影響了等待時間，而最後的結果是交了"最終一致性稅"卻沒有得到它的好處。


幾乎所有的NoSQL方案都有一些技術上的限制，比如壓縮對低延時性的影響，無法自動碎片化，可靠性問題，以及節點宕機時的長恢復週期等。 在MapR這裡，我們已經創建了一個"未來版"企業級HBase，它包括暫態恢復，無縫碎片化和高可用性，並且它摒棄了壓縮。 2013年5月我們把它納入到了標記為M7的GA版本中，同時通過AWS Elastic MapReduce，它也在雲端可用。


　　最後同樣重要的是，HBase擁有 -- 通過作為Hadoop的貢獻專案而得到的遺產 -- 一個強大而可靠的整合進整個Hadoop生態系統的方式，包括Apache Hive和Apache Pig。


　　概括起來講，在那些需要進行快速的小規模的更新和大規模的查詢的用例場景中，HBase 將會成為統治性的NoSQL平臺。 最近的改進也給HBase帶來了架構上的優勢，包括消除了壓縮並且提供了真正的分散協作。


　　Michael Hausenblas 是MapR Technologies公司EMEA大區的首席資料工程師。 他的工作背景是大規模資料整合的研究和開發，宣導和標準化。


　　反方


　　Jonathan Ellis


　　聯合創始人 & CTO,


　　DataStax


　　HBase 受到太多缺點的困擾


　　NoSQL包括了幾個特性，比如圖形資料庫和文檔存儲，這些都是HBase不具備的，而且即使在它所屬的分區行存儲這一類型中，HBase也落後于領跑者。 技術上的缺陷可以把HBase的失敗使用案例分為兩個主要類型: 一是工程問題，如果時間和人力充足，該問題可以處理，二是架構上的缺陷，這是設計層面固有的問題所以無法修復。


　　工程問題


--操作複雜，且容易發生故障。 HBase的部署需要配置的檔包括：最小Zookeeper集群，一級HMaster,二級 HMaster,RegionServers，活動NameNode，備用NameNode，HDFS管理，還有DataNodes。 儘管HBase可以被自動安裝，但是要是沒有説明就想成功安裝太難了，比如說RegionServers出現故障或者一個低級別NameNode出現故障了怎麼 辦？ HBase使用需要足夠多的專業知識甚至需要知道要監視什麼。 只用上帝才能説明你進行定期備份吧。


　　--RegionServer容錯移轉需要花費10到15分鐘的時間，HBase將分區形成區域，每個區域由RegionServer來進行管理。 RegionServer對於其管理的區域來說只允許單次故障。 當它發生故障時，就必須選擇一個新的區域伺服器，而且在新伺服器工作之前還得必須重新寫入之前伺服器的日誌。


　　-- 用HBase進行開發很痛苦。 HBase的 API很笨拙而且是以JAVA為中心的。 非JAVA用戶端被降級到第二級別的Thrift或REST入口。 與此相對的是Cassandra 查詢語言，它提供給開發者一個在所有語言中都熟悉的、富有成效開發體驗。


　　-- HBase社區是一盤散沙。 Apache的主線不穩定是廣為人知的。 Cloudera, Hortonworks,和高級使用者們都在頂層維護著他們自己的補丁樹。 領導權被拆分開了而且沒有清晰的發展路線圖。 相反的，開源的Cassandra社區的貢獻者來自包括DataStax、Netflix、Spotify、Blue Mountain Capital和其他組織，並且沒有派系或分支。


　　總體上，自從我關注NoSQL生態圈以來，HBase和其它NoSQL平臺在工程上的差距已經變大了。 在我第一次評估他們的時候，我就已經認定HBase在工程進度上落後于Cassandra6個月，但是今天這種落後已經擴大到2年左右。


　　架構上的缺陷


--面向Master的設計使得HBase的操作很不靈活。 通過RegionServer master來路由所有的讀和寫意味著HBase不可能在多個資料中心之間進行主動/主動結構的非同步複製，還意味著你不能把工作負載分給一個集群上的各個複製者。 相比之下，Cassandra的P2P複製允許在沒有ETL的情況下無縫地集成Hadoop,Solar和Cassandra，而且在你需要極少出現的線性一致性的情況下還允許你進行 羽量級交易處理。


　　--容錯移轉意味著停機。 許多應用無法接受甚至一分鐘的停機時間，然而這是HBase設計固有的問題；每一個RegionServer都是一個單節點故障。 而完全分散式設計意味著一個複製者停機，不需要任何特殊的動作就可以恢復；系統仍然與其他複製者一起正常的運轉，而且在以後可以把停機的複製者納入進來。


　　-- HDFS是主要為了以流的形式訪問大檔而設計的。 HBase建立在為批量分析而優化的分散式檔案系統之上。 這是HBase 低性能的直接原因，尤其對於讀取，而且 在固態硬碟上讀取更是如此。 就像關聯式資料庫不能優化30年前為准大資料工作負載而設計的B樹引擎一樣，HDFS也不能在主要目的和縮小關鍵功能上的差距之間不做權衡：


　　--在一個集群裡混合一般硬碟和固態硬碟，並把表固定在適合工作負載的介質上。


　　--快照、增量備份和時間點恢復。


　　--壓縮流量以避免應用回應時間的峰值。


　　--動態地路由請求到性能最佳的複製者上。


　　讓HBase的基礎HDFS更適合於批量分析那樣的設計將確保HBase仍天然地不適合于高速、隨機訪問的工作負載，而這些正是NoSQL市場所獨有的。


　　Jonathan Ellis是DataStax的CTO和聯合創始人，在DataStax他固定了技術方向並以專案領導人的身份領導著Apache Cassandra專案。