CN104765876B - 海量gnss小文件云存储方法 - Google Patents

Abstract

本发明涉及海量GNSS小文件云存储方法，有效解决海量GNSS小文件高效存储、管理、发布和共享的问题，方法是，首先将海量GNSS小文件合并为大文件，对合并后的大文件建立索引；并优化索引块存储策略，将切分后的文件块和索引块存储在数据块的节点或离数据块最近的数据节点上，将GNSS数据类型的索引存储在名称节点上，降低存储容量的消耗和名称节点的内存消耗，提高大量小文件写入、访问和删除的性能，本发明方法简单，易操作，节省存储空间，降低内存消耗，提高写入、读取和删除效率，有效提高海量GNSS小文件高效存储、管理、发布和共享之目的，是对海量GNSS小文件管理上的一大创新，经济和社会效益巨大。

Description

海量GNSS小文件云存储方法

技术领域

本发明涉及“测绘科学与技术”学科中的“大地测量学与测量工程”技术领域，特别是一种海量GNSS小文件云存储方法。

背景技术

随着科学技术的不断发展，全球、国家、区域级连续运行参考站网(CORS，Continuously Operating Reference Station System)的不断建成，全球卫星导航***(GNSS，Global Navigation Satellite System)被广泛应用在各个领域，特别是整合独立型CORS形成的拥有更多基准站、更高层次的联合型CORS的陆续组网及连续观测，全球卫星导航***数据量的规模越来越大。

海量的数据给存储和管理带来挑战，大量TB级以上的数据等待处理。以GNSS观测数据为例，连续观测1天、采样率为1秒、仅GPS卫星的数据量就可达80MB，全球有上万个观测站，一天的数据量就可达数十至数百TB；此外，不同于网络日志和遥感影像，GNSS数据种类和格式丰富多样，以GNSS观测文件和解算成果为代表的GNSS数据均属于小文件的范畴。

针对海量GNSS小文件给存储和管理带来的挑战，传统的存储区域网络(SAN，Storage Area Network)和网络附加存储(NAS，Network-Attached Storage)在容量和性能的扩展上存在瓶颈。目前GNSS数据中心采用的文件传输协议(FTP，File TransferProtocol)和关系数据库在管理海量GNSS数据方面存在诸多限制，集中式存储方法已不能满足大规模GNSS数据存储应用的需要。国内外研究机构和研究人员对海量小文件存储进行了广泛的关注和研究，发表的文献主要包括：国外《Journal of Network and ComputerApplications》的《An Optimized Approach for Storing and Accessing Small Fileson Cloud Storage》、《Web Information Systems and Mining》的《Metadata-Aware SmallFiles Storage Architecture on Hadoop》、《Algorithms and Architectures forParallel Processing》的《Hmfs：Efficient Support of Small Files Processing overHDFS》，国内《西安交通大学学报》的《一种提高云存储中小文件存储效率的方案》、《武汉大学学报·信息科学版》的《一种结合RDBMS和Hadoop的海量小文件存储方法》和《云环境下的时空数据小文件存储策略》。

已有的解决方案都把焦点放在了探讨元数据模型、分析海量小文件之间的相关性、调整***的结构和用户访问规律等方面，但对数据类型和特点以及对合并后文件索引的放置策略关注较少，不能完全应用于GNSS小文件的管理。面对以小文件为代表的海量GNSS数据的存储需求，利用底层的开源云平台，结合GNSS数据类型和特点，设计海量GNSS小文件云存储方法，成为海量GNSS小文件高效存储、管理、发布和共享的有效途径。

发明内容

针对上述情况，为克服现有技术之缺陷，本发明之目的就是提供一种海量GNSS小文件云存储方法，有效解决海量GNSS小文件高效存储、管理、发布和共享的问题。

本发明解决的技术方案是，针对海量GNSS小文件集中式存储方法的缺陷和瓶颈，基于底层开源云平台(Hadoop)，构建并设计海量GNSS小文件云存储方法，实现海量GNSS小文件的高效云存储，首先将海量GNSS小文件合并为大文件，对合并后的大文件建立索引；并优化索引块存储策略，将切分后的文件块和索引块存储在数据块的节点或离数据块最近的数据节点(DataNode)上，将GNSS数据类型的索引存储在名称节点(NameNode)上，降低存储容量的消耗和名称节点(NameNode)的内存消耗，提高大量小文件写入、访问和删除的性能，具体包括以下步骤：

