面向软件定义地图模式的水利数据共享方法

黄 伟，娄渊清，李长松

（黄河水利委员会信息中心，河南 郑州 450004）

0 引言

为解决数据资源模型不一致造成数据共享困难，应用系统技术架构差异形成的业务系统缺少关联，以及基础软硬件环境服务于单一应用造成资源利用率不高等问题，长江水利委员会（以下简称长委）开展了流域水利综合管理信息资源整合与共享项目，围绕软硬件设施、数据资源和应用系统对信息化资源开展整合和共享[1]。水利部 2015 年启动水信息基础平台项目，提出完成业务系统、数据资源和基础设施的整合，促进水利部本级信息化良性发展目标，提出主要数据资源“统一模型、一数一源、共建共享、授权使用”，建立了 41 类统一水利数据模型。黄河水利委员会（以下简称黄委）在借鉴水利部和长委项目成果基础上，提出以流域综合信息门户为核心，自顶向下逐步推进以下信息资源整合共享思路：

1）通过华为云对服务器资源进行虚拟化管理，黄河数据中心为数据和应用整合业务提供统一的计算和存储环境。虚拟存储扩容到 230 TB，备份存储空间 166 TB，满足黄委未来数据存储和虚拟机运行环境需求。

2）采用面向对象-事件的水利数据建模方法，对水利数据资源进行统一建模。通过为水利对象建立基本、业务、空间和时相等属性描述，将其映射成地图图层使用和交换的数据对象，旨在面向水利“一张图”的数据汇聚和交换[2]。

3）在应用资源整合方面，通过建立综合信息门户，建立单点登录和统一用户管理机制。实现对人事、财务政务信息和水调防汛等 11 个大类 70 个小类业务信息聚合展现。在此基础上，建设综合监控专题，实现对预算执行进度、大额资金变动，以及重大工程建设、工情险情等动态监管。本研究旨在探讨数据共享方法，以解决水利应用对异构数据的一致性共享需求。

在异构系统中共享数据有以下几种方法：

1）依靠在数据平面中使用表单和数据 2 种映射机制，将用户本地查询转换成多个子查询，使得子查询符合关联数据源中的表单结构和数据类型，并将最终查询结果进行汇聚[3–4]。这种机制不需要全局协调机制确保数据一致性，数据共享发生在局部关联数据源之间。但表单数据的改变会使得对关联数据源的查询映射失效，数据共享效率取决于关联数据源中最慢节点处理速度。

2）在应用平面中使用语义网技术进行数据共享和服务集成[5–6]。尽管基于本体数据访问具有明显前景和优势，但是隐含的工程代价包括本体建立、更新维持及推导并没有成熟工具和技术支持[7]。水利数据的顶层本体设计标准缺失，因此应用时机还未成熟。

3）采用物理和逻辑集中相结合方式对应用系统产生的数据进行整合。物理集中是指在初始化时对历史数据进行统一对象提取，编码建立目录和集中存储。应用系统共享负载主要由中心服务器完成，通过数据迁移系统与中心服务器上的数据交换平台交互。逻辑集中是将具有强专业性的数据本身仍存储在原有数据库中，由原数据所有者更新维护，将对应的数据资源目录统一存储在中心服务器上，数据共享后由需求方完成数据转换和利用。

应用系统处理逻辑和数据耦合使得分析应用必须考虑数据源异构及复杂数据转换。数据提供者必须确保应用对数据的一致性、现势性要求，并使用复杂同步和协调机制来回传递数据。为此，提出一种面向软件定义地图（SDM）的共享方法。这种方法模拟了软件定义网络抽象[8]，使用统一的地图表示对一致性数据的要求。用地图约束作为数据平面中进行传递的实体单元，数据平面将通过“匹配-行动”规则在不同数据源中进行传递[9]。

1 时空数据抽象与应用程序逻辑表达

黄委使用对象-事件模型对水利要素建模，用时间序列表示非空间属性变化的关系图如图 1 所示。时间序列由几何体、时间及值 3 个类型参数表示。用轨迹描述空间属性变化，轨迹和时间序列一样由几何体、时间和值构成，表示特定对象在某个时间范围下观测位置变化。数据源头记录数据产品获得历史，用于评估数据产品质量[10]；数据源头属性记录数据原始出处，以及最后一次数据被修改信息。事件由对象创建，包含几何体、时间和标识，表示某个时间范围内事件发生时几何体位置。

