HBase和Cassandra的分布式架構深度對比

架構對比

HBase和Cassandra幾乎都是一個時候出現的，都是在2010年成為Apache的頂級項目，不過如果我們細品其内部機制，我們會發現其實兩者是完全不同的架構風格。

HBASE起源于Google BigTable，幾乎遵從了BigTable論文的大多數架構設計。Cassandra則是采納了BigTable的資料模型，同時吸收了Amazon Dynamo的分布式設計。

是以從存儲結構模型的微觀上看，HBASE和Cassandra在單點存儲資料的機理是類似的，但是從分布式架構的宏觀上看，兩者則大相徑庭。

因為兩者參考和遵從的分布式架構産品不同，前者BigTable，後者Dynamo，是以前者是中心化架構并滿足分布式CAP定理中的CP(分布式一緻性)，強調資料寫入的強一緻性；後者去中心化架構并滿足分布式CAP定理中的AP(分布式高可用)，适應資料在讀取過程中完成最終一緻性。

我們看到此處就首先會明白這兩個夥計從分布式架構上壓根走的不是一路，隻不過都從單點存儲模型上看起來很像，有日志追加(WAL VS CommitLog)，有記憶體寫入緩沖區(MemStore VS MemTable)，也都刷盤(flush)到LSM-Tree結構的持久化檔案(StoreFile VS SSTable File)，都用Bloomfilter和Row Index的組合模式進行行鍵的索引，它們也都是利用BigTable的資料模型結構實作高速的寫入和熱點資料的查找。

關鍵特性對比

有兩個關鍵特性區分了它們：

由内看結構： 在查詢方面Cassandra還支援二級索引，内置CQL(MySQL的SQL文法接近)，SSTable分層結構也側重定位與查找；但HBase沒有二級索引，隻強調列簇的行鍵scan，Region中的Store與HDFS密切配合，StoreFile中KV以順序排列，存儲強調整體的時間寫入順序。是以Cassandra就非常适合通過列字段為條件來查找，而HBase更擅長通過行掃描做列集分析。

本質原因在于Cassandra的資料是基于一緻性雜湊演算法，按照HASH範圍劃分，實作記錄根據哈希值在整個叢集節點的随機分布以及複本備援，那麼查找起來更适合在整個叢集中對任何記錄進行大範圍的定位和查詢，充分利用叢集的整體算力；

但是HBase是順序的寫入同一個Region，在資料量足夠大後再分裂，那麼HBase就不适合頻繁大範圍的對資料定位與查找，更适合按行鍵做順序掃描的集合分析。查詢主要展現在就近和熱點資料上的高性能。

由外看分布式： Cassandra的叢集去中心化主要利用一緻性哈希環機制實作資料的分布和擴容縮容的資料遷移，利用gossip協定在對等節點的網絡傳播下儲存叢集狀态一緻性，利用anti-entropy(反熵)機制實作資料讀取過程中節點之間的比對，保證資料一緻性，這些都是叢集在對等條件下基于機制而達成狀态上的共識，那麼Cassandra的這些特性，就使得叢集不能太大，太大就不好管理，也容易導緻網絡通訊過于密集。

不過Cassandra這種去中心化架構表現出來的優點就是叢集無單點故障隐患，叢集健壯性高，可用性極高，運維很省事。

HBASE以及所依賴的Hadoop HDFS都是基于中心化集中式管理，存在HMaster的叢集單點故障風險，是以一般HBASE的HMaster可以有一個或多個HA熱備，引入HA後的HBASE叢集依然很健壯，隻是必然引入更高的部署複雜度，底層依賴的HDFS NameNode HA在服務部署複雜性方面則更甚之。

不過無論是HBase的Region Server，還是HDFS DataNode作為被管理的資料節點，要比Cassandra的對等節點承載的功能要簡單得多，複雜的協調指揮問題都是由主節點服務來完成，資料節點通訊關系都是朝向主節點的被動處理，節點功能越簡單，風險會越小。

而不是Cassandra那樣，必須通過gossip協定的全網絡病毒式傳播狀态來保證叢集一緻性，還要通過anti-entropy(反熵)機制，進行節點副本資料的一緻性比對，每個節點承載的内容太多了，自然故障風險也會變得更大。是以，Hadoop HBase更适合去管理大規模的資料節點。

HBASE基于HMaster和ZooKeeper協調，實作表->列簇->Region在單點HRegionserver上做行級事務寫入，當Region切分與合并後，才會在多個HRegionserver節點上形成資料分布，是以HBase強調了寫入過程的一緻性，而且叢集中任何狀态變更過程，都會以保證一緻性為前提，(例如：region切分與合并過程緩慢的話，面向該Region的用戶端會感受到短暫的中斷)；