(1)、将海量GNSS小文件合并为大文件，以降低大量小文件对名称节点(NameNode)内存的占用，小文件合并是首先将同一观测时段或解算时间、同一类型的文件进行合并；其中在对GNSS观测文件的合并时，按测站名四位字母的先后顺序进行合并，在对解算成果文件的合并时，按GNSS分析中心名称三位字母的先后顺序进行合并，将大量GNSS观测文件合并成为一个观测时段连续的观测大文件，将解算成果文件合并成为一个解算时间序列连续的解算成果大文件；

(2)、对合并后的GNSS大文件构建索引，即分别对观测文件和解算成果构建索引，采用字符与索引一一对应的方式，对观测文件，按文件序号、年积日和测站名构建五级索引，在最后一级索引中存储观测文件的位置信息；对解算成果文件，按GPS周、周内日和分析中心名称构建六级索引，在最后一级索引中存储解算成果文件的位置信息；

(3)、将建立的索引按数据块大小进行切分，由于可以通过GNSS数据处理软件将一天内的观测数据合并，因此文件序号可统一为0，对应观测文件第一级索引文件序号也为0，索引切分时，对观测文件的第二至第五级索引、解算成果的第一至第六级索引，采取自下而上的方式，计算索引的大小，将其切分为64MB大小的索引块；

(4)、将索引块放置在存储数据块的节点或离数据块最近的节点上，提高文件读取速度并进一步降低名称节点(NameNode)的内存消耗；

(5)、将合并后GNSS大文件的文件类型的索引存储在名称节点(NameNode)上，文件块路径映射和表征观测文件与解算成果类型的三位字符/索引块路径映射存储在名称节点(NameNode)上，文件块和索引块均存储在数据节点(DataNode)上，实现海量GNSS小文件的云存储。

本发明方法简单，易操作，节省存储空间，降低内存消耗，提高写入、读取和删除效率，有效提高海量GNSS小文件高效存储、管理、发布和共享之目的，是对海量GNSS小文件管理上的一大创新，经济和社会效益巨大。

附图说明

图1为本发明小文件存储平台功能示意图。

图2为本发明观测文件索引构建图。

图3为本发明解算成果索引构建图。

图4为本发明观测文件和解算成果文件存储位置示意图。

具体实施方式

以下结合附图对本发明的具体实施方式作详细说明。

由图1-4所示，本发明在具体实施中，包括以下步骤：

步骤1：将海量GNSS小文件合并为大文件，以降低大量小文件对名称节点(NameNode)内存的占用，海量GNSS小文件包括以下两种类型文件：一类是，以观测数据、导航星历和气象文件为代表的观测文件，另一类是以坐标文件、精密星历、精密钟差为代表的解算成果文件；无论是观测文件还是解算成果文件，都采用了国际统一的标准格式，观测文件采用的与接收机无关的交换格式(RINEX，Receiver Independent Exchange Format)、解算成果采用的解算无关成果交换格式(SINEX，Solution(Software/technique)Independent Exchange Format)、电离层交换格式(IONEX，Ionosphere Exchange Format)和精密星历数据格式(SP3，NGS Standard GPS Format)格式，***中存储n个GNSS小文件，每份GNSS小文件都包含位置、时间和文件类型三种参数，数据之间通过参数进行区分，GNSS小文件数据集D表示为：

D＝{d(L_i,T_j,I_k),d|L_i∈L,T_j∈T,I_k∈I},i,j,k∈Z 式(1)

其中，L代表文件产生的位置信息，主要包括采集观测文件的测站和解算成果文件的机构；T代表文件产生的时间标记，由于测站的24h连续观测及数据中心的定时连续解算与发布，T是一个连续的时间序列；I代表文件类型，由上述的标准格式定义，L和T均从文件名和文件记录的文件头部分获取，I从文件扩展名和文件记录的文件头部分获取；d代表集合，i、j、k分别代表文件位置、时间和类型参数的序号，Z为整数；

