CN104376053A - 一种基于海量气象数据的存储与检索方法 - Google Patents

Abstract

本发明针对传统的数据集中存储单点查询的问题，公开了一种基于海量气象数据的存储与检索方法，利用Hadoop平台，通过对分布式非关系型数据库Hbase建立二级索引，并且将数据通过转换、迁移导入到云平台，实现海量数据的可靠存储与快速检索。本发明包括如下步骤：数据过滤；在Hbase中定义对应的表格式；建立二级索引；分情况进行数据导入；分情况进行数据检索。本发明既能实现数据的实时查询，也避免以往存储和维护大量数据所产生的高昂成本，在保证敏感数据安全的前提下能够更经济高效地实时查询海量气象数据。

Description

一种基于海量气象数据的存储与检索方法

技术领域

    本发明属于云存储技术领域，具体涉及一种基于海量气象数据的存储与检索方法。

背景技术

云计算技术起源于企业界，由于其强大的处理大数据的能力，成为了计算机技术发展的趋势，因此受到了业界与学术界的关注。随着云计算的发展，云存储的重要性和价值也日益显著。衡量系统的可用性通常用系统的正常服务时间与总运行时间的比值表示，即如下计算方式：

其中，MTTF为平均无故障时间，MTTR为平均为维修时间。从提高性价比的角度，采用容错的方式提高MTTF更加有效。因此，如何设计实现既能安全可靠存储海量气象数据，又能低延迟查询这些数据的方案成为了当前首要任务。

随着Apache开源项目Hadoop的普及，存储设备成本的降低，使得企业自身搭建云平台成为可能。早期的存储方案中直接使用Hadoop+Hbase的组合，通过组合行键来建立索引以提高检索性能，但是这种方法只适用于少量列簇的情况而且功能单一，一旦建立索引就无法更改，给以后的系统功能扩展带来不便。也有方案选择依托第三方的paas（平台即服务）方式，这种方式虽然利用商业平台简化了搭建高性能集群的技术问题，但是由于数据不在本地，敏感数据不能得到很好地保护，更有泄露的风险。进一步有研究者在大规模数据存储方法中主要是利用Hadoop平台和HIVE的整合，大幅度减少了海量数据的查询时间，但是由于基于HDFS，使得Hive中数据一旦导入就无法更改，对此需要人为定时的下载最新数据。

气象数据由于需要不断采集与更新，数据量很大，传统的存储方法占据了大量的空间，伴随数据量的增加，数据维护成本暴增并且检索时间大大增长，从而导致了数据的处理效率低下。传统方法利用专用服务器简单通过关系型数据库（RDBMS）单点存储气象数据造成成本高企，而利用hadoop平台的大量廉价机器搭建集群则会带来数据的分布式冗余存储的问题。

发明内容

随着对非关系型数据库研究的深入，云存储得到进一步的应用和发展，数据从传统的关系型数据库迁移至云端也成为了以后的趋势。本发明针对传统的数据集中存储单点查询的问题，公开了一种基于海量气象数据的存储与检索方法，利用Hadoop平台，通过对分布式非关系型数据库Hbase建立二级索引，并且将数据通过转换、迁移导入到云平台，实现海量数据的可靠存储与快速检索。

为了达到上述目的，本发明提供如下技术方案：

一种基于海量气象数据的存储与检索方法，包括如下步骤：

步骤（1），对不同的采集终端所收集到的气象数据进行归类和校验，去除掉错误数据、重复数据；

步骤（2），按照采集的气象数据结构，在HBase中建立对应的表，其中，RowKey为能唯一标识的字符串，列簇按对应的气象数据的格式预先定义；

步骤（3），建立主表的同时创建一张索引表Index，索引表的行键与主表的对应列值相关联并且包含主表的行键值；

步骤（4），导入数据：若是已经存在HDFS文件系统上的tsv,csv格式文件，则将数据封装成Hfile后加载到Hbase上；本地文件系统上的数据需要先上传到HDFS再导入Hbase；对于传统关系型数据库的数据，使用ETL工具kettle完成数据导入；

步骤（5），检索数据时，根据索引表信息判断被检索的列是否有索引，如果有则直接通过索引表查询；如果被检索的列没有索引，则利用Hive通过Mapreduce框架进行全表的查询。

进一步的，所述步骤（2）建立的表中的列簇下面的列在数据导入时动态添加。

进一步的，所述步骤（3）中创建的索引表的行键rowkey构成为：{开始地址+索引表名称+索引列值+主表行键值}。

