气象云建设的思考

1、气象云建设的思考 章国材 2015年8月 目录 1 现状现状与与需求分析需求分析 2 气象气象云建设云建设原则原则 3 气象云总体设计思路气象云总体设计思路 4 气象云建设中的数据获取气象云建设中的数据获取 1 现状与需求分析现状与需求分析 1.1需求分析需求分析 从需求看，气象已进入大数据时代。气象数据有4 个特点： 第一，数据体量巨大。从TB级别跃升到PB级别； 第二，数据类型繁多。既有高空、地面、卫星、雷 达等观测资料，各种数值预报预测产品和各种类型 的气象预报服务产品，还有办公文档、文本、图片、 XML、HTML、各类报表、图像和音频、视频信息等。 第三，处理速度快。从各种类型的数据中

2、快速获得 高价值的信息，这是当今气象业务和服务的迫切需 求。 第四，回报价值高。只要合理利用数据并对其进行 正确、准确的分析，将会带来很高的价值回报。 气象预报预测的需求 有关天气产品的加工处理要求进一步提高气象要素和灾 害性天气的时间、空间和量值的分辨率和预报准确率； 目前正在发展的气象灾害风险评估业务,不仅要求很高的 天气预报准确率和精细度,而且要评估天气和气候对人类 社会的负面影响风险，这需要掌握详尽的承灾体易损 性数据； 气候预测不仅涉及大气圈，而且涉及水圈、岩石圈、冰 雪圈和生物圈以及五个圈层的复杂相互作用； 农业和生态气象、交通气象、环境气象、能源和电力气 象、健康气象等都对数据加

3、工提出了新的需求 这些新需求既涉及气象科学技术本身的发展,也涉及气象 信息化的支撑,气象信息化如何更好地支撑这些业务,面 临诸多挑战。 气象观测的需求 气象观测数据的获取的方式由于遥感遥测 技术、智能手机、移动互联网、物联网等 先进技术的应用，将发生重大变化。 例如，如何挖掘城市多如牛毛的视频中的 气象信息，对我们就是重大的挑战。 当“人人都是气象观测员”和物联网应用 于气象观测时，气象观测信息的获取和处 理将会更加复杂多样。 气象服务的需求 气象服务对象有决策者、公众、专业用户等，当人 人享受气象服务时，不仅气象服务用户数海量增长 着,而且为他们提供的气象服务呈现产品多样化（适 应不同用户的

4、需求）、表现方式多样化（包括视频、 音频、图片、图像、文档、文本等形式）、服务的 手段多样化（包括电视、手机、声讯、网站、报纸、 电台等）等特征。 随着智能手机、移动互联网、物联网等先进技术的 应用，气象服务的方式将发生重大转变。气象信息 化如何更好地支撑这种转变，也面临诸多挑战。 1.2 现状分析现状分析 从气象信息化现状看，我国虽然已经建成了气象信息化 业务服务系统，但是气象信息化仍然存在不少问题。 首先，气象数据未实现标准化。地面气象观测有旧Z1、 Z2格式、新Z格式、区域站格式、交通气象站格式等； 天气雷达有7种格式,其它观测资料亦未统一格式；预报 产品没有统一的格式，服务产品没有统一

5、的格式，使得 数据传输、处理和存储复杂,共享困难。 其次，气象通信先进性和集约性欠佳。所有的省区市国 家部署的新一代气象通信系统与CIMISS中的CTS并存； 一些省区市国内通信系统依托新一代通信系统，另一些 省(市)以自建的通信系统为主，新一代通信系统仅作为 数据上传和与CTS连接之用。国内通信系统需要整合。 气象通信系统中还存在不少人为设计的瓶颈，使得数据 传输的速度不尽人意。数据流、移动互联网、物联网等 新技术的应用也向气象通信的变革提出了挑战。 第三，数据存储与管理系统“信息 孤岛遍布” 目前国家级和各省市的数据存储和管理系统处于高度分 散、重复存储、缺乏统一管理的状态。各单位都有自己

6、 的数据存储系统，各种业务系统也有自己的数据存储系 统，这些数据存储系统缺乏统一的规范管理。目前数据 存储与管理系统存在以下问题：（1）数据存储和管理 高度分散；（2）数据存储高度重复，所有的数据存储 系统都长期保存地面观测资料。（3）数据库选型较乱， 数据库选型有ORACLE、SQL-SERVER、mysql等, NoSQL的 数据库选型也是五花八门,一个单位内数据库型号也不统 一。（4）存储介质多，有的数据存储在数据库的磁盘 中，有的数据存储在光盘或移动硬盘中。（5）缺少面 向业务应用的灵活的数据检索接口，专门数据库专用， 相互独立，各不相干。（6）长期保存的数据种类偏多。 造成“信息孤岛

