面向城軌線網的海量小文件存儲方法

劉　靖　廖家趙　劉　瓊

1(廣州市地下鐵道總公司建設事業總部　廣東 廣州 510380)2(華南理工大學計算機科學與工程學院　廣東 廣州 510006)

?

面向城軌線網的海量小文件存儲方法

劉靖1廖家趙2劉瓊2

1(廣州市地下鐵道總公司建設事業總部廣東 廣州 510380)2(華南理工大學計算機科學與工程學院廣東 廣州 510006)

城軌線網小文件數據量巨大，傳統的分布式文件系統很難為海量小文件存儲提供符合需求的高吞吐、低延遲讀寫過程。根據城軌線網級業務的數據特點和以天為周期的數據訪問方式，提出基于FastDFS分布式文件系統和Redis鍵值數據庫的城軌線網海量小文件存儲方法，將具有相關性的城軌小文件合并成大文件進行聚合寫操作；根據FastDFS返回的大文件索引、小文件存儲起始偏移量和小文件長度建立全局索引，利用Redis存儲小文件名和全局索引的鍵值對；采用數據預取機制，預取創建時間相鄰的數據。實驗結果表明，相較于FastDFS系統，FastDFS-Redis系統的小文件讀寫吞吐量分別提高了9.35%和4.45%，達到明顯改善城軌線網海量小文件的訪問效率的目的。

小文件存儲城軌線網FastDFSRedis訪問性能

0　引　言

隨著城市軌道交通(簡稱城軌)線路規模的增長，建立城軌線網數據中心對線路實施集中管理的需求日益凸顯。城軌線網數據中心面臨存儲管理海量數據的需求。城軌線網數據包括結構化數據和非結構化數據，尤其非結構化數據種類繁多，從便于存儲管理的角度，非結構化數據可以歸為大文件(如視頻、文檔)和小文件(如圖片、報表)。大文件存儲技術(如HDFS文件系統[1])已有成熟的技術和系統，已經得到較好的效果，而小文件的高效存儲問題尚未得到很好的解決。通常而言，容量在1MB以內的文件被認為是小文件，城軌線路存在大量的小文件，僅從廣州城軌的報表類文件進行分析可知，現有9條線路投入運營，共164個車站，每個車站每天平均生成大約100個日報表。由此，城軌線網數據中心每天將產生約16 400個日報表，這些報表的平均大小為500 KB。

主流的文件存儲系統通常面向大文件的特點設計，海量小文件的存儲管理存在三個方面的問題：1)元數據管理低效[2]，由于當前主流的文件系統是面向大文件的順序訪問特點設計的，索引節點、數據和目錄分別保存在磁盤的不同位置。因此訪問一個文件至少需要訪問磁盤的三個不同位置，使得并發的小文件訪問轉變成大量的隨機訪問，隨之帶來的磁頭的頻繁移動顯著地降低傳統機械磁盤的讀寫性能。2)I/O訪問流程復雜：主流的操作系統采用虛擬文件系統VFS(Virtual File System)作為文件系統的抽象接口。其中包括四種數據對象：超級塊對象、索引結點對象、文件對象和目錄項對象。由于在用戶態中使用路徑名表示文件，因此在打開文件時需要將文件的路徑名進行分量解析，轉換成對應文件在內核中的四種數據對象，此過程占用的系統開銷非常大。3)數據布局單一：為了便于用戶對文件進行并發的訪問，分布式文件系統通常采用條帶化技術切分文件，將某個文件的各部分存儲到多個數據服務器。然而，小文件容量較小，不宜進行條帶化，只能將單個小文件存儲在單個數據服務器中，原來的多服務器并發訪問變成單服務器訪問。因此當大量訪問某個服務器的小文件時，將使數據服務器的性能大幅下降。

