針對海量小文件的可伸縮分布式文件系統研究

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

關鍵詞： 可伸縮性； 分布式系統； 文件系統； 小文件

中圖分類號： TN911?34； TM417 文獻標識碼： 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 引 言

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

1 系統的可伸縮架構設計

1.1 系統設計目標

本系統的設計目標重點圍繞高可伸縮性，高可伸縮性代表的是一種彈性，當文件系統的容量不足，系統需要擴展時，軟件系統能夠通過較少的改動，甚至僅僅通過添加硬件設備，就能夠實現整個軟件系統處理能力的線性增長。

1.2 系統概述

根據微軟提出的系統優化金字塔，設計優化、代碼優化、產品優化、硬件優化對整個系統的優化影響依次遞減。由此可見，位于金字塔底部的設計優化對系統各種性能的影響最大。鑒于系統的設計目標，本文分布式文件系統將構筑在高速局域網連接的普通服務器集群上，以期達到利用廉價的服務器集群實現高可伸縮的軟件系統的目的。本系統采用主從架構，系統內節點分為NameNode和DataNode。對于元數據管理采用集中式管理方法，將元數據集中于NameNode中進行管理，DataNode為文件的實際存儲節點[3]。

1.3 可伸縮系統架構

1.3.1 系統整體架構

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

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

1.3.2 DataNode節點內部結構

DataNode為系統中文件數據實際的存儲節點，負責實際數據的存儲和讀寫。本文設計在存儲節點的機器上，針對每塊磁盤創建一個DataNode實例，單獨管理此塊磁盤，不僅能使單塊磁盤的讀寫性能達到最優，同時也能極大地降低單塊磁盤故障對系統帶來的影響[4]。

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

1.3.3 NameNode節點內部結構

NameNode主要負責管理和維護元數據，即邏輯塊的相關信息，包括邏輯塊的創建、備份、負載均衡、刪除等。同時，NameNode還負責接收DataNode的心跳包，并根據心跳維護系統內DataNode的加入和退出[6]。

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

1.3.4 平滑擴容方法

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

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

2.1 元數據管理方法

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

2.2 模型理論基礎及假設

NameNode并沒有保存存儲文件的元數據，而僅保存了邏輯塊的元數據。同時，實現的分布式文件系統應用場景對文件名并不敏感。因此，將存儲文件的元數據通過編碼的方式表示在文件名主名部分，擴展名不變，如圖1所示。

存儲文件的元數據主要包括該文件存儲的邏輯塊組ID以及該文件在塊內索引的File ID。由于邏輯塊的大小的限制，File ID的范圍是有限的。可以粗略估算，File ID是不會超過230的。因此，File ID可以用30位二進制數進行表示。將這30位二進制數拆分成6組長度為5的二進制數，然后轉換成6個十進制數，并根據Base32的對應關系，將其轉換成長度為6的Base32編碼。同理，可以將邏輯塊組ID轉化成Base32編碼方式。但由于邏輯塊組ID沒有范圍，因此邏輯塊組ID編碼后的結果長度并不固定。通過計算可以得知，當塊大小為64 MB時，1 PB的磁盤大約會分割為16M（16×1 024×1 024）個文件塊，即224個。此時邏輯塊組ID的編碼長度不超過5，即當系統容量達到1 PB時，文件名主名長度部分不超過9。

2.3 文件寫入方法

（1） 寫入新文件方法

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

（2） 更新文件方法

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

（3） 數據一致性

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

2.4 文件讀取方法

在讀取文件時，系統會對相應的邏輯塊加讀鎖，其余用戶能夠對該塊發起讀訪問，但不能向其發起寫訪問。文件讀取方法如圖3所示。

2.5 文件備份方法

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

2.6 文件刪除方法

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

3 系統應用與測試

3.1 系統應用介紹

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

3.2 讀寫性能測試

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

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

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

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

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

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

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

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

4 結 論

本文在深入研究分布式文件系統的可伸縮性相關理論后，設計并實現了一套可伸縮的分布式海量文件存儲系統。針對當前互聯網中大部分資源文件尺寸小、規模大的特點，進一步優化了分布式文件系統，確保了在實際應用中的可伸縮性與小文件的存儲能力和讀寫效率。

根據本文系統可伸縮架構設計和海量小文件的存儲與讀寫方法，本文設計完成了一套分布式文件存儲系統。從理論上完成了可伸縮文件系統的設計；在實踐中實現并驗證了該文件系統的有效性。并針對海量小文件存儲和讀寫的特定應用場景進行了相應的性能優化。

參考文獻

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

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

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

[4] 尹向東，楊杰，屈長青.云計算環境下分布式文件系統的負載平衡研究[J].計算機科學，2014（3）：141?144.

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

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

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

[8] 王赟.磁盤陣列的數據安全與數據修復分析[J].數字技術與應用，2012（1）：186.

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