图 1 基于对象-事件的水利对象模型

黄委使用水利地理空间信息元数据标准对空间对象元数据进行建模[11]，使用地图代数理论及规范形式声明描述应用逻辑[12]。地图代数以地图图层作为基本数据处理单元，并以局部、条带、焦点及增量等操作表述标准化操作[13]。图层类似于弹性分布式数据集[14]，对图层的操作直接被映射成对图层中每一个数据对象操作，因此可以通过序列化操作或者封装在云环境中的容器传递到该对象所在数据位置进行计算。目前地图代数作为严格框架已经被大量开源和商业 GIS 软件支持[15]。数据平面中的处理单元能够通过已有软件实现标准化函数调用接口，处理控制平面发送任务，并将处理结果在彼此间进行传递。

2 软件定义地图

SDM 是一个框架，目的是构建一个动态自适应环境用于支持面向地图的时空数据分析应用。SDM框架解耦应用逻辑和底层异构数据，使得分析应用可自动灵活实现，具体架构如图 2 所示。SDM 架构层由数据传递元素组成，主要职责是在异构数据源中进行数据传递，负责监控局部信息并收集统计信息。中间层负责对数据平面进行规划和管理，通过数据平面提供的信息定义数据操作和转发路由规则。控制器可以是 1 个或多个分布式协调控制器，通过标准的南桥接口与数据平面中的元素通信。应用层可以从控制器接收到当前分布式数据的抽象视图，并使用这些信息指导控制层任务分发。在应用层和控制层之间的接口称为北桥接口。当前控制层软件提供自己特有的应用程序开发接口。

图 2 SDM 架构

数据平面的元素叫做代理，代理依据流表传递数据包和消息，流表中包含 1 个或多个流表项。流表项由以下 3 个部分组成：1）头部域。描述此流表项会应用于哪一个数据包，数据包可以是地图图层中某个空间对象，也可以是指向代理本地文件系统中的某个文件地址，还可以是一个服务接口的哈希值等。消息以数据包形式传递时会在头部域添加唯一对象标识及对象访问有关的协议信息。 2）计数域。即保留域，用于存储接收数据包数目、字节及流表项持续时间。3）指令域。用于指定数据包如何被加工处理，有向前传递、执行及丢弃数据包不做处理等操作。

通过插入、修改及删除流表项，控制器能够更改代理行为。SDM 南桥协议主要用于指示代理执行任务。当代理接收到 1 个数据包时，首先解析数据包头部域。如果流表的某个流表项匹配上该数据包，则考虑执行该流表项；如果多个流表项匹配该数据包，则依据优先级选择执行某个特定的流表项。接着，代理更新流表项计数域。代理依据指令域中定义的处理过程对数据包进行处理，否则，如果没有任何流表项匹配该数据包头部域，代理通知控制器，如果该代理有内存则缓存该数据包。代理发送消息到控制器，安装 1 个或多个合适的流表项到所请求的代理。

2.1 南桥接口的协议规范

与 SDM 南桥接口协议类似[16]，SDM 接口协议表达了控制器与数据平面中数据元素之间的交互。代理是实现该南桥接口协议的进程或服务。代理包含多个流表和组表，通过它们实现数据查找和传递功能；此外，还包含 1 个或多个通道，用于和控制器通信。使用南桥协议与代理通信时，控制器可以指示代理添加、删除和修改流表中的流目录，在代理中的每个流表都可以有 1 个或者多个流目录，每个目录中包含匹配域、计数器及指令用于处理输入数据。

SDM 中流表包含的是控制器传递的指令或指令集合，可以是代理自身所支持的某个地图代数功能库、函数或者应用程序。代理端口是数据访问接口，用于在数据平面的代理之间传递数据。代理与代理之间通过端口建立连接，一个数据对象可以从一个代理的输出端口传递到另一个代理的输入端口。代理与代理之间的端口可以不同，代理可自行定义和禁止端口行为。通常定义的端口可与某个传统应用程序服务接口关联，SDM 代理内部结构如图3 所示。

