烟台新型自动气象站数据本地存储的设计及实现

哈艳丽++黄本峰++袁海豹+徐立君

摘要：该文以新型自动气象站数据上传机制为基础，针对大监站数据在市一级存储存在的问题，对数据流程、数据获取、数据解析、数据存储、数据纠错等各环节开展了有针对性的研究。通过研究实现了大监站分钟数据、小时数据、日数据在市一级的自动入库，为各项应用提供了基础。

关键词：烟台；新型自动气象站；数据；存储

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2016）14-0193-03

近年来，新型自动气象站在各地布设完成，成为基准站、基本站和一般站的标配。随着新型站的运行以及工作流程的完善，与以前类型测站运行产生了若干差异：数据存储差异，新型站B文件不能直接读取；订正差异，异常数据的订正流程改变；数据传输差异，以单个文件的形式上传数据等。新型站数据传输机制是直传到省局服务器，这些都使得地市无法实时方便地直接从各台站获取到大监站数据。之前，烟台市在获取各大监站小时数据时，是靠同步省局服务器上的数据查询页面完成，日数据是靠在各站计算机上安装软件，自动获取B文件数据来完成，但这样获取数据在稳定性和可靠性均存在不足，对观测数据纠错流程设计等方面考虑不够等问题。基于此，也就需要对新型站上传、纠错、存储的流程及规律进行详细了解，以便于找到切实可行的办法。本文就是对此流程进行分析、研究，找出其规律，并就数据如何下载、处理、存储等提出了解决方案。

1 设计思路

目前，山东省各级台站通过宽带网络将实时数据传输到省局服务器，当遇有网络故障时，则自动启动3G网卡，进行数据传输。数据到省局后，经过一体化平台的审核，对有疑问的数据直接反馈给台站，由台站进行确认或订正，订正后的数据再由原路由上传，或由台站直接登录MDOS平台进行修改。当MDOS平台审核通过后，则存放于省局172.18.200.251服务器的对应的质控目录下，供各单位访问，如图1所示。从中我们可看出，各台站到省局一体化质控部分，这部分流程是比较完整的，因此研究点的选择要从质控后的数据入手比较合适。

2 技术实现

2.1 文件名命名及数据结构

目前新型站传输数据文件名及结构符合《地面气象要素数据文件格式（V1.0）》的命名要求和存储要求，其中常用的长Z文件格式如下：

Z_SURF_I_IIiii_yyyyMMddhhmmss_O_AWS_FTM[-CCx].txt

其各代码含义以及文件内容结构参见文件格式规定。

2.2 数据传输及解析处理

我们通过ftp方式获取251服务器中一体化目录以及数据质控后存放的目录（ST_QC、ST_DAY_QC、SS_DAY_QC）下的数据。

2.2.1 本地实时数据的获取

1）本地数据的识别。由于一体化目录存放的是全省123个大监站每5分钟的实时数据，若每次传输所有站点数据文件，会因无效站数据多造成运行的效率低下，因此我们在下载时增加了本地站点的筛选功能。

2）最新数据的识别。下载过程还会遇到一个问题：由于一体化目录存放多天的数据，若每次都同步获取指定台站数据，也会造成大量已传输的数据被重复下载。因此我们在本地设置一个下载过的历史文件列表，当系统获取一体化ftp目录文件列表后和本地列表核对，若为新文件，则下载，否则跳过，这样就保证了只获取最新的记录，提高了运行效率。

3）列表的定时清理。当运行一段时间后，本地列表文件会变得很庞大，增加了系统检索比对的时间，因此设定每旬检查一次列表文件，只保存最新的10万个文件记录。

2.2.2 解析与处理

1）数据文件的排序处理。大监站数据生成都是按时间顺序进行的，但数据通过转存，会造成文件的修改时间的变化，因此，只通过文件的修改时间来确定处理顺序会存在问题。唯一可行的就是通过文件名排序后，按照文件名顺序依次处理。我们通过读取最新文件列表，再根据列表内容排序，然后按顺序来处理，以避免站点数据在先后次序上出现问题。

