一种基于分布式文件系统的遥感数据快速并发读写方法

本发明涉及计算机应用技术和遥感大数据处理领域，尤其涉及大数据文件的并发读写技术，特别涉及基于分布式文件系统实现遥感数据的快速并发读写技术。

背景技术：

随着遥感技术的迅猛发展，各国发射的遥感卫星越来越多，每天接收的卫星数据已经到达pb级，海量遥感数据处理对存储技术和处理速度提出了更高的要求。另一方面，随着计算机特别是互联网技术的迅猛发展，数据存储技术也得到了质的飞跃，特别是近年来云技术的出现，将数据存储技术提高到前所未有的水平。云技术通常采用基于分布式文件系统，既保证高了可靠性又提高了容量和性价比。在众多分布式文件系统中，提供了开源代码的hdfs(hadoopdistributedfilesystem)分布式文件系统格外受人们欢迎。hdfs是hadoop项目的核心之一，是分布式数据存储的基础。hdfs基于流数据模式访问超大文件的需求设计，可以运行在性价比高的通用服务器上，具有高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征，为超大数据集(largedataset)的处理带来了诸多便利。

但是，hdfs也具有如下3个缺点(这些情况下不适用hdfs)：1、无法实现低延时数据访问，比如毫秒级的读写数据。hdfs只适合高吞吐率的场景，即在某一时间内写入大量的数据，但不支持立刻快速将数据读取回来。2、不支持大量小文件存储。存储大量小文件会占用索引服务(namenode)的大量内存来存储数据块索引信息，然而hdfs的索引服务内存是有限的，无法实现海量扩充，此外大量索引将导致寻道时间超过读取时间，极大降低存取效率。3、无法并发写入或随机修改文件。hdfs的文件必须独占式访问，不允许多个线程同时写，而且只支持追加(append)模式，不支持随机修改。然而在遥感大数据处理中，数据改写和更新是必须支持的一种处理模式，遥感影像通常很大，不可能每次都全部重新处理，而是仅修改需要修改的位置，这个特性是由遥感影像专业处理的算法所决定的。

因此，包含以上3个缺点的hdfs无法适用于遥感大数据处理，为此本发明提出了改进分布式文件系统的方法，实现遥感大数据快速并发读写。

技术实现要素：

为解决hdfs的3个缺点问题，本发明对原生hdfs分布式文件系统进行改造，提供一种改进分布式文件系统的方法。

为了实现上述目的，本发明的技术方案如下：

本发明提供一种基于分布式文件系统的遥感数据快速并发读写方法，底层物理结构上继承hdfs文件系统特点，包括在计算机群中的每台数据服务器上安装hadoop系统，并建立hdfs文件系统，然后在每台数据服务器上划分一部分空间作为自有文件系统的物理存储空间；在hdfs业务处理层上进行了一级封装，接管操作系统对文件系统的访问，当操作系统只要求读取文件，且文件数据已经存在，则直接引用hdfs文件系统接口，由hdfs完成文件数据的读取；

当操作系统要求对文件的访问包括有写文件操作则全面接管文件操作，由自有文件系统实现数据读写，并在读写数据完成后，引用hdfs文件系统的写文件接口将数据同步到hdfs中；所述自有文件系统只对一台服务器进行读写。

而且，所述计算机群中部署多台通用的数据服务器实现数据存储与科学计算；在完成硬件安装后，在所有数据服务器上安装hadoop系统，并建立hdfs文件系统，完成hdfs原生存储机群的组建；同时，每台数据服务器上划分一部分空间作为自有文件系统的物理存储空间。

而且，自有文件系统采用raid模式读写数据。

而且，部署一台索引服务器，实现对整个分布式文件系统的管理。

而且，所述自有文件系统调度时每次总是选择读写性能最好的数据服务器进行数据读写服务，性能最好的考量标准实现方式如下，

为每个数据服务器提供一个指示器，实时汇报自己的数据读写情况，指示器的值计算公式为，

i＝(imax–(d/t)/(1-(c-s)))×(1-w)

式中，其中i为指示器值，imax为本服务器硬盘组提供的最大数据吞吐量，d为最近数据读写量，t为读写d数据的时间，c为当前时间，s为开始统计时间，w为存储服务器的cpu使用率。

而且，在索引服务器选择出性能最好的数据服务器后，后续的文件读写将由相应数据服务器实现，数据读写过程中，任何数据都不会经由索引服务器周转，确保不形成数据读写瓶颈。

而且，数据服务器提供读写数据过程中包括两种情况，

其一为写全新的数据，自有文件系统只需提供简单文件读写，在文件读写结束后，自有文件系统引用hdfs系统的文件写入功能，将文件同步到hdfs文件系统中，并对外提供文件读取服务；

