民航华东地区空中交通管理局 气象中心200335
摘要：民航空管气象数据的体量随着航空运输事业的蓬勃发展而与日俱增，使得空管气象部门对于气象相关数据存储、管理和读取的要求越来越高，传统的气象数据存储结构和服务模式面临相当大的挑战。本文通过分析开源大数据平台Hadoop的分布式文件系统HDFS、数据仓库工具Hive等架构，提出了一种结合了Hadoop技术的气象数据存储检索模式，并进行了相关实验和性能测试。实验证明，该气象信息存储系统可实现海量气象数据文件的分布式存储、元数据管理以及气象数据的查询，使用其进行大型气象数据文件存储和操作时，可以很好地提升数据吞吐率和数据读写操作效率。
关键词：空管气象；数据存储；大数据；Hadoop
引言
华东空管局各空管分局（站）主要承担华东地区各主要机场及机场周边范围内的空中交通管制、航空情报、通信导航监视和航空气象服务。十二五期间，华东地区的起降量从157万架次增长到227万架次，保持着年均8.8%的较快增长速度。2016年华东地区空管行业共保障各类飞行866万架次，占全国总保障架次份额为26.23%，同比增长7.28%。其中塔台、进近保障总量在全国七个地区空管局中位居第一；区域保障总量居全国第二。但与之相对应的航班正常性下滑非常明显，民航局、民航局空管局对保障民航飞行安全始终坚持安全隐患零容忍态度，在保证飞行安全的前提下，支持鼓励通过技术手段，改善和提高航班的正常率。
为确保飞行安全、有序、平稳，持续提升服务运行品质，气象信息需融合相关用户信息，并能更精细化的呈现，方便航空用户参考用于协同运行决策。针对用户的细致需求，通过技术手段建设能真正融入用户运行体系的气象服务，是当前空管部门乃至民航业对气象部门的迫切要求。对此，气象相关探测数据、产品数据体量都呈快速增长之势，不仅是数据种类上的增加，数据的规模也随着覆盖范围和精度的扩展、数据密度频次的提高而不断增加。
一、现有气象数据存储系统分析
气象数据具有以下特点： ①观测数据及时存储服务、长序列大数据集的气候研究数据服务需求并存；②观测数据收集和气象产品数据的生产都有时次性，会集中在整点出现存储和处理访问高峰，这对系统瞬时的峰值的处理要求高；③数据包括地面、高空、雷达、卫星、数值模式、各种气象产品等，种类繁多，结构化、非结构化数据混合；④数据的收集、处理和产品生成都是每天24小时不间断运行，对系统可用性要求高。
现有的气象信息系统多采用关系型数据库和集群文件系统结合的数据管理架构，其中关系型数据库存储结构化数据和非结构化数据的元数据信息，集群文件系统存储非结构化数据文件。这种经典的存储架构在一定的数据吞吐量和并发规模下运行正常，但不断增长的数据量使得系统负载过于饱和，影响了系统服务的时效性和稳定性。传统的通过购置更高端的设备来提升系统能力的垂直扩展方式成本高昂，而且扩展性能有限，急需应用分布式计算和存储技术，在低成本服务器集群上实现系统能力的水平扩展和快速提升。
在分布式计算和存储技术中，Hadoop能实现高吞吐量、高并发、高容错性、高可靠性、低成本、能扩展到云环境，被广泛地应用到互联网和多个行业。随着Hadoop技术的不断应用和发展，新的Hadoop2。0 版本通过多计算框架支持改造、Master节点单点故障排除、资源管理功能独立，在资源利用率和可用性方面都得到提升，特别是其对Storml实时流式处理、Spark内存迭代式计算、MPI并行计算应用程序框架等多种计算框架的支持，更加适用于民航气象这样有多种处理需求的应用场景。
二、Hadoop的原理
Hadoop的核心部件包括Hadoop common、HDFS、MapReduce、Hbase等。其中Hadoop common提供远程调用，序列化库等公共基础支持功能；HDFS实现了一个分布式文件系统；Hbase是基于HDFS的一个分布式列式数据库系统；MapReduce能对存储在HBase和HDFS中的数据进行分布式并行处理。本文主要涉及Hbase和HDFS的应用研究。
HDFS采用主从结构。名字节点NameNode是管理者，负责管理文件系统命名空间、集群配置和数据块复制，NameNode上存储了分布式文件的元数据。数据节点DataNode负责数据文件的存储和访问，数据节点作为从节点，会接收主节点的指令，向主节点报告各种状态信息。每个数据文件以数据块Block的形式复制多个副本分布在不同的DataNode上，而数据块需要物理写入底层文件系统，这个操作由数据节点上的守护进程执行。
Hbase在HDFS上增加了一层数据库实现，Hbase的层次从上而下依次是数据库逻辑层、文件系统逻辑层、底层系统逻辑层。数据逻辑层对外提供的读写接口所操作的数据都要写到HDFS上，依靠HDFS来屏蔽底层系统的异构性，实现集群数据的负载均衡、容错和故障恢复。Hbase数据库表在存储时根据RowKey范围被切分成一个个Region分布在多个RegionServer上，这些分布信息保存在HMaster上以备在读写数据时进行定位。每个Region又按列族分成不同的Store，Store在物理存储时存成HDFS上的若干HFile。这种多层次的数据分片方式在进行读写时能实现更高的并行能力。
三、框架与流程的设计
基于Hadoop的气象数据存储检索是气象数据环境整体框架的一个组成部分。根据全国综合气象信息共享平台系统现有总体框架，结合Hadoop在分布式存储处理技术方面的扩展，设计框架如图1所示：
图1 基于Hadoop的气象数据存储与检索系统设计框架
数据流程如下：国内国际气象观测资料和产品从数据收发部件收集进来后，经过解码、格式转化、算法运算等处理后，将数据经数据存储管理引擎的统一接口存储到异构的底层存储中。数据处理分析引擎基于异构的存储底层对数据进行分析处理和产品生成数据服务模块通过数据存储管理引擎、数据处理分析引擎来获取数据、产品和分析结果，对系统和用户提供数据服务以及数据可视化服务。在总体框架中，Hadoop技术主要应用于数据存储管理引擎和数据分析引擎部分，本文仅探讨数据存储管理引擎部分。
数据存储管理引擎能实现数据人库、数据检索、元数据管理、副本制作、数据迁移等功能，对外通过一套统一数据访问接口来提供数据的写人、读取及其他处理服务。统一访问接口的方式能屏蔽底层存储的差异，实现对异构数据的灵活组织和统一管理，也便于对底层存储组织方式的升级替换。未引入分布式技术之前，底层存储包括内存数据库、ORACLE关系型数据库和GPFS文件系统，应用分布式存储技术后，增加了HDFS分布式文件系统和Hbase列式数据库，以后还可以扩展到分布式关系数据库等其他类型的数据存储系统。
期刊文章分类查询,尽在期刊图书馆
气象数据在传输和服务时主要以文件形式存在，根据其数据特点和使用方式，可分为结构化数据和非结构化数据两种，其中结构化数据经过文件解码和格式转换后，可以存储在数据库中，如地面观测的风温湿压及降水等数据；而非结构化数据以各种组织编码格式数据集，使用时用户根据数据的时间、空间维度和变量属性来检索和获取数据集文件，如雷达基数据、卫星数据等。
四、应用实验设计
4.1 应用场景。实验面向典型的业务和资料开展，其中结构化数据选择自动站数据，非结构化数据选择雷达基数据。在数据访问中，不同业务人员会使用不同类型的检索条件。自动站数据常见的查询类型有面检索、时间序列检索和统计检索：面检索主要由根据时次查询所有站或部分站的气象要素数据；时间序列检索一般是单站连续长时间段的气象要素检索，也有一定范围内站点或所有站点的长时间段的气象要素检索；统计检索包括通过排序查询一定时间内某要素极值前十，统计给定时间，一定范围内站点的某气象要素均值或累计值等。雷达基数据常见的查询类型有面检索、时间序列检索：面检索如根据时次查询所有雷达站的基数据；时间序列检索如查询单雷达站一段时间的所有基数据。
4.2 运行环境。实验环境由8台服务器组成一个Hadoop集群，其中一个为MASTER节点，每台服务器配置64G内存，8核2.5GHZ的CPU，2块300GB SAS盘和6块3TB STAT盘，SAS盘用作系统盘，STAT盘用于数据存储；操作系统为RedHat Linux 6.4；Hadoop版本为1.03，Hbase版本为0.94.1。
4.3 存储结构设计
4.3.1 Hbase表行键设计。Hbase是无模式无类型的，只需要定义行键和列族，行键和列族会在数据文件级别产生影响，而在数据文件内部的具体数据都是以Key-Value键值对的形式存在。Hbase定位一个数据通过行键、列族、列和版本四个维度，但访问仅需左起的部分维度即可，维度越少，访问返回的数据集越大，使用起来是比较灵活。但是对于具体应用的开发而言，数据存储模式非常重要，一个好的数据存储模式能兼顾读写性能的均衡，会使整体性能运行良好。
Hbase数据存储模型的设计时，首先要确定表行键。我们根据数据访问方式提出了两种行键设计方案，通过测试分析，采用了其中综合性能较优的一种行键设计方案。在自动站业务中，自动站文件一般以时间和站点作为标识，这两个维度也是常用的检索条件，因此考虑了A：时间加站号以及B：站号加时间两种行键设计方案，列设计为每个气象要素一个列。在相同运行环境和参数下，对同一批测试数据进行了入库和查询测试，结果发现A方案下人库耗时仅为B方案的57.4%，A方案入库速度比B方案提升74.2%；而两者的检索效率互有优劣，综合分析后，采用了时间加站号的行键设计方案。
4.3.2 列族设计。行键确定后要进行列族和列的设计，在Hbase中，不同列族的数据是存储在不同的HFILE中，所以一般把同时访问的数据放在一个列族中，而在自动站应用中因为业务需要访问全要素，所以把数据都放置在一个列族中；同时考虑到列族和列的标识符包含在每个单元数据的Key-Value键值对的Key部分，这样如果标识符过长会造成空间的浪费，所以设计时尽量简化列族和列的标识符，以单字母和三位数字作为列族和列的标识符。
4.3.3 Solr索引的设计。因为在应用场景中，需要对主键外的要素进行查询和统计，而在Hbase中，只对主键的查询响应时间在毫秒级，所以非主键的要素查询响应时间不理想，考虑对Hbase的数据通过Solr建立索引。Solr建立索引的原理是从Hbase中检索列的角度建立其和主键间的对应关系。这样当需要查询这些列时, 首先通过对Solr索引的过滤获得符合条件的主键集, 然后在Hbase中通过这些主键可以快速获取数据。在建立Solr索引中, 根据检索需求, 主要对省代码、经纬度、降水量等列建立了索引。
五、性能表现
5.1 HDFS写入性能。以质量控制前具有统一格式的多普勒雷达基数据为例, 有1583个文件, 共22750M, 平均大小14.4M。从本地机通过put操作写入到HDFS集群需要293.85S，平均写文件速度为77.42MB/S。
5.2 HDFS读取性能。对于面检索如获取10分钟内所有雷达基数据文件（例1）, 6个线程并行查询, 结果集为271个文件, 从HDFS检索获取全部数据到客户机的耗时为3010毫秒, 吞吐量约为1273M/S。对于时间序列检索如获取Z9817雷达站1小时内的所有雷达基数据文件（例2），2个线程并行查询, 结果集为12个文件234MB, 从HDFS检索获取全部数据到客户机的耗时为1046毫秒, 吞吐量约为223.7M/S。
对例2进行并发测试, 在一台客户机上模拟50个并发查询进程, 同一个执行时间段里, 在另一台客户机上依次连续执行查询, 并发时段里共执行了5次, 平均耗时3630.1毫秒；最长耗时5999毫秒, 系统对并发查询的支持能力比较强。
5.3 Hbase入库性能。以自动站逐小时数据为例, 365个ASCII文件,2.47亿条记录, 每条记录95个要素, 共259GB数据量, 将这些数据均分到8台机器上, 每台机器并发12线程人库, 自动站数据从8个进程插入Hbase表最长耗时15821.2S, 平均写入速度15613条/S。
5.4 Hbase检索性能。针对2006-2011年8.96亿条自动站数据, 建立Solr索引后, 分别进行检索性能测试。在单用户测试中面检索测试中, 面查询各用例检索响应时间在481-629毫秒之间, 最多返回20519条记录；时间序列检索中, 24小时之内的数据查询响应时间分别为624毫秒和669毫秒。而对于跨度为6个月的查询耗时较长, 为11025毫秒和11046毫秒。分析其原因在于时间跨度大需要检索的记录数大大增加。统计检索中，1个月之内的数据排序及均值检索都在511-558毫秒之间完成；所有站日累计降水量和样本数耗时较长, 为3019毫秒。平台在处理单用户查询时拥有较好的查询性能，大部分查询的响应时间均在秒级。
在单机50个随机用例并发的压力测试中, 面检索平均耗时1025.5毫秒，最长耗时1800毫秒；统计检索的平均响应时间为12834.2毫秒, 最长耗时为40717毫秒；时间序列查询因并发需求不大, 所以暂未做测试。从结果可知, 面检索响应时间基本在秒级之内, 统计检索考虑到其中包含全时间跨度的全站统计, 测试结果还是比较能满足应用需要的。
六、结束语
本文根据民航空管工作中的气象数据存储检索所面临的问题, 提出了基于Hadoop的气象数据存储检索设计, 针对代表性的结构化与非结构化气象业务数据, 进行应用实验和测试。从测试结果来看，该实验中设计的气象数据存储结构能较好的满足业务需求, 可作为应对海量气象数据增长带来的存储服务问题的有效解决途径之一，亟待进一步的性能优化。
参考文献
[1]蔡斌，陈湘萍. Hadoop技术内幕[M].北京：机械工业出版社，2013；217.
[2]N.Dimiduk. Hbase实战[M]. 谢磊，译,北京：人民邮电出版社，20163；81-102.
[3]李建东．数据仓库技术在气象领域的应用前景分析[J]．气象与环境科学，2009，(S1)．
[4]姚燕，李湘．基于web的国外实时气象资料服务系统[J]．计算机应用与软件，2007，(02).
论文作者:夏莹
论文发表刊物:《科技新时代》2019年4期
论文发表时间:2019/6/19
标签：数据论文; 气象论文; 数据存储论文; 分布式论文; 文件论文; 结构化论文; 时间论文; 《科技新时代》2019年4期论文;