小文件合并时，首先将同一观测时段或解算时间、同一类型的文件，按测站名四位字符、分析中心名称三位字符的先后顺序进行合并，合并后GNSS小文件集表示为：

式(2)

其中，T_j代表了第j个观测时段或解算时刻，I_k代表了第k个文件类型，Z为整数；

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

式(3)

通过以上两步的合并，即可将连续7天的GNSS观测文件合并成一个观测时段连续的观测大文件，将7天的解算成果文件合并成一个解算时间序列连续的解算成果大文件；大文件的文件名以文件类型、起始和结束的观测或解算时间、首个和末尾测站名或分析中心名标记，合并后的文件存储在云存储***中采用分块的方式，数据块的大小设置为64MB，每个数据块是多个小文件的集合，并占用名称节点(NameNode)150B的内存空间，较合并之前的每个小文件占用150B的内存空间相比，大大降低名称节点(NameNode)的内存消耗；

所述的海量GNSS小文件包括GNSS观测文件和解算成果文件，这些文件都遵循国际统一的标准格式，由于GNSS数据和成果格式会不断升级，因此，对升级后的文件格式和最新提出的文件类型，均可纳入到GNSS小文件的范畴；

所述的同一观测时段或解算时间、同一类型的文件进行合并，还可首先分别按相同的观测时段解算日期进行合并，再按连续的观测时段或解算周期进行合并，大文件的文件名以文件类型、起始和结束的观测或解算时间、首个和末尾测站名称或分析中心名称作为标记，大文件合并后存储在云存储***中采用分块的方式，数据块的大小设置为64MB，每个数据块是多个GNSS小文件的集合；

步骤2：对合并后的GNSS大文件构建索引，即分别对观测文件和解算成果按L和T构建索引，方法是：

对观测文件构建索引时，由于观测文件采用RINEX格式保存，RINEX格式采用8.3的命名方式，其中8代表用于表示文件归属的8字符长度的主文件名，3代表用于表示文件类型的3位字符长度的扩展名，具体形式为ssssdddf.yyt，其中ssss代表4字符长度的测站名，ddd代表年积日，f代表一天的文件序号；采用字符f代表一天内的文件序号、字符串ddd代表年积日，字符串ssss代表测站名，从上而下，采取字符与索引一一对应的方式，构建五级索引，在最后一级索引的结束节点存储观测文件的位置信息；第一级索引为文件序号，索引范围由[0,9]和[a,z]两个区间组成，[0,9]代表10个***整数，[a,z]代表26个英文小写字母，第二级索引为年积日的百位，索引范围为[0,3]，[0,3]代表4个***整数，第三级索引对应为年积日的十位，索引范围为[0,9]，第四级索引为年积日的个位，索引范围为[0,9]，第五级索引为四字符长度的测站名，每一个字符的范围落在[0,9]和[a,z]两个区间内；

对解算成果文件，采用sssddddd.ttt的形式保存，其中sss代表分析中心的三位字符简称，ddddd中的前四个d代表自1980年1月6日0h起算的GPS周，最后一个d代表周内日，ttt代表解算成果的类型，按GPS周、周内日和分析中心名称构建六级索引，在索引的结束节点存储解算成果文件的位置信息，第一级至第四级索引分别为GPS周的千位、百位、十位和个位，索引范围均为[0,9],第五级索引为GPS周内日，索引范围为[0,7],其中[0,6]代表的7个整数代表一周的日解文件，数字7代表周解文件，第六级索引为三字符长度的分析机构名称，每一个字符均的范围落在[a,z]区间内；

所述的观测文件和解算成果文件分别构建五级和六级索引，索引的建立遵循标准文件格式，在最后一级索引中存储文件的路径信息；

步骤3：将建立的索引按数据块64MB进行切分，对观测文件，由于可以通过GNSS数据处理软件将一天内的观测数据进行合并，因此文件序号统一为0，对应第一级索引文件序号也为0；索引切分时，对观测文件的第二至第五级索引、解算成果的第一至第六级索引，采取自下而上的方式，计算索引块的大小，当前i-1和i个索引的大小(IBlock)满足下式