2）数据的解析处理。对每次获取的最新的文件，根据时序进行打包，通过每次解析打包文件中的内容来实现要素的识别，最后存储到相应的数据库中。数据的解析按照处理文件的种类分三种：5分钟（小时）数据文件，日数据文件、日照数据文件。每种数据文件根据所含的要素不同，解析出对应的值，若数据有问题，则以“-9999”进行标注处理。解析后的数据根据内容存放到分钟数据表、小时数据表和日数据表中。

2.3 数据存储设计

当前各地新型站上传省局的实时数据文件主要分三种：分钟数据文件、日数据文件、日照数据文件，小时数据与分钟数据相同。为能够方便存储和识别，我们建立了分钟数据表、小时数据表和日数据表，这样就保证了分类存储，很方便的实现有序访问。

2.3.1 分钟数据表设计

表名为obserRealTimeDataMinuteAWS，存放各站每5分钟的数据，其数据源来自各站的分钟长Z文件。其表结构设计时，考虑最大限度的提取长Z文件的要素数据，为今后的应用提供基础，其中对无效数据冠以“-9999”进行标注，除经纬度以浮点形式存放，观测时间、写入时间以日期型存放外，其余均设置为字符型，这样能更方便的应对一些特殊数据的处理，如风速的PPC等。具体的表结构如下：

各站的整点长Z文件，表结构同分钟数据表。

2.3.3 日数据表设计

表名为obserRealDayDataAWS，存放的是各站的日数据。数据表中包含了08-08时的数据，如高低温、降水量，这部分为预报质量评定提供数据；日照数据和蒸发数据，这是根据可能会涉及到的服务增加的；在日平均气温、最大、极大风挑取时增加了统计时次，以方便查阅统计数据的完整程度。日数据表中的数据可分别由以下途径来获取：

（1）08时和20时小时长Z文件。如降水量、高低温等；

（2）日数据文件。如天气现象等；

（3）日照数据文件。如蒸发、日照数据等；

（4）程序自动统计。如平均气温取各站02、08、14和20时干球温度均值；最大风、极大风的风向、风速取各站24个整点时次的相应数值进行挑取。

其表结构如下：

2.4 数据的备份及纠错机制设计

2.4.1 备份机制设计

当对获取的数据文件处理完毕后，系统会自动打包备份到分钟数据、小时数据和日照数据单独的文件夹内，作为历史文件资料保存，也为以后数据的查阅和系统测试提供数据源。

2.4.2 纠错机制设计

数据处理若要保证正确无误，就要考虑、设计进纠错或完整性设计。在系统处理过程中，对这部分的考虑如下：

1）数据统计的规范性。在日数据统计中，涉及到平均值、极值的挑取，其算法和规则，均按照《地面气象观测规范》以及报表规定进行设计，保持结果的统一。

2）数据处理的时序性。在1.2.2的1中提及，数据处理时必须按照时间先后顺序进行。

3）数据的即传即处理。系统处理中，会自动捡取最新的上传文件，依据时间进行处理，并将插入或重新改写数据库中的原有记录，这就保证了数据的即时处理。

4）数据的人工补传。当各站检查数据有疑误时，可单独上传到本地服务器的指定目录下，系统会自动进行挑取处理，这样就弥补了数据意外缺失造成的问题。

5）数据完整性检查。这体现在两方面，其一是在日数据统计中，均给出有效时次的记录，便于核对；其二，在每天的19时后，对全天记录进行核查，若记录数不足，则启动数据回传机制，重新补录、处理数据，这样就尽可能的避免了数据处理过程中造成的不完整。

6）数据的人工检查。在研究过程中，先后3次下文，要求各站对处理后的数据进行人工核查，对出现的问题进行汇总，并提出尽可能的解决方案，我们对反馈的信息注意查找，最终实现问题的解决。

3 应用

通过研究形成的大监站数据库，在烟台市的以下方面进行了应用：数据用于预报质量对比和评定，有助于随时掌握市局的预报质量情况，以及对各县市区的指导，对提高预报准确率比较有利；在农气旬月报编辑上为农气周报、旬报、月报、季度及年度气候影响评价的提供了数据支持，为各站积温等各类数据统计提供了便利。替代了各站原有的手工上传日数据工作，大大减轻了基层的工作量。另外在气象证明开具、气象信息服务等方面均提供了数据支持。