論文地址

Facebook的照片、視頻和其他需要可靠存儲和快速訪問的二進(jìn)制大型對象(BLOB)的語料庫非常龐大，而且還在繼續(xù)增長。隨著BLOB占用空間的增加，將它們存儲在我們傳統(tǒng)的存儲系統(tǒng)-- Haystack 中變得越來越低效。為了提高我們的存儲效率(以Blob的有效復(fù)制系數(shù)衡量)，我們檢查了Blob的底層訪問模式，并確定了包括頻繁訪問的熱Blob和訪問頻率低得多的熱Blob的溫度區(qū)域。我們的整體BLOB存儲系統(tǒng)旨在隔離暖BLOB，并使我們能夠使用專門的溫BLOB存儲系統(tǒng)f4。F4是一種新系統(tǒng)，它降低了warm的有效復(fù)制因子，同時(shí)保持了容錯(cuò)并能夠支持較低的吞吐量需求。

F4目前存儲超過65PB的邏輯Blob，并將其有效復(fù)制系數(shù)從3.6降至2.8或2.1。F4提供低延遲；對磁盤、主機(jī)、機(jī)架和數(shù)據(jù)中心故障具有恢復(fù)能力；并為熱BLOB提供足夠的吞吐量。

一、Introduction

隨著Facebook的發(fā)展，每個(gè)用戶共享的數(shù)據(jù)量也在增長，有效地存儲數(shù)據(jù)變得越來越重要。Facebook存儲的一類重要數(shù)據(jù)是二進(jìn)制大對象(BLOB)，它們是不可變的二進(jìn)制數(shù)據(jù)。Blob只創(chuàng)建一次，讀取多次，從不修改，有時(shí)還會被刪除。Facebook的BLOB類型包括照片、視頻、文檔、跟蹤、堆轉(zhuǎn)儲和源代碼。BLOB的存儲占用空間很大。截至2014年2月，F(xiàn)acebook存儲了超過4000億張照片。

Facebook最初的BLOB存儲系統(tǒng)Hystack[5]已經(jīng)投入生產(chǎn)超過7年，專為IO綁定的工作負(fù)載而設(shè)計(jì)。它將讀取BLOB的磁盤尋道次數(shù)減少到幾乎總是一次和三次復(fù)制數(shù)據(jù)，以實(shí)現(xiàn)容錯(cuò)和支持高請求率。然而，隨著Facebook的發(fā)展壯大，BLOB存儲工作負(fù)載也發(fā)生了變化。存儲的Blob的類型有所增加。在大小和創(chuàng)建、讀取和刪除速率方面的多樣性增加了。而且，最重要的是，現(xiàn)在有大量且不斷增加的低請求率BLOB。對于這些BLOB，從吞吐量的角度來看，三重復(fù)制會導(dǎo)致過度調(diào)配。然而，三重復(fù)制也提供了重要的容錯(cuò)保證。

我們較新的f4 BLOB存儲系統(tǒng)提供了與HayStack相同的容錯(cuò)保證，但有效復(fù)制系數(shù)更低。F4簡單、模塊化、可擴(kuò)展和容錯(cuò)；它處理我們存儲的Blob的請求率；它以足夠低的延遲響應(yīng)請求；它可以容忍磁盤、主機(jī)、機(jī)架和數(shù)據(jù)中心故障；它以較低的有效復(fù)制系數(shù)提供所有這些功能。

我們將f4描述為 warm blob storage，因?yàn)閷ζ鋬?nèi)容的請求率低于對HayStack中的內(nèi)容的請求率，因此不是那么“熱”。熱存儲系統(tǒng)也與冷存儲系統(tǒng)形成對比，冷存儲系統(tǒng)可靠地存儲數(shù)據(jù)，但可能需要幾天或幾個(gè)小時(shí)來檢索數(shù)據(jù)，這對于面向用戶的請求來說是不可接受的長。我們還使用溫度來描述blob，其中熱blob接收許多請求，而暖blob接收很少的請求

正如我們將演示的那樣，一個(gè)blob的年齡和它的溫度之間有很強(qiáng)的相關(guān)性。請求新創(chuàng)建的BLOB的速度比請求較舊BLOB的速度高得多。例如，對于九種檢查類型中的八種，對一周前的Blob的請求率比對不到一天的舊內(nèi)容的請求率低一個(gè)數(shù)量級。此外，年齡和缺失率之間存在很強(qiáng)的相關(guān)性。我們使用這些發(fā)現(xiàn)來指導(dǎo)我們的設(shè)計(jì)：溫暖blob的較低請求率使我們能夠?yàn)閒4調(diào)配比干草堆棧更低的最大吞吐量，并且溫暖blob的低刪除率使我們能夠通過不需要在刪除后快速物理回收空間來簡化f4。我們還利用我們的發(fā)現(xiàn)，通過年齡和溫度之間的相關(guān)性來識別溫暖的成分。

Facebook的整體BLOB存儲架構(gòu)旨在實(shí)現(xiàn)熱存儲。它包括一個(gè)緩存堆棧，它顯著減少了存儲系統(tǒng)的負(fù)載，并使它們能夠針對更少的每個(gè)BLOB請求進(jìn)行配置；一個(gè)轉(zhuǎn)換器層，它處理計(jì)算密集型BLOB轉(zhuǎn)換，并且可以獨(dú)立于存儲進(jìn)行擴(kuò)展；一個(gè)路由器層，它抽象底層存儲系統(tǒng)并實(shí)現(xiàn)它們之間的無縫遷移；以及熱存儲系統(tǒng)HayStack，它將新創(chuàng)建的BLOB聚合到卷中并存儲它們，直到它們的請求和刪除率冷卻到足以遷移到f4為止。

