針對海量小文件的可伸縮分布式文件系統(tǒng)研究

摘 要： 在對分布式文件系統(tǒng)可靠性、可用性以及可伸縮性進(jìn)行深入研究后，設(shè)計并實現(xiàn)了一套可伸縮的分布式文件系統(tǒng)，針對當(dāng)前互聯(lián)網(wǎng)應(yīng)用中大部分圖片資源大小不超過100 KB的具體應(yīng)用場景，進(jìn)一步對設(shè)計的文件系統(tǒng)做出改進(jìn)，確保文件系統(tǒng)在應(yīng)對海量小文件存儲、頻繁讀寫時具有良好的性能。

關(guān)鍵詞： 可伸縮性； 分布式系統(tǒng)； 文件系統(tǒng)； 小文件

中圖分類號： TN911?34； TM417 文獻(xiàn)標(biāo)識碼： A 文章編號： 1004?373X（2016）19?0116?04

Abstract： The reliability， availability and scalability of the distributed file system are studied deeply. A set scalable distri?buted file system was designed and implemented. Since the size of most image resources in current Internet application is less than 100 KB， the designed file system was improved to ensure the file system performance while frequently storing， reading and writing the massive small files.

Keywords： scalability； distributed system； file system； small file

0 引 言

隨著互聯(lián)網(wǎng)的普及，數(shù)據(jù)資源中有很大一部分是以小文件形式存在的，海量小文件的存儲方式和備份方式顯得越來越重要。面對規(guī)模龐大，數(shù)目眾多的應(yīng)用文件，傳統(tǒng)的單臺文件服務(wù)器顯然已經(jīng)難以滿足用戶需求。單純的依靠增加硬盤個數(shù)來擴(kuò)展一個文件系統(tǒng)容量大小的方式，在這種應(yīng)用背景下變得無能為力[1]。將存儲和網(wǎng)絡(luò)結(jié)合起來成為一個必然的發(fā)展方向，新一代的基于網(wǎng)絡(luò)的分布式文件系統(tǒng)應(yīng)運而生[2]。

1 系統(tǒng)的可伸縮架構(gòu)設(shè)計

1.1 系統(tǒng)設(shè)計目標(biāo)

本系統(tǒng)的設(shè)計目標(biāo)重點圍繞高可伸縮性，高可伸縮性代表的是一種彈性，當(dāng)文件系統(tǒng)的容量不足，系統(tǒng)需要擴(kuò)展時，軟件系統(tǒng)能夠通過較少的改動，甚至僅僅通過添加硬件設(shè)備，就能夠?qū)崿F(xiàn)整個軟件系統(tǒng)處理能力的線性增長。

1.2 系統(tǒng)概述

根據(jù)微軟提出的系統(tǒng)優(yōu)化金字塔，設(shè)計優(yōu)化、代碼優(yōu)化、產(chǎn)品優(yōu)化、硬件優(yōu)化對整個系統(tǒng)的優(yōu)化影響依次遞減。由此可見，位于金字塔底部的設(shè)計優(yōu)化對系統(tǒng)各種性能的影響最大。鑒于系統(tǒng)的設(shè)計目標(biāo)，本文分布式文件系統(tǒng)將構(gòu)筑在高速局域網(wǎng)連接的普通服務(wù)器集群上，以期達(dá)到利用廉價的服務(wù)器集群實現(xiàn)高可伸縮的軟件系統(tǒng)的目的。本系統(tǒng)采用主從架構(gòu)，系統(tǒng)內(nèi)節(jié)點分為NameNode和DataNode。對于元數(shù)據(jù)管理采用集中式管理方法，將元數(shù)據(jù)集中于NameNode中進(jìn)行管理，DataNode為文件的實際存儲節(jié)點[3]。

1.3 可伸縮系統(tǒng)架構(gòu)

1.3.1 系統(tǒng)整體架構(gòu)

