自2010年將SMS、chat、email及Facebook Messages整合到1個收件箱后，我們就開始使用HBase。自此之后，社交巨頭Facebook就一直擴展這個基于HDFS的分布式鍵值存儲系統以滿足自己的業務需求。基于其高寫入和低隨機讀取延時，那個時候HBase被選擇作為Messages平臺的潛在持久數據存儲系統。此外，HBase還具備一些其他優點，比如縱向擴展、強一致性以及自動故障轉移帶來的高可用。從那時起，Facebook就開始重度使用HBase，比如Messages這樣的在線事務處理以及一些經常用到在線分析的地方，當下HBase已用于內部監視系統、Nearby Friends功能、索引查詢、流數據分析以及為內部數據倉庫抓取數據。
HBase可靠性
在Facebook通常會出現這樣一個情況，選擇一個潛在滿足需求的技術堆棧，然后不停的去優化。對于Facebook來說，可靠性尤為重要，而當下我們使用HBase需求面臨的挑戰是單主機失敗、機架級故障以及密集存儲之間的細微差別。解決這些方法的途徑之一就是使用主從設置，在兩個集群之間做異步更新。然而，這樣做的話，我們需要面對集群級別的故障轉移，如此主從故障轉移將會花費數分鐘的時間，而異步操作毫無疑問會帶來數據丟失，HydraBase幫我們解決了這一問題。
HBase基礎
在了解HydraBase之前，首先解釋一些HBase的基礎概念。在HBase中，數據是物理共享的，也就是所說的regions。regions通過region服務器管理，每個region服務器會負責一個或以上的region。當數據被添加到HBase，它首先會被寫到一個write-ahead log（WAL），即HLog。一旦寫入，這個數據會被存儲到一個內存MemStore中。一旦數據超過了某個閾值，它們就被持久化到磁盤。隨著MemStore持久化到磁盤的HFiles數量增多，HBase會將幾個小的文件合到一些大的文件中，來減少讀的開銷，這就是所謂的壓縮。
當某個region服務器發生故障，這個服務器負責的所有region都會轉移到另一個服務器，執行故障轉移。鑒于HBase故障轉移中的實現方式，這將需要做WAL的分割和復制，這將大大的延長故障轉移的時間。
HydraBase相關
上文所說正是HydraBase與之最大的區別，取代region都只被單一的region服務器控制，在HydraBase中，每個region可以被一群region服務器控制。當某個region服務器發生故障，備用的region服務器會立刻接手服務它所控制的region，這些備用的region服務器可能橫跨不同的機架甚至是數據中心，通過不同的故障域來提供高可用。控制每個region的服務器會形成一個quorum，每個quorum都有1個負責region服務器來處理來自客戶端的讀和寫請求。HydraBase使用RAFT一致協議來保證跨quorum的一致性，每個quorum都使用2F+1，HydraBase可以承受F級故障。region server通過同步寫入WAL來保障一致性，但是只有一部分的region server需要完全的寫入來保證一致性。
quorum中的成員只存在active或witness兩個模式，active模式成員會寫入到HDFS，期間會執行數據持久化和壓縮。witness成員只會參與復制WAL，但是在負責region服務器失敗時可以立刻使用。
HydraBase部署模型
HydraBase部署
在這個情況下，HydraBase的部署跨越了3個數據中心，quorum的大小為5。通過這樣的設置，負責region server可以轉移到該區域的任何一個成員。如果只是圖1中的Active Leader失敗，同一個數據中心的Witness Follower將取而代之，客戶端的請求將給它發送。如果丟失的是整個數據中心，見第二張圖，第二個數據中心的Active Follower會取而代之，鑒于數據中心2的region server仍然可以給HDFS中寫數據，因此即使是數據中心1不可見，數據仍然可以訪問。
圖1
圖2
HydraBase的另一個好處是有效的解耦邏輯和物理備份，此外，因為不需要分割日志，故障轉移將會很快速的執行，HydraBase能將Facebook全年的宕機時間縮減到不到5分鐘。Facebook目前正在測試HydraBase，并計劃在生產集群中逐步開始部署。
京公網安備 11010502049343號