式(4)

将前i-1个索引保存为一个独立的索引块，按这样的方式，完成对步骤2构建的所有索引的切分；

步骤4：将索引块放置在存储数据块的数据节点(DataNode)或离数据块最近的数据节点(DataNode)上，提高读取速度并进一步降低名称节点(NameNode)的内存消耗，将切分的索引块的内容与合并后的GNSS大文件数据块的名称进行匹配，匹配时采取自上而下逐级匹配的方式，当索引出现分支时，统计出现分支处的各索引字符所占的比例，将占索引块比例最大的字符与数据节点(DataNode)中数据块进行匹配，将匹配率最高的节点作为索引块的存储节点；当索引块放置在存储数据块的节点或离数据块最近的节点时，一方面，减少数据读取时的通信开销，即找到某个索引之后再本地或相邻的节点上就能找到对应的文件内容，提高读取速度；另一方面，由于索引并未存放在名称节点(NameNode)上，而是在数据节点(DataNode)上，因此进一步降低名称节点(NameNode)的内存消耗；

步骤5：将合并后的GNSS大文件的文件类型的索引存储在名称节点(NameNode)上，对GNSS观测文件，存储在名称节点(NameNode)上的索引除包含一位字母代表的文件类型外，还包含观测日期年的后两位数字；对解算成果文件，存储在名称节点(NameNode)上的索引只包含三位字母代表的文件类型；因此，除存储的数据块副本数量和大文件文件名/路径映射，由三位数字或字母组成的文件类型/索引块路径也存储在名称节点(NameNode)上，从而实现海量GNSS小文件云存储。

本发明在具体实施中，还可由以下方法实现：

由图1给出，本发明主要包括一个名称节点(NameNode)作为主节点，若干个数据节点(DataNode)作为文件块和索引块的存储节点，各个数据节点(DataNode)的任务包括负责小文件合并和索引块的构建，某一特定的数据节点(DataNode)负责索引的合并与索引块的切分，具体步骤是：

1)合并海量GNSS小文件：海量GNSS小文件包括GNSS观测文件、解算成果文件两类，观测文件是经由各类接收机接收，经数据格式转换软件转换成的标准RINEX格式的文件构成，主要包括RINEX 2.0和3.0两种格式，文件类型包括多***多频的观测数据、各***的导航星历、卫星钟差和观测概要(summary file)四类文件；解算成果文件包括精密星历、精密钟差、地球自转参数、卫星偏航率和坐标文件等，是由国际GNSS服务组织(IGS，International GNSS Service)各分析中心利用高精度GNSS数据处理软件解算得到，格式遵循SP3、SINEX、IONEX标准；

观测文件对应于相应的观测时段，包含起始时间、结束时间和采样间隔等信息，因此可先将相同时段的观测文件按测站名进行合并；然后按连续的观测时间序列，合并不同观测时段的观测文件；解算成果对应于被解算数据的时段，包含解算数据的起始和结束时间，因此可将相同时段观测数据对应的解算成果合并，再按照连续的解算周期合并不同时期的解算成果，大文件的文件名以文件类型、起始和结束的观测或解算时间、首个和末尾测站名称或分析中心名称作为标记；

各个数据节点(DataNode)负责完成该节点小文件的合并；

2)分别对合并后的观测文件和解算成果构建索引：对观测文件构建索引时，由于观测数据普遍采用RINEX格式，RINEX格式采用8.3的命名方式，其中8代表用于表示文件归属的8字符长度的主文件名，3代表用于表示文件类型的3位字符长度的扩展名，具体形式为ssssdddf.yyt，因此可利用字符f代表的一天内的文件序号、字符串ddd代表的年积日和字符串ssss代表的测站名，从上而下，采取字符与索引一一对应的方式，构建五级索引，在最后一级索引的结束节点存储观测文件的路径信息；如图2观测文件索引所示，第一级索引为文件序号，索引范围由[0,9]和[a,z]两个区间组成，[0,9]代表10个***整数，[a,z]代表26个英文小写字母，第二级索引为年积日的百位，索引范围为[0,3]，[0,3]代表4个***整数，第三级索引对应为年积日的十位，索引范围为[0,9]，第四级索引为年积日的个位，索引范围为[0,9]，第五级索引为四字符长度的测站名，每一个字符的范围落在[0,9]和[a,z]两个区间内；

