架構對比
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 老方發表，轉載請註明來源和作者。