CIMISS 数据环境中数据入库滞后常见问题的解决＊

许竹霞，孔小怡，徐 娟，付 杰

（甘肃省气象信息与技术装备保障中心，甘肃 兰州 730020）

随着人们生活质量的不断提高，天气预报在社会公众中的地位也不断提升，精准、快速地向广大群众提供天气预报服务变得尤为重要。这就要求气象信息中心高效地保障快速增长的气象数据的收集、分发、解码入库及资料共享服务，为气象预报业务、科研、气象公共服务提供高效、精确的气象资料。

全国综合气象信息共享平台（China Integrated Meteorological Information Sharing System，简称“CIMISS”）是国家气象信息中心2009 年启动建设的数据管理和服务平台，集气象数据收集、加工处理、存储管理和共享于一体，运行于国家级和31 个省级气象数据中心，管理国家级或省级数据中心全部可收集的国内外气象资料和业务产品[1]。CIMISS 系统主要包括数据收集与分发（CTS）、加工处理（DPC）、存储管理（SOD）、业务监控（MCP）及标准化的接口服务（MUSIC）5 个子系统。

CIMISS 系统于2016 年在甘肃省气象局全面业务化运行，实现了数据集约化管理，同时，统一的数据服务接口（MUSIC）为用户提供了数据应用服务的能力。目前，甘肃省气象局兰州中心气象台、西北区域气候中心、公服气象服务中心等多个单位的业务系统已与CIMISS 平台的MUSIC接口对接，CIMISS 平台为气象服务提供了更有力的业务支撑。随着用户访问量提升，CIMISS 数据库暴露出来的问题日益显著。造成数据入库滞后及不入库的原因主要有：台站上传数据所归属的表分区不存在，比如台站上传的30 d 以前的大量历史数据的分区已清除、实时分区未及时创建；标准格式数据（BUFR）入库程序自身局限性；接口用户的暴力检索等。针对这些问题，通过梳理问题、优化数据库表及接口配置、对已入库的重复数据进行处理，以期提高数据的及时性、准确性，为气象预报、科研、公共服务做好保障工作。

1 CIMISS 系统总体数据流程

气象原始观测资料由台站直接上传至省局CIMISS 系统的收集与分发系统（CTS），通过CTS 收集处理（打包、文件名检查、格式检查等）后发送至国家局、数据加工处理系统（DPC）、本地共享服务器及省际共享用户等。DPC 负责气象数据加工处理工作，处理后的数据入库存储在SOD 系统中，结构化数据解码后存储在关系型Oracle 数据库中，非结构化数据通过DPC 解码、重命名在Oracle 数据库中，只存储索引表，实际数据存放在GPFS 共享文件系统中。用户通过统一的数据访问接口（MUSIC）访问数据。甘肃省CIMISS 系统总体数据流程如图1 所示。

图1 甘肃省CIMISS 系统总体数据流程

2 数据库表分区不存在导致入库滞后

分区技术[2]是Oracle 数据库为简化一些数据量庞大的表的管理推出的重要技术，将表和索引细分为较小、较容易管理的段，从而使数据库管理员能够用分而治之的手段进行数据管理，具有相当大的灵活性。其优势[3-4]在于：提高数据访问的速率；每个分区之间的数据操作不会相互影响，将每个分区的数据分割开来，最大程度地保证了所存储数据的安全性和可靠性。

甘肃省CIMISS 数据库中存储了实时历史的气象海量数据，随着表中数据量不断增加，查询数据的速度会变得非常缓慢，因此在设计数据库时根据不同的气象数据（分钟数据、小时数据、日数据等）设计的数据库表也不同。对于观测及访问频率较高的分钟数据，CIMISS 数据库在设计时采用小时分区表，每小时都会自动添加下一时次的分区；小时数据及日值数据表以日为分区表，每天凌晨业务空闲时段添加次日的分区表。其他类型的资料分区思路是一致的。当数据通过全国气象通信系统CTS 分发至DPC 解码入库时，如果表分区不存在，数据库表在自动创建分区的时候使表相关的游标[5]（cursor）全部失效，而CIMISS 数据库存在按小时的自动间隔分区，每个小时都会自动添加新的分区，而新增分区会导致正在创建分区的表在library cache 中的对象全部需要重新解析，造成解析锁争用，从而影响数据入库。此外，数据库设置有自动清除历史数据的脚本，删除大量历史分区也将影响数据入库。一般出现该问题的表是创建分区较频繁的表，即分钟数据表。

以地面分钟降水表SURF_WEA_CHN_PRE_MIN_TAB为例，该表存储了全国2 427 个国家级气象自动站的每分钟数据及甘肃、青海、陕西、宁夏、四川5 省共9 300 多个区域站的5 min 加密数据。结合甘肃省实际的CIMISS 存储空间，地面分钟数据表的存储时效设置为30 d。每天通过自动脚本定时清除30 d 以前的数据，即删除分区表。