对解算成果文件，采用sssddddd.ttt的形式保存，其中sss代表分析中心的三位字符简称，ddddd中的前四个d代表自1980年1月6日0h起算的GPS周，最后一个d代表周内日，ttt代表解算成果的类型，按GPS周、周内日和分析中心名称构建六级索引，在索引的结束节点存储解算成果文件的位置信息；如图3解算成果文件索引所示，第一级至第四级索引分别为GPS周的千位、百位、十位和个位，索引范围均为[0,9],第五级索引为GPS周内日，索引范围为[0,7],其中[0,6]代表的7个整数为一周的日解文件，数字7代表周解文件，第六级索引为三字符长度的分析机构名称，每一个字符的范围落在[a,z]区间内；

各个数据节点(DataNode)负责完成该节点小文件索引的构建；索引构建完成后，索引的合并是在另一特定的数据节点(DataNode)完成；

3)切分索引块，将第二步建立的索引按数据块大小(64MB)进行切分，对观测文件，由于可以通过GNSS数据处理软件将一天内的观测数据进行合并，因此文件序号可统一为0，对应第一级索引文件序号也为0，索引切分时，对观测文件的第二至第五级索引、解算成果的第一至第六级索引，采取自下而上的方式，计算索引块的大小，当索引大小首次超过数据块的大小时，回到上一个索引，将此索引保存为一个独立的索引块，按这样的方式，完成对第二步构建的所有索引的切分；

索引块的和切分是在第二步合并索引的数据节点(DataNode)完成；

4)索引块存储，将第三步切分好的索引块存储在对应数据块的数据节点(DataNode)或离数据块最近的数据节点(DataNode)上，将索引块的内容与合并后的GNSS大文件数据块的名称进行匹配，匹配时采取逐级匹配方式，当索引块出现分支时，统计出现分支处的各索引字符所占的比例，将占该级索引比例最大的字符与数据节点(DataNode)中数据块的名称进行匹配，将匹配率最高的节点作为该索引块的存储节点；

5)将文件类型索引/索引块路径存储在名称节点(NameNode)上，如图4观测文件和解算成果文件存储位置说明示意图所示，对GNSS观测文件，存储在名称节点(NameNode)上的索引除包含一位字母代表的文件类型外，还包含观测日期年的后两位数字；对解算成果文件，存储在名称节点(NameNode)上的索引只包含三位字母代表的文件类型；将文件类型索引与索引块一一对应的地址映射存储在名称节点(NameNode)上，完成上述构建的索引的映射，因此，除了存储的数据块副本数量和大文件文件名/路径映射，由三位数字或字母组成的文件类型/索引块路径也存储在名称节点(NameNode)上，从而实现海量GNSS小文件云存储。

以上所述，仅为本发明较佳的具体实施方式，本发明的保护范围不限于此，任何熟悉本技术领域的技术人员在本发明披露的技术范围内，可显而易见地得到的技术方案的简单变化或等效替换均落入本发明的保护范围内。

由上述可知，本发明是一种新的海量GNSS小文件云存储的方法，支持对海量GNSS小文件的高效存储、管理、查询和共享。实验通过搭建一个9节点组成的集群，1台作为名称节点(NameNode)，其余8台作为数据节点(DataNode)，副本数设置为3，测试海量GNSS小文件的写入、读取和删除速度。通过测试，本发明提出的小文件存储方法与传统HDFS方法相比，大大节省了存储空间，内存消耗降低了1/2，写入速度提高了约4倍，读取速度提高约3倍，删除速度提高了约2.5倍。实际应用的效果与存储***的规模、各节点的性能、网络环境、数据大小和类型的差异等密切相关。因此本发明与现有技术相比，具有以下突出的有益技术效果：