目前，海量小文件存儲優化已經成為熱點技術，如Yahoo使用PNUTS[3]為其應用平臺提供數據存儲服務；Amazon使用Dynamo系統[4]解決其電子商務應用的數據存儲問題；Facebook使用Haystack系統[5]存儲百億級別的社交圖片；Google 使用BigTable[6]系統來存儲其海量的Google地球圖片和網頁索引。上述系統都經歷了實踐的檢驗，能夠高效地存儲數以億計的小對象或小文件。然而，這些存儲系統專門針對社交網絡或電子商務等互聯網應用而設計，存儲數據多為Web類應用數據。城軌線網海量小文件訪問針對地鐵專業系統的非結構化數據，具有層次性和周期性的特點?，F有的海量小文件存儲系統與城軌線網海量小文件存儲系統具有不同的設計需求，難以直接應用于城軌線網海量小文件數據存儲。因此，為城軌線網數據中心提供高效的海量小文件存儲訪問技術迫在眉睫。

本文針對城軌線網海量小文件存儲的需求，指出部分已有海量小文件存儲訪問技術的局限性，從城軌線網業務分層的特點和數據周期性訪問方式出發，提出基于FastDFS分布式文件系統和Redis鍵值數據庫的城軌線網海量小文件存儲方法。首先，將同一線路同一地鐵專業系統同一天產生的小文件合并成大文件進行聚合寫操作。其次，根據FastDFS分布式文件系統返回的大文件索引、小文件存儲的起始偏移量和小文件長度建立全局索引，使用Redis鍵值數據庫存儲小文件名與全局索引的鍵值對。最后，采用數據預取機制，預取創建時間相鄰的數據。

1　相關研究

本文方法從小文件合并優化和元數據管理優化技術出發，研究已有工作的優勢和不足。

1.1小文件合并優化

當Linux文件系統維護大量的小文件時，inode的管理容易成為性能瓶頸，將小文件合并成數據塊文件可以減少文件個數，有效地降低 inode管理負載。Liu等[7]根據地理信息數據的特征，將具有地理相關性的小文件合并成同一個大文件，并為這些小文件建立全局哈希索引，以便對小文件進行存取。Bo等[8]針對中國電子教學共享系統Bluesky的特點，將屬于同一個教學課件的文件合并成同一個大文件，并且提出一種索引文件預取與數據文件預取結合的數據預取機制，以解決電子課件小文件存儲的問題。張春明等[9]根據“中華字庫”工程小文件之間的相關性和文獻的目錄結構，將同一文獻的圖片文件合并成大文件，并建立分層索引，同時使用索引文件和數據文件的預取機制以提高順序讀的效率。以上文獻針對具體應用的數據特點，將具有強數據相關性的小文件合并成大文件進行訪問，但是HDFS最初是面向存儲海量大文件設計的。因此受限于其存儲結構，海量小文件的訪問性能很難得到本質的提升。相比以上研究工作，本文提出方法基于的FastDFS分布式文件系統是面向存儲海量中小文件的需求設計的。其重要特點是將文件元數據存儲在FastDFS文件索引中，返回給客戶端，大大減少元數據管理服務器的負擔。

1.2元數據管理優化

元數據管理低效是海量小文件存儲訪問性能低下的主要原因之一。Luo等[10]使用基于Fat-Btree的索引結構，解決海量的小文件訪問時元數據服務器的內存占用問題，但是該方法沒有從整體系統架構考慮，優化性能受到限制。Philip等[11]在PVFS[12]文件系統中使用分批提交的方式提交元數據以降低數據訪問延遲。但是，此方法局限于在PVFS文件系統中使用，過分依賴PVFS的存儲結構。相比以上研究工作，本文提出的方法使用Redis鍵值數據庫，存儲小文件名與文件全局索引的鍵值對，進行元數據管理，不局限于特定的分布式文件系統。

2　FastDFS-Redis存儲方案

