面向城轨线网的海量小文件存储方法

刘　靖　廖家赵　刘　琼

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类应用数据。城轨线网海量小文件访问针对地铁专业系统的非结构化数据，具有层次性和周期性的特点。现有的海量小文件存储系统与城轨线网海量小文件存储系统具有不同的设计需求，难以直接应用于城轨线网海量小文件数据存储。因此，为城轨线网数据中心提供高效的海量小文件存储访问技术迫在眉睫。

本文针对城轨线网海量小文件存储的需求，指出部分已有海量小文件存储访问技术的局限性，从城轨线网业务分层的特点和数据周期性访问方式出发，提出基于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]中的元数据管理服务器更为精简，跟踪服务器不记录文件索引信息，占用的内存量很少。存储服务器存储文件和文件属性，以组为单位组织，一个组内可以包含多台存储服务器，同组内的存储服务器的数据互为备份。客户端作为业务请求的发起方，当需进行文件读写的时候，向跟踪服务器询问可用的存储服务器地址，然后直接与存储服务器连接，进行文件读写操作。

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