f4 stores volumes of warm BLOBs in cells that use distributed erasure coding，這種編碼比三次復(fù)制使用更少的物理字節(jié)。它使用Reed-Solomon(10，4)[46]編碼，并在不同的機(jī)架上布置塊，以確保在單個(gè)數(shù)據(jù)中心內(nèi)對磁盤、機(jī)器和機(jī)架故障的恢復(fù)能力。IS在廣域中使用XOR編碼，以確保對數(shù)據(jù)中心故障的恢復(fù)能力。F4已經(jīng)在Facebook投入生產(chǎn)超過19個(gè)月了。F4目前存儲超過65PB的邏輯數(shù)據(jù)，節(jié)省超過53PB的存儲。

我們在這篇論文中的貢獻(xiàn)包括：

• 一個(gè)關(guān)于 warm storage 的案例，它為未來對它的研究提供了信息，并證明了我們的努力。
• 我們支持 warm storage 的整體 BLOB 存儲體系結(jié)構(gòu)的設(shè)計(jì)。
• f4的設(shè)計(jì)，這是一款簡單、高效且容錯(cuò)的熱存儲解決方案，可將我們的 effectivereplication-factor(有效復(fù)制因子)從3.6降至2.8，然后降至2.1。
• 對f4進(jìn)行產(chǎn)量評估。

本文在第二節(jié)繼續(xù)介紹背景知識，第三節(jié)介紹 warm storage 的案例。第4節(jié)介紹了支持熱存儲的整體BLOB存儲體系結(jié)構(gòu)的設(shè)計(jì)。第5節(jié)介紹了F4。第6節(jié)介紹了對F4的成果評估，第7節(jié)介紹了所學(xué)到的經(jīng)驗(yàn)教訓(xùn)，第8節(jié)介紹了相關(guān)工作，第9節(jié)結(jié)束了。

二、Background

本節(jié)解釋 BLOB 存儲在Facebook的完整架構(gòu)中的位置。它還描述了我們存儲的不同類型的blob及其大小分布。

2.1 Where BLOB Storage Fits

圖1顯示了BLOB存儲如何適應(yīng)Facebook的整體架構(gòu)。

Blob Create–例如，視頻上傳–起源于網(wǎng)絡(luò)層(C1)。Web層將數(shù)據(jù)寫入BLOB存儲系統(tǒng)(C2)，然后將該數(shù)據(jù)的句柄存儲到我們的圖形存儲(C3)中，即TAO[9]。該句柄可用于檢索或刪除blob。TAO將句柄與圖形的其他元素相關(guān)聯(lián)，例如，視頻的所有者。

BLOB讀取–例如觀看視頻–也源自Web層(R1)。Web層訪問Graph Store(R2)以查找必要的句柄，并構(gòu)造可用于獲取BLOB的URL。當(dāng)瀏覽器稍后發(fā)送對BLOB(R3)的請求時(shí)，該請求首先去往高速緩存通常訪問的BLOB的內(nèi)容分發(fā)網(wǎng)絡(luò)(CDN)[2，34]。如果CDN沒有所請求的blob，則它向blob存儲系統(tǒng)發(fā)送請求(R4)，高速緩存該blob，并將其返回給用戶。CDN保護(hù)存儲系統(tǒng)不受對頻繁訪問數(shù)據(jù)的大量請求的影響，我們將在4.1節(jié)回到它的重要性。

2.2 BLOBs Explained

BLOB是不變的二進(jìn)制數(shù)據(jù)。它們只創(chuàng)建一次，可能會多次讀取，并且只能刪除，不能修改。這涵蓋了Facebook的許多類型的內(nèi)容。大多數(shù)BLOB類型都是面向用戶的，例如照片、視頻和文檔。其他BLOB類型是內(nèi)部的，如跟蹤、堆轉(zhuǎn)儲和源代碼。面向用戶的BLOB更加流行，因此我們在本文的其余部分將重點(diǎn)放在它們上，并將其簡稱為BLOB。

圖2顯示了五種類型blob的大小分布。blob的大小有很大的多樣性，這對我們的設(shè)計(jì)有影響，如第5.6節(jié)中所討論的那樣。

三、The Case for Warm Storage

這一部分旨在鼓勵在Facebook創(chuàng)建一個(gè)溫暖的存儲系統(tǒng)。它證明了 tempeature zone 的存在，age is a good proxy for temperature, and that warm content is large and growing.

3.1 方法

本節(jié)提供的數(shù)據(jù)來自兩周的跟蹤、現(xiàn)有系統(tǒng)的基準(zhǔn)和匯總統(tǒng)計(jì)數(shù)據(jù)的每日快照。跟蹤包括隨機(jī)的0.1%的讀取、10%的創(chuàng)建和10%的刪除。

提供了九種面向用戶的BLOB類型的數(shù)據(jù)。由于日志信息不完整，我們從一些分析中排除了一些數(shù)據(jù)類型。

這九種斑點(diǎn)類型包括個(gè)人資料照片、照片、高清照片、移動同步照片[17]、高清移動同步照片、群組附件[16]、視頻、高清視頻和消息(聊天)附件。組附件和郵件附件對于我們的存儲系統(tǒng)來說是不透明的BLOB，它們可以是文本、pdf、演示文稿等。

3.2 Temperature Zones Exist

為了說明熱存儲的情況，我們首先說明存在溫度區(qū)域，即內(nèi)容一開始是熱的，接收了許多請求，然后隨著時(shí)間的推移冷卻，接收的請求越來越少。