本文提出的FastDFS-Redis小文件存儲方法包括：(1)將具有相關性的城軌小文件合并成大文件進行聚合寫操作；(2)根據FastDFS分布式文件系統返回的大文件索引、小文件的起始偏移量和文件長度建立全局索引，使用Redis鍵值數據庫存儲原始文件名與全局索引的鍵值對；(3)采用數據預取機制，預取創建時間相鄰的數據。

2.1相關系統

2.1.1FastDFS分布式文件系統

FastDFS[13]是一個開源的輕量級分布式文件系統，面向海量中小文件的存儲需求進行設計，由跟蹤服務器、存儲服務器和客戶端三個部分組成，其基本架構如圖1所示。

圖1　FastDFS分布式文件系統的架構圖

FastDFS服務端有三個角色：跟蹤服務器、存儲服務器和客戶端。跟蹤服務器在內存中記錄集群中所有存儲組和存儲服務器的狀態信息，是客戶端和數據服務器交互的樞紐，主要負責存儲服務器的調度工作。相比GFS[14]中的元數據管理服務器更為精簡，跟蹤服務器不記錄文件索引信息，占用的內存量很少。存儲服務器存儲文件和文件屬性，以組為單位組織，一個組內可以包含多臺存儲服務器，同組內的存儲服務器的數據互為備份?？蛻舳俗鳛闃I務請求的發起方，當需進行文件讀寫的時候，向跟蹤服務器詢問可用的存儲服務器地址，然后直接與存儲服務器連接，進行文件讀寫操作。

2.1.2Redis鍵值數據庫

Redis[15]是一個開源的基于內存的高性能鍵值數據庫。與Memcached[16]相同的是，為了提高讀寫的效率，數據都是存儲在內存中的，提供快照和AOF兩種數據持久化方式。與Memcached不同的是，它支持存儲的值類型相對更多，包括字符串、鏈表、集合、有序集合和哈希表。

2.2線網小文件合并

城軌線網業務系統具有層級特點，包括線路車站級系統、線路控制中心級系統和線網中心級系統，如圖2所示。城軌線網小文件數據由車站數據、線路控制中心數據和線網數據中心數據組成，其特點是同一線路專業系統的文件具有很強的相關性，每個文件名按照車站、專業系統和創建時間共同組成。

圖2　廣州城軌線網系統層次結構圖

各城軌線路將以地鐵專業系統為級別按周期(如以一天或半天為周期)向線網數據中心寫入小文件。同時線網數據訪問具有局部性，往往讀取相同地鐵專業系統的創建時間連續的文件。因此，本方法首先在客戶端將同一線路同一地鐵專業系統同一天產生的小文件合并成大文件，再將大文件寫入到FastDFS文件系統中。

2.3全局索引存儲

在FastDFS分布式文件系統中，客戶端向存儲服務器寫入文件后，存儲服務器會向客戶端返回該文件的文件索引，以便客戶端以該文件索引為參數讀取文件。文件索引信息包含了文件的主要元數據，其組成如圖3所示，包括組名、虛擬磁盤路徑、數據兩級目錄和文件名。

圖3FastDFS索引組成圖

其中，組名為文件上傳后所在的存儲組名稱；虛擬磁盤路徑為存儲服務器配置的虛擬路徑；數據兩級目錄為存儲服務器在每個虛擬磁盤路徑下創建的兩級目錄；文件名是由存儲服務器根據特定信息生成，文件名包含存儲服務器IP地址、文件創建時間戳、文件大小、隨機數和文件拓展名等信息。

FastDFS返回索引給客戶端，而不是將文件索引存儲在跟蹤服務器，降低了跟蹤服務器的負擔，但是沒有從根本上解決海量小文件的文件索引的元數據存儲和管理問題。

因此，本方法將FastDFS返回的大文件索引、小文件在大文件存儲的起始偏移量和小文件長度合并構造全局索引，如圖4所示。并使用Redis鍵值數據庫存儲小文件名與文件索引的鍵值對，從而提高元數據查找的效率。

圖4　全局索引組成圖

2.4數據預取