进一步的，在所述步骤（2）建立的主表中插入数据时先在索引表中插入相关索引信息，再完成主表插入工作；当主表被分割的时候，对应索引表自动分割，并且保证索引表的region与对应主表的region在同一个region server上；在主表数据发生更新时，索引表里的对应记录也同时更新。

进一步的，所述步骤（5）中通过索引表查询时，通过Coprocessor创建scanner并设置起止范围，在索引表中查找到具体的rowkey之后，根据此rowkey具体关联的主表Rowkey，在主表region中查找实际的数据。

与现有技术相比，本发明具有如下优点和有益效果：

本发明基于云平台、分布式文件系统技术，结合并优化了分布式数据库的二级索引功能，有助于大量气象数据的可靠存储与快速查询；同时为能快速高效的得到数据查询结果，充分利用Coprocessor的功能，使得Hbase实现了二级索引。通过上述手段既能实现数据的实时查询，也避免以往存储和维护大量数据所产生的的高昂成本，在保证敏感数据安全的前提下能够更经济高效地实时查询海量气象数据。

附图说明

图1为本发明方法的步骤流程示意图；

图2为是Hbase建立二级索引的原理图；

图3是利用二级索引查询数据的流程图。

具体实施方式

以下将结合具体实施例对本发明提供的技术方案进行详细说明，应理解下述具体实施方式仅用于说明本发明而不用于限制本发明的范围。

本例采用某观测站的常规气象数据，通过数据过滤、数据转换、数据迁移等步骤、基于Hadoop平台来保证海量数据的存储与检索。如图1所示，本方法包含如下步骤：

步骤10，从不同的采集终端收集各种气象数据，并对这些气象数据进行归类和校验，去除掉错误数据、重复数据。本例中采集的数据集按照如下列分类：{观测站代码、行政编码、时次、一小时雨量、气温、最高气温、最低气温、二分风速、二分风向、十分风向、十分最大风速、最高气温时间、阵风最大风速、阵风最大风向、阵风最大时间、相对湿度、日期}。每项参数应预先设置正确的范围值，采集的时候判断各项参数范围是否正确，删除超出正常范围的错误数据，这样能够确保入库的数据都是真实有效数据，再通过本文方法导入数据库中。

步骤20，按事先人为按照采集的气象数据结构建立Hbase的表格式，并在HBase中建立对应的表，RowKey为能唯一标识的字符串，列簇（column family）按对应的气象数据的格式预先定义，列簇下面的具体列（qualifier）可以在数据导入时动态添加。基于步骤10中采集的数据集，需要建立的Hbase表可以采用{自增ID+观测站代码+行政编码+时次}（{region_startkey + index_name + indexed_column_value + user_table_rowkey}）的格式作为Rowkey，如{000_025001_210044_2013-8-31_21:00}。这样的行键设计，既满足了Rowkey不会重复，也可以直接按指定观测站、地域、时间等条件查询。列簇则可分为{气温，风力，降雨信息}。

步骤30，在步骤20建立主表的同时利用Coprocessor的子类Endpoint同时创建一张二级索引表Index，索引表的行键与主表的对应列值相关联并且包含主表的行键值（Rowkey）。

建立二级索引，具体的建立过程如下：

步骤301，Hbase的协处理器Coprocessor分为两个子类：Endpoint和Observer。Endpoint相当于存储过程，Observer相当于触发器。在建索引表时，首先利用Endpoint的实例拦截客户端的插入、删除、更新数据的操作，在用户对表进行如上操作的同时建立索引；

步骤302，对于插入操作，首先需实现Coprocessor子类Observer中的prePut方法，此方法在每一次put执行之前被调用，用来判断用户是否插入新的数据。每一个被插入的值，都通过Put类的实例先插入到索引表中，插入的同时追加索引表名、列值、对应行键值等信息。每插入一条数据需要创建一个新的索引表连接，与直接插入相比耗时增加约一倍。如图2所示，R1为用户表usertable的一部分（即003-077），存储在某Region上，每个Region是一张表的一个分区，每个RegionServer又有多个Region组成，负责处理用户的数据读写请求，并进行相应的HDFS文件读写操作。当用户（Client）想插入一条数据时，如步骤20的记录中插入的最高气温为39度，由于建表时在{气温：最高气温}({TEMP：Highest})列建立了名为HighTemp的索引,当插入的值为39(单位：度)时，协处理器coprocessor利用prePut方法同时向相应的索引表中添加一个行键为{003/HighTemp/39/000_025001_210044_2013-8-31_21:00}的记录，其中开头的003是此分区（region）的起始位置，便于检索时候的定位。