圖3顯示了給定年齡的內(nèi)容的相對請求率，即每對象每小時(shí)請求數(shù)。兩周的0.1%閱讀量的跟蹤被用來創(chuàng)建這個(gè)數(shù)字。每個(gè)正在讀取的對象的年齡都會被記錄下來，并以1天為間隔進(jìn)行存儲。然后，我們計(jì)算跟蹤中每個(gè)小時(shí)對每日存儲桶的請求數(shù)，并報(bào)告平均值–中位數(shù)相似，但噪音更大。絕對值被反規(guī)格化以增加可讀性，因此每一行都只與其自身相關(guān)。分?jǐn)?shù)標(biāo)志著數(shù)量級的下降。

隨著時(shí)間的推移，申請率不斷下降的趨勢清楚地表明了溫區(qū)的存在。對于所有九種類型的內(nèi)容，不到一天的內(nèi)容收到的請求率是一年前內(nèi)容的100多倍。其中八種類型的請求率在不到一周的時(shí)間內(nèi)下降了一個(gè)數(shù)量級，六種類型的請求率在不到60天的時(shí)間內(nèi)下降了100倍。

3.3 Differentiating Temperature Zones

考慮到溫度區(qū)域的存在，接下來要回答的問題是如何區(qū)分熱內(nèi)容和熱內(nèi)容，以及何時(shí)將內(nèi)容移動到熱存儲是安全的。

我們定義溫暖的溫度區(qū)域，包括不變的內(nèi)容和低請求率。Blob不會修改，因此唯一的更改是刪除。因此，區(qū)分熱內(nèi)容和熱內(nèi)容取決于請求率和刪除率。

首先，我們檢查請求率。為了確定熱存儲和熱存儲之間的界限，我們考慮了接近最壞情況的請求率，因?yàn)槲覀兊膬?nèi)部服務(wù)級別對象在一天中最繁忙的時(shí)段需要較低的接近最壞情況的延遲。

在我們一天中最忙的時(shí)候。圖4顯示了按年齡分組的各種類型BLOB的第99個(gè)百分位數(shù)或接近最差情況的請求負(fù)載。兩周的0.1%閱讀量的跟蹤被用來創(chuàng)建這個(gè)數(shù)字。記錄讀取的每個(gè)對象的時(shí)間，并將這些時(shí)間間隔存儲到與創(chuàng)建該BLOB類型的1TB所需的時(shí)間相等的間隔中。例如，如果每3600秒創(chuàng)建一種類型的1TB，則第一個(gè)存儲桶用于0-3599秒的年齡，第二個(gè)存儲桶用于3600-7200秒的時(shí)間，依此類推。1然后，我們通過查看1000秒的窗口來補(bǔ)償0.1%的采樣率。我們報(bào)告這些窗口的第99個(gè)百分位數(shù)請求率，即，我們報(bào)告每個(gè)年齡段的兩周跟蹤中1000秒窗口內(nèi)的第99個(gè)請求百分位計(jì)數(shù)。F4中使用的4TB磁盤最多可提供每秒80次輸入/輸出操作(IOPS)，同時(shí)將每次請求的延遲保持在可接受的低水平。該圖顯示了20 IOPS/TB的最高熱存儲吞吐量。

對于九種類型中的七種，在不到一周的時(shí)間內(nèi)，接近最差情況的吞吐量將低于熱存儲系統(tǒng)的容量。對于照片，需要大約3個(gè)月的時(shí)間才能達(dá)到熱存儲容量，而對于個(gè)人資料照片，需要一年的時(shí)間。

我們還檢查了斑點(diǎn)類型隨時(shí)間的刪失率，但沒有嚴(yán)格量化?？傮w趨勢是，大多數(shù)刪除是針對年輕斑點(diǎn)的，并且一旦對斑點(diǎn)的請求率降至熱存儲閾值以下，刪除率也很低。

將刪除分析與請求率分析相結(jié)合，將一個(gè)月作為除兩個(gè)斑點(diǎn)類型之外的所有斑點(diǎn)類型的熱內(nèi)容和熱內(nèi)容之間的安全分隔符。其中一種類型是個(gè)人資料照片，不會被移到熱存儲中。另一種是Photos，它使用三個(gè)月的門檻。

3.4 Warm Content is Large and Growing

我們通過展示溫暖內(nèi)容的百分比很大并且持續(xù)增長來結(jié)束對熱存儲的討論。圖5給出了六種BLOB類型在三個(gè)月間隔內(nèi)為熱的內(nèi)容的百分比。

我們使用上述分析來確定每種類型的溫暖截止時(shí)間，即大多數(shù)類型的溫暖截止時(shí)間為一個(gè)月。此圖報(bào)告了從9-6個(gè)月前、6-3個(gè)月前和3個(gè)月前到現(xiàn)在的三個(gè)月間隔內(nèi)每種類型的熱內(nèi)容的中位數(shù)百分比。

該圖顯示，熱內(nèi)容在所有對象中占很大比例：在最早的時(shí)間間隔中，超過80%的對象對于所有類型都是熱的。它還表明，熱的比例正在增加：在最近的時(shí)間間隔內(nèi)，超過89%的物體對所有類型都是熱的。

這一部分顯示了溫度區(qū)域的存在，大多數(shù)類型在一個(gè)月內(nèi)就可以安全地劃分Facebook現(xiàn)有類型的熱內(nèi)容和暖內(nèi)容之間的分界線，并且暖內(nèi)容在整個(gè)BLOB內(nèi)容中所占的比例很大，而且比例還在不斷增長。接下來，我們將描述Facebook的整體BLOB存儲架構(gòu)如何實(shí)現(xiàn)熱存儲。

四、BLOB Storage Design

我們的BLOB存儲設(shè)計(jì)遵循的原則是保持組件簡單、集中且與其工作很好地匹配。在本部分中，我們將介紹卷，描述我們的BLOB存儲系統(tǒng)的完整設(shè)計(jì)，并說明它如何使用f4實(shí)現(xiàn)集中且簡單的熱存儲。

