引言

随着大气监测和预报预警服务需求的提升，各类探测设备(刘思瑶等，2021；余蓉等，2021)和数值模式预报系统(夏军等，2019)的时间、空间分辨率不断提高，所产生的数据量不断增大。中国气象局武汉暴雨研究所建立的基于双偏振雷达、X波段雷达、边界层风廓线雷达等多种探测装备的暴雨监测外场试验基地初具规模，依托该基地以及多个国家自然基金重点项目开展联合观测试验，获得了大量的观测资料和试验数据(傅云飞，2019)；依据多途径探测资料的融合分析系统已经全年业务运行，可提供每3 h间隔10 km分辨率的中尺度分析场；华中区域中尺度数值天气预报模式可提供各种高分辨率的预报产品；武汉RUC快速更新循环预报系统更是达到了1.5 km水平分辨率、15 min分析更新频率、1 h预报更新频率、0~12 h预报时效的快速循环分析系统(赖安伟等，2021)；华中区域环境气象数值预报业务系统能够提供华中区域9 km分辨率、0~78 h内逐小时6种污染物浓度及能见度数值预报产品(刘琳等，2018)。

大量气象及气象敏感行业所产生的各类结构化和非结构化数据，使气象数据具有了大数据的海量性、多样性与高速更新的特征，可以说真正进入了气象大数据时代(沈文海，2019；刘媛媛等，2021)。气象数据价值随时间往往呈断崖式下跌，必须第一时间融合相关应用技术，深度挖掘气象数据所存在的价值。因此，气象大数据业务处理平台往往要求数据实时在线，并且可以随时被调用与计算(邱晨辉，2021)。气象大数据主要分为行业大数据和互联网大数据两种(沈文海，2016)。行业大数据包括：与气象部门内部业务工作息息相关、由专业设备采集的内部气象数据；与水利、环保、生态等其他行业部门进行数据共享、交换获得的数据(殷志远等，2020)；由原始气象数据经过处理加工产生的气象服务类产品数据；以及各个业务系统的运行日志数据等。互联网大数据包括互联网上所有与气象有关的数据，可以是历史气象信息，或者搜索引擎对气象相关的分析数据，以及所有可供气象部门业务工作应用的数据等(徐亮亮，2021)。截止2021年12月，湖北省存有的各类气象数据总量约7 PB，且近年来气象及相关数据增长明显加速，2020年以来各类数据增加超过109 TB，其日增量由2015年的约200 GB提高到2021年的约400 GB。

气象发达国家的大数据进程启示我们，要推动以大数据为基础的创造性服务，就必须大力发展基于行业数据平台的专业服务、基于统计数据挖掘的分析服务、基于大数据的民生服务、管理服务以及基于行业或价值模块细分的服务，通过对自然灾害历史信息和实时天气信息的挖掘，提高对自然灾害的安全防范意识和应急处理能力。以美国国家海洋大气局(NOAA)发起的大数据项目(BDP，Big Data Project)为例，通过与互联网云商(亚马逊、微软、谷歌和IBM等公司)合作，来提升资源存储、数据分析和高性能计算能力，构建数据联盟(Data Alliances)，面向公众开放海量大气海洋数据，通过数据的利用来促进气象技术和社会经济发展。

针对国内气象业务现状和未来发展趋势，2017年12月，国家气象信息中心提出构建“天擎”系统。“天擎”系统是一种以“云+端”为设计思路，实现“数算一体”的气象综合业务支撑平台，这一平台改变了过去传统烟囱式信息系统架构方式，各业务系统的输入输出数据均在“天擎”中进行统一集约化管理，使包括机器学习、人工智能在内的多类数据加工算法可以更为高效的应用于气象大数据中(夏正龙等，2021；徐亮亮，2021)。随着信息技术的快速发展，以往以虚拟机为最小单位的算力资源分配模式，现在来看，存在资源利用率低、软件环境不一致和应用部署、运维效率低等问题，已无法满足气象大数据云平台计算业务场景需求，一种新的技术应运而生，那就是容器技术。不同于虚拟机技术，容器技术通过打包应用程序的所有依赖，实现应用程序的快速部署和运行，开发、测试和生产环境完全一致，用户再也不用去定位因环境差异导致的各种异常问题，大大提高了生产效率。此外，容器技术还有跨平台、可移植的特性，对于开发者和系统管理员来说简单易用，容器技术直接解决的问题，就是目前云计算架构遇到的问题。