(1)节省存储空间

本发明根据GNSS的数据类型和数据特点，对连续观测时段的观测数据和解算成果，采取合并成大文件的策略，改善了Hadoop分布式文件***(HDFS，Hadoop DistributedFile System)中每个小文件占用整个数据块空间的情况，合并后的大文件经切分后的数据块占用一个数据块的大小，有效节省了数据节点(DataNode)的存储空间，提高了存储空间的利用率。

(2)降低内存消耗

本发明提出的根据GNSS观测文件和解算成果命名规则，对合并后的大文件建立索引，在索引的结束节点存储文件保存的路径。一方面，对小文件合并，可大大减少存储***中数据块的数量，降低了名称节点(NameNode)的内存开销；另一方面，对合并后的大文件建立索引并切分后，将索引块存放在数据节点(DataNode)中，名称节点(NameNode)只保存了文件扩展名的索文件类型/索引路径的映射和大文件文件名/文件路径的映射，进一步降低了名称节点(NameNode)的内存消耗。

(3)提高写入、读取和删除效率

本发明提出的方法通过合并GNSS小文件，对合并后的文件建立索引的方法，建立了高效的存储机制，减少了客户端与名称节点(NameNode)、名称节点(NameNode)与数据节点(DataNode)、客户端与数据节点(DataNode)之间的通信，减少了查询和检索的响应时间。提高了写入、读取和删除效率。

(4)易于扩展

本发明提出的方法具有较广泛的适用性，对各类GNSS观测文件和解算成果通过合并、建立索引和分块后，都可以实现高效存储。对新增的GNSS数据和成果格式，根据数据类型和特点进行合并，经过构建索引、分块存储等步骤后，都可纳入本发明的小文件存储***，可具有广泛适用性和较强的扩展性，解决了现有GNSS小文件存储面临的瓶颈和挑战，带来了高效的存储效率，有效应用于“测绘科学与技术”学科中的“大地测量学与测量工程”技术领域，实现海量GNSS小文件高效存储、管理、发布和共享，经济和社会效益巨大。

Claims (5)

1.一种海量GNSS小文件云存储方法，其特征在于，首先将海量GNSS小文件合并为大文件，对合并后的大文件建立索引；并优化索引块存储策略，将切分后的文件块和索引块存储在数据块的节点或离数据块最近的数据节点上，将GNSS数据类型的索引存储在名称节点上，降低存储容量的消耗和名称节点的内存消耗，提高大量小文件写入、访问和删除的性能，具体包括以下步骤：

(1)、将海量GNSS小文件合并为大文件，以降低大量小文件对名称节点内存的占用，小文件合并是首先将同一观测时段或解算时间、同一类型的文件进行合并；其中在对GNSS观测文件的合并时，按测站名四位字母的先后顺序进行合并，在对解算成果文件的合并时，按GNSS分析中心名称三位字母的先后顺序进行合并，将大量GNSS观测文件合并成为一个观测时段连续的观测大文件，将解算成果文件合并成为一个解算时间序列连续的解算成果大文件；

(2)、对合并后的GNSS大文件构建索引，即分别对观测文件和解算成果构建索引，采用字符与索引一一对应的方式，对观测文件，按文件序号、年积日和测站名构建五级索引，在最后一级索引中存储观测文件的位置信息；对观测文件构建索引时，第一级索引为文件序号，索引范围由[0,9]和[a,z]两个区间组成，[0,9]代表10个***整数，[a,z]代表26个英文小写字母，第二级索引为年积日的百位，索引范围为[0,3]，[0,3]代表4个***整数，第三级索引对应为年积日的十位，索引范围为[0,9]，第四级索引为年积日的个位，索引范围为[0,9]，第五级索引为四字符长度的测站名，每一个字符的范围落在[0,9]和[a,z]两个区间内；对解算成果文件，按GPS周、周内日和分析中心名称构建六级索引，在最后一级索引中存储解算成果文件的位置信息；对解算成果文件，第一级至第四级索引分别为GPS周的千位、百位、十位和个位，索引范围均为[0,9],第五级索引为GPS周内日，索引范围为[0,7],其中[0,6]代表的7个整数代表一周的日解文件，数字7代表周解文件，第六级索引为三字符长度的分析机构名称，每一个字符均的范围落在[a,z]区间内；