4.0 Volumes

我們將BLOB聚合在一起形成邏輯卷。卷聚合文件系統(tǒng)元數(shù)據(jù)，使我們的存儲系統(tǒng)幾乎不會浪費(fèi)IOPS，正如我們在下面進(jìn)一步討論的那樣。我們將邏輯卷分為兩類。卷最初是解鎖的，并支持讀取、創(chuàng)建(附加)和刪除。一旦卷已滿，大小約為100 GB，它們將轉(zhuǎn)換為鎖定狀態(tài)，不再允許創(chuàng)建。鎖定的卷僅允許讀取和刪除。

每個(gè)卷由三個(gè)文件組成：數(shù)據(jù)文件、索引文件和日志文件。數(shù)據(jù)文件和索引文件與《干草堆》的出版版本相同[5]，而日記文件則是新的。數(shù)據(jù)文件保存每個(gè)BLOB以及相關(guān)的元數(shù)據(jù)，如鍵、大小和校驗(yàn)和。索引文件是存儲機(jī)的內(nèi)存中查找結(jié)構(gòu)的快照。它的主要目的是允許重新啟動的機(jī)器快速重建其內(nèi)存中的索引。日志文件跟蹤已刪除的BLOB；而在HayStack的原始版本中，刪除是通過直接更新數(shù)據(jù)和索引文件來處理的。對于鎖定的卷，數(shù)據(jù)和索引文件為只讀，而日志文件為讀寫。對于解鎖的卷，所有三個(gè)文件都是可讀寫的。

4.1 Overall Storage System

完整的BLOB存儲體系結(jié)構(gòu)如圖6所示。創(chuàng)建在路由器層(C1)進(jìn)入系統(tǒng)，并被定向到熱存儲系統(tǒng)(C2)中的適當(dāng)主機(jī)。刪除操作在路由器層(D1)進(jìn)入系統(tǒng)，并定向到相應(yīng)存儲系統(tǒng)(D2)中的相應(yīng)主機(jī)。讀取在緩存堆棧(R1)進(jìn)入系統(tǒng)，如果在那里不滿足要求，則遍歷轉(zhuǎn)換器層(R2)到路由器層(R3)，路由器層將它們定向到適當(dāng)存儲系統(tǒng)(R4)中的適當(dāng)主機(jī)。

4.1.1 Controller

Controller 確保整個(gè)系統(tǒng)的平穩(wěn)運(yùn)行。它有助于配置新的存儲計(jì)算機(jī)、維護(hù)解鎖的卷池、確保所有邏輯卷都有足夠的物理卷支持它們、在必要時(shí)創(chuàng)建新的物理卷以及執(zhí)行定期維護(hù)任務(wù)，如壓縮和垃圾收集。

4.1.2 Router

Router Tier（路由層）是BLOB存儲的接口；它隱藏了存儲的實(shí)施，并允許添加新的子系統(tǒng)，如f4。它的客戶端、Web層或緩存堆棧將邏輯Blob上的操作發(fā)送給它。

路由器層機(jī)器是相同的，它們執(zhí)行相同的邏輯，并且都具有邏輯卷到物理卷映射的軟狀態(tài)副本，該副本規(guī)范地存儲在單獨(dú)的數(shù)據(jù)庫中。路由器層通過添加更多機(jī)器進(jìn)行擴(kuò)展，其大小獨(dú)立于整個(gè)系統(tǒng)的其他部分。

• 對于讀取，路由器從BLOB ID中提取邏輯卷ID，并找到該卷的物理映射。它從可用物理卷中選擇一個(gè)–通常是最近計(jì)算機(jī)上的卷–并向其發(fā)送請求。如果出現(xiàn)故障，則會觸發(fā)超時(shí)，并將請求定向到下一個(gè)物理卷。
• 對于創(chuàng)建，路由器選擇具有可用空間的邏輯卷，并將BLOB發(fā)送到該邏輯卷的所有物理卷。如果出現(xiàn)任何錯(cuò)誤，任何部分寫入的數(shù)據(jù)都將被忽略，以便稍后進(jìn)行垃圾收集，并選擇一個(gè)新的邏輯卷進(jìn)行創(chuàng)建。
• 對于刪除，路由器向Blob的所有物理副本發(fā)出刪除命令。響應(yīng)被異步處理，并且不斷地重試刪除，直到在失敗的情況下完全刪除BLOB。

路由器層通過對其客戶端隱藏存儲實(shí)施來實(shí)現(xiàn)熱存儲。當(dāng)卷從熱存儲系統(tǒng)遷移到熱存儲系統(tǒng)時(shí)，它臨時(shí)駐留在兩者中，同時(shí)更新規(guī)范映射，然后將客戶端操作透明地定向到新存儲系統(tǒng)。

4.1.3 Transformer

Transformer Tier（轉(zhuǎn)換器層）處理檢索到的BLOB上的一組轉(zhuǎn)換。例如，這些轉(zhuǎn)換包括調(diào)整照片大小和裁剪照片。在Facebook的舊系統(tǒng)中，這些計(jì)算密集型轉(zhuǎn)換是在存儲機(jī)器上執(zhí)行的。

通過將存儲系統(tǒng)釋放出來，使存儲系統(tǒng)只專注于提供存儲，轉(zhuǎn)換器層實(shí)現(xiàn)了熱存儲。將計(jì)算劃分到自己的層允許我們獨(dú)立地橫向擴(kuò)展存儲層和轉(zhuǎn)換器層。反過來，這使我們能夠?qū)⒋鎯拥拇笮【_地匹配到我們的需求。此外，它使我們能夠?yàn)檫@些任務(wù)中的每一項(xiàng)選擇更優(yōu)化的硬件。特別是，存儲節(jié)點(diǎn)可以設(shè)計(jì)為只使用單個(gè)CPU和相對較少的RAM來容納大量磁盤。