為了避免由于元數(shù)據(jù)的集中管理而造成單點故障隱患，NameNode采用主從熱備的方式。系統(tǒng)對外提供命名服務(wù)的默認(rèn)節(jié)點為主命名節(jié)點，另一臺為備命名節(jié)點，兩個節(jié)點之間互相進(jìn)行熱備，并向系統(tǒng)監(jiān)控服務(wù)器定時發(fā)送心跳。當(dāng)監(jiān)控服務(wù)器超時沒有接收到任意一臺NameNode的心跳信息時，即表示該節(jié)點失效，發(fā)出報警。如果失效的節(jié)點為主命名節(jié)點，則將對外服務(wù)切換到備命名節(jié)點上。待原主命名節(jié)點恢復(fù)后，為了讓系統(tǒng)實現(xiàn)穩(wěn)定的服務(wù)，系統(tǒng)不再對外服務(wù)切換回原主命名節(jié)點，即主備角色發(fā)生互換。

當(dāng)系統(tǒng)經(jīng)過長期運行發(fā)生容量不足需要擴(kuò)容時，由于DataNode和NameNode之間使用心跳機制進(jìn)行通信，當(dāng)系統(tǒng)擴(kuò)容時，將新加入的DataNode部署完應(yīng)用程序并啟動后，新加入的DataNode便會開始向NameNode發(fā)送心跳信息匯報自己的工作狀態(tài)，NameNode接收到心跳后，將新加入的DataNode并入當(dāng)前運行的系統(tǒng)，并根據(jù)系統(tǒng)的負(fù)載均衡策略將部分寫文件請求分發(fā)到新的存儲節(jié)點上。通過上述方法，系統(tǒng)完成了平滑擴(kuò)容，擴(kuò)容過程中系統(tǒng)不需要停機，不會對外終止服務(wù)，系統(tǒng)擁有較好的可伸縮性。

1.3.2 DataNode節(jié)點內(nèi)部結(jié)構(gòu)

DataNode為系統(tǒng)中文件數(shù)據(jù)實際的存儲節(jié)點，負(fù)責(zé)實際數(shù)據(jù)的存儲和讀寫。本文設(shè)計在存儲節(jié)點的機器上，針對每塊磁盤創(chuàng)建一個DataNode實例，單獨管理此塊磁盤，不僅能使單塊磁盤的讀寫性能達(dá)到最優(yōu)，同時也能極大地降低單塊磁盤故障對系統(tǒng)帶來的影響[4]。

DataNode將預(yù)先在物理磁盤上創(chuàng)建的文件塊分成主塊（MainBlock）和擴(kuò)展塊（ExtendBlock）兩類。系統(tǒng)在實際讀寫文件時以邏輯塊（LogicBlock）為單位。根據(jù)不同的系統(tǒng)需求，可以配置不同的主塊和擴(kuò)展塊大小，主塊和擴(kuò)展塊的比例也可以進(jìn)行配置。在DataNode中，所有的塊操作和文件讀寫都以邏輯塊為單位，一個邏輯塊包含一個主塊和若干個擴(kuò)展塊，并且會對應(yīng)一個塊內(nèi)索引文件，用來存儲邏輯塊的元數(shù)據(jù)，包括塊中包含的文件數(shù)量，全部文件的索引ID以及其在塊內(nèi)的起始偏移量、文件長度等[5]。由于硬盤的讀寫速度遠(yuǎn)不及內(nèi)存的讀寫速度，DataNode在啟動時會將所有的索引文件導(dǎo)入到內(nèi)存中，在運行過程中系統(tǒng)也會將索引文件的修改定期的持久化到磁盤上，以減少DataNode短時間失效對該節(jié)點數(shù)據(jù)安全帶來的影響。

1.3.3 NameNode節(jié)點內(nèi)部結(jié)構(gòu)

NameNode主要負(fù)責(zé)管理和維護(hù)元數(shù)據(jù)，即邏輯塊的相關(guān)信息，包括邏輯塊的創(chuàng)建、備份、負(fù)載均衡、刪除等。同時，NameNode還負(fù)責(zé)接收DataNode的心跳包，并根據(jù)心跳維護(hù)系統(tǒng)內(nèi)DataNode的加入和退出[6]。