图 3 南桥协议控制的代理内部结构

代理输入端口用于接收数据，数据处理经过一系列流表组成的管道，最后 1 个流表决定数据处理结果的输出端口。代理实现以下端口：1）物理端口。表示与本地数据库或已有应用程序交互的数据接口，对象与数据交互接口是一对一关系，但在实际中，可通过 Web 服务发现获取多个数据对象。多个物理端口可以对应 1 个数据接口。2）逻辑端口。是更高级别抽象的端口，可能包含数据封装，可以映射到不同物理端口。逻辑端口代表数据更新操作，由代理依据管理对象定义。在代理中逻辑端口和物理端口唯一区别在于逻辑端口可能有 1 个外部管道域，这个管道域用于在代理和控制器或在代理之间传递数据。保留端口代表发送到控制器的通用数据传递过程。在代理中，端口会随时发生变化，例如当数据库某一对象的访问发生变化时，代理会改变端口的状态，端口状态改变时代理都会通知控制器。在流表中，那些引用失效端口的流表项指令集会失败，数据处理结果会丢失。端口在代理中具有唯一编码，在流表中应用修改过的端口，流表项指令集可以支持重新定向新的端口。逻辑端口可以表示复杂处理过程，例如当对某一对象的处理触发其它对象状态改变，这种逻辑端口被用于在代理内部维护数据一致性。

除了那些运行时定义的流表没有具体结构要求之外，其它流表项由匹配域、优先级域、计数域、指令域、失效域、Cookie 域及标志域组成。其中，匹配域主要用于匹配数据对象标识，数据对象经由端口传递时，可能附加上元数据信息；流目录具有优先级，用优先级域表示；计数域表示计数器，当数据对象匹配时，代理更新这个域；指令域表示经由管道执行的指令集或者自动生成的数据集，或者是变更指令集；失效域表示流表中最长等待或有效时间，使得应用可以控制延时响应的指令集的最长等待时间；Cookie 域包含控制器，依据流项目进行有关统计，从而作为过滤特定流目录的一种参考；标志域影响管理流目录的方式。

在 SDM 中有组表和元表 2 个重要支持组件。组表表示代理的分组表示，内部结构由组标识域、类型域、技术域及指令域组成，其中，组标识域在代理中唯一，类型域用于决定组语义，计数域是自增域，指令域是指令集合，命令处理的结果发送到端口。组表经常被用于控制一组代理的数据更新任务，组表的标识符由控制器控制和管理，一个相同分组内的代理执行相同指令。元表主要用于控制器更高级别管理应用。

2.2 控制器和代理通信

南桥协议支持以下 3 种消息类型：

1）控制器到代理消息。由控制器发起，主要用于管理和检测代理状态。a. 特征消息。控制器通过此消息获取代理的标识和能力。这些能力包括代理可用资源大小及表示代理健康状态的其它参数。在收到此消息时，代理必须回复，这种消息通常在控制器与代理通道建立连接时触发。b. 配置消息。控制器通过此消息配置和查询代理参数，代理仅回复配置查询消息。 c. 修改状态消息。控制器发送此消息以管理代理端口状态，目的主要是增加、移除和修改流表或组表。d. 读状态消息。控制器通过此消息搜集不同代理状态，内容包括当前配置、统计信息及代理当前可用资源说明。e. 数据包输出消息。控制器使用此消息往代理特定端口发送数据，或者通过得到的包输入消息传递数据包到代理。数据包输出消息包含完整的数据消息，或者所发送的消息中包含在代理缓存区或本地存储区中的数据地址。

2）异步消息。由代理触发，发送到控制器，主要用于通知控制器数据发生变化，或者表示任务完成及自身状态变化消息，代理并不要求控制器做出回应。a. 数据包输入消息。传输一个对数据包的控制到控制器，代理处理的结果通常用此消息发送到控制器。b. 流表项移除消息。通知控制器一个流表的流目录已被删除。c. 端口状态消息。 通知控制器代理端口状态发生改变，代理发送状态和配置的改变消息到控制器，产生这些消息的事件包括代理管理者关闭端口，或者端口对应的接口失效。d. 控制器状态消息。当代理的通道状态发生变化时通知控制器，此消息会发送到所有与该代理联系的控制器。