4.1.4 Caching Stack

高速緩存堆棧，BLOB讀取最初被定向到高速緩存堆棧[2，34]，并且如果BLOB駐留在高速緩存之一中，則直接返回該BLOB，從而避免在存儲系統(tǒng)中讀取。這會吸收常用Blob的讀取，并降低存儲系統(tǒng)的請求率。緩存堆棧通過降低其請求速率來實(shí)現(xiàn)熱存儲。

4.1.5 Hot Storage with Haystack

Facebook的熱存儲系統(tǒng)HayStack設(shè)計(jì)為僅使用充分利用的IOPS。它通過處理所有BLOB創(chuàng)建、處理大多數(shù)刪除以及處理更高的讀取率來實(shí)現(xiàn)熱存儲。Haystack is designed to fully utilize disk IOPS by:

• Grouping Blobs：它只創(chuàng)建少量(~100)文件，其中BLOB按順序排列在這些文件中。結(jié)果是一個(gè)簡單的BLOB存儲系統(tǒng)，它使用少量文件，并繞過底層文件系統(tǒng)進(jìn)行大多數(shù)元數(shù)據(jù)訪問。
• 緊湊型元數(shù)據(jù)管理：它標(biāo)識定位每個(gè)BLOB所需的最小元數(shù)據(jù)集，并仔細(xì)布局這些元數(shù)據(jù)，使其適合機(jī)器上的可用內(nèi)存。這允許系統(tǒng)將極少的IOPS浪費(fèi)在元數(shù)據(jù)獲取上。

BLOB分組到邏輯卷中。為了實(shí)現(xiàn)容錯(cuò)和性能，每個(gè)邏輯卷映射到不同地理區(qū)域的不同主機(jī)上的多個(gè)物理卷或副本：邏輯卷的所有物理卷存儲相同的BLOB集。每個(gè)物理卷完全駐留在一個(gè) Haystack 主機(jī)上。每個(gè)邏輯卷通常有3個(gè)物理卷。每個(gè)卷最多可容納數(shù)百萬個(gè)不變的Blob，大小可增加到約100 GB。

當(dāng)主機(jī)接收到讀操作時(shí)，它會在內(nèi)存哈希表中查找相關(guān)的元數(shù)據(jù)–數(shù)據(jù)文件中的偏移量、數(shù)據(jù)記錄的大小以及它是否已被刪除。然后，它對數(shù)據(jù)文件執(zhí)行單個(gè)I/O請求以讀取整個(gè)數(shù)據(jù)記錄。

當(dāng)主機(jī)收到CREATE時(shí)，它會同步地將一條記錄附加到其物理卷中，更新內(nèi)存中的哈希表，并同步更新索引和日志文件。

當(dāng)主機(jī)收到刪除操作時(shí)，它會更新內(nèi)存中的哈希表和日志文件。BLOB的內(nèi)容仍然存在于數(shù)據(jù)文件中。我們定期壓縮卷，這會完全刪除BLOB并回收其空間。

4.1.6 Fault tolenrance

Hystack通過數(shù)據(jù)文件和硬件RAID-6(1.2倍復(fù)制)的三重復(fù)制，對磁盤、主機(jī)、機(jī)架和數(shù)據(jù)中心故障具有容錯(cuò)能力。每個(gè)卷的兩個(gè)副本位于主數(shù)據(jù)中心但在不同的機(jī)架上，因此主機(jī)和磁盤。這提供了對磁盤、主機(jī)和機(jī)架故障的恢復(fù)能力。針對磁盤故障，RAID-6提供了額外的保護(hù)。第三個(gè)副本位于另一個(gè)數(shù)據(jù)中心，可提供對數(shù)據(jù)中心故障的恢復(fù)能力。

該方案提供了良好的容錯(cuò)性和高吞吐量，但有效復(fù)制因子為3 BLOB 1.2=3.6。這是HayStack的主要限制：它針對IOPS進(jìn)行了優(yōu)化，但沒有針對存儲效率進(jìn)行優(yōu)化。正如熱存儲的情況所表明的那樣，這會導(dǎo)致大量Blob的過度復(fù)制

4.1.7 Expiry-Driven Content

到期驅(qū)動的內(nèi)容某些BLOB類型的內(nèi)容有到期時(shí)間。例如，上傳的視頻在被轉(zhuǎn)碼為我們的存儲格式時(shí)，會以其原始格式臨時(shí)存儲。我們避免將這種過期驅(qū)動的內(nèi)容移動到f4，并將其保留在HayStack中。熱存儲系統(tǒng)通過頻繁運(yùn)行壓縮來回收當(dāng)前可用的空間來應(yīng)對高刪除率。

五、f4 Design

本節(jié)介紹我們的熱存儲設(shè)計(jì)目標(biāo)，然后介紹我們的熱存儲系統(tǒng)f4。

5.1 Design goals

從高層次上講，我們希望我們的熱存儲系統(tǒng)能夠提高存儲效率并提供容錯(cuò)功能，這樣我們就不會丟失數(shù)據(jù)或?qū)τ脩舨豢捎谩?/p>

存儲效率：我們新系統(tǒng)的主要目標(biāo)之一是提高存儲效率，即在保持高度可靠性和性能的同時(shí)降低有效復(fù)制系數(shù)。有效復(fù)制系數(shù)描述數(shù)據(jù)的實(shí)際物理大小與存儲的邏輯大小的比率。在維護(hù)3個(gè)副本并在每個(gè)具有12個(gè)磁盤的節(jié)點(diǎn)上使用RAID6編碼的系統(tǒng)中，有效復(fù)制系數(shù)為3.6。