(3)、将建立的索引按数据块大小进行切分，由于可以通过GNSS数据处理软件将一天内的观测数据合并，因此文件序号可统一为0，对应观测文件第一级索引文件序号也为0，索引切分时，对观测文件的第二至第五级索引、解算成果的第一至第六级索引，采取自下而上的方式，计算索引的大小，将其切分为64MB大小的索引块；

(4)、将索引块放置在存储数据块的节点或离数据块最近的节点上，提高文件读取速度并进一步降低名称节点的内存消耗；

(5)、将合并后GNSS大文件的文件类型的索引存储在名称节点上，文件块路径映射和表征观测文件与解算成果类型的三位字符/索引块路径映射存储在名称节点上，文件块和索引块均存储在数据节点上，实现海量GNSS小文件的云存储。

2.根据权利要求1所述的海量GNSS小文件云存储方法，其特征在于，包括以下步骤：

步骤1：将海量GNSS小文件合并为大文件，以降低大量小文件对名称节点内存的占用，海量GNSS小文件包括以下两种类型文件：一类是，以观测数据、导航星历和气象文件为代表的观测文件，另一类是以坐标文件、精密星历、精密钟差为代表的解算成果文件；无论是观测文件还是解算成果文件，都采用了国际统一的标准格式，观测文件采用的与接收机无关的交换格式、解算成果采用的解算无关成果交换格式、电离层交换格式和精密星历数据格式格式，***中存储n个GNSS小文件，每份GNSS小文件都包含位置、时间和文件类型三种参数，数据之间通过参数进行区分，GNSS小文件数据集D表示为：

D＝{d(L_i,T_j,I_k),d|L_i∈L,T_j∈T,I_k∈I},i,j,k∈Z 式(1)

其中，L代表文件产生的位置信息，主要包括采集观测文件的测站和解算成果文件的机构；T代表文件产生的时间标记，由于测站的24h连续观测及数据中心的定时连续解算与发布，T是一个连续的时间序列；I代表文件类型，由上述的标准格式定义，L和T均从文件名和文件记录的文件头部分获取，I从文件扩展名和文件记录的文件头部分获取；d代表集合，i、j、k分别代表文件位置、时间和类型参数的序号，Z为整数；

小文件合并时，首先将同一观测时段或解算时间、同一类型的文件，按测站名四位字符、分析中心名称三位字符的先后顺序进行合并，合并后GNSS小文件集表示为：

其中，T_j代表了第j个观测时段或解算时刻，I_k代表了第k个文件类型，Z为整数；

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

通过以上两步的合并，即可将连续7天的GNSS观测文件合并成一个观测时段连续的观测大文件，将7天的解算成果文件合并成一个解算时间序列连续的解算成果大文件；大文件的文件名以文件类型、起始和结束的观测或解算时间、首个和末尾测站名或分析中心名标记；合并后的文件存储在云存储***中采用分块的方式，数据块的大小设置为64MB，每个数据块是多个小文件的集合，并占用名称节点150B的内存空间，较合并之前的每个小文件占用150B的内存空间相比，大大降低名称节点的内存消耗；

步骤2：对合并后的GNSS大文件构建索引，即分别对观测文件和解算成果按L和T构建索引，方法是：

对观测文件构建索引时，由于观测文件采用RINEX格式保存，RINEX格式采用8.3的命名方式，其中8代表用于表示文件归属的8字符长度的主文件名，3代表用于表示文件类型的3位字符长度的扩展名，具体形式为ssssdddf.yyt，其中ssss代表4字符长度的测站名，ddd代表年积日，f代表一天的文件序号；采用字符f代表一天内的文件序号、字符串ddd代表年积日，字符串ssss代表测站名，从上而下，采取字符与索引一一对应的方式，构建五级索引，在最后一级索引的结束节点存储观测文件的位置信息；第一级索引为文件序号，索引范围由[0,9]和[a,z]两个区间组成，[0,9]代表10个***整数，[a,z]代表26个英文小写字母，第二级索引为年积日的百位，索引范围为[0,3]，[0,3]代表4个***整数，第三级索引对应为年积日的十位，索引范围为[0,9]，第四级索引为年积日的个位，索引范围为[0,9]，第五级索引为四字符长度的测站名，每一个字符的范围落在[0,9]和[a,z]两个区间内；