其二为文件改写，用于修改已经存在的文件，实现如下，首先在自有文件系统中立刻申请与待改写文件一样大小的存储空间，并按hdfs文件系统的相应分块一致进行分块，并标识为0；然后，将hdfs中文件标识为无效，读hdfs数据块，更新数据后写到自有文件系统；最后同步自有文件到hdfs文件系统中。

而且，对于大量小文件的情况，对每个文件夹中的文件名称用hbase数据库进行管理，而文件内容则采用包含固定记录大小的大文件进行管理。

本发明基于开源hdfs系统，针对hdfs系统的3个缺点，设计了一套通道读写技术(英文gateio)，代理分布式文件系统对外提供服务，通过自有文件系统，弥补了文件并发快速读写的不足。同时，为实现并发读写的负载均衡，在自有文件系统中设计了并发读写的调度策略，保证文件系统具有较好的读写性能。最后，为了支持海量小文件，本发明充分利用hbase数据库的优越管理能力，对每个文件夹中的文件名称用hbase数据库进行管理，而文件内容则采用包含固定记录大小的大文件进行管理，最终实现海量数据的快速并发读写。

本发明方案实施简单方便，实用性强，解决了相关技术存在的实用性低及实际应用不便的问题，能够提高用户体验，具有重要的市场价值。

附图说明

图1为本发明实施例的逻辑结构组成图；

图2为本发明实施例的处理流程图；

图3为本发明实施例每个服务器的物理存储结构示意图；

图4为本发明实施例整个分布式文件系统结构组成示意图；

图5为本发明实施例自有文件系统的读写调度流程示意图。

具体实施方式

以下结合附图和实施例具体说明本发明的技术方案。

本发明提供了一种改进分布式文件系统实现遥感数据的快速并发读写的方法，命名为通道读写技术(英文gateio)，它能够实现海量数据的快速并发读写。为解决hdfs的3个缺点问题，本发明实施例对原生hdfs分布式文件系统进行改造：

首先，在底层物理结构上继承hdfs文件系统高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征，保证分布式文件系统高效稳定。

然后，在hdfs业务处理层上进行了一级封装，接管操作系统对文件系统的访问。如果操作系统只要求读取文件，且文件数据已经存在，则直接引用hdfs文件系统接口，由hdfs完成文件数据的读取。如果操作系统要求对文件的访问包括有写文件操作(包括创建、改写)则全面接管文件操作，由本发明提出建立的自有文件系统实现数据读写，并在读写数据完成后，引用hdfs文件系统的写文件接口将数据同步到hdfs中。

本发明实施例的逻辑结构组成及处理流程如图1、图2所示。本发明实施例提供gateio对外提供文件读写服务，其中原生hdfs文件系统实现分布式数据组织，自有文件系统提供文件写入。流程可设计为：

根据文件读写请求，判断是否需要写文件；

若是则自有文件系统读写数据，然后读已有数据或写数据结束，当结束时与hdfs同步数据；

若否则原生hdfs读写数据。

为实现数据的快速并发读写，本发明需组建计算机群，也即部署多台通用的数据服务器实现数据存储与科学计算。每台数据服务器安装的硬盘必须在4块以上，推荐8块。在完成硬件安装后，在所有数据服务器上安装hadoop系统，并建立hdfs文件系统，完成hdfs原生存储机群的组建。在此之后，在每台数据服务器上划分一部分空间作为自有文件系统的物理存储空间。为保证自有文件系统的读写性能，自有文件系统物理空间必须充分利用多个硬盘组成磁盘阵列(raid，redundantarraysofindependentdisks)的特性，也即自有文件系统必须采用raid模式读写数据。根据每个数据服务器的硬盘数量来设置raid属性，推荐采用raid5模式，也即冗余数为1的模式。每台数据服务器的存储划分示意图如图3所示，其中每台数据服务器上，除了原生hdfs文件系统使用的物理存储空间，还包括部分空间作为自有文件系统的物理存储空间。

在完成单个数据服务器的存储空间组织后，本发明与hdfs类似，需要部署一台索引服务器(即namenode服务器)，实现对整个分布式文件系统的管理，整个分布式文件系统的组成如图4所示。具体实施时，还可以设置备用索引服务器namenode。与原生hdfs不同，本发明部署的索引服务器提供两类服务，

其一为读文件服务，读文件服务直接引用原生hdfs的读文件，这里不再详细介绍。

其二为写文件(包括创建文件和改写文件)服务，这个服务将由自有文件系统完成。

自有文件系统不同于hdfs将文件按预定义的规则分布保存于各数据服务器，而只对一台数据服务器进行读写。为支持多机多文件的并发读写，自有文件系统需要提供一套调度算法完成多机并发读写数据的负载均衡。自有文件系统调度算法的总体思想为：每次总是选择读写性能最好的服务器进行数据读写服务。性能最好的考量标准为每个存储服务器提供一个指示器，实时汇报自己的数据读写情况，指示器的值最大值为100，如最近无任何数据读写申请，且有空余磁盘物理空间，指示器取最大100，无空间直接给0，有数据读写则根据近一段时间的数据流量统计出指示器的值，统计算法推荐为：