容器具有更小颗粒度的算力分配、更轻量和快捷的部署方式、灵活的任务调度等特点，近年来，以Docker为代表的容器技术被愈来愈广泛的应用在云计算中。Docker在应用程序的开发、发布和部署上具有十分明显的优势，由于其简单、便捷、实用的特点，国内外知名的公司已经开始大规模的使用这一技术(徐蕴琪等，2021；Amit et al.，2022；Ren，2022)。但是，由于Docker本身只具备基本的容器管理功能，如：镜像的制作、下载和上传、容器生命周期的管理等(武志学，2017)，在大规模的容器技术运用中，需要一种容器集群管理系统来统一管理分布在集群中的各个容器，从而实现容器的编排、自动化部署、任务调度、资源分配和服务发现等功能。因此，业界产生了大量针对容器的管理系统，例如Google的Kubernetes、Docker的Swarm和Mesos发布的Marathon等(徐珉，2017)。以Docker容器技术为核心的第三方容器云平台正在日益广泛的被业界所应用，Kubernetes (也称为k8s) 是基于Docker容器技术的一种容器集群管理系统，其为用户提供了一个容器化应用的整体解决方案，具备强大的容器编排能力，遵循微服务架构理论，并且开放开源(杜军，2016)。正因为Kubernetes具有这些特征，其从出现之初便受到业界的广泛关注，现今Kubernetes已成为Docker生态圈最流行的开源容器集群调度系统(肖斐，2010；孙大为等，2014；齐磊等，2017)。

Docker容器技术是气象大数据云平台实现“数算一体”功能所采用的关键技术之一，随着业务化进程的不断推进，越来越多的算法将实现容器化部署，如何高效、便捷的管理这些容器，使之稳定、高效的发挥业务支撑作用，已成为新的难题。为了解决这一难题，湖北省气象局基于Kubernetes开源框架，结合气象大数据云平台业务实际需求，设计并构建了一套面向容器的算力资源优化管理系统，该系统从多个方面促进了容器技术在气象大数据云平台中的应用。

1 系统设计

算力资源优化管理系统包括一种容器平台调度子系统，该子系统以“天擎”SOD为原始输入数据源和返回产品存储、共享中心，通过账户创建、资源授权、镜像制作、算法注册、算法加载、任务定义、任务启动、任务日志查看等多项功能，实现容器的串联与调度。此外，该系统还设计并构建了一种基于Kubernetes的容器管理子系统，能够对跨服务器的多容器进行管理，实现负载均衡、存储编排、自动部署和回滚等功能。

1.1 设计思路与架构

算力资源优化管理系统框架图如图 1所示，主要由加工容器调度子系统(以下简称调度子系统)和容器平台管理子系统(以下简称管理子系统)两部分组成, 两者相辅相成，缺一不可。一方面，调度子系统以“天擎”SOD作为数据源输入，通过服务接口与“天擎”SOD进行数据交换，获取计算所需原始数据，并将加工计算后的产品输出给“天擎”接口实现产品共享；另一方面，调度子系统在用户和容器之间搭建了桥梁，用户通过调度子系统提供的账户创建、资源授权、镜像制作、算法注册、算法加载、任务定义、任务启动、任务日志查看等功能，可以轻松的完成目标算法的部署和计算结果的获得，而不必关心容器实现的具体细节。

从逻辑层面看，相比于调度子系统，管理子系统处于较底层位置。管理子系统基于Kubernetes容器编排引擎，一方面，针对计算节点群，开展节点资源监控，根据节点状态和用户对容器的需求，完成容器化应用自动化部署、扩缩和管理；另一方面，接收调度子系统算法加载和运行请求，通过节点预选、节点优选打分、算法仓库创建等功能，实现容器的快速调度和调度结果反馈。