7、”遍布的原因 一是全国布局的业务项目各自都带一个数据存储系统，例如 MICAPS、SWAN、CIPAS 1.0、FODAS、MODES、MAPFS、DERF2.0， MESIS、农业气象业务系统、交通气象业务系统等都带一个数据 存储系统； 二是省区市业务建设项目大都包括数据库建设，因此就出现诸 如水情共享、土壤水分、闪电、负氧离子、精细化预报、 GNSS/MET、中小河流暴雨致灾雨量分析、中小尺度天气资料应 用、气象信息短信、气象声讯电话、兴农网等数据库； 三是工程项目也建数据库，例如大气监测自动化工程、气象灾 害监测预警工程、山洪项目，有的省也建立了数据库； 四是科研项目也建众多数据库。“信

8、息孤岛”遍布造成浪费存 储资源、数据不能共享、管理维护困难等。 因此，国家和省级都急需建设一个统一的具有数据存储管理和 服务能力的数据库系统,使数据存储管理和服务走上集约高效的 轨道。 第四，“业务应用系统林立” 应当指出：业务应用应当是多样的，但是,MICAPS、 SWAN、CIPAS 1.0、FODAS、MODES、MAPFS、 DERF2.0，MESIS、农业气象业务系统、交通气象业 务系统等都带一个数据存储系统，都有数据服务器 加工处理产品，都有自己的数据接口,这些数据接口 对外是不公开的,其它用户不可能共享它们加工的产 品；都有自己的终端,只有它们的终端才能调用这些 产品，因此这些业

9、务应用系统都是一个孤立的系统。 它们都应当成为一个完全开放的系统,它们加工的产 品,所有注册的用户都很容易共享。 另一方面，我们的业务系统数据挖掘能力不强，气 象数据增值还有很大的空间。 第五，气象服务系统碎片化 应当指出：气象服务应当是多样的，但是,但 是气象服务系统目前呈现碎片化状态,其表现 亦如业务应用系统,每个气象服务系统都带一 个数据存储系统,都有独立的数据服务器加工 处理产品,都有自己独立的显示平台,只有这个 平台才能调用这个气象服务系统的产品等,造 成管理和维护维修这些系统困难,耗费大量人 力物力和财力。 另外,移动互联网、物联网等先进技术为气象 服务提供了广阔的发展空间。 出路

10、 应用“互联网+”技术，亦即云计算和云存 储、移动互联网、物联网等技术建设气象 云。 2 气象云建设原则气象云建设原则 2.1 满足各种气象业务、服务和管理需求满足各种气象业务、服务和管理需求 以前建设的工程大都只是满足某一方面的业务需求， 这是造成“信息孤岛遍布”和“业务应用系统林立” 的重要原因。因此，建设气象云首先必须弄清楚各 种气象业务、服务和管理的需求，弄清楚他们对数 据的需求、数据加工的需求和它们相互之间的关系 等，这些问题没有搞清楚之前，不要忽忙设计，否 则“缺胳膊少腿”在所难免。 满足气象业务、服务和管理需求的另一层含义是气 象信息化应当适应气象业务、服务和管理数据存储 和加工

11、的特点，而不是反过来要求气象业务、服务 和管理去适应人为设计的气象信息系统。 2.2 有利于提高气象预报预测准确率有利于提高气象预报预测准确率 气象业务的发展过程是不断提高气象监测预报预测的精细度、 准确率和业务服务面的过程，为此，我们不仅需要不断增加观 测资料，提高气象数值预报预测的水平，而且需要合理的业务 布局。例如，按照现代天气业务发展指导意见（2010）,省级气 象台需要承担中期、短期、短时、临近天气预报任务,地市级气 象台需要承担短期、短时、临近天气预报任务,县级气象站也需 要开展灾害性天气和气象灾害监测、灾害性天气临近预报业务、 订正上级指导预报产品等业务。 天气业务之所以这样布局