數據預取是行之有效的存儲優化技術[8]，其原理是利用應用的局部性特征預先讀取數據，從而減少磁盤I/O的訪問次數，有效提高數據訪問的性能?？紤]到同一地鐵專業系統小文件的相關性和用戶訪問的局部性特征，本方法采用數據預取機制讀取文件。

城軌線網數據讀取的特點是往往讀取相同地鐵專業系統同一時間段寫入的文件，具有局部性。本方法是當客戶端讀取某個地鐵專業系統的小文件時，預取與該文件相同地鐵專業系統的創建時間相鄰的10個文件。

3　FastDFS-Redis存儲系統

本文基于FastDFS 分布式文件系統和Redis數據庫，建立了面向城軌線網海量小文件的FastDFS-Redis存儲系統，其架構如圖5所示。FastDFS-Redis存儲系統有四個角色：跟蹤服務器、存儲服務器、Redis鍵值數據庫和客戶端。跟蹤服務器主要用于管理存儲服務器，起到負載均衡的作用，在內存中記錄集群中所有存儲組和存儲服務器的狀態信息；存儲服務器用于存儲來自客戶端上傳的文件；Redis鍵值數據庫用于存儲小文件名與全局索引的鍵值對；客戶端通過跟蹤服務器獲得可用的存儲服務器的地址，然后直接與存儲服務器連接進行讀寫。

圖5　FastDFS-Redis架構圖

3.1小文件寫入流程

如圖5所示，客戶端向FastDFS-Redis系統寫入小文件的流程包括如下步驟：

步驟1客戶端將同一線路同一地鐵系統同一天產生的小文件合并成大文件，并記錄小文件在大文件的起始偏移量和文件長度；

步驟2客戶端向跟蹤服務器詢問可用存儲服務器的地址；

步驟3跟蹤服務器向客戶端返回一臺可用存儲服務器的IP地址和端口號；

步驟4客戶端直接與存儲服務器建立連接，并向其寫入大文件，寫入完成后，存儲服務器向客戶端返回新生成的大文件索引；

步驟5客戶端結合FastDFS返回的大文件索引、小文件的起始偏移量和文件長度建立全局索引，使用Redis存儲小文件名和全局索引的鍵值對。

3.2小文件讀取流程

如圖5所示，客戶端從FastDFS-Redis系統讀取小文件的流程包括如下步驟：

步驟1客戶端根據小文件名在Redis數據庫中獲取小文件名對應的全局索引；

步驟2客戶端從全局索引獲取對應大文件的索引，向跟蹤服務器詢問可以下載大文件的存儲服務器，參數為大文件索引；

步驟3跟蹤服務器向客戶端返回一臺可用的存儲服務器的IP地址和端口號；

步驟4客戶端直接與該存儲服務器建立連接，讀取大文件；

步驟5客戶端根據全局索引中的文件起始偏移量和文件長度從大文件中預取與該文件創建時間相鄰的10個文件。

4　性能評測

4.1實驗環境

本文的實驗環境由四臺服務器組成。三臺服務器是Dell T110II，Intel Xeon E3-1220 3.1 GHz，8 GB內存，500 GB硬盤，一臺服務器是Intel E750 2.93 GHz，4 GB內存，320 GB硬盤。網絡環境是百兆以太網。其中兩臺Dell T110II機器各組成一個存儲組，每個組內有一臺存儲服務器。有一臺Dell T110II機器作為Redis數據庫，最后一臺機器作為跟蹤服務器。每臺服務器的操作系統是Ubuntu Server 14.04。

4.2實驗數據

實驗數據由廣州地鐵報表數據組成，分別是文件大小為50 KB、100 KB、200 KB、500 KB和1 MB的報表各10 000個。各類數據由廣佛線路ACS系統近100天的報表文件挑選而成。

4.3實驗對比

本文實驗對比的主要指標是FastDFS系統和FastDFS-Redis系統讀取和寫入小文件吞吐量，即每秒讀寫小文件的數據量。每項測試重復四次，取實驗數據的平均值作為最終的實驗結果。