容錯(cuò)性：我們的存儲系統(tǒng)的另一個(gè)重要目標(biāo)是對故障層次結(jié)構(gòu)的容錯(cuò)，以確保我們不會丟失數(shù)據(jù)，并且存儲始終可用于客戶端請求。我們明確考慮了四種類型的故障：

• 驅(qū)動器故障，年增長率為低個(gè)位數(shù)。
• 定期發(fā)生主機(jī)故障。
• 機(jī)架故障，每年多次。
• 數(shù)據(jù)中心故障，極其罕見，通常是暫時(shí)的，但潛在的災(zāi)難性更大。

5.2 f4 Overview

F4是我們的熱數(shù)據(jù)存儲子系統(tǒng)。它由多個(gè)單元組成，其中每個(gè)單元完全位于一個(gè)數(shù)據(jù)中心內(nèi)，并由同構(gòu)硬件組成。當(dāng)前的單元使用14個(gè)機(jī)架，每臺主機(jī)有30個(gè)4TB驅(qū)動器，每臺主機(jī)有15臺主機(jī)[42]。我們將蜂窩視為獲取的單元，以及部署和推出的單元。

單元負(fù)責(zé)可靠地存儲一組鎖定的卷，并使用Reed-Solomon編碼以較低的存儲開銷存儲這些卷。Distributed erasure coding achieves reliability 以比復(fù)制更低的存儲開銷實(shí)現(xiàn)了可靠性，同時(shí)權(quán)衡了在故障情況下增加的重建和恢復(fù)時(shí)間以及更低的最大讀取吞吐量。Reed-Solomon編碼[46]是最流行的擦除編碼技術(shù)之一，并且已經(jīng)在許多不同的系統(tǒng)中使用。Reed-Solomon(n，k)碼用k個(gè)額外的奇偶校驗(yàn)位對n位數(shù)據(jù)進(jìn)行編碼，并且可以容忍k個(gè)故障，總存儲大小為n+k。此方案可防止磁盤、主機(jī)和機(jī)架故障。

我們使用單獨(dú)的XOR編碼方案來容忍數(shù)據(jù)中心或地理區(qū)域故障。我們將每個(gè)卷/條帶/數(shù)據(jù)塊與不同地理區(qū)域中的伙伴卷/條帶/數(shù)據(jù)塊配對。我們將伙伴的XOR存儲在第三個(gè)區(qū)域中。該方案可防止三個(gè)區(qū)域中的一個(gè)發(fā)生故障。我們將在第5.5節(jié)中討論容錯(cuò)

5.3 Individual f4 Cell

單個(gè)f4單元對磁盤、主機(jī)和機(jī)架故障具有恢復(fù)能力，是它們存儲的BLOB的主要位置和接口。每個(gè)f4單元僅處理鎖定的卷，即它只需要支持對該卷的讀取和刪除操作。數(shù)據(jù)和索引文件是只讀的。跟蹤刪除的干草堆日志文件在f4中不存在。相反，所有BLOB都使用存儲在外部數(shù)據(jù)庫中的密鑰進(jìn)行加密。刪除f4中BLOB的加密密鑰會使其不可讀，從而在邏輯上將其刪除。

索引文件在一個(gè)單元格內(nèi)使用三重復(fù)制。這些文件非常小，因此對它們進(jìn)行編碼所獲得的存儲收益太小，不值得增加復(fù)雜性。

具有實(shí)際斑點(diǎn)數(shù)據(jù)的數(shù)據(jù)文件通過里德-所羅門(n，k)碼被編碼和存儲。最近的f4 cell使用n=10和k=4。文件在邏輯上被劃分為n個(gè)塊的連續(xù)序列，每個(gè)大小為b。對于每個(gè)這樣的n個(gè)塊序列，生成k個(gè)奇偶校驗(yàn)塊，從而形成大小為n+k的邏輯條帶。對于條帶中的給定塊，該條帶中的其他塊被視為其同伴塊。如果文件不是n個(gè)塊的整數(shù)倍，則對下一個(gè)倍數(shù)進(jìn)行零填充。在正常操作中，BLOB直接從其數(shù)據(jù)塊中讀取。如果塊不可用，則可以通過對其任意n個(gè)同伴塊和奇偶校驗(yàn)塊進(jìn)行解碼來恢復(fù)該塊。對應(yīng)于BLOB的塊的子集也可以僅從其同伴塊和奇偶校驗(yàn)塊的任何N個(gè)的等價(jià)子集中解碼。圖7顯示了BLOB、數(shù)據(jù)塊、條帶和卷之間的關(guān)系。

選擇用于編碼的塊大小較大–通常為1 GB–有兩個(gè)原因。首先，它減少了跨多個(gè)數(shù)據(jù)塊的BLOB數(shù)量，因此需要多個(gè)I/O操作才能讀取。其次，它減少了f4需要維護(hù)的每個(gè)數(shù)據(jù)塊的元數(shù)據(jù)量。我們避免了較大的塊大小，因?yàn)橹亟▔K會產(chǎn)生較大的開銷。圖8顯示了一個(gè)f4單元格。其組件包括存儲節(jié)點(diǎn)、名稱節(jié)點(diǎn)、回退節(jié)點(diǎn)、重建器節(jié)點(diǎn)和協(xié)調(diào)器節(jié)點(diǎn)。

5.3.1 Name Node

The name node maintains the mapping between data blocks and parity blocks and the storage nodes that hold the actual blocks. The mapping is distributed to storage nodes via standard techniques [3, 18]. Name nodes are made fault tolerant with a standard primarybackup setup.

5.3.2 Storage Nodes