12、,就是为了发挥各级优势，提高天气预 报的精细度和准确率。不管下一步怎么改革，省级短期、短时、 临近天气预报是不可少的，市级短时、临近天气预报也不可少， 县级补充订正也不可少，否则天气预报准确率和精细度会下降， 这是不以人的意志为转移的客观规律。 而要加工天气预报产品，就必须有气象观测资料和数值天气预 报产品，还需要天气预报工作平台支撑预报员的产品加工。其 它业务也是如此。气象信息系统建设应当为提高气象预报预测 准确率提供支撑而不是相反。 2.3 集约高效集约高效 首先需要统一数据存储和管理系统，逐步消灭 信息孤岛，在同一级建设一个供各种业务、服 务和管理共享和服务的大数据中心。 其次是统一数据

13、加工平台，各类加工气象产品 的算法使用统一的数据库和统一的硬件软件平 台，生成的产品又能回存到大数据中去。 这样做可以大大节省硬件和软件资源，维护维 修也更加简单明了，集约带来高效。 2.4 数据共享数据共享 与银行、公安等部门不同，它们的数据是 保密的，不提供给外部门的用户使用；而 气象观测资料和各种预报预测产品,不仅气 象部门的用户能够共享,而且社会的用户也 能够按规定共享。 这将造成气象数据查询和检索的巨大压力 和不确定性,使得气象数据中心的建设与这 些部门有所不同，这是气象云建设必须认 真考虑的问题。 3 气象云总体设计思路气象云总体设计思路 气象云包括云存储、云计算和云服务 云存储应

14、当为云计算提供支撑 云存储、云计算应当为云服务提供支撑 （三者的关系见图1）。 图图1 云存储、云计算和云服务关系示意图云存储、云计算和云服务关系示意图 云服务云服务 云计算服务管理平台云计算服务管理平台 高性能计算高性能计算分布式并行计算 分布式数据库管理平台分布式数据库管理平台 分布式数据存储分布式数据存储 3.1 云存储云存储 云存储是指通过集群应用、网格技术和数据库 系统等，将网络中大量各种不同类型的存储设 备通过应用软件集合起来协同工作，共同对外 提供数据存储和业务访问功能的一个系统7-8。 云数据库是部署和虚拟化在云计算环境中的数 据库，如图2所示 。在云数据库应用中，客户端不需要

15、了解云数 据库的底层细节，所有的底层硬件都已经被虚 拟化,对客户端而言是透明的。它就像在使用 一个运行在单一服务器上的数据库一样，非常 方便、容易,同时又可以获得理论上近乎无限 的存储和处理能力。 图图2云数据库示意图云数据库示意图 3.1.1数据存储模型的选择 任何数据库设计的首要目标是应用程序如何方 便快速地获取数据。因此, 云数据库设计既要 考虑气象数据本身的特点,又要考虑气象应用 程序如何方便快速地获取数据。 气象云存储需要将所有气象数据存放在同一数 据库之中，实时和历史数据是一体化的，因此， 气象数据必然是大数据。 虽然传统的关系型数据库管理系统可满足数据 的一致性和可用性，在小规模

16、数据量时可达到 很好的效应，但随着数据量和应用范围的增长 导致节点的增加，由于需要考虑数据同步和分 区失败等开销,性能会快速下降。 数据分布式存储是必然的选择。 数据分布式存储有三种技术选择 一是分布式关系型数据库 二是分布式文件系统（又可称为分布式半 关系型数据库） 三是非关系型数据库（NoSQL）。 分布式关系型数据库 将存储的某类大数据切分成片段，每个片段 的数据釆用关系型数据库存储。它需要满足三个 条件： （1）完备性条件：必须把全局关系的所有数据 映射到片段中，决不允许有属于全局关系的数据 却不属于它的某一个片段。 （2）可重构条件：必须保证能够由同一个全局 关系的各个片段来重建该全

17、局关系。 （3）不相交条件：要求一个全局关系被分割后 所得的各个数据片段互不重叠。 观测数据的存储 例如，气象站点观测数据需要实时与历史数据一体 化存储，随着时间的积累，必然产生大数据 而且气象地面观测数据读与写都很频繁,每分钟都有 地面观测数据写入数据库；MICAPS至少每10分钟要 读气象站点观测数据,生成地面天气图;如果允许部 门内外的用户不受限制地调用地面观测的实时和历 史数据，那么将所有的自动气象站资料存在一张表 中，显然难于承受。 如果采取切分的方法把全国5万多个自动气象站的 观测数据切分成组（比如一个县一组），每个组中 的每个站点观测数据一主两备镜像(三份)存储在关 系型数据库中

