您當前位置：首頁 > 互聯網 > 將宕機時間縮減到5分鐘，Facebook揭露下一代數據存儲

將宕機時間縮減到5分鐘，Facebook揭露下一代數據存儲

來源：程序員人生發布時間：2014-09-10 00:38:19 閱讀次數：2352次

【編者按】作為社交巨頭，Facebook數據增長的速度可想而知，因此，在選擇了適合的技術后，他們還必須根據業務需求、數據增長情況等不停的優化，因此就有了之前的 WebScaleSQL。而本次我們要說的是該公司HBase內部衍生版本HydraBase，雖然并未開源，但是我們不妨從Facebook博文中一睹社交巨頭的設計理念。

免費訂閱“CSDN云計算”微信公眾號，實時掌握第一手云中消息！

CSDN作為國內最專業的云計算服務平臺，提供云計算、大數據、虛擬化、數據中心、OpenStack、CloudStack、Hadoop、Spark、機器學習、智能算法等相關云計算觀點，云計算技術，云計算平臺，云計算實踐，云計算產業資訊等服務。

以下為譯文

自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不可見，數據仍然可以訪問。