留言板

尊敬的读者、作者、审稿人, 关于本刊的投稿、审稿、编辑和出版的任何问题, 您可以本页添加留言。我们将尽快给您答复。谢谢您的支持!

姓名
邮箱
手机号码
标题
留言内容
验证码

海量GNSS小文件云存储优化方法研究

李林阳 吕志平 崔阳 王宇谱 周海涛

李林阳, 吕志平, 崔阳, 王宇谱, 周海涛. 海量GNSS小文件云存储优化方法研究[J]. 武汉大学学报 ● 信息科学版, 2017, 42(8): 1068-1074. doi: 10.13203/j.whugis20150136
引用本文: 李林阳, 吕志平, 崔阳, 王宇谱, 周海涛. 海量GNSS小文件云存储优化方法研究[J]. 武汉大学学报 ● 信息科学版, 2017, 42(8): 1068-1074. doi: 10.13203/j.whugis20150136
LI Linyang, LV Zhiping, CUI Yang, WANG Yupu, ZHOU Haitao. The Optimized Cloud Storage Method of Massive GNSS Small Files[J]. Geomatics and Information Science of Wuhan University, 2017, 42(8): 1068-1074. doi: 10.13203/j.whugis20150136
Citation: LI Linyang, LV Zhiping, CUI Yang, WANG Yupu, ZHOU Haitao. The Optimized Cloud Storage Method of Massive GNSS Small Files[J]. Geomatics and Information Science of Wuhan University, 2017, 42(8): 1068-1074. doi: 10.13203/j.whugis20150136

海量GNSS小文件云存储优化方法研究

doi: 10.13203/j.whugis20150136
基金项目: 

国家自然科学基金 41674019

国家重点研发计划 2016YFB0501701

地理信息工程国家重点实验室开放基金 SKLGIE2016-M-1-2

详细信息

The Optimized Cloud Storage Method of Massive GNSS Small Files

Funds: 

The National Natural Science Foundation of China 41674019

the National Key Research and Development Program of China 2016YFB0501701

State Key Laboratory of Geo-information Engineering SKLGIE2016-M-1-2

More Information
图(11) / 表(1)
计量
  • 文章访问数:  1378
  • HTML全文浏览量:  64
  • PDF下载量:  379
  • 被引次数: 0
出版历程
  • 收稿日期:  2015-09-14
  • 刊出日期:  2017-08-05

海量GNSS小文件云存储优化方法研究

doi: 10.13203/j.whugis20150136
    基金项目:

    国家自然科学基金 41674019

    国家重点研发计划 2016YFB0501701

    地理信息工程国家重点实验室开放基金 SKLGIE2016-M-1-2

    作者简介:

    李林阳, 博士生, 主要从事GNSS数据处理理论与方法研究。lilinyang810810@163.com

    通讯作者: 吕志平, 博士, 教授。ssscenter@126.com
  • 中图分类号: P228.41

摘要: GNSS数据量呈指数级趋势增长,Hadoop分布式文件系统(HDFS)解决了海量GNSS数据存储瓶颈的难题,却面临内存占用多、文件相关性差和缺乏优化机制的问题。针对HDFS处理海量GNSS小文件效率不高的问题,结合GNSS数据类型、特点以及存储过程,提出了一种新的GNSS小文件云存储方法,优化了GNSS小文件的写入、读取、添加和删除策略。该方法分别按观测文件和解算成果的类型进行合并,对合并后的文件构建压缩Trie树索引,索引切分后,根据匹配算法分布式地存储索引块。实验采用国际GNSS服务(IGS)28 d的数据和产品进行云存储优化。结果表明,该方法降低了各节点内存消耗,提高了海量GNSS小文件写入、读取和删除的效率,实现了对海量GNSS小文件的高效云存储。

English Abstract