i＝(imax–(d/t)/(1-(c-s)))×(1-w)

式中，其中i为指示器值，imax为本数据服务器硬盘组提供的最大数据吞吐量，d为最近数据读写量，t为读写d数据的时间，c为当前时间，s为开始统计时间，w为存储服务器的cpu使用率。

在选择读写的数据服务器过程中，还需要考虑如果申请读写的数据服务器本身就提供数据存储服务的情况。这种情况下，若本机指示器值不为0则，优先选择本机的存储服务。

在索引服务器选择出具体数据存储服务器后，后续的文件读写将由数据服务器实现，数据读写过程中，任何数据都不会经由索引服务器周转，这样做到目的就是确保不形成数据读写瓶颈。

具体数据存储服务器提供具体读写数据过程中又包括两种情况，

其一为写全新的数据，这种情况比较简单，自有文件系统只需提供简单文件读写即可。在文件读写结束后，自有文件系统还需要引用hdfs系统的文件写入功能，将文件同步到hdfs文件系统中，并对外提供文件读取服务。

其二为文件改写，也即修改已经存在的文件。这种情况的处理比较复杂，其处理流程如图5所示，主要工作步骤如下：

(1)首先在自有文件系统中立刻申请与待改写文件一样大小的存储空间，并对空间进行分块，分块大小与待改写文件在hdfs中的分块一致；

(2)将所有块标识为0，代表这个数据块还不存在；

(3)在hdfs文件中将修改的文件标识为无效，确保hdfs不再接受对此文件的访问，如果还有文件访问申请，直接交自有文件系统。

(4)根据改写文件地址，计算修改的数据块，并引用hdfs的读文件接口将数据读入内存，更新修改部分，然后将数据写入自有文件系统对应的块中，同时修改标识为1；

(5)所有修改完成后，与新建文件类似，引用hdfs系统的文件写入功能，将文件同步到hdfs文件系统中。

(6)将hdfs文件中已经标识为无效的原有文件删除，释放存储空间。

此外，为了解决大量小文件问题，本发明实施例采用hadoop系统提供的hbase数据库和小文件专用空间来解决。针对原生hdfs系统不支持对海量文件名的管理问题，引入hbase数据库管理文件名。hbase本身提供了基于支付串的索引和优化方法，理论上支持无限数据条目管理，经过测试已经确认hbase对上亿条记录的字符串检索时间优于2秒。在性能如此强大的数据库支持下，海量文件名检索已经不是问题。而针对小文件数据内容的存储，本发明通过建立大文件方式进行处理，具体讲就是将多个小文件保存到一个大文件中。在安装系统时，让使用者给系统设定小文件的容量限制(推荐默认值是64kb)，系统运行过程中，凡是文件大小小于64kb的文件，都将认为是小文件。本发明提供的文件系统中，所有文件的创建只有一个通道，那就是先在自有文件系统中创建文件，然后同步到hdfs中。在同步过程中碰到小文件时，系统不开展同步，而是将小文件的内容统一写到一个大文件中。特别提醒的是，这个存储小文件的大文件将采用固定记录大小的方式保存数据，其中每个记录的大小就是小文件大小阈值(如64k)，实际数据小于这个阈值也同样占用同样大小空间，采用这个机制看起来有点浪费空间，但却可以换来数据检索的便利和性能的提升。将小数据保存到大文件的同时也需要在文件名数据库的对应的数据条目中记录数据实际保存大文件名和文件偏移，以便应对以后对文件读取时可以方便的找到文件实际内容。这种组织方式可有效解决海量小文件的写入和读取，但对小文件的删除不利，为此本发明不得不添加额外的工作来解决这个问题，但综合效果仍然是优于现有技术。通常情况小，如果有小文件删除请求，索引服务器将直接对hbase数据库进行操作，移除文件名记录，但并不是删除记录，而是将记录移到另一个称为删除文件的表中。当删除文件表达到一定程度(如10万条记录)时，启动小文件内容整理工作。小文件整理其实也无需重新设计和开发，这个操作的本质是对文件进行改写，直接对保存小文件内容的大文件执行前面描述的文件改写功能即可。

综上所述，本发明基于开源hdfs系统，针对hdfs系统的3个缺点，设计的一套通道读写技术，最终能够实现海量数据的快速并发读写。

显然，本领域的技术人员应该明白，上述本发明的各步骤可以用通用计算机来实现，它们可以在存在于单个计算机或者分布在多个计算服务器所组成的网络上，通过设计开发或直接设置可执行的程序代码来实现，并且在某些情况下可以不同于文中所列顺序和步骤的执行，或将它们分别制作成单个或多个独立模块，因此，本发明不限制于任何特定的硬件和软件结合。

本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。