將NameNode對邏輯塊的管理設(shè)計成邏輯塊組的形式。NameNode會為每一個邏輯塊組進(jìn)行編號，即邏輯塊組ID。這個編號由NameNode負(fù)責(zé)分配和存儲。每一個邏輯塊都?xì)w屬于一個邏輯塊組，每一個邏輯塊組都會有一個全局惟一的邏輯塊組ID，并對應(yīng)多個實際DataNode中的邏輯塊。寫文件時，系統(tǒng)會通過異步的方式將待寫入文件寫入某個邏輯塊組ID所對應(yīng)的全部邏輯塊后才會被系統(tǒng)認(rèn)為寫入成功。而在讀取文件時，邏輯塊組ID對應(yīng)的全部DataNode上的邏輯塊可以提供并發(fā)讀操作，因而提高了讀性能。在對邏輯塊加鎖方面，系統(tǒng)會將鎖分為讀、寫鎖兩種：寫鎖只允許有一個線程進(jìn)行寫操作；而讀鎖則允許有多個線程進(jìn)行讀操作。因此在邏輯塊的大小配置方面可能會影響到系統(tǒng)性能。邏輯塊越大，則邏輯塊的總數(shù)越小，當(dāng)寫操作較多時，會出現(xiàn)較多的邏輯塊被加寫鎖，導(dǎo)致可寫塊不足，影響系統(tǒng)的讀文件性能。邏輯塊越小，則邏輯塊的總數(shù)越大，導(dǎo)致邏輯塊的元數(shù)據(jù)增加，增加NameNode的管理壓力。

1.3.4 平滑擴(kuò)容方法

系統(tǒng)是否能夠在運行中實現(xiàn)系統(tǒng)的平滑擴(kuò)容是衡量系統(tǒng)是否具有良好可伸縮性的一個重要指標(biāo)。系統(tǒng)在擴(kuò)容時，首先將待加入的DataNode節(jié)點磁盤創(chuàng)建文件塊，然后在進(jìn)行相應(yīng)配置的部署后啟動，新節(jié)點開始定時向NameNode發(fā)送心跳匯報，NameNode在接到心跳匯報后將新節(jié)點創(chuàng)建的邏輯塊加入元數(shù)據(jù)管理中，即完成了在不停服務(wù)的條件下的整個平滑擴(kuò)容過程[7]。

2 海量小文件的存儲與讀寫方法設(shè)計

2.1 元數(shù)據(jù)管理方法

DataNode預(yù)先將實際用于存儲的磁盤空間創(chuàng)建成一系列大小相等的空文件，稱為文件塊（Block），實際文件存儲于這些預(yù)先創(chuàng)建的文件中，這樣不僅能夠減少操作系統(tǒng)的文件系統(tǒng)在讀寫過程中造成的數(shù)據(jù)碎片帶來的性能損失，而且能夠極大地減少元數(shù)據(jù)。NameNode存儲的元數(shù)據(jù)不再為實際存儲文件的元數(shù)據(jù)，而是DataNode預(yù)先建立的文件，如此能夠極大地降低所需存儲的元數(shù)據(jù)總大小[8]。預(yù)先創(chuàng)建的文件塊大小默認(rèn)設(shè)置為64 MB，當(dāng)一個文件元數(shù)據(jù)大小同樣為150 B時，1 PB磁盤所需存儲元數(shù)據(jù)總大小不到3 GB，極大地降低了元數(shù)據(jù)存儲對NameNode的內(nèi)存壓力，提升了系統(tǒng)存儲海量小文件的能力。

2.2 模型理論基礎(chǔ)及假設(shè)

NameNode并沒有保存存儲文件的元數(shù)據(jù)，而僅保存了邏輯塊的元數(shù)據(jù)。同時，實現(xiàn)的分布式文件系統(tǒng)應(yīng)用場景對文件名并不敏感。因此，將存儲文件的元數(shù)據(jù)通過編碼的方式表示在文件名主名部分，擴(kuò)展名不變，如圖1所示。