18、，由此可以较好解决写与读的高可用 性问题。 气象观测数据的特殊需求 为了满足科研用户检索并复制长序列历史气象 观测数据的需求，可能还需要再建设一个只读 不写的气象站点观测数据的关系型数据库，以 防止科研用户长时间占用上面提到的关系型数 据库，影响该数据库的实时读与写。 这个数据库不仅是只读不写的，而且为了满足 多用户并发调用，最细的切分可以到气象观测 站。 这实际上是牺牲数据的冗余性以换取数据的可 用性。 气象管理信息的存储 气象管理信息由于数据量小,可以采取关系 型数据库存储 但一定要做好数据的备份,以免某块磁盘出 故障丢失数据。 也可以采用分布式文件系统存储。 分布式半关系型数据库 分布式

19、半关系型数据库是指将每种数据的元数 据存储在关系型数据库中，将其数值存储在分 布式文件库中，它可以将同一份文件存储在三 个结点中,也可以采用N+M备份机制实现数据 的恢复。 天气雷达、气象卫星数据量大，而且每天都在 增长，可以采取分布式半关系型数据库存储。 例如单部天气雷达数据，可以将天气雷达站名、 时间、产品属性等元数据存储在关系型数据库 中，将产品属性的数值存储在分布式文件库中。 数值预报预测产品，每次生成的高分辨率数值分析预报 预测产品数据量都比较大，对于用户少的产品(例如动 力气候产品；如果MICAPS的绝大多数算法在后台实现， 用户调用的是MICAPS生成的产品，那么数值天气预报产

20、品的用户也不多)，可以把模式名称、产品生成的时间、 预报时效、物理量作为索引存储在关系型数据库中，将 物理量的三维数据存储在分布式文件系统之中，这种存 储方式可以满足数值预报预测产品的三种基本应用，快 速检索得到所需要的这些数据，支持这些应用：从三维 数据中检索出该物理量某等压面的二维数据（生成等压 面物理量图形等）、某垂直截面的二维数据（生成物理 量垂直剖面图等）、某格点的垂直一维数据（生成模式 产品探空图及有关的物理量）。 对于用户较多的产品，可以把层次也作为元数据放到索 引之中，将物理量某层次的二维数据存储在分布式文件 系统之中。这种存储方式，虽然调用垂直截面二维数据、 某格点垂直一维数

21、据需要从多个文件中获取，计算速度 可能慢一些，但是可以更好地满足多用户的并发调用。 两种存储方式孰优孰劣，与厂家开发的软件有关，需要 测试后才能决定。 由MICAPS4.0、SWAN、CIPAS2.0、MESIS、LAPS、 SWAP、SMART、农气业务系统、交通气象业 务系统等自动生成的产品，气象影视产品，也 可以采用分布式文件系统存储。 例如，MICAPS生成的探空站T-logP图,可以将站 名、时间、T-logP作为索引存储在关系型数据 库中,将T-logP图存储在分布式文件库中; 又如影视产品,可以将制作单位、时间、产品 属性等作为索引存储在关系型数据库中,将视 频图像存储在分布式文

22、件库中,等等。 分布式半关系型数据库的优点 分布式半关系型数据库将关系型数据库和分布 式文件系统的优点结合起来。分布式文件系统 理论上存储是无限的，同样的文件存储在三个 不同的结点中，分布式文件系统可以保证数据 的高可用性、分区容错性和用户可容忍时效内 数据的一致性。 同时分布式半关系型数据库又将索引存储在关 系型数据库中，可以充分利用SQL的完备查询 检索功能。 这是一种比较适合气象数据的存储方式。 非关系型数据库（NoSQL） 非关系型数据库（NoSQL）采用键/值模型 存储数据。 对于一些小的文件系统读与写都很快。例 如天气网站可以采用键/值模型存储数据， 每个小文件中只存储一种产品。

23、未来的气象云数据库 由此可见，未来的气象云数据库可能是一个混 合数据库，但是，数据库的监控和管理应当是 统一的。 气象云数据库的数据冗余不可避免，尽管我们 应当避免不必要的冗余。 此外，气象云存储还需要在研究气象数据特征 的基础上确定气象数据存储标准,数据存储标 准也应当有利于各种应用，气象数据的存储标 准和传输标准应当进行一体化研究,尽可能减 少数据传输到存储的格式转换。 3.1.2气象云存储需要解决的问题 （1）容量问题 （2）延迟问题 （3）安全问题 （4）成本问题 （5）数据的积累 （6）灵活性 3.1.3气象大数据中心的设计 气象部门到底需要建几级大数据中心？仁者见 仁，智者见智。设