The storage nodes are the main component of a cell and handle all normal-case reads and deletes. Storage nodes expose two APIs:

• an Index API that provides existence and location information for volumes
• and a File API that provides access to data

Each node is responsible for the existence and location information of a subset of the volumes in a cell and exposes this through its Index API. It stores the index—BLOB to data file, offset, and length—file on disk and loads them into custom data structures in memory. It also loads the location-map for each volume that maps offsets in data files to the physically-stored data blocks. Index files and location maps are pinned in memory to avoid disk seeks.

用每個(gè)斑點(diǎn)加密密鑰對f4中的每個(gè)斑點(diǎn)進(jìn)行加密。通過刪除存儲在單獨(dú)的密鑰存儲(通常是數(shù)據(jù)庫)中的BLOB的加密密鑰，在f4之外處理刪除。這使得斑點(diǎn)不可讀，并有效地刪除了它，而不需要在f4中使用壓縮。它還使f4能夠消除HayStack用來跟蹤關(guān)鍵存在和刪除信息的日志文件。

通過驗(yàn)證BLOB是否存在，然后將調(diào)用方重定向到具有包含指定BLOB的數(shù)據(jù)塊的存儲節(jié)點(diǎn)來處理讀取(R1)。數(shù)據(jù)API提供對節(jié)點(diǎn)存儲的數(shù)據(jù)和奇偶校驗(yàn)塊的數(shù)據(jù)訪問。正常情況下的讀取被重定向到相應(yīng)的存儲節(jié)點(diǎn)(R2)，然后該存儲節(jié)點(diǎn)直接從其封閉的數(shù)據(jù)塊(R3)讀取BLOB。故障情況讀取使用數(shù)據(jù)API讀取在回退節(jié)點(diǎn)上重建BLOB所需的伴隨塊和奇偶校驗(yàn)塊。路由器層與讀路徑的其余部分(即，R1-R3或R1、R4、R5)并行地獲取每二進(jìn)制大對象加密密鑰。然后在路由器層對BLOB進(jìn)行解密。解密的計(jì)算代價(jià)很高，在路由器層上執(zhí)行解密使f4能夠?qū)Ｗ⒂诟咝Т鎯Γ⒃试S獨(dú)立于存儲擴(kuò)展解密。

5.3.3 Backoff Nodes

當(dāng)單元中出現(xiàn)故障時(shí)，一些數(shù)據(jù)塊將變得不可用，并且為其持有的BLOB提供讀取服務(wù)將需要從伴隨數(shù)據(jù)塊和奇偶校驗(yàn)塊在線重建它們?；赝斯?jié)點(diǎn)是占用大量CPU的無存儲節(jié)點(diǎn)，用于處理請求Blob的在線重建。

每個(gè)回退節(jié)點(diǎn)公開一個(gè)文件API，該API在正常情況下讀取失敗后從路由器層接收讀取(R4)。主卷服務(wù)器已將讀請求映射到數(shù)據(jù)文件、偏移量和長度。回退卷服務(wù)器從不可用數(shù)據(jù)塊(R5)的所有n個(gè)?1伴隨數(shù)據(jù)塊和k個(gè)奇偶校驗(yàn)數(shù)據(jù)塊的等效偏移量發(fā)送該長度的讀取。一旦它接收到n個(gè)響應(yīng)，它就對它們進(jìn)行解碼以重建所請求的BLOB。

此在線重建僅重建請求的BLOB，而不重建整個(gè)塊。因?yàn)榘唿c(diǎn)的大小通常比塊大小小得多–例如，40KB而不是1 GB–重建斑點(diǎn)比重建塊要快得多，重量也輕得多。完整數(shù)據(jù)塊重建由重建器節(jié)點(diǎn)離線處理。

5.3.4 Rebuilder Nodes

在大規(guī)模情況下，磁盤和節(jié)點(diǎn)故障是不可避免的。發(fā)生這種情況時(shí)，需要重建存儲在故障組件上的塊。重建器節(jié)點(diǎn)是占用大量CPU的存儲較少的節(jié)點(diǎn)，用于處理數(shù)據(jù)塊的故障檢測和后臺重建。每個(gè)重建器節(jié)點(diǎn)通過探測來檢測故障，并將故障報(bào)告給協(xié)調(diào)器節(jié)點(diǎn)。它通過從故障數(shù)據(jù)塊的條帶中取出n個(gè)伴生或奇偶數(shù)據(jù)塊并對其進(jìn)行解碼來重建數(shù)據(jù)塊。重建是一個(gè)重量級過程，會對存儲節(jié)點(diǎn)施加巨大的I/O和網(wǎng)絡(luò)負(fù)載。重建器節(jié)點(diǎn)自行節(jié)流以避免對在線用戶請求產(chǎn)生不利影響。調(diào)度重建以最大限度地減少數(shù)據(jù)丟失的可能性是協(xié)調(diào)器節(jié)點(diǎn)的責(zé)任。

5.3.5 Coordinator Nodes

一個(gè)單元需要許多維護(hù)任務(wù)，如調(diào)度塊重建和確保當(dāng)前數(shù)據(jù)布局將數(shù)據(jù)不可用的可能性降至最低。協(xié)調(diào)器節(jié)點(diǎn)是處理這些計(jì)算單元范圍任務(wù)的存儲較少、占用大量CPU的節(jié)點(diǎn)。

如前所述，條帶中的數(shù)據(jù)塊分布在不同的故障域中，以最大限度地提高可靠性。但是，在初始放置以及故障、重建和替換之后，如果條帶的數(shù)據(jù)塊位于同一故障域中，則可能會出現(xiàn)違規(guī)。協(xié)調(diào)器運(yùn)行放置平衡器進(jìn)程，該進(jìn)程驗(yàn)證單元中的塊布局，并根據(jù)需要重新平衡塊。重新平衡操作(如重建操作)會在存儲節(jié)點(diǎn)上產(chǎn)生巨大的磁盤和網(wǎng)絡(luò)負(fù)載，并且還會受到限制，從而對用戶請求產(chǎn)生不利影響。