3）对称消息。指由控制器或代理发送的不要求回复消息，接收方可以发送回复也可不回复。a. 对称消息。控制器和代理都可以发送对称消息，这种消息发送方对消息接收方是否回复不敏感。b. 探测消息。当代理和控制器建立连接时，此消息被双方交换。c. 回显消息。回显消息可由代理和控制器任意一方发出，任何接收回显消息的一方都必须发送回复。此消息主要用于检验控制器和代理之间的连接是否在线，也可用于测量延时或者带宽。d. 错误消息。此消息用于消息接收方报告错误或者问题出现，主要用于代理通知由控制器发送的请求执行失败消息。

3 信息共享和业务系统协调实现方法

假定 MS 和 LS 分别表示按地图代数逻辑表达的业务系统和原有业务系统。在控制器中有一个注册机构，每个需共享数据的业务系统通过该机构提供的统一接口注册，控制器为其分配唯一对象编码。这类原有业务系统不会经常发生变化。按照应用系统对数据不同需求，分 2 种情形讨论实现方式：第1 种，多个应用系统需要相同数据；第 2 种，多个应用系统需要不同数据。

3.1 第 1 种情况实现方式

第 1 种情况比较容易实现，如果用 M 代表应用定义的共享变量，则代码片段 1 如下：

Sharing ( ls: LS, m:M ) {

val broadcast Value = SDMA Context.broadcast (o)

ls.for each (i = ＞ {

share (i，o)

})

}。

具体实现步骤如下：

1）控制器调用广播方法，将应用定义的共享变量装载入内存区域。

2）对 LS 的每个业务系统调用 share 函数。控制器在预装载处理过程中会判断业务系统集合中业务系统接口和共享变量可用性。

3）控制器向指定代理发送包输出消息。该消息发送后，代理通过输入端口接收此消息。代理通过在流表项目中匹配消息头部域，执行流表项中预定义操作，流表项通过输出端口输出结果。代理通过发送端口状态消息到控制器以反馈操作结果。

3.2 第 2 种情况实现方式

第 2 种情况，当多个系统彼此互不关联，需要不同数据对象。这类似于第 1 种情形，不同之处在于控制器调度任务到代理的次数，控制器产生的任务相同。当多个业务系统彼此关联时，每个业务处理的输入和输出参数格式有可能互不相同。此时，软件定义地图模型的上层应用（SDMA）的设计依赖于关联矩阵定义。在 SDMA Context 类中，关联矩阵是一个稀疏矩阵，矩阵中每一行定义每一业务系统所依赖的其它业务系统的唯一编码。 假定用 S 代表输入参数不依赖于其它业务系统输出结果的业务系统，用 O 代表与对应 S 业务系统集合中的输入对象列表，用 D 表示关联矩阵。代码片段 2 如下：

Sharing ( s:S，o:O，d:D ){

check (o)

share (s，o，d)

}

具体实现步骤如下：

1）在检验要共享的对象是否存在之后，控制器从依赖矩阵中分析关联关系，并开始分配任务。

2）控制器内部首先并行发送包输入消息到业务系统所在代理端口，消息中包含每一个业务系统依赖的对象信息。代理通过解析消息头部域获得所依赖的对象唯一标识，然后发送包输入消息以询问控制器如何获得访问该对象。

3）控制器发送修改状态消息，在流表项中增加如何获取该对象的方法。

4）业务系统在执行新增流表项方法之后，开始调用业务系统所对应的流表项执行业务逻辑。执行结束后，使用包输出消息通知控制器。与传统应用依靠复杂参数匹配算法互相传递输入输出参数不同，由代理向控制器描述底层数据更新系统所支持的具体操作细节，例如底层对象的唯一标识，在该对象上施加的操作及可能返回的结果类型。这样，在应用层提交应用之前，控制器将生成不同应用系统输入输出参数的类型转换逻辑。数据平面中的元素主要任务是传递数据和执行控制器任务。

5）代理通过包输入消息向控制器发布数据更新操作。当多个应用系统需要操作这些数据对象时，它们向控制器订阅这些对象的访问规则，最后再由控制器控制系统数据共享的任务安排。