存儲文件的元數(shù)據(jù)主要包括該文件存儲的邏輯塊組ID以及該文件在塊內(nèi)索引的File ID。由于邏輯塊的大小的限制，F(xiàn)ile ID的范圍是有限的?？梢源致怨浪悖現(xiàn)ile ID是不會超過230的。因此，F(xiàn)ile ID可以用30位二進(jìn)制數(shù)進(jìn)行表示。將這30位二進(jìn)制數(shù)拆分成6組長度為5的二進(jìn)制數(shù)，然后轉(zhuǎn)換成6個十進(jìn)制數(shù)，并根據(jù)Base32的對應(yīng)關(guān)系，將其轉(zhuǎn)換成長度為6的Base32編碼。同理，可以將邏輯塊組ID轉(zhuǎn)化成Base32編碼方式。但由于邏輯塊組ID沒有范圍，因此邏輯塊組ID編碼后的結(jié)果長度并不固定。通過計算可以得知，當(dāng)塊大小為64 MB時，1 PB的磁盤大約會分割為16M（16×1 024×1 024）個文件塊，即224個。此時邏輯塊組ID的編碼長度不超過5，即當(dāng)系統(tǒng)容量達(dá)到1 PB時，文件名主名長度部分不超過9。

2.3 文件寫入方法

（1） 寫入新文件方法

系統(tǒng)的寫入新文件方法如圖2所示。用戶向系統(tǒng)發(fā)起寫入請求時，NameNode會返回給用戶一個可寫塊，并對該可寫塊加寫鎖，其余用戶不能對該塊進(jìn)行讀寫訪問。待文件寫入完成后，NameNode會將該塊的寫鎖取消，其余用戶才能訪問該塊。

（2） 更新文件方法

更新必須在原塊上進(jìn)行，但是如果更新后的文件大于更新前的文件，且原來的塊空間又已經(jīng)不足時，系統(tǒng)將會發(fā)生錯誤。通過擴(kuò)展塊解決此問題。當(dāng)更新后的文件數(shù)據(jù)大小小于更新前時，直接對文件進(jìn)行覆蓋。而當(dāng)更新后的文件數(shù)據(jù)大小大于更新前時，DataNode會先在原塊上更新，然后將多余部分寫入到擴(kuò)展塊中。

（3） 數(shù)據(jù)一致性

系統(tǒng)使用讀寫鎖控制邏輯塊的讀寫。當(dāng)邏輯塊被加讀鎖時，其余用戶仍然可以對其發(fā)生讀訪問，但如果邏輯塊被加寫鎖，說明該塊可能正在發(fā)生修改，其余用戶無法對其發(fā)起任何訪問請求。同時，在設(shè)計邏輯塊的元數(shù)據(jù)時，設(shè)置了一個字段為該邏輯塊的版本號，并結(jié)合該塊的鎖信息，對版本號設(shè)置了一個有效期。在NameNode返回用戶可寫塊ID時，會同時返回用戶該塊的版本號以及當(dāng)前版本號的有效期。在用戶寫入數(shù)據(jù)前，DataNode會先驗證版本號是否正確，以及是否過期，只有當(dāng)版本號合法時，DataNode才會將文件數(shù)據(jù)寫入到該塊中。寫入完成之后，版本號會進(jìn)行遞增，并隨寫入狀態(tài)一起匯報。只有當(dāng)NameNode收到的各DataNode版本號均沒有過期失效，且一致符合預(yù)期時，文件才會被認(rèn)為寫入成功。

2.4 文件讀取方法

在讀取文件時，系統(tǒng)會對相應(yīng)的邏輯塊加讀鎖，其余用戶能夠?qū)υ搲K發(fā)起讀訪問，但不能向其發(fā)起寫訪問。文件讀取方法如圖3所示。

2.5 文件備份方法

存儲節(jié)點對邏輯塊的管理方法類似RAID10機制，但與之不同的是，單位存儲單元不是一整塊磁盤，而是一個邏輯塊。這樣的設(shè)計能夠極大地提高系統(tǒng)的可伸縮性[9]。因為無論加入或退出的節(jié)點磁盤空間多大，都是以邏輯塊為單位對存儲數(shù)據(jù)資源進(jìn)行組織，只是邏輯塊的多少不同。在系統(tǒng)擴(kuò)展過程中，容量擴(kuò)充的本質(zhì)是邏輯塊的擴(kuò)充，而與擴(kuò)充的硬件設(shè)備的物理屬性無關(guān)，系統(tǒng)在可伸縮性方面性能較好。