分钟历史数据并不提供有效的气象服务，额外增加了删除历史数据的工作量，对数据库入库性能造成一定影响。因此，需要通过修改DPC 系统的BUFR 入库程序限制历史数据入库，根据业务需求入库程序将入库资料的时间限制设置为48 h 以内的数据（包括地面分钟、地面小时、辐射分钟、辐射小时、酸雨日数据）自动处理入库。修改的相关程序文件和参数文件包括：/space/cimiss_BCLZ/app/bin/dpc/dbmerge_bufr2/bin/running 目录下的程序文件dpc_bufr_file、dpc_bufr_msg/space/cimiss_BCLZ/app/bin/dpc/dbmerge_bufr2/cfg 下的参数文件 surf_mm.xml、surf_hh.xml、radi_mm.xml、radi_hh.xml、acid_rain.xml。此外，对于特殊情况，如需将48 h 以外的数据入库，需要系统维护人员手工将原始文件生成消息后入库，跳过入库程序时间限制环节入库。

此外，有时会因为诸多原因Oracle 数据库表没有提前创建分区，大量实时数据涌入，业务量大的时候，新增分区会造成阻塞。此时，应采用提前手动创建分区的方法，步骤如下。

检索出CIMISS 数据库中以小时为分区的所有数据表，SQL 查询语句为：select owner，table_name，INTERVAL from dba_part_tables where owner=&apos；USER_SOD&apos；AND INTERVAL like&apos；%HOURS%&apos。

编写脚本配置文件table，将需要提前创建小时分区的表都配置在table 文件中，创建自动分区的脚本从table 表中按顺序读取需要创建的分区。

编写创建自动分区的脚本auto_add_part.sh 后，停止与数据库连接的DPC 系统、SOD 系统以及MUSIC 系统的应用，三个应用系统涉及到的应用进程比较多，分别停止各个系统的应用比较麻烦且耗时。因此，选择业务比较空闲时候，直接在数据库服务器上使用命令srvctl stop scan_listener 关闭SCAN 监听；并且在数据库各节点机（甘肃的CIMISS 基础库为db01、db02）上kill 掉所有应用进程ps -ef|grep$ORACLE_SID|grep -v ora_|grep LOCAL=NO|awk '{print$2}'|xargs kill-9；执行提前分区脚本sh auto_add_part.sh，创建15 张数据表的30 d 的分区大概用时40 min；分区创建完成后，重启SCAN 监听srvctl start scan_listener，应用会自动连接数据库[6]。

3 入库进程异常导致入库滞后

CIMISS 系统中解码入库程序常会出现进程掉或僵死的情况，导致数据入库异常的因素主要有入库程序不完善、数据接口访问用户暴力检索等。

3.1 入库程序不完善

全国数据标准化（BUFR）格式于2019-12-12 单轨运行，正常情况下，BUFR 数据入库时间比资料观测时间晚24 s 左右，但在运维过程中发现地面BUFR 分钟数据入库时间字段（D_IYMDHM）比观测时间字段（D_DATETIME）晚2～3 min，延时最高时可达4 min 以上。以2019-12-16 的情况为例，2019-12-16T07：30—08：40（国际时）兰州站（52889）地面分钟数据入库时间与数据观测时间的差值情况如图2所示，08：00 后 D_IYMDHM 比 D_DATETIME 平均滞后 2～3 min。查询日值发现出现入库程序僵死现象，但是数据竟然滞后入库。此类情况是由于数据库出现异常中断后，入库进程未设置重连机制，修改入库程序，增加数据库重连机制可解决此问题。

图2 兰州站（52889）地面分钟数据入库时间与观测时间差值

3.2 数据接口访问用户暴力检索

甘肃省气象数据统一服务接口的WEB 用户有130 个、API 账户有74 个用户，MUSIC 接口用户每日访问数据次数为45 万次左右、访问数据量达350 G 左右，汛期该数据还会上浮很多。接口用户高并发访问CIMISS 数据时对数据库造成的压力是不可忽视的，通常在汛期数据库僵死的概率更高。运维中遇到的情况是数据库性能低下、数据入库缓慢，数据库服务器的CPU 使用率持续在99%左右，省局运维人员可通过停止接口服务应用恢复CPU 使用率。

接口用户对分钟数据的获取各自指定了程序策略，比如在获取地面分钟数据时，数据同步策略是每5 min 一次，但是由于数据偶尔会出现入库滞后的问题，用户会对每批数据的同步设定重复同步3～5 次，这就会严重影响其他用户的访问效果。省局运维人员需与用户沟通自定义一些接口，将用户的全量同步变为增量同步。

4 总结

本文根据日常的运维经验对CIMISS 数据库入库滞后的常见问题进行分析并提出解决办法，但是影响数据入库的因素众多，文中的处理办法也存在一定的局限性，在今后的运维工作中应进行更加全面的考虑和研究。