1.2 系统软件实现

基于B/S(Browser/Server，即浏览器/服务器)架构实现的算力资源优化管理系统主要包括数据纵览、环境资源、镜像仓储、应用服务和用户中心等功能模块，每个功能模块又包含若干子功能模块。数据纵览直观反映应用、应用CPU和内存使用量、实例、系统状态、镜像、系统日志等基本概况；环境资源包括环境管理、主机管理、容器管理和存储卷，分别用于实现Kubernetes环境、容器宿主主机、容器和存储的管理；镜像仓库实现仓库和镜像的导入、创建和编辑等功能；应用服务针对各类应用实现应用实例的新增与编辑、编排和基础信息配置管理；用户中心实现用户角色、权限的统一管理。算力资源优化管理系统针对容器提供了一站式的系统维护与可视化工具，大大方便了用户对容器的使用和技术管理人员对算法调度与容器平台的运维。

2 子系统功能 2.1 调度子系统

调度子系统包括账户创建、资源授权、镜像制作、算法注册、算法加载、任务定义、任务启动、任务日志收集等功能。主要业务逻辑如下：

调度子系统授权从“天擎”系统接入的用户，并将用户相关信息同步至容器平台；算法管理员通过调度子系统向用户授权计算资源和存储资源；用户在得到授权后，可以上传算法镜像并填写相应的元数据信息；调度子系统在审核镜像的安全性与完整性后，将镜像上传至容器平台并授权用户相应的数据访问权限。

用户通过调度子系统的镜像仓库，选取镜像并填写算法执行目录，选择存储挂载目录，将镜像加载至计算节点，完成在调度平台上的算法注册与加载；此后，用户可以在调度平台上通过任务参数的设定实现任务的触发。一般的任务触发方式分为四种：DI触发、顺序触发、定时触发与人工触发。

任务被触发后，调度子系统将在容器平台中创建容器，执行任务并实时监控任务执行期间的容器使用情况，若执行超时或资源不足，任务将被加入执行队列中；任务执行成功后，将发送MQ消息通知管理子系统将容器销毀。这一步中，容器平台将调用Kubernetes的api接口(即应用程序接口)清除已执行完成的算法容器, 并反馈删除结果。

2.2 管理子系统

管理子系统基于Kubernetes容器编排引擎，其调度器的执行流程如图 2所示。某个算法触发调度后，系统将算法配置的CPU、内存与可调度节点上可分配资源进行对比，若资源充足，则进行算法资源配置文件拼装、资源部署脚本下发、节点预选、节点优选等一系列调度动作，最终获取算法运行结果；反之，由于可调度节点上可分配的资源无法满足配置的算法资源需求，调度无法成功，则调度结束，后期可以通过增加资源或缩减算法资源配置等方式达到成功调度的目的。

在管理子系统中，将创建和管理的最小的可部署的计算单元称为Pod。这些Pod是一个或多个容器，这些容器共享存储、网络、以及怎样运行这些容器的声明。Pod中的内容总是并置的并且一同调度，在共享的上下文中运行。图 2中，管理子系统给一个Pod做调度选择，主要包含两个步骤：预选与优选。预选阶段，调度器使用节点预选策略将所有满足Pod调度需求的节点选出来。例如，使用某种节点预选策略检查候选节点的可用资源，包括CPU、内存等能否满足Pod的资源请求，得出节点列表，节点列表包含了所有可调度节点；通常情况下，节点列表包含不止一个节点。若节点列表为空，则代表该Pod不可调度。常用的节点预选策略包括基础调度、volume相关、宿主机相关、Pod相关等策略。

优选阶段，调度器使用节点优选策略为Pod从预选阶段得到的节点列表中选取一个最合适的节点，并将Pod调度到该节点上。根据启用的节点优选策略打分规则，调度器会给每一个可调度节点进行打分，得分最高的节点成为最合适节点。若存在多个得分最高的节点，调度器将从中随机选取一个。节点的优选策略包括：选择空闲资源最多的宿主机、选择资源分配最均衡的节点和偏向具有最多请求资源的节点等。