李林阳, 吕志平, 崔阳, 王宇谱, 周海涛. 海量GNSS小文件云存储优化方法研究[J]. 武汉大学学报 ● 信息科学版, 2017, 42(8): 1068-1074. doi: 10.13203/j.whugis20150136
引用本文: 李林阳, 吕志平, 崔阳, 王宇谱, 周海涛. 海量GNSS小文件云存储优化方法研究[J]. 武汉大学学报 ● 信息科学版, 2017, 42(8): 1068-1074. doi: 10.13203/j.whugis20150136
LI Linyang, LV Zhiping, CUI Yang, WANG Yupu, ZHOU Haitao. The Optimized Cloud Storage Method of Massive GNSS Small Files[J]. Geomatics and Information Science of Wuhan University, 2017, 42(8): 1068-1074. doi: 10.13203/j.whugis20150136
Citation: LI Linyang, LV Zhiping, CUI Yang, WANG Yupu, ZHOU Haitao. The Optimized Cloud Storage Method of Massive GNSS Small Files[J]. Geomatics and Information Science of Wuhan University, 2017, 42(8): 1068-1074. doi: 10.13203/j.whugis20150136
  • 随着全球、国家、区域级连续运行参考站网(Continuously Operating Reference Station System, CORS)的不断建成及联合型CORS的陆续组网和连续观测[1],GNSS数据量的规模越来越大。集中式管理方式,如文件传输协议(file transfer protocol, FTP)和关系数据库(relational database management system, RDBMS),在存储容量、并发访问、扩展性和可用性等方面面临挑战[2]。研究表明,云存储是解决海量GNSS数据存储瓶颈的一种有效途径[3]。作为云计算社区应用范围最广的平台,Hadoop[4]支持研究人员从底层研究云计算的体系结构。但Hadoop分布式文件系统(Hadoop distributed file system, HDFS)在处理海量GNSS小文件时存在3个问题[5],一是海量GNSS小文件过多占用NameNode节点的内存空间;二是GNSS小文件存储时,HDFS未顾及文件之间的相关性;三是HDFS适合流式地访问大文件,并没有提供提高海量GNSS小文件输入/输出性能的优化机制。

    针对HDFS处理小文件效率不高的问题,文献[6]基于SequenceFile文件合并技术,通过部署新的Metadata Node节点管理小文件的元数据索引;文献[7]根据文件之间的相关性将小文件分为结构相关、逻辑相关和独立的文件,并采取相应的存储机制;文献[8]提出了一种综合利用RDBMS和Hadoop各自优势、同时避免各自缺陷的小文件存储方法;文献[9]提出了一种结合用户访问规律和数据自身属性的时空数据小文件管理方案;文献[10]将保存相邻地理位置信息的WebGIS小文件合并成一个大文件,构建全局Hash索引。上述方法都采取小文件合并的策略,分别把研究重点放在了探讨元数据模型、分析小文件相关性、调整系统结构和分析用户访问规律等方面,能很好地提高小文件存储效率。但上述方法对文件类型、特点、存储过程及合并后索引的放置策略关注较少,不能完全应用于GNSS小文件的管理。

    本文根据GNSS小文件的类型、特点和实际存储过程,提出了一种新的GNSS小文件优化存储方法。实验对比了4种存储方案,验证了该方法的高效性。

    • 表 1所示,GNSS小文件主要包括两类。一是观测文件,包括观测数据、导航星历和气象文件等,遵循RINEX(receiver independent exchange format)等标准格式;二是解算成果文件,包括日解、周解、精密星历、钟差等,遵循SINEX (solution (software/technique) independent exchange format)、IONEX (ionosphere exchange format)、SP3 (NGS standard GPS format)等标准格式。表中,yy是年(year)的缩写。

      表 1  GNSS文件分类

      Table 1.  The Category of GNSS files

      文件分类 子类型 扩展名
      观测数据 yyd、yyo
      观测文件 星历文件观测文件 yyn、yyg、yyl、yyp、
      yyh、yyb、yyq
      气象文件 yym
      汇总文件 yys
      精密星历 sp3、eph
      精密钟差 clk、clk_30s、clk_05s、cls
      地球自转参数 erp
      解算成果文件 地球定向参数 eop
      DCB改正文件 dcb、bsx
      系统偏差改正文件 bia
      对流层产品 yyzpd、tro、vmf1_G…
      电离层产品 yyi
      解算坐标 snx、ssc
    • 根据国际GNSS服务(International GNSS Service, IGS)组织的数据中心CDDIS (crustal dynamics data information system)的技术报告[11],GNSS数据存储的过程主要包括以下4步。

      1) 写入。写入当天的观测文件和对应的解算成果。

      2) 添加。添加其他CORS网的观测文件;重处理后,存储新的解算结果。

      3) 用户下载。用户下载所需时段的观测数据和相对应的解算成果;同时存在大量用户并发访问的情况。

      4) 删除。主要是删除高采样率观测文件,考虑到时效性和文件大小,实际只在一定时期内保存高采样率文件,如IGS和美国大地测量局(Ntional Godetic Srvey, NGS)分别只保存前2~3个月和前1个月的高采样率观测文件。

      GNSS小文件的存储过程具有一次写入、多次读取、添加和删除部分数据的特点,对读取性能的要求高于写入性能,同时文件增减时要求不影响存储的效率。

    • 小文件写入的流程如图 1所示,共分为小文件合并、构建压缩Trie树索引、索引切分、索引块存储4个阶段。

      图  1  GNSS小文件写入流程

      Figure 1.  The Writing Flow of GNSS Small Files

    • 假设系统中存储了n个GNSS小文件,每份文件都包含位置、时间和文件类型3种参数,文件之间可以通过参数进行区分,GNSS小文件数据集可表示为:

      $$D = \left\{ {d\left( {{L_i},{T_j},{I_k}} \right),d|{L_i} \in L,{T_j} \in T,{I_k} \in I} \right\}$$ (1)

      式中,D代表GNSS小文件集合;L代表文件产生的位置信息,主要包括采集观测文件的测站和解算成果文件的机构;T代表文件产生的时间标签,是一个连续的时间序列;I代表文件类型,对应表 1中的扩展名;LT均可从文件名和文件头中获取;I可从文件扩展名和文件头中获取;i、j、k分别代表文件位置、时间和类型参数的序号,i, j, kZ

      首先,将同一类型、同一观测时段的观测文件按测站名4位字符的先后顺序合并,将同一类型、同一解算时间的解算成果文件,按分析中心名称3位字符的先后顺序合并。合并后同一类型、同一观测时段或解算时间的小文件集合DTj, Ik可表示为:

      $${D_{{T_j},{I_k}}} = \left\{ {d\left( {{L_i},{T_j},{I_k}} \right),d|{L_i} \in L,{T_j},{I_k}} \right\}$$ (2)

      式中,Tj代表第j个观测时段或解算时间;Ik代表第k个文件类型。

      然后,分别对每一类型的文件按连续的观测时段或解算时间序列进行合并。在GNSS测量中,周解具有普遍意义,因此分别将连续7 d的观测文件和7 d的日解文件合并为一个大文件,合并后同一类型的小文件集合DIk可表示为:

      $${D_{{I_k}}} = \left\{ {d\left( {{L_i},{T_j},{I_k}} \right),d|{L_i} \in L,{T_j} \in T,{I_k}} \right\}$$ (3)

      通过以上两步的合并,即可分别将连续7 d的GNSS观测文件和解算成果文件合并成一个观测时段连续的观测大文件和一个解算时间序列连续的解算成果大文件。大文件的文件名以文件类型,起始和结束的观测或解算时间,首个和末尾测站名或分析中心名标记。

      合并后的文件采取分块存储的策略,数据块大小设置为64 MB,对GNSS小文件合并后,减少了HDFS存储的数据块数量,提高了存储空间的利用率,降低了各节点的内存消耗和通信开销。

    • Trie树是一种树形结构,用于统计和排序大量的字符串以便快速检索,在新增关键字时无需修改函数。在索引海量的、不同长度的小文件名时,压缩Trie树表现出良好的性能[12, 13]

      由于RINEX采用8.3的命名方式,具体形式为ssssdddf.yyt。其中,字符f代表一天内的文件序号,字符串ddd代表年积日,字符串ssss代表测站名。按文件序号、年积日和测站名自上而下构建5级压缩Trie树索引,在最后一级索引的地址域中存储观测文件在合并文件中的偏移值和文件大小。如图 2所示,基于压缩Trie树,第一级索引为文件序号,索引范围由[0, 9]和[a, z]两个区间组成;第二级索引为年积日的百位,索引范围为[0, 3];第三级索引为年积日的十位,索引范围为[0, 9];第四级索引为年积日的个位,索引范围为[0, 9];第五级索引为4字符长度的测站名。

      图  2  观测文件索引构建

      Figure 2.  The Index of Observation Files

      解算成果文件采用sssddddd.ttt的形式保存,其中sss代表分析中心的3位字符简称,ddddd中的前4个d代表GPS周,最后一个d代表周内日,ttt代表解算成果的类型。因此可按GPS周、周内日和分析中心名称构建6级压缩Trie树索引,在最后一级索引的地址域中存储解算成果在合并文件中的偏移值和文件大小。如图 3所示,基于压缩Trie树,第1~4级索引分别代表GPS周的千位、百位、十位和个位,索引范围均为[0, 9];第五级索引为GPS周内日,索引范围为[0, 7],其中[0, 6]代表日解文件,7代表周解文件;第六级索引为3字符长度的分析机构名称。

      图  3  解算成果索引构建

      Figure 3.  The Index of Solutions

      基于上述建立的索引结构,分别对合并后的观测文件和解算成果按LT构建压缩Trie树索引,主要分为两个阶段。一是映射(map)阶段,为HDFS中的小文件并行创建索引;二是归约(reduce)阶段:并行合并所有索引。

    • 索引切分时,对观测文件的1~5级索引、解算成果的1~6级索引,采取自下而上的方式,计算索引的大小,当前i-1和i个索引的大小(IBlock)满足:

      $$\left\{ {\begin{array}{*{20}{c}} {\sum\limits_1^{i - 1} {{\rm{IBlock}}} \le 16{\rm{MB}}}\\ {\sum\limits_1^i {{\rm{IBlock}}} > 16{\rm{MB}}} \end{array}} \right.$$ (4)

      将前i-1个索引保存为一个独立的索引块。按这样的方式,完成对上述构建的所有索引的切分。

    • 首先,利用式(5) 计算节点中每个类型文件各级索引的每个字符所占的比例fIk, m, cm, q

      $${f_{{I_k},m,{c_{m,q}}}} = \frac{{\sum {{\rm{Inde}}{{\rm{x}}_{m,{c_{m,q}}}}} }}{{{M_{{I_k}}}}}$$ (5)

      式中,m为索引的级别,m∈[1, 5]或[1, 6];cm, q为第m级索引的第q个字符;∑Indexm, cm, q为包含第m级索引字符cm, q的文件数;MIkIk类型的文件数量。

      将切分的索引块内容与每个从节点(DataNode节点)的fIk, m, cm, q进行比较,匹配度ω为:

      $$\omega = \sum\limits_{m - 1} {\sum\limits_{q - 1}^p {{f_{{I_k},m,{c_{m,q}}}}} } \cdot {W_{{c_{m,q}}}}$$ (6)

      式中,p为第m级索引的字符数;Wcm, qcm, q在索引块的第m级索引字符中所占的比例。

      W值的大小对DataNode节点进行排序,将前3个节点作为索引块的存储节点,这样就可将索引块放置在存储数据块的节点或离数据块最近的节点上。采取这样的放置策略,一方面索引存放在DataNode节点,可进一步降低主节点(NameNode节点)的内存消耗;另一方面可以减少数据读取时的通信开销,即找到某个索引之后在本地或相邻的节点上就能找到对应的文件,提高读取速度。

      然后,对索引块建立索引,将每个GNSS文件类型的索引存储在NameNode节点上。如图 4所示,文件块和索引块存储在DataNode节点,文件块路径映射和表征观测文件与解算成果类型的扩展名/索引块路径映射存储在NameNode节点上。

      图  4  GNSS文件存储位置示意图

      Figure 4.  The Storage Area of GNSS Files

    • 添加GNSS小文件时按§2.1.1和§2.1.2的方法合并文件,构建索引,在索引存储时,由于索引块的大小(16 MB)小于HDFS数据块(64 MB)的大小,可将新构建的Trie树索引直接插入到原索引块中。

      GNSS文件读取的步骤如下。

      1) 根据文件扩展名,访问NameNode节点。

      2) NameNode节点处理用户请求,根据文件类型,返回索引块序列,根据返回的序列,客户端访问指定的DataNode节点。

      3) 根据DataNode节点返回的多个索引块,将每个索引块划分为1个map任务,每个map函数自上向下逐级进行索引匹配,当文件名与某条索引路径完全匹配时,检索成功,由reduce函数完成一个或多个索引路径的合并。

      4) 读取最后一级索引的位置信息,定位到数据块;根据数据块内偏移和文件的长度读取GNSS小文件。

      GNSS文件删除方法如下。先根据GNSS文件名查找索引,将索引标记为删除(valid = false),然后定位文件的位置,再将文件标记为删除。当被标记为删除的索引与文件数量达到阈值时,就对无效的索引和文件进行清理,将剩下的内容与其他索引块和数据块合并。

    • 实验搭建了7个节点组成的云存储集群,其中1台虚拟机作为主(master)节点,其余6台作为从(slave)节点。各节点都为Intel酷睿双核处理器,频率2.0 GHz,主节点内存4 GB,slave节点内存2 GB,操作系统为Ubuntu 14.04,各节点部署Hadoop 2.5.1,开发环境为Eclipse 3.8,节点间采用SSH (Secure Shell)无密码配置。

      实验采用以下4种存储方案,每次实验重复5次,结果取平均值。

      方案1 HAR归档文件技术。将小文件合并后放入HDFS中,通过创建层次化的文件系统来处理小文件。

      方案2 SequenceFile序列文件技术。将文件名存入到键(key)中,将文件内容存储到值(value)中,构建一个可切分的序列文件。

      方案3 文献[6]和[10]采用的合并小文件建立索引技术。索引存储在某个DataNode节点上;采用压缩Trie树建立索引。

      方案4 本文提出的方法。

    • 搜集2015年4月26日~5月23日(对应GPS 1 842~1 845周,共28 d)IGS全球跟踪站网的数据,测试文件总量为60.5 GB,包含645 269个文件,其中每天大约包括2.1 GB大小、2.3万个文件。图 5显示了文件数量及大小的分布情况,小于50 KB的文件大约占文件总数量的88%。

      图  5  GNSS小文件分布

      Figure 5.  The Distribution of GNSS Small Files

      按连续的观测时段和解算时间,将这些文件直接存入HDFS耗时约610 min,利用方案4存入HDFS耗时约148 min,加速比约为4.12倍。图 6显示了写入完成后各个节点上的内存占用率情况。方案4通过对GNSS小文件的合并,降低了集群中数据块的数量,优化了索引块放置策略,减少了NameNode节点与DataNode节点之间的通信消耗,最终降低了各节点的内存占用率。

      图  6  内存占用情况对比

      Figure 6.  The Comparison of Memory Use

      将每天的每种类型的文件集合依次写入到HDFS中,不同数据规模下(步长设置为1周的数据),不同方案的写入时间如图 7所示。4种方案均进行GNSS小文件的合并,因此写入时间的差异不是很大。方案1直接合并小文件,写入所需时间最短,但若要修改合并后的文件,必须新建存档文件;方案2采用key/value对合并小文件,将小文件转换成SequenceFiles的过程影响了写入速度;方案3和4额外构建压缩Trie树索引,并将索引写入DataNode节点,因此比较耗时。但与方案3相比,方案4可以并行构建索引,因此方案3所需时间最长。

      图  7  写入文件时间对比

      Figure 7.  The Comparison of Writing Time

    • 实验中对每天的GNSS数据的随机访问模式定义为:先将该天每种类型的文件按数量随机分成6~10份,然后将所有类型的每份文件自由组合为一个随机文件集合,对该文件集合的访问构成一次随机的读取过程,6~10次的读取完成了对当天所有GNSS数据的访问。

    • 按照上述随机访问模式,分别对1周、2周、3周和4周的GNSS数据进行读取,所需时间如图 8所示。方案1建立索引时,没有考虑文件之间的相关性,降低了文件读取的命中率;方案2产生的索引随文件数量的增多而增多,由于自身的key/value是未排序的,没有完善小文件到大文件的映射,文件定位效率较低,需要频繁地更换DataNode节点,系统内部通信频繁;方案3和方案4通过构建Trie树索引提高了文件定位的效率,但方案3将索引存储在本地磁盘上,索引越来越多时就需要进行频繁的输入/输出访问,而方案4检索索引可以并行执行,优化了索引存储机制,减少了节点之间的通信,因此表现出来的性能最优。

      图  8  读取文件时间对比

      Figure 8.  The Comparison of Reading Time

    • 添加美国2015年4月26日~5月24日的CORS观测文件(每天约有1 300个站的观测数据),进行数据读取实验,结果如图 9所示。与图 8相比,方案1~4的读取时间分别增加了1.46、1.42、1.24和1.08倍。与方案1、2的无序存放索引相比,方案3、4将新构建的Trie树索引插入到已有的索引块中,实现了索引的有序排列,提高了新添加文件定位的效率;而方案4优化了索引存储机制,分布式地存储索引,因此读取时间的增长最慢。

      图  9  添加GNSS文件后的读取时间对比

      Figure 9.  The Reading Time After Adding GNSS Files

    • 利用传输工具curl,配置客户端,分别从2、4、6和8台客户机同时随机下载不同天的GNSS数据,模拟多用户的并发访问。当存在高并发用户访问时,系统内部的通信频繁,文件读取的时间受NameNode节点的内存开销、索引检索的效率、文件定位的速度和通信开销等因素的共同影响。如图 10所示,方案4并发访问效率最高。

      图  10  并发访问读取时间

      Figure 10.  The Reading Time of Concurrent Access

    • 由于方案1、2不支持对小文件的删除,因此仅对方案3和4进行测试,测试数据选择2015年4月26日~5月24日的高采样率观测文件。如图 11所示,由于方案4将索引块分布式存储在数据块的节点或离数据块最近的节点,通过并行检索可实现文件的快速定位,减少了通信的时间和内存开销,因此删除速度最快。

      图  11  删除文件时间对比

      Figure 11.  The Comparison of Deleting Time

      本文提出的方法提高了HDFS处理GNSS小文件的效率,实际应用的效果与存储系统的规模、各节点的性能、网络环境、数据大小和类型的差异以及访问模式等因素密切相关。

    • 本文优化了GNSS小文件的写入、添加、读取和删除方法,其优点如下。首先,通过对GNSS小文件的合并,减少了HDFS中存储的数据块数量,节省了存储空间,降低了各节点内存消耗对合并后的GNSS文件构建压缩Trie树索引,索引分块后按匹配度分布式地存储索引,优化了索引存储机制,实现了索引的动态添加和并行检索,提高了文件的定位效率,减少了节点间的通信。

      本文所述方法提高了海量GNSS小文件写入、读取和删除的效率,实现了对海量GNSS小文件的高效云存储。

参考文献 (13)

目录

    /

    返回文章
    返回