2.6 文件刪除方法

當(dāng)用戶刪除文件時，系統(tǒng)并不會立即刪除該文件對應(yīng)的塊內(nèi)實際數(shù)據(jù)并整理塊內(nèi)數(shù)據(jù)和塊內(nèi)索引，而是在元數(shù)據(jù)中對該文件設(shè)置一個標(biāo)志位，標(biāo)識該文件的刪除狀態(tài)。雖然通過設(shè)置刪除狀態(tài)的方法會產(chǎn)生塊內(nèi)碎片，但由于分布式文件系統(tǒng)的容量較大，且在本文所設(shè)計系統(tǒng)的應(yīng)用背景中刪除行為較少，因此每天產(chǎn)生的碎片并不會過多，對系統(tǒng)不會造成較大的影響。對于刪除行為所產(chǎn)生的碎片，系統(tǒng)可以定時對碎片占其所在文件塊的比例超過一定閾值的塊進(jìn)行整理，并且可以將定時設(shè)置在午夜，即用戶訪問流量最小時，使整理塊內(nèi)碎片對系統(tǒng)的影響降到最低。

3 系統(tǒng)應(yīng)用與測試

3.1 系統(tǒng)應(yīng)用介紹

分布式文件系統(tǒng)將應(yīng)用于某社交網(wǎng)絡(luò)產(chǎn)品，該產(chǎn)品一項重要的功能是分享美圖。因此，該產(chǎn)品的服務(wù)器端將存儲大量用戶上傳的圖片數(shù)據(jù)，并且這些圖片數(shù)據(jù)大部分都是一次寫入，少量刪除，多次讀取。為了節(jié)約服務(wù)器帶寬和用戶流量，在該產(chǎn)品內(nèi)，用戶上傳的圖片大多不超過100 KB，但數(shù)量龐大，并且隨著時間的發(fā)展，用戶的增長，未來服務(wù)器端將會積攢出大量的小文件。為了解決這些文件在服務(wù)器端的存儲問題，本文所設(shè)計和實現(xiàn)的分布式文件系統(tǒng)作為一個服務(wù)端組件為服務(wù)端提供實時的、透明的文件讀寫服務(wù)。

3.2 讀寫性能測試

（1） 面對不同尺寸文件的讀寫性能

使用程序生成了大量內(nèi)容不同尺寸不同的文件。由于在正常情況下，互聯(lián)網(wǎng)中的圖片大小都不超過10 MB，因此生成文件大小分別為1 KB，10 KB，100 KB，1 MB，10 MB，50 MB，每種大小的文件各生成1 000個。使用這些文件對系統(tǒng)進(jìn)行了讀寫性能測試，統(tǒng)計計算系統(tǒng)的讀寫平均響應(yīng)時間，結(jié)果見表1。

表1統(tǒng)計了大小為1 KB～50 MB的文件在系統(tǒng)上的讀寫性能。平均讀寫響應(yīng)時間基本成線性增長，但在文件較小時平均讀寫響應(yīng)時間相差不多。經(jīng)過分析，說明在文件較小時，系統(tǒng)花費時間主要在磁盤讀寫上，在硬件方面可以通過更換SSD磁盤在一定程度上提高系統(tǒng)的性能。而在文件較大時，系統(tǒng)花費時間主要在網(wǎng)絡(luò)I/O上，在硬件方面可以通過將網(wǎng)卡或交換機更換至千兆或萬兆帶寬提高系統(tǒng)性能。

（2） 使用不同副本數(shù)量策略的文件讀寫性能

系統(tǒng)為每個文件創(chuàng)建副本能夠有效地提高數(shù)據(jù)的安全性，由于創(chuàng)建副本會增加系統(tǒng)資源消耗，因此使用會對系統(tǒng)性能產(chǎn)生一定影響。使用程序生成了大量內(nèi)容不同的小文件，平均大小為100 KB。使用這些文件分別對系統(tǒng)針對副本數(shù)量為1～3的情況進(jìn)行讀寫測試，分別執(zhí)行寫操作和讀操作10 000次，統(tǒng)計計算系統(tǒng)的讀寫平均響應(yīng)時間，結(jié)果見表2。