4.3.1小文件寫入性能對比

分別向FastDFS系統和FastDFS-Redis系統寫入文件大小為50 KB、100 KB、200 KB、500 KB和1 MB的報表各10 000個，各吞吐量統計數據如表1所示。由于FastDFS-Redis方法采用了合并小文件進行聚合寫操作的方法，客戶端與存儲服務器的網絡交互次數明顯減少，因此 FastDFS-Redis的吞吐量普遍大于FastDFS的吞吐量。FastDFS-Redis系統和FastDFS系統的平均吞吐量分別為8.34和7.98 MB/s，因此FastDFS-Redis系統提高了4.45%的寫吞吐量。實驗結果表明，FastDFS-Redis存儲方案能夠提高海量小文件在城軌線網場景下的寫入性能。

表1　FastDFS和FastDFS-Redis的小文件寫入吞吐量統計表

根據表1可以得到FastDFS和FastDFS-Redis的小文件寫入吞吐量對比圖，如圖6所示。

圖6　FastDFS和FastDFS-Redis的小文件寫入吞吐量對比

4.3.2小文件讀取性能對比

城軌線網讀取數據的請求具有以組為單位的特點，每組讀請求是隨機的，組內的讀請求是順序的。因此，為模仿在城軌線網場景下的小文件讀取行為，分別對各類型的報表文件發出1000組隨機讀請求，其中每組包含9個順序讀請求。FastDFS系統和FastDFS-Redis系統各情況的讀取吞吐量統計數據如表2所示。FastDFS-Redis的吞吐量普遍大于FastDFS的吞吐量。FastDFS-Redis系統和FastDFS系統的平均吞吐量分別為7.86和7.19 MB/s，因此FastDFS-Redis系統提高了9.35%的讀吞吐量。實驗結果表明，FastDFS- Redis存儲方案能夠顯著提高海量小文件在城軌線網場景下的讀取性能。

表2　FastDFS和FastDFS-Redis的小文件讀取吞吐量統計表

根據表2可以得到FastDFS和FastDFS-Redis的小文件讀取吞吐量對比圖，如圖7所示。

圖7　FastDFS和FastDFS-Redis的小文件讀取吞吐量對比

5　結　語

本文提出并實現一種優化城軌線網海量小文件存儲效率的方法。主要工作有：

1) 將具有相關性的城軌小文件合并成大文件進行聚合寫操作；

2) 結合FastDFS返回的大文件索引、小文件的起始偏移量和文件長度建立全局索引，利用Redis存儲小文件名和全局索引的鍵值對；

3) 采用數據預取機制，預取創建時間相鄰的數據。

相較于FastDFS系統，該方法實現的FastDFS-Redis系統提高了4.45%的寫吞吐量和9.35%的讀吞吐量。證明FastDFS- Redis存儲方案能夠顯著提高城軌線網小文件的讀寫性能。下一步的工作是利用用戶態文件系統接口實現FastDFS-Redis系統的POSIX文件訪問接口，提高系統的可用性和擴展性。

[1] Konstantin Shvachko,Hairong Kuang,Sanjay Radia,et al.The Hadoop Distributed File System[C]//Proceedings of the 26th IEEE Symposium on Mass Storage Systems and Technologies,2010.

[2] 王玲惠,李小勇,張軼彬.海量小文件存儲系統研究綜述[J].計算機應用與軟件,2012,29(8):106-109.

[3] Cooper B F,Ramakrishnan R,Srivastava U,et al.PNUTS:Yahoo!’s hosted data serving platform[C]//Proc.of the VLDB Endowment,2008.

[4] DeCandia G,Hastorun D,Jampani M,et al.Dynamo:Amazon’s highly available key-value store[C]//Proceedings of the 25st ACM SIGOPS Symposium on Operating Systems Principles,New York,USA,2007.