黄委信息中心整合了从黄委水文局获取的水雨情数据，从国家防汛抗旱指挥系统二期灾情评估系统获取的社会经济数据，从黄河水量调度业务处理系统中获取的用水计划、日报月报数据，以及国家水资源监控能力建设项目建立的国控水资源标准数据库；涵盖了用水监测点的日用水量信息，水文站的水质自动监测数据，防汛指挥系统依赖的河道、水库的水情数据，沿黄河流域县级以上行政区域农作物产量、人口数据及工业产值等数据。这些数据库都是依据国家水利行业有关标准设计建立的，例如，国控水资源标准数据库按照 SL 380－2007《水资源监控管理数据库表结构及标识符标准》建立，以结构化数据为主。数据中心按照对象事件模型将这些结构化数据映射成全局唯一的水利对象，例如，一个水质监测站基本信息表包含了监测站的基本信息（测站编码、测站名称、管理单位、经纬度坐标等 19 个属性数据）。每个监测站对象有 1 个在中央数据中心具有全局唯一编码，通过中心实现对全局水利对象的统一管理，局部系统自更新水利对象及支持面向地图的自定义查询分析 3 个核心功能。黄委综合管理信息资源共享项目解决了水利对象在异构系统中的共享与更新难题。每当水质监测站的管理单位项发生变化时，数据平面中的代理首先通过南桥协议向控制器发送异步消息，在控制器内部通过查询统一对象元数据目录，对在数据中心存储的该水质监测站对象数据进行修改。之后由控制器生成数据更新通知消息到代理端口，每个数据平面中的代理在接收到消息后，在流表项中进行任务匹配，最终由代理负责更新对应数据库中的监测站数据条目。支持面向软件定义地图应用的查询是实现数据共享的一种方式，中心节点在数据目录访问之后，将要查询对象的全局编码装载到内存区域，通过发送查询消息到数据平面的代理，由代理执行流表项中定义查询，最终由各代理返回查询处理结果。

4 实验分析

2 种数据共享方式耗费的时间由 3 个部分构成：第 1 部分是中心节点数据目录访问和内存装载过程时消耗时间；第 2 部分是数据平面中代理执行流表中定义的流表项所耗费时间；最后是各代理返回消息到控制器消耗时间。黄委共享服务平台中包含了实时水情及水质监测等数据，水情数据包含水文站名称、水位、流量、时间及警戒水位信息。假定业务系统的执行功能相同且执行代价都相同（仅仅在获取共享数据后，在终端显示数据）。为确定业务系统数量对执行数据共享效率的影响，本研究用 Docker 管理业务系统镜像，用 Kubernetes 管理和加载业务容器使之自动水平扩展。Docker 版本为社区版 17.09.0-ce，Kubernetes 采用 1.10.4 稳定版。Kubernetes 扩展容器的能力使得实验过程中能加载任意数目的业务系统。本次实验环境为黄委信息中心黄河云，底层由 OpenStack 相关组件管理虚拟机实例，使用 Ceph 文件系统管理虚拟机存储。总共申请使用 6 台虚拟机，其中 5 台虚拟机参数是2vCPUs， 8 GB 内存，以及 250 GB 硬盘；另外 1 台虚拟机配置有 4vCPUs，16 GB 内存，以及 500 GB硬盘。内存较大的虚拟机实例用于加载控制器镜像，其它 5 个虚拟机则用于运行代理及业务系统的镜像。假定业务系统都已经迁移到云环境中，本研究用云计算虚拟化网络模拟业务系统复杂通信网络使之具有一定代表性。