5.6 Additional Design Points

為清楚起見，本小節(jié)簡要介紹了我們在基本f4設(shè)計(jì)中排除的其他設(shè)計(jì)要點(diǎn)。

5.6.1 混合年齡和類型

我們的BLOB存儲系統(tǒng)同時(shí)為每個(gè)BLOB類型填充多個(gè)卷。這將在一個(gè)體積內(nèi)混合斑點(diǎn)的年齡，并使它們的溫度變得平滑。體積中最新的斑點(diǎn)的溫度可能高于我們對f4的目標(biāo)溫度。但是，如果體積中較老的斑點(diǎn)將其整體溫度降低到我們的目標(biāo)以下，則體積仍可能遷移到f4。

不同的斑點(diǎn)類型在f4細(xì)胞中的宿主上混合在一起，以實(shí)現(xiàn)類似的效果。如果將高溫類型與低溫類型混合在一起，可以更快地遷移到f4，從而平滑每個(gè)磁盤上的整體負(fù)載。

5.6.2 Index Size Consideration

f4(和HayStack)的內(nèi)存需求主要由索引的內(nèi)存占用量驅(qū)動。F4前面的多個(gè)緩存層消除了在存儲機(jī)器上使用大容量緩存的需要。

除了個(gè)人資料照片，索引的內(nèi)存大小適合我們定制硬件的內(nèi)存。對于個(gè)人資料照片，我們目前將它們從f4中排除，并將它們保留在HayStack中。個(gè)人資料照片的索引大小對于HayStack主機(jī)來說仍然是個(gè)問題，即使它們存儲的Blob比f4主機(jī)少。為了保持合理的索引大小，我們充分利用了HayStack主機(jī)上的存儲。這使我們能夠使HayStack保持簡單，并且不會顯著影響整個(gè)系統(tǒng)的效率，因?yàn)槊總€(gè)用戶只有一張個(gè)人資料照片，而且照片非常小。

七、經(jīng)驗(yàn)

在設(shè)計(jì)、構(gòu)建、部署和改進(jìn)f4的過程中，我們學(xué)到了很多教訓(xùn)。其中，簡單性對操作穩(wěn)定性的重要性、為用例的效率衡量底層軟件的重要性以及硬件異構(gòu)性以降低相關(guān)故障的可能性的需求尤為突出。

在Facebook的許多系統(tǒng)中，設(shè)計(jì)簡單的系統(tǒng)以保持其部署的穩(wěn)定性的重要性突顯出來[41]，我們使用f4的經(jīng)驗(yàn)也加強(qiáng)了這一點(diǎn)。F4的早期版本使用日記文件來跟蹤刪除，方法與HayStack相同。這個(gè)單一的讀寫文件與只讀的f4設(shè)計(jì)的其余部分不一致。我們實(shí)施的核心分布式文件系統(tǒng)(HDFS)最多只能有一個(gè)編寫器的要求、大型分布式系統(tǒng)中故障的必然性，以及很少寫入日志文件，這些都不能很好地結(jié)合在一起。這是f4生產(chǎn)問題的首要來源。我們后來的設(shè)計(jì)刪除了這個(gè)讀寫日志文件，將刪除跟蹤推送到另一個(gè)設(shè)計(jì)為讀寫的系統(tǒng)。這一更改簡化了f4，使其成為完全只讀的，并修復(fù)了生產(chǎn)問題。

測量和理解構(gòu)建在f4之上的底層軟件有助于提高f4的效率。F4的實(shí)現(xiàn)構(gòu)建在Hadoop文件系統(tǒng)(HDFS)之上。HDFS中的讀取通常由群集中的任何服務(wù)器處理，然后由該服務(wù)器代理到具有所請求數(shù)據(jù)的服務(wù)器。通過測量，我們發(fā)現(xiàn)由于HDFS調(diào)度IO線程的方式，這種代理讀取具有比預(yù)期更低的吞吐量和更高的延遲。特別是，HDFS為每個(gè)并行網(wǎng)絡(luò)IO請求使用一個(gè)線程，而Java的多線程不能很好地?cái)U(kuò)展到大量并行請求，這導(dǎo)致網(wǎng)絡(luò)IO請求的積壓不斷增加。我們通過第5.3節(jié)描述的兩部分讀取解決了這個(gè)問題，避免了通過HDFS代理讀取。此解決方法導(dǎo)致了f4的預(yù)期吞吐量和延遲。

最近，當(dāng)一批磁盤開始以高于正常速度的速度出現(xiàn)故障時(shí)，我們了解到底層硬件中的異構(gòu)性對于f4的重要性。此外，我們的一個(gè)地區(qū)經(jīng)歷了高于平均溫度的情況，這加劇了壞盤的故障率。壞磁盤和高溫的組合導(dǎo)致在幾周內(nèi)從正常的~1%的AFR增加到超過60%的AFR。幸運(yùn)的是，高故障率磁盤被限制在單個(gè)單元中，沒有數(shù)據(jù)丟失，因?yàn)榛锇楹蚗OR塊位于其他溫度較低的單元中，不受影響。在未來，我們計(jì)劃使用硬件異構(gòu)性來降低發(fā)生此類相關(guān)故障的可能性。文章來源地址http://www.zghlxwxcb.cn/news/detail-670098.html

到了這里，關(guān)于【seaweedfs】3、f4: Facebook’s Warm BLOB Storage System 分布式對象存儲的冷熱數(shù)據(jù)的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！