24、计的依据是什么？笔者认为 应该是第2节中提出的四个原则。因为管理数 据量小、用户少，管理数据库在国家气象大数 据中心建设即可，就可以满足管理的需求。 气象大数据中心在国家和省两级建设为宜。为 什么是两级而不是一级？在第2节中已经指出 省级在气象产品加工中处于骨干地位，都需要 加工气象预报产品，因此都需要各类气象观测 资料、数值预报产品，这些数据量巨大，不可 能所有省级业务和服务人员都从中央数据库中 调取这些数据，否则宽带网无法支撑。 一级数据中心设想 把产品加工都集中到国家级进行？ 在国家级给各省市区安排虚拟机？ 市县两级大数据库建设问题 3.2 云计算云计算 大数据必然无法用单台的计算机进行

25、处理， 必须采用分布式架构。 它的特色在于对海量数据进行分布式数据 挖掘，但它必须依托云计算的分布式处理、 分布式数据库和云存储、虚拟化技术。 云计算是并行计算、分布式计算和网格计 算的发展，或者说是这些计算科学概念的 商业实现 3.2.1气象部门如何应用SaaS、PaaS和IaaS 根据NIST的权威定义，云计算包括SaaS、PaaS和IaaS 三大服务模式。 （1）SaaS：软件即服务。提供给客户的服务是运营 商运行在云计算基础设施上的应用程序，用户可以 在各种设备上通过瘦客户端界面(如浏览器)访问。 消费者不需要管理或控制任何云计算基础设施(包括 网络、服务器、操作系统、存储等)和应用程

26、序等。 很显然，这种模式只适用于小企业。对于气象单位 用户不适用，因为没有一个运行商真正懂得气象应 用程序，气象应用程序必须依靠气象用户自己开发。 但是,如果将用户理解为业务、服务、科研和管理人 员,则这种模式很适用于这些最终用户，他们不需要 管理或控制任何云计算基础设施和应用程序，但可 以在各种设备上通过瘦客户端界面(如浏览器)访问 他所需要的产品和数据。 （2）PaaS：平台即服务 提供给消费者的服务是把客户开发的或收 购的应用程序部署到供应商的云计算基础 设施上去。 客户不需要管理或控制底层的云基础设施， 包括网络、服务器、操作系统、存储等， 但客户能控制部署应用程序，也可能控制 运行应

27、用程序的托管环境配置。 这种模式最适合气象部门除气象信息中心 之外的各个单位。 （3）IaaS: 设施即服务 提供给消费者的服务是对所有设施的利用，包 括处理器、存储、网络和其它基本的计算资源， 用户能够部署和运行任意软件，包括操作系统 和应用程序。 消费者不管理或控制任何云计算基础设施，但 能控制操作系统的选择、储存空间、部署的应 用，也有可能获得有限制的网络组件（例如， 防火墙，负载均衡器等）的控制。 这种模式适用于将信息基础设施外包给运行商 建设和运行的单位（部门）。 气象部门如何应用IaaS、PaaS、SaaS？ 如下的安排最适合气象部门的实际情况：气象 信息中心运行和管理所有基础信息

28、资源，包括 处理器、存储、网络和其它基本的计算资源， 并提供IaaS、PaaS、SaaS服务； 气象中心(台)、气候中心、公服中心、人影中 心、科研所、管理机构等将自己的基础信息资 源交给气象信息中心统一建设和管理，并将自 己开发的或收购的应用程序部署到信息中心的 云计算基础设施上去，但能控制部署自己的应 用程序，也可能控制运行应用程序的托管环境 配置。 图图3 IaaS、PaaS、SaaS三者的关系三者的关系 访问层 天 气 终端 气 候 终 端 服 务 终 端 天气网 站 手 机 1212 1 应用接口层 网络接入、用户认证、权限管理 数值模式 系统 公用API接口应用软件W e b se