实验首先分析在业务系统数量为 100 个时，控制器使用同步和异步模式共享数据时的执行时间开销，具体时间开销如表 1 所示。面向软件定义地图共享的算法在执行水情数据共享时，实验记录收到业务系统反馈的时间。每次不同的配置被执行 10 次，记录平均执行时间。当控制器使用异步操作指定共享 100 MB 数据时，大约在 23.3 s 时间内完成所有系统对该数据对象的访问与业务更新。当控制器指定共享 500 MB 数据时，大约在 34.9 s 时间内所有业务系统完成更新操作。尽管数据量增加时，所有业务系统完成更新的时间会增加，例如在更新 1000MB数据时，大约需要 42.3 s 完成；但也发现，控制器广播变量传递数据时，控制器使用 P2P 协议减少了业务系统获取控制器内存数据的时间。在执行同步共享数据操作时，控制器通过发送数据包输出消息到代理端口，代理需等待业务系统完成后才能返回确认消息。因此，可以看到在同步情况下，共享1000MB 数据时，大约在 42.8 s 时间内所有业务系统返回确认消息，内存装载操作时间会随着数据量大小增加而增大。在实验过程中，通过统计发现广播 1 个 2 GB 对象大约消耗的时间是 61.0 s。实际上，在控制器版本的升级过程中已经考虑引入 Redis缓存优化以降低这一部分时间消耗。实验跟踪了代理在执行流表操作时的平均执行时间，此次数据共享操作使得每一个代理都会匹配最后 1 个流表项以执行代理到业务系统的数据传递，50% 的代理的流表项执行时间在 450 ms 左右。因此，控制器在执行共享操作时的效率主要由第 1 部分时间决定。

表 1 控制器使用同步和异步模式共享数据时的执行时间开销（业务系统数为 100 个）

本研究还分析了业务系统数对执行器共享执行大小数据的影响，共享数据为 1000MB 时的执行时间开销如表 2 所示。更新 500，600，700，1000个业务系统数据时，控制器异步执行 1000MB 数据共享消耗时间大约分别为 32.6，34.1，33.1，35.1 s。结果表明，业务系统数和控制器共享大规模数据的性能之间没有明显关系。所有数据共享操作都在30.0 s 左右时间完成。在使用同步模式时，控制器返回的时间会随着业务系统数增加而产生较大延时。实际上业务系统所处网络环境复杂，且业务系统的逻辑操作各不相同，因此，深入地实验分析控制器流表项如何使用计数域避免长时间等待代理返回是必须的。后一阶段任务重点考虑延时等待问题。

表 2 控制器使用同步和异步模式共享数据时的执行时间开销（共享数据为 1000MB）

5 结语

水利数据整合共享是实现水利数据深度挖掘的一个重要前提，其中技术框架和管理体系的建立是主要工作任务[18]。在第一次全国水利普查开展之后[19]，水利信息化标准体系确保了普查成果的有效开发利用，促进了水利业务协同[20]。这些标准体系包含水利对象和信息的分类编码、传输交换、数据存储、图示表达、产品服务、建设管理和运维服务标准，它们在推动水利业务系统之间全面共享数据方面发挥了重要作用。近年来，面向“一张图”的资源整合成为主流。黄委将标准化组织和存储的水利对象数据通过一张图的形式直观表示出来，使用标准 WMTS 图层服务汇聚了包括河流、湖泊及淤地坝等 9 类水利基础数据。此外，黄委通过数据整合提供雨量站、大堤等 18 项专题图层服务，与防汛抗旱有关的 6 项图层服务包含了险工险点、治河工程等数据。这些工作使得通过通用的集合操作对图层中所含对象进行数据操作和分析成为趋势。

考虑到对异构服务聚合需要依赖复杂的参数转换、服务注册与更新，使得分析应用及数据整合共享的任务实现非常困难，为此从解耦应用逻辑和数据管理方面分析一个应用的执行过程。SDM 形式化将分析过程划分到应用、控制及数据平面。其中数据平面模拟软件定义交换机的行为，通过接收控制器发送的指令，实现对数据平面中的数据进行交换和处理的功能。SDM 综合考虑了地图约束条件下的应用层表达模式，使得智能化分析应用可以在统一的抽象概念上自动组织。SDM 控制器作为传递应用层数据需求和协调任务执行的中枢，通过标准的南桥协议与数据平面中的异构数据单元通信。南桥协议规范地描述了控制器和数据平面中代理的消息传递模式，定义了控制器获取代理状态、控制代理执行流表更新任务及管理代理回复。在 SDM 架构中，数据平面代理主要任务是传递数据和执行控制器任务，通过匹配对象以执行控制器分发任务，代理成为能自适应底层数据存储模式通用组件。SDM 是面向“一张图”产生智能化分析应用的基础，不仅适用于整合和共享异构水利数据，在自管理、自优化及自配置异构水利资源方面也有着独特作用。