2.3 硬件部署

算力资源优化管理系统的硬件部署示意图如图 3所示。其中，系统部署在console服务器上，与“天擎”系统中的Xugu集群(即虚谷数据库集群)对接，并对其它节点进行管理。Xugu集群是“天擎”系统向用户提供的定制化、高性能、高可靠、易用便捷的存储体系，用于存储应用系统的元数据信息和应用中间结果。

为保障系统的正常运行，并实现系统的故障检测与定位，设计了镜像仓库。镜像仓库的高可用实现方案如图 4所示。镜像仓库使用NAS(即网络附属存储) 作为共享存储，多个镜像仓库指向同一个NAS目录，通过负载均衡实现高可用。仓库中的镜像文件每天定时自动全量备份，接口网关做加权轮询负载均衡。

系统中的核心组件均进行了高可用设计，表 1给出了核心组件的高可用模式和实现方式。Xugu数据库采用集群模式实现数据高可用；镜像仓库存储在NAS(NAS数据高可用)，镜像仓库01和镜像仓库02指向同一个NAS目录，接口网关做IP_hash负载均衡，实现镜像仓库的高可用；Master Node采用了Leader Election(即主从选举)方式实现高可用；容器云平台控制台和后台分别部署两个Paas-web、Paas-server，接口网关做轮询负载均衡实现服务的高可用。

3 关键技术

算力资源优化管理系统通过多节点均衡调度、算法资源精细化匹配、容器运行资源隔离、算法镜像存储故障恢复、容器指标和算法运行故障监控等关键技术，支撑用户在气象大数据算法业务上的需求。

3.1 多节点均衡调度

当算法调度计算节点为多节点，在调度过程中，由于一些原因，会出现调度不均衡的问题。例如：节点故障、新节点被加到集群中、节点资源利用不足等，这些问题会导致Pod在调度过程中分配不均，例如会造成节点负载过高，引发Pod触发OOM(Out of memory, 即内存不足)等操作，影响服务的正常使用。为应对这些情况，本系统采用多节点均衡调度方法，在部分计算节点故障时，容器算法可自动检测节点状态，仍可正常进行调度，保障算法调度的可靠性。另外，如2.2节所述，系统还采用节点负载均衡调度策略，进一步使计算节点资源得到均衡使用。

3.2 算法资源精细化匹配

在Kubernetes与Docker默认的设置中，容器内单个算法执行将会占用容器设置的所有资源，造成资源与算力的冗余。为解决这一问题，管理子系统会根据用户设置的资源进行容器创建，并进行资源限制以精确匹配算法运行时所需资源。资源限制是通过Pod中容器属性的resources字段进行设置的，它是Kubernetes提供的Resource Requirements类型的api对象。管理子系统采用resources字段下的requests和limits两种限制类型对资源进行控制。所谓requests，即资源需求，代表了资源下限，例如，运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod；所谓limits，即资源限额，代表了资源的上限，例如，运行Pod期间，可能内存使用量会增加，那最多能使用多少内存，这就是资源限额。当集群资源不足时，Kubernetes会根据Pod标记的QoS (Quality of Service，即服务质量保证) 类别做剔除决策，腾出空闲资源。QoS优先级从低到高分为最大努力型(Best-Effort)、突发流量型(Burstable) 和保证型(Guaranteed)三种。在系统临近内存耗尽情况下，最大努力型Pods会最先被结束掉；当没有最大努力型Pods可以被结束掉时，突发流量型Pods会被结束掉；当没有最大努力型和突发流量型Pods可以被kill时，保证型Pods才会被结束掉。因此，为更好的提高资源利用率，重要业务服务设置为保证型，其它服务根据重要程度设置为最大努力型或突发流量型。

3.3 容器运行资源隔离

在原始Kubernetes与Docker中，容器内有多个算法同时运行时，算法间会相互影响。例如，当某个算法运行消耗资源较大时，会导致其他算法运行资源不足，影响算法执行结果。为解决这一问题，管理子系统采用了一种“随调随起”的管理策略，即：在每次执行都会新建一个独立的容器，容器与容器之间运行环境及资源隔离，从而提升算法运行的稳定性。