29、rves 基础管理层 高 性 能 计 算 调 度 气 象 数 据 处理 数据分发 重复数据删除 数据压缩 数据加密 数据备份 基础信息设 备 高 性 能 计算 存储虛拟化 分布式并行 计算 集群系统 存储和计算 集中管理 状态 监控 维护 升级 存储和计算设备 3.2.2如何应用PaaS平台进行气象信息加工 第一类是数值天气预报和动力气候预测系统。它们的数 值模式复杂,而且模式框架是一体化设计的,其中平流计 算一个格点值与周围的格点值是相关的,不容易划分为大 量的更小的计算片断,因此需要用到高性能计算技术MPI 和GPU；目前模式中的物理、化学、生物等过程是在格 点上计算的，可以进行分布式并行

30、计算。 与此同时，数值天气预报和动力气候预测系统应当是 “数算异体”的，即数值天气预报和动力气候预测系统 所需要的初值和边值以及它们产生的产品是存储在数据 存储设备上的，而数值计算则是在高性能计算机上完成 的，存储设备与高性能计算机是不同的计算机。 数值天气预报和动力气候预测系统只需要从数据存储系 统中调用模式所需要的初值和边值,并将它们产生的产品 存入数据存储系统即可, 每一次计算二者之间的输入输 出（I/O）仅一次而已。 第二类是其它业务应用系统 例如MICAPS4.0、SWAN、CIPAS 2.0、LAPS、SWAP、SMART、 MESIS、农业气象业务系统、交通气象业务系统、气象灾害

31、预报 和风险评估系统等,随着气象部门专业气象服务的发展，应用业 务系统还会不断涌现，这些业务系统与数据库的交互（I/O）是 很频繁的，需要认真研究如何减少I/O的次数。尽管这些业务系 统各不相同，但是它们的产品加工有其共同特点。它们都包含 只涉及站点或格点数据的算法、涉及周围站点或格点数据的平 流算法和涉及整个区域数据的算法。 例如，MICAPS4.0中用探空站资料和数值预报格点产品计算对流 有效位能（CAPE）、K指数、位温（）、假相当位温（se）、 抬升指数（LI）、沙氏指数（SI）等的算法,只涉及本探空站 （格点）的数据,按照上一节提出的数据存储方案，这些物理量 可以采用“数算同体”的方

32、式计算,即在存储数据的计算机上计 算,这样可以节省I/O的开销,提高计算的速度。 MICAPS4.0另外一些算法,例如涡度、散度、垂直速 度及各种平流的计算涉及多个站(格点)的数据, 如果 所有探空站数据存储在一个分布式关系型数据库中 （实际上就是这样做的），数值天气预报产品按照 上一节提出的分布式文件系统存储，这些物理量既 可以采用“数算同体”的方式计算,也可以采用“数 算异体”的方式计算，后者是从数据存储系统中获 得所需的数据,然后在计算结点计算物理量,并将其 存储到存储物理量数据的结点中去，一次计算需要 一次输入输出（I/O）。 涉及全局的算法,例如寻找相似个例的算法，对于寻 找地面形势

33、的相似，就必须采用“数算异体”的方 式计算，因为每个结点只存储了部分站点的观测数 据，必须先拼成全域的地面图，才能进行相似算法 的计算。 CIPAS 2.0大部分算法与MICAPS4.0类似,既有 只在站点和格点上计算的算法, 可以采用 “数算同体”的方式进行分布式并行计算; 也有平流计算的方法, 既可以采用“数算同 体”也可以采用“数算异体”的方式计算; 气候业务广泛应用的EOF分析、波谱分析等 算法都涉全局的数据, 需要采用“数算异体” 的方式计算。 其它业务应用系统的算法大体如此。 如何改变“业务应用系统林立”的状况， 首先需要对这些业务应用系统的算法进行 分析，删除重复的算法； 其次在

34、PaaS平台上统一对所有的算法根据其 特点进行不同的分布式并行计算，并它们 将生成的产品存储在分布式产品库中； 第三，做好所有产品的用户接口，供所有 内部用户调用。 第三类气象服务网站 它们的产品加工简单（绝大多数是产品显 示），但是用户巨大 需要釆用分布式计算和分布式存储技术， 以同时对巨量的并发用户提供快速的服务。 第四类气象影视产品的制作。 气象影视产品大多数来源于业务应用系统加工的产 品，需要从云存储中检索所需要的产品进行加工处 理，其中气象图形图像的加工与MICAPS加工同类产 品是类似的，只不过要求可视度更高，有时候还需 要利用四维动画技术宣染气氛。这些计算可以归为 第二类，都可以

