您當前位置：首頁 > 互聯(lián)網(wǎng) > 將宕機時間縮減到5分鐘，F(xiàn)acebook揭露下一代數(shù)據(jù)存儲

將宕機時間縮減到5分鐘，F(xiàn)acebook揭露下一代數(shù)據(jù)存儲

來源：程序員人生發(fā)布時間：2014-09-10 00:38:19 閱讀次數(shù)：2349次

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

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

CSDN作為國內(nèi)最專業(yè)的云計算服務(wù)平臺，提供云計算、大數(shù)據(jù)、虛擬化、數(shù)據(jù)中心、OpenStack、CloudStack、Hadoop、Spark、機器學習、智能算法等相關(guān)云計算觀點，云計算技術(shù)，云計算平臺，云計算實踐，云計算產(chǎn)業(yè)資訊等服務(wù)。

以下為譯文

自2010年將SMS、chat、email及Facebook Messages整合到1個收件箱后，我們就開始使用HBase。自此之后，社交巨頭Facebook就一直擴展這個基于HDFS的分布式鍵值存儲系統(tǒng)以滿足自己的業(yè)務(wù)需求。基于其高寫入和低隨機讀取延時，那個時候HBase被選擇作為Messages平臺的潛在持久數(shù)據(jù)存儲系統(tǒng)。此外，HBase還具備一些其他優(yōu)點，比如縱向擴展、強一致性以及自動故障轉(zhuǎn)移帶來的高可用。從那時起，F(xiàn)acebook就開始重度使用HBase，比如Messages這樣的在線事務(wù)處理以及一些經(jīng)常用到在線分析的地方，當下HBase已用于內(nèi)部監(jiān)視系統(tǒng)、Nearby Friends功能、索引查詢、流數(shù)據(jù)分析以及為內(nèi)部數(shù)據(jù)倉庫抓取數(shù)據(jù)。

HBase可靠性

在Facebook通常會出現(xiàn)這樣一個情況，選擇一個潛在滿足需求的技術(shù)堆棧，然后不停的去優(yōu)化。對于Facebook來說，可靠性尤為重要，而當下我們使用HBase需求面臨的挑戰(zhàn)是單主機失敗、機架級故障以及密集存儲之間的細微差別。解決這些方法的途徑之一就是使用主從設(shè)置，在兩個集群之間做異步更新。然而，這樣做的話，我們需要面對集群級別的故障轉(zhuǎn)移，如此主從故障轉(zhuǎn)移將會花費數(shù)分鐘的時間，而異步操作毫無疑問會帶來數(shù)據(jù)丟失，HydraBase幫我們解決了這一問題。

HBase基礎(chǔ)

在了解HydraBase之前，首先解釋一些HBase的基礎(chǔ)概念。在HBase中，數(shù)據(jù)是物理共享的，也就是所說的regions。regions通過region服務(wù)器管理，每個region服務(wù)器會負責一個或以上的region。當數(shù)據(jù)被添加到HBase，它首先會被寫到一個write-ahead log（WAL），即HLog。一旦寫入，這個數(shù)據(jù)會被存儲到一個內(nèi)存MemStore中。一旦數(shù)據(jù)超過了某個閾值，它們就被持久化到磁盤。隨著MemStore持久化到磁盤的HFiles數(shù)量增多，HBase會將幾個小的文件合到一些大的文件中，來減少讀的開銷，這就是所謂的壓縮。

當某個region服務(wù)器發(fā)生故障，這個服務(wù)器負責的所有region都會轉(zhuǎn)移到另一個服務(wù)器，執(zhí)行故障轉(zhuǎn)移。鑒于HBase故障轉(zhuǎn)移中的實現(xiàn)方式，這將需要做WAL的分割和復制，這將大大的延長故障轉(zhuǎn)移的時間。

HydraBase相關(guān)

上文所說正是HydraBase與之最大的區(qū)別，取代region都只被單一的region服務(wù)器控制，在HydraBase中，每個region可以被一群region服務(wù)器控制。當某個region服務(wù)器發(fā)生故障，備用的region服務(wù)器會立刻接手服務(wù)它所控制的region，這些備用的region服務(wù)器可能橫跨不同的機架甚至是數(shù)據(jù)中心，通過不同的故障域來提供高可用。控制每個region的服務(wù)器會形成一個quorum，每個quorum都有1個負責region服務(wù)器來處理來自客戶端的讀和寫請求。HydraBase使用RAFT一致協(xié)議來保證跨quorum的一致性，每個quorum都使用2F+1，HydraBase可以承受F級故障。region server通過同步寫入WAL來保障一致性，但是只有一部分的region server需要完全的寫入來保證一致性。

quorum中的成員只存在active或witness兩個模式，active模式成員會寫入到HDFS，期間會執(zhí)行數(shù)據(jù)持久化和壓縮。witness成員只會參與復制WAL，但是在負責region服務(wù)器失敗時可以立刻使用。

HydraBase部署模型

HydraBase部署

在這個情況下，HydraBase的部署跨越了3個數(shù)據(jù)中心，quorum的大小為5。通過這樣的設(shè)置，負責region server可以轉(zhuǎn)移到該區(qū)域的任何一個成員。如果只是圖1中的Active Leader失敗，同一個數(shù)據(jù)中心的Witness Follower將取而代之，客戶端的請求將給它發(fā)送。如果丟失的是整個數(shù)據(jù)中心，見第二張圖，第二個數(shù)據(jù)中心的Active Follower會取而代之，鑒于數(shù)據(jù)中心2的region server仍然可以給HDFS中寫數(shù)據(jù)，因此即使是數(shù)據(jù)中心1不可見，數(shù)據(jù)仍然可以訪問。