3.4 算法镜像存储故障恢复

为保障用户的信息和算法存储安全，调度子系统为镜像仓库配置了高可用及备份机制。镜像仓库的高可用通过部署多节点负载均衡实现，当某一节点镜像仓库服务故障时，会自动切换至正常镜像仓库，不影响服务正常使用；镜像仓库使用全量周备份、增量日备份的备份机制，并定时清理30 d以上的“僵尸”镜像数据。镜像仓库的高可用和备份机制，可以保证镜像仓库及算法镜像文件存储故障或误操作时，可以及时进行恢复，挽回用户的损失。

3.5 容器指标和算法运行故障监控

为解决监控容器运行状况，引入了Prometheus容器监控技术，它是一套开源的新一代云原生监控告警框架。系统采用了两个Prometheus server监控同时一目标的高可用实现方案，通过Prometheus监控端点采集容器性能指标数据，并将监控端点通过Http服务的形式暴露给Prometheus主机，Prometheus主机通过访问监控端点，便可获取采集到的数据。在算法运行故障监控方面，本系统新增算法输出日志下载能力，提供容器化算法及服务的资源监视能力，通过容器平台监控组件可查询容器资源使用情况，包含CPU、内存、网络等，算法故障错误日志查询功能，算法在容器内执行过程出现错误的日志进行查询，快速定位问题，并解决故障。此外，系统实现了容器、算法故障监控与气象综合业务实时监控系统“天镜.湖北”的对接，进一步提升了容器、算法故障的及时发现与快速处理能力。

4 结论与讨论

本文从气象大数据算力资源优化管理系统的建设需求、总体架构以及实现方式等问题出发，探讨了该系统设计的思路和若干关键技术，得出以下结论：

(1) 基于B/S架构，设计并实现了一套面向容器平台的气象大数据算力资源优化管理系统，该系统包括加工容器调度和容器平台管理两个子系统。系统以气象大数据云平台“天擎”为数据中台，基于Kubernetes的容器编排引擎，通过两个子系统的合理调度和配置，搭建了用户使用容器的桥梁，使容器高效、便捷地为各类气象大数据的算法产品加工与挖掘分析计算服务。

(2) 调度子系统包括账户创建、资源授权、镜像制作、算法注册、算法加载、任务定义、任务启动、任务日志收集等功能。用户可以在调度平台上通过任务参数的设定实现任务的触发，其触发方式灵活机动。任务被触发后，调度子系统在容器平台中创建容器、执行任务并实时监控任务执行期间容器的使用情况；管理子系统将算法配置的CPU、内存与可调度节点上可分配资源进行对比，并完成配置文件拼装、资源部署脚本下发、节点预选优选，最终获取算法运行结果。

(3) 综合运用多节点均衡调度、算法资源精细化匹配、容器运行资源隔离、算法镜像存储故障恢复、容器指标和算法运行故障监控等关键技术，有效提升了容器算力资源的调度能力、可靠性和利用率。自动负载调度方式，支持多节点负载均衡调度，使服务器资源充分利用，保证算法调度高可用性；算法容器可进行CPU、内存限制，保证宿主机上的容器资源相互隔离，服务器资源合理使用，保障服务器稳定可靠运行；算法任务运行完成后，相应的容器会进行回收，容器占用的资源也会进行释放，大大提升资源利用率。

该系统于2022年1月开始业务运行，截止目前，累计实现多个类别、近百个算法的部署与调度的统一管理，为“天擎”系统的“云+端”业务发展规划提供了一定的实践基础和有效助力。近年来，运用大数据推动经济发展、完善社会治理、提升政府服务和监管能力正成为趋势，大数据也成为气象部门重塑竞争优势的新机遇。基于“天擎”系统进行气象大数据挖掘，将人工智能、知识图谱与数字孪生等前沿业界技术与气象大数据相结合，将会是气象领域研究者进一步的研究方向之一。后续将不断改进和完善面向容器平台的气象大数据算力资源优化管理系统，持续促进气象大数据和研究型业务的发展。