[5] Beaver D,Kumar S,Li H C,et al.Finding a needle in haystack:facebook's photo storage[C]//Proceedings of the 9th USENIX Symposium on Operating System Design and Implementation(OSDI’10),Vancouver,Canada,2010.

[6] Fay Chang,Jeffrey Dean,Sanjay Ghemawat,et al.Bigtable:a distributed storage system for structured data[C]//Proceedings of the 7th USENIX Symposium on Operating System Design and Implementation (OSDI’06),2006.

[7] Xuhui Liu,Jizhong Han,Yunqin Zhong,et al.Implementing WebGIS on Hadoop:A Case Study of Improving Small File I/O Performance on HDFS[C]//Proc.of the 2009 IEEE Conf.on Cluster Computing,2009.

[8] Bo Dong,Jie Qiu,Qinghua Zheng,et al.A Novel Approach to Improving the Efficiency of Storing and Accessing Small Files on Hadoop:A Case Study by PowerPoint Files[C]//Proceedings of IEEE SCC,2010.

[9] 張春明,芮建武,何婷婷.一種Hadoop小文件存儲和讀取的方法[J].計算機應用與軟件,2012,29(11):95-100.

[10] Luo Min,Yokota H.Comparing Hadoop and fat-tree based access method for small file I/O applications[C]//Proc.of the 11th Int Conf on Web-Age Information Management,Berlin:Springer,2010.

[11] Philip Carns,Sam Lang,Robert Ross,et al.Small-File Access in Parallel File systems[C]//Proceedings of the 23rd IEEE International Parallel and Distributed Processing Symposium,2009.

[12] Carns P H,Ligon W B,Ross B R,et al.PVFS:A parallel file system for Linux cluster[C]//Proceedings of the 4th Annual Linux Showcase&Conf.Berkeley,CA:USENIX Association,2000.

[13] 余慶.FastDFS[CP/OL].https://code.google.com/p/fastdfs/.

[14] Ghemawat S,Gobioff H,Leung S T.The Google file system[C]//Proc. of the 19th ACM Symp.on Operating Systems Principles (SOSP 2003),New York:ACM Press,2003.

[15] Salvatore Sanfilippo.Redis[CP/OL].http://redis.io/.

[16] LiveJournal Corporation.Memcached[CP/OL].http://memcached .org/.

AN APPROACH TO STORING MASSIVE SMALL FILES FOR URBAN RAIL TRANSIT NETWORK

Liu Jing1Liao Jiazhao2Liu Qiong2

1(ConstructionDivision,GuangzhouMetroCorporation,Guangzhou510380,Guangdong,China)2(SchoolofComputerScienceandEngineering,SouthChinaUniversityofTechnology,Guangzhou510006,Guangdong,China)

Because of the great amount of small files for urban rail transit network system, traditional distributed file system is difficult to provide read and write process with high throughput and low latency meeting the demand for massive small files storage. According to the data characteristics of urban rail transit network system and the data access method cycled in day, we propose an approach of storing massive small files for urban rail transit network, which is based on FastDFS distributed file system and Redis key-value database. The method merges the small files with correlation for urban rail transit into a big file to accomplish the aggregated writing operation; It forms the global index according to the big file indexes returned by FastDFS, the initial offset of small file storage and the lengths of small files, and uses Redis to store key-value pair of the filename of small file and global index; It adopts data prefetching mechanism to prefech the files with adjacent creation time. Experimental results show that compared with FastDFS distributed file system, the read throughput and write throughput of small files in FastDFS-Redis storage system increase by 9.35% and 4.45% respectively, which reaches the goal of noticeably improving the small file access efficiency for urban rail transit network.

Small file storageUrban rail transit networkFastDFSRedisAccess performance

2014-12-29。劉靖，教授級高工，主研領域：城市軌道交通機電一體化，自動化控制和通信工程。廖家趙，碩士生。劉瓊，教授。

TP311

A

10.3969/j.issn.1000-386x.2016.08.017