步骤303，每张表开始时只有一个Region，当表中数据变多超过一个阈值的时候，这个Region会等分成两个相同的Region，此过程循环进行。对于分割操作，首先需实现Observer（Coprocessor的子类）中的preSplit方法，此方法在Region分割前被调用，然后再执行分割操作。在分割的时候得到分割处rowkey的ID值，再通过解析将索引表中所有此ID之后的数据复制到新索引表中，并删除原记录。再通过重写的负载均衡机制balance保证索引表和主表在同一个region server上。同时，在主表数据发生更新时，索引表里的对应记录也要同时更新，且此更新满足事务性要求。

步骤40, 将数据导入数据表中，首先判断数据的来源，根据文件的位置选用两种不同的方法完成数据的导入工作：

1）HDFS上的文件：若是已经存在HDFS文件系统上的tsv,csv格式文件，则使用Hadoop的importTsv类将数据封装成HFile，再通过completebulkload命令加载到Hbase上；本地文件系统上的数据需要先上传到HDFS，再通过以上方法导入Hbase。

2）传统关系型数据库中的表：手动使用ETL工具Kettle完成迁移。

在通过以上两种数据导入方法导入数据时均采用步骤301-302中的方法，在更新数据的同时，将实现索引表的同步更新，当数据表过大进行分割的时候，按照步骤303，自动对原数据表和索引表进行分割与调整。

步骤50，检索数据时，首先拦截客户端请求，判断被搜索列是否建有索引，如没有建立索引，则转入步骤501，否则，转入步骤502：

步骤501，如检索“相对湿度=30%”，但在步骤10中该列没有建立索引时，则利用Hive通过mapreduce框架完成整表的扫描，并返回结果；

步骤502，如检索“最高气温=39”，而该列在步骤302中已经建立索引，则首先通过协处理器Coprocessor创建一个搜索实例scanner并设置起止范围(如[startrow,endrow)为：[003/HighTemp/39, 003/HighTemp/40))，如图3中的第1、2步,在索引表的行键中检索，把“39”对应的exact key“000_025001_210044_2013-8-31_21:00”解析出来后返回给服务端，如图3的第3、4步，再通过Observer类实例的回调函数去主表查询该行键对应的列值如图3的第5步，最后返回最终搜索结果，如图3的第6步，完成查询过程，完整流程如图3所示；

本发明方案所公开的技术手段不仅限于上述实施方式所公开的技术手段，还包括由以上技术特征任意组合所组成的技术方案。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围。

Claims (5)

1.一种基于海量气象数据的存储与检索方法，其特征在于，包括如下步骤：

步骤（1），对不同的采集终端所收集到的气象数据进行归类和校验，去除掉错误数据、重复数据；

步骤（2），按照采集的气象数据结构，在HBase中建立对应的表，其中，RowKey为能唯一标识的字符串，列簇按对应的气象数据的格式预先定义；

步骤（3），建立主表的同时创建一张索引表Index，索引表的行键与主表的对应列值相关联并且包含主表的行键值；

步骤（4），导入数据：若是已经存在HDFS文件系统上的tsv,csv格式文件，则将数据封装成Hfile后加载到Hbase上；本地文件系统上的数据需要先上传到HDFS再导入Hbase；对于传统关系型数据库的数据，使用ETL工具kettle完成数据导入；

步骤（5），检索数据时，根据索引表信息判断被检索的列是否有索引，如果有则直接通过索引表查询；如果被检索的列没有索引，则利用Hive通过Mapreduce框架进行全表的查询。

2.根据权利要求1所述的基于海量气象数据的存储与检索方法，其特征在于：所述步骤（2）建立的表中的列簇下面的列在数据导入时动态添加。

3.根据权利要求1或2所述的基于海量气象数据的存储与检索方法，其特征在于：所述步骤（3）中创建的索引表的行键rowkey构成为：{开始地址+索引表名称+索引列值+主表行键值}。

4.根据权利要求1或2所述的基于海量气象数据的存储与检索方法，其特征在于：在所述步骤（2）建立的主表中插入数据时先在索引表中插入相关索引信息，再完成主表插入工作；当主表被分割的时候，对应索引表自动分割，并且保证索引表的region与对应主表的region在同一个region server上；在主表数据发生更新时，索引表里的对应记录也同时更新。

5.根据权利要求1或2所述的基于海量气象数据的存储与检索方法，其特征在于：所述步骤（5）中通过索引表查询时，通过Coprocessor创建scanner并设置起止范围，在索引表中查找到具体的rowkey之后，根据此rowkey具体关联的主表Rowkey，在主表region中查找实际的数据。