另外底層HFile檔案的存儲是建立在Hadoop HDFS之上，檔案的高可靠全部由HDFS代管，HBase所謂的Region遷移，并不存在實質上的檔案移動，僅僅是HDFS中繼資料的變化。是以HBASE更适合大規模資料形成的檔案在分布式環境中的管理，叢集可以做的足夠大。

但是Cassandra強調的是高可用，任何時候都要先照顧用戶端的感受，例如：hinted handoff機制會讓兄弟節點把面向故障節點的寫請求先接過來，總之以不能堵塞用戶端為優先，但這裡存在兄弟節點的單點故障風險。

适應場景對比

通過上面的描述，實際上我們可以分析出來，Cassandra更适合在資料大吞吐的情況下，借助資料分布優勢，高速寫入，并通過二級索引實作SQL文法豐富的字段級查找，以及支援線上應用實時産生的超大規模資料的存儲，可以在大規模資料寫入與查詢的都比較适合的場景下替代MySQL，在事務和一緻性要求不嚴格的環境下，為每天并發與寫入量驚人的線上業務系統，提供資料庫支撐。是以其面向服務的領域偏重oltp。

HBASE更适合管理着大規模叢集，并在超大規模資料之上進行實時的，結構化的海量資料支撐，而且滿足強一緻性要求，達到行級事務要求，可以使其對接一些關鍵性業務在可靠性要求高的環境下支撐線上實時分析，例如電子商務交易，金融交易等等。但并不适合随機性很強的查詢，更适合大吞吐的資料寫入，熱點資料的行級查找以及大規模的掃描分析。并且具有Hadoop生态的數倉工具支撐。是以HBASE更面向olap。

流行度對比

我們說完它們的大體架構對比分析，我們再看看國内外流行度。

我們可以看出在國内HBASE的流行度更高，但是國外則相反。

首先HBASE基于Hadoop，自然名聲響，但是其本質特征适合關鍵性資料的高可靠支撐，大規模叢集資料管理，以及Hadoop生态的結合，自然在大規模的結構化資料的實時與離線分析上數一數二的優勢，同時HBASE也在進化，對诟病已久的RIT(導緻region遷移緩慢問題)進行了根除，精簡zookeeper依賴，加強master中心管理，解決了過去很多導緻緩慢的根子問題，也更适合面向實時性分析業務。

這些特征就特别适合中國這個特别容易産生超大規模資料的地方，更适合大廠所面對的大規模使用者在關鍵性業務上産生的結構化資料，通過HBASE來支撐大吞吐的寫入，實時的線上分析以及資料可靠性方面的需求，并且大廠的工程師團隊也具備消化Hadoop平台複雜性的能力。

Cassandra架構是最終一緻性，去中心化，節點對等，元件更精簡，非常适合一個分布式資料庫的小型叢集的快速搭建，非常靈活，并不像HBASE搭建那麼複雜，但我認為在國内不好找到需求點，為什麼呢？

因為Cassandra的定位是線上事務應用的大規模資料支撐，無縫對接SQL文法，滿足大範圍的海量資料的快速查詢，同樣也适合實時性的流庫連接配接，但前提是在寫入資料方面，應該是弱一緻性的業務環境要求(盡管一緻性可調配置支援強一緻性ALL，但代價太高)。

這就比較尴尬，剛性業務不合适，日志型業務國内Elasticsearch才是熱門，MongoDB一樣提供了可調的分布式一緻性，支援的查詢語義更豐富，還支援關鍵性業務的分布式事務，而且在國内也更流行。

但是我相信随着大資料技術的不斷發展，國内工程師的不斷普及，Cassandra是有非常多的優點，面向分布式海量資料的查詢優化架構，尤其是去中心化帶來的叢集健壯性，對于一個運維團隊會非常省事，尤其是越來越多的物聯網項目和海量資料的搜尋需求，必将在中小型團隊中流行起來。

至于國外為什麼Cassandra更流行，沒太涉及過國外項目和團隊，不能貿然下結論。但我能看到和想到的客觀推理包括兩方面：

(1)中英文關于Cassandra技術資料的新鮮度差距很大，可研讀資料稀缺，我對Cassandra的技術研究也主要是基于英文。

(2)在強調分布式資料庫面向結構化海量資料的承載能力之外，HBASE更側重分析，Cassandra則勝于查詢，項目中往往資料查詢需求是遠高于資料分析需求，是以國外的熱度對比很正常，隻不過Cassandra在國内工程師的認識上尚未普及而已！

作者：西安守護石資訊科技CTO