架構對比
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 老方發表，轉載請注明來源和作者，
公眾號 "讀位元組" 大資料，分布式，容器技術，Linux的深度，專業解讀轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/308618.html
標籤：其他