表2統(tǒng)計對比了系統(tǒng)使用不同副本數(shù)時在文件讀寫性能上的測試結(jié)果。通過對比可以發(fā)現(xiàn)，如果系統(tǒng)使用副本策略，在文件讀取方面，平均響應(yīng)時間基本相同。而在文件寫入方面，如果系統(tǒng)使用副本策略，平均響應(yīng)時間要大于不使用副本策略的情況。經(jīng)過分析，在使用副本策略情況下時，增加的延遲主要為寫入副本過程花費的時間，其中包括網(wǎng)絡(luò)I/O，磁盤I/O，以及校驗過程。但由于推送寫入副本過程是異步的，因此副本數(shù)為2和副本數(shù)為3，對系統(tǒng)的寫入平均響應(yīng)時間影響較小。

（3） 面向海量小文件的讀寫性能測試

使用程序生成了大量內(nèi)容不同的小文件，平均大小為100 KB，系統(tǒng)保存副本數(shù)為3。使用這些文件分別對系統(tǒng)和HDFS進(jìn)行讀寫性能測試，其中讀寫操作比例為5[∶]1，共測試12萬次，統(tǒng)計計算讀寫平均響應(yīng)時間。通過表3中的對比數(shù)據(jù)可以看出，本文實現(xiàn)系統(tǒng)在小文件的讀寫上相較于HDFS具有更好的性能，平均響應(yīng)時間小于HDFS響應(yīng)時間的20%。

4 結(jié) 論

本文在深入研究分布式文件系統(tǒng)的可伸縮性相關(guān)理論后，設(shè)計并實現(xiàn)了一套可伸縮的分布式海量文件存儲系統(tǒng)。針對當(dāng)前互聯(lián)網(wǎng)中大部分資源文件尺寸小、規(guī)模大的特點，進(jìn)一步優(yōu)化了分布式文件系統(tǒng)，確保了在實際應(yīng)用中的可伸縮性與小文件的存儲能力和讀寫效率。

根據(jù)本文系統(tǒng)可伸縮架構(gòu)設(shè)計和海量小文件的存儲與讀寫方法，本文設(shè)計完成了一套分布式文件存儲系統(tǒng)。從理論上完成了可伸縮文件系統(tǒng)的設(shè)計；在實踐中實現(xiàn)并驗證了該文件系統(tǒng)的有效性。并針對海量小文件存儲和讀寫的特定應(yīng)用場景進(jìn)行了相應(yīng)的性能優(yōu)化。

參考文獻(xiàn)

[1] 周大水，馬紹漢.RAID1的實現(xiàn)策略及性能研究[J].計算機研究與發(fā)展，1997，34（2）：137?142.

[2] 楊華南，金海.RAID10：高I/O性能和高可靠性的完美結(jié)合[J].小型微型計算機系統(tǒng)，1998，19（8）：63?66.

[3] 周江，王偉平，孟丹，等.面向大數(shù)據(jù)分析的分布式文件系統(tǒng)關(guān)鍵技術(shù)[J].計算機研究與發(fā)展，2014，51（2）：382?394.

[4] 尹向東，楊杰，屈長青.云計算環(huán)境下分布式文件系統(tǒng)的負(fù)載平衡研究[J].計算機科學(xué)，2014（3）：141?144.

[5] 程付超，苗放，陳墾.自適應(yīng)的分布式文件系統(tǒng)元數(shù)據(jù)管理模型[J].計算機工程與設(shè)計，2014，35（3）：867?874.

[6] 趙鐵柱，袁華強.分布式文件系統(tǒng)性能研究[J].東莞理工學(xué)院學(xué)報，2014，21（1）：20?24.

[7] 羅天鑫，陳長慶，蔣帥.RAID5磁盤陣列數(shù)據(jù)安全對策分析[J].青春歲月，2012（20）：423.

[8] 王赟.磁盤陣列的數(shù)據(jù)安全與數(shù)據(jù)修復(fù)分析[J].數(shù)字技術(shù)與應(yīng)用，2012（1）：186.

[9] 謝斌，高揚.Linux高可用集群心跳機制研究[J].計算機工程與應(yīng)用，2004，40（1）：65?67.