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機制會讓兄弟節點把面向故障節點的寫請求先接過來，總之以不能堵塞客戶端為優先，但這裡存在兄弟節點的單點故障風險。
另外，去中心化架構幾乎默認都是利用HASH算法實現數據分佈的共識機制，但麻煩的問題在於數據管理，例如：遷移過程，必須誠實地進行物理層面的數據移動，這點是無法匹敵HBASE與HDFS的中心化架構組合，其底層機制是通過元數據對集群數據文件的邏輯操作，帶來數據管理的靈活性優勢。這也是中心化集中管理架構相對於去中心化共識架構最大的優勢所在。
適應場景對比
通過上面的描述，實際上我們可以分析出來，Cassandra更適合在數據大吞吐的情況下，藉助數據分佈優勢，高速寫入，並通過二級索引實現SQL語法豐富的字段級查找，以及支持在線應用實時產生的超大規模數據的存儲，可以在大規模數據寫入與查詢的都比較適合的場景下替代MySQL，在事務和一致性要求不嚴格的環境下，為每天並發與寫入量驚人的在線業務系統，提供數據庫支撐。因此其面向服務的領域偏重oltp。
HBASE更適合管理着大規模集群，並在超大規模數據之上進行實時的，結構化的海量數據支撐，而且滿足強一致性要求，達到行級事務要求，可以使其對接一些關鍵性業務在可靠性要求高的環境下支撐在線實時分析，例如電子商務交易，金融交易等等。但並不適合隨機性很強的查詢，更適合大吞吐的數據寫入，熱點數據的行級查找以及大規模的掃描分析。並且具有Hadoop生態的數倉工具支撐。因此HBASE更面向olap。
流行度分析
我們說完它們的大體架構對比分析，我們再回到問題上來，首先HBASE基於Hadoop，自然名聲響，但是其本質特徵適合關鍵性數據的高可靠支撐，大規模集群數據管理，以及Hadoop生態的結合，自然在大規模的結構化數據的實時與離線分析上數一數二的優勢，同時HBASE也在進化，對詬病已久的RIT(導致region遷移緩慢問題)進行了根除，精簡zookeeper依賴，加強master中心管理，解決了過去很多導致緩慢的根子問題，也更適合面向實時性分析業務。
這些特徵就特別適合中國這個特別容易產生超大規模數據的地方，更適合大廠所面對的大規模用戶在關鍵性業務上產生的結構化數據，通過HBASE來支撐大吞吐的寫入，實時的在線分析以及數據可靠性方面的需求，並且大廠的工程師團隊也具備消化Hadoop平台複雜性的能力。
Cassandra架構是最終一致性，去中心化，節點對等，組件更精簡，非常適合一個分佈式數據庫的小型集群的快速搭建，非常靈活，並不像HBASE搭建那麼複雜，但我認為在國內不好找到需求點，為什麼呢？
因為Cassandra的定位是在線事務應用的大規模數據支撐，無縫對接SQL語法，滿足大範圍的海量數據的快速查詢，同樣也適合實時性的流庫連接，但前提是在寫入數據方面，應該是弱一致性的業務環境要求(儘管一致性可調配置支持強一致性ALL，但代價太高)。
這就比較尷尬，剛性業務不合適，日誌型業務國內Elasticsearch才是熱門，MongoDB一樣提供了可調的分佈式一致性，支持的查詢語義更豐富，還支持關鍵性業務的分佈式事務，而且在國內也更流行。
但是我相信隨着大數據技術的不斷發展，國內工程師的不斷普及，Cassandra是有非常多的優點，面向分佈式海量數據的查詢優化架構，尤其是去中心化帶來的集群健壯性，對於一個運維團隊會非常省事，尤其是越來越多的物聯網項目和海量數據的搜索需求，必將在中小型團隊中流行起來。
至於國外為什麼Cassandra更流行，沒太涉及過國外項目和團隊，不能貿然下結論。但我能看到和想到的客觀推理包括兩方面：
- 中英文關於Cassandra技術資料的新鮮度差距很大，可研讀資料稀缺，我對Cassandra的技術研究也主要是基於英文。
- 在強調分佈式數據庫面向結構化海量數據的承載能力之外，HBASE更側重分析，Cassandra則勝於查詢，項目中往往數據查詢需求是遠高於數據分析需求，因此國外的熱度對比很正常，只不過Cassandra在國內工程師的認識上尚未普及而已！
本文由西安守護石信息科技的 CTO 老方發表，轉載請註明來源和作者。