对解算成果文件，采用sssddddd.ttt的形式保存，其中sss代表分析中心的三位字符简称，ddddd中的前四个d代表自1980年1月6日0h起算的GPS周，最后一个d代表周内日，ttt代表解算成果的类型，按GPS周、周内日和分析中心名称构建六级索引，在索引的结束节点存储解算成果文件的位置信息，第一级至第四级索引分别为GPS周的千位、百位、十位和个位，索引范围均为[0,9],第五级索引为GPS周内日，索引范围为[0,7],其中[0,6]代表的7个整数代表一周的日解文件，数字7代表周解文件，第六级索引为三字符长度的分析机构名称，每一个字符的范围均落在[a,z]区间内；

步骤3：将建立的索引按数据块64MB进行切分，对观测文件，由于可以通过GNSS数据处理软件将一天内的观测数据进行合并，因此文件序号统一为0，对应第一级索引文件序号也为0；索引切分时，对观测文件的第二至第五级索引、解算成果的第一至第六级索引，采取自下而上的方式，计算索引块的大小，当前i-1和i个索引的大小满足下式

将前i-1个索引保存为一个独立的索引块，按这样的方式，完成对步骤2构建的所有索引的切分；

步骤4：将索引块放置在存储数据块的数据节点或离数据块最近的数据节点上，提高读取速度并进一步降低名称节点的内存消耗，将切分的索引块的内容与合并后的GNSS大文件数据块的名称进行匹配，匹配时采取自上而下逐级匹配的方式，当索引出现分支时，统计出现分支处的各索引字符所占的比例，将占索引块比例最大的字符与数据节点中数据块进行匹配，将匹配率最高的节点作为索引块的存储节点；当索引块放置在存储数据块的节点或离数据块最近的节点时，一方面，减少数据读取时的通信开销，即找到某个索引之后在本地或相邻的节点上就能找到对应的文件内容，提高读取速度；另一方面，由于索引并未存放在名称节点上，而是在数据节点上，因此进一步降低名称节点的内存消耗；

步骤5：将合并后的GNSS大文件的文件类型的索引存储在名称节点上，对GNSS观测文件，存储在名称节点上的索引除包含一位字母代表的文件类型外，还包含观测日期年的后两位数字；对解算成果文件，存储在名称节点上的索引只包含三位字母代表的文件类型；因此，除存储的数据块副本数量和大文件文件名/路径映射，由三位数字或字母组成的文件类型/索引块路径也存储在名称节点上，从而实现海量GNSS小文件云存储。

3.根据权利要求2所述的海量GNSS小文件云存储方法，其特征在于，所述的步骤1海量GNSS小文件包括GNSS观测文件和解算成果文件，这些文件都遵循国际统一的标准格式，由于GNSS数据和成果格式会不断升级，因此，对升级后的文件格式和最新提出的文件类型，均可纳入到GNSS小文件的范畴。

4.根据权利要求2所述的海量GNSS小文件云存储方法，其特征在于，所述的步骤1同一观测时段或解算时间、同一类型的文件进行合并，还可首先分别按相同的观测时段解算日期进行合并，再按连续的观测时段或解算周期进行合并，大文件的文件名以文件类型、起始和结束的观测或解算时间、首个和末尾测站名称或分析中心名称作为标记，大文件合并后存储在云存储***中采用分块的方式，数据块的大小设置为64MB，每个数据块是多个GNSS小文件的集合。

5.根据权利要求2所述的海量GNSS小文件云存储方法，其特征在于，所述的步骤2观测文件和解算成果文件分别构建五级和六级索引，索引的建立遵循标准文件格式，在最后一级索引中存储文件的位置信息。