35、统一纳入PaaS平台。 除此之外，气象主持人节目和气象专题片等是气象 影视产品的特色，采用与业务应用系统完全不同的 制作方法，当然它们也需要从数据库中获取数据和 知识，并将制作的产品存储在云数据库中，这些都 需要云存储的支撑。 第五类管理信息的加工处理 从管理信息的加工本身来看，可以分为数值运算和非数值处理 两大类。数值运算包括简单的算术与代数运算，数理统计中的 各种统计量的计算及各种检验，运筹学中的各种最优化算法以 及模拟预测方法等等。非数值数据处理包括排序、归并、分类 以及平常归入字处理（word processing）的各项工作。在各类 信息系统中，决策支持系统对信息的要求是最高的，这是

36、由于 管理决策常常要用到一些相当复杂的加工方法。 管理信息系统也要用到各种类型的算法，但是往往是以比较固 定的方式使用的，因此处理起来比较容易。 业务信息系统与办公信息系统所使用的加工方法比较简单，但 是由于它们使用频繁，要求加工速度快，在制定具体算法时， 应认真考虑其效率问题。这些管理信息的加工算法都可以在 PaaS平台上进行 因为渉及人、财等的信息处理具有保密的特点，因此可以在 PaaS平台上划出专门的区域供其使用。 3.2.3 SaaS的应用 利用SaaS，用户可以在各种设备上通过瘦客户端界面 （如浏览器）调用其所需要的产品和资料，不需要管理 或控制任何云计算基础设施。 客户端界面设计应

37、当尽可能简洁，符合用户的习惯。例 如,国家和省两级的预报员工作平台可以设计为由天气雷 达（包括临近预报产品）、卫星云图、天气图和辅助图 表、数值天气预报、集合预报等若干个浏览器和一个制 作预报产品的人机交互平台所组成。市县两级可以进一 步对浏览器进行集约化设计,同时简化人机交互功能。浏 览器仅作产品显示之用，因此“很瘦”，易于维护。 目前MICAPS的客户端过于庞大，需要瘦身，瘦身的途径 是将客户端加工产品的大部分功能转移到PaaS平台中去。 其它业务的客户端也应当根据用户的需求和习惯进行设 计，因为产品加工已在PaaS平台上实现了，客户端必定 是瘦型客户端。而且根据这种设计理念，客户端界面可

38、 以根据业务的发展和用户的需求灵活进行调整。 业务应用系统的变革 因此，气象云建设将使各类业务应用系统 发生深刻的变革，数据处理与产品显示的 客户端完全分离 人们看不出“林立”的业务应用系统，只 能从客户端看出不同业务系统的差别。 一体化设计 综上所述,在进行数据存储设计和计算平台以 及客户端设计时必须详细分折每种气象算法的 特点和用户的需求，对数据存储与气象数据处 理进行一体化设计。 如果我们分析清楚了每种气象算法的特点和用 户的需求,我们就不难对PaaS平台和SaaS平台进 行设计了。 这需要气象算法开发者、最终用户与气象云设 计者密切合作，气象算法的开发者提出算法的 功能需求,最终用户提

39、出客户端的设计意见， 气象云的设计者根据这些功能需求和意见进行 数据分布式存储和算法分布式并行计算以及客 户端的设计。 3.3 云服务云服务 这里所说的云服务不是一般意义上的云（平台）服 务，而是专指如何利用云+端的技术开展公共气象 服务，实际上它也是SaaS服务的一种，只不过气象 内部客户端建在气象云内，大多数气象云服务平台 建设在气象云之外罢了。 首先，应当指出：公共气象服务产品应当由气象云 的PaaS平台加工出来，存储在气象云的数据存储系 统之中，由数据存储系统推送至气象云服务平台。 其次，除了决策气象服务系统建在气象云内外，其 它气象云服务平台在公共云中建设，包括天气网站、 气象基础资料网站、移动互联网服务网站、物联网 服务网站等。 气象服务对象有决策者、公众、专业用户等， 为他们提供的气象服务产品绝大部分是非结构 化数据，包括视频、音频、图片、图像、文档、 文本等形式。气象服务的手段多样化，包括电 视、手机、声讯、网站、报纸、电台等，随着 移动互联网、物联网等先进技术的应用，气象 服务的方式将发生重大转变。 决策气象服务除了继续完善计算机网络服务之 外，应当大力发展移动互联网服务，使决策者 无论在何时何地都能享受到无延时的气象服务。 与此同时