CN113962297A - 一种共性监测平台的数据融合方法 - Google Patents

Abstract

本发明公开了一种共性监测平台的数据融合方法，数据融合过程的输入是各类感知设备的监测数据，结合支持数据库数据和融合数据库数据，支持数据库主要包含融合过程需要的对象状态、属性参数数据、先验信息等，融合数据库主要用于存储有重要意义的融合案例，作为后续融合和评估的依据；对象估计的输出是融合产品。本发明数据融合的模型可以将各种业务数据、空间数据整合起来，实现数据的统一存储、备份/恢复、复制、数据迁移、归档、辅助决策分析、存储资源管理和服务级的数据管理。解决了以前数据存贮杂乱、数据冗余、数据管理工作繁复等问题。实现了在网络环境下各主要业务系统的互联交换和资源共享。

Description

一种共性监测平台的数据融合方法

技术领域

本发明属于共性监测平台技术领域，具体涉及一种共性监测平台的数据融合方法。

背景技术

目前，现有的一些参量监测管理软件业务功能与数据库结构关联紧密，由于共性监测平台的数据经常变更，在变更后，系统的某些功能就不能再使用了，需要修改或重新开发，耗费大量的人力财力，而且，这种软件的升级会随着数据结构的变迁永无止境，给系统开发和维护人员带来很大麻烦。

因此，迫切需要建立一个数据融合的模型，作为程序与数据库之间的沟通桥梁，数据融合模型用来表示数据的内容，由于数据的内容变化远远少于结构变化，所以，数据融合模型的变更是很少的，程序访问的是数据逻辑模型，也就不需要总是随着数据库结构的变化而变化。为此，我们提出一种共性监测平台的数据融合方法，以解决上述背景技术中提到的问题。

发明内容

本发明的目的在于提供一种共性监测平台的数据融合方法，以解决上述背景技术中提出的问题。

为实现上述目的，本发明提供如下技术方案：一种共性监测平台的数据融合方法，包括如下步骤：

S1、对象状态估计包括：时空统一、误差补偿、数据关联、状态估计、状态预测；

所述时空统一具体为：对输入的感知设备采集数据、信号检测数据进行时间统一和空间变换；

所述误差补偿具体为：对多源输入数据，进行时间、空间和其他特征数据进行误差估计和补偿；

所述数据关联具体为：对补偿后的多源数据基于时间、空间及其它特征关系进行聚集，参照属性识别结果，生成同一对象的数据集合；

所述状态估计具体为：对数据关联形成的同一对象的数据集合进行估计、滤波等综合处理，生成该对象的状态参数估计及估计精度；

所述状态预测具体为：利用对象的状态估计参数，通过对象状态变化模型预测对象未知状态和精度；

S2、对象属性识别：将多源数据进行数据配准（包括时空统一、误差补偿）和数据关联后，然后参照对象状态估计信息生成同一对象的属性数据集合，对该数据集合进行融合，然后对融合属性数据进行特征提取和对象属性判定识别，形成该对象的融合属性说明。

优选的，所述时间统一是将输入的不同步时钟下的数据变换到融合系统的基准时标下；所述空间变换是将输入的各局部坐标系下的数据变换到融合系统的基准坐标系下，包括坐标变换、幅度变换和分辨率统一。

优选的，所述状态估计的输入信息是生态参量感知设备信息、监测系统输入以及支持数据库、融合数据库和对象属性识别结果；状态估计的输出是对象状态估计和估计精度。

优选的，所述支持数据库主要包含融合过程需要的对象状态、属性参数数据、先验信息。

优选的，所述融合数据库主要用于存储有重要意义的融合案例，作为后续融合和评估的依据。

与现有技术相比，本发明的有益效果是：本发明提供的一种共性监测平台的数据融合方法，本发明数据融合的模型可以将各种业务数据、空间数据整合起来，实现数据的统一存储、备份/恢复、复制、数据迁移、归档、辅助决策分析、存储资源管理和服务级的数据管理。解决了以前数据存贮杂乱、数据冗余、数据管理工作繁复等问题。实现了在网络环境下各主要业务系统的互联交换和资源共享。

附图说明

图1为本发明数据融合过程示意图；

图2为本发明对象状态估计过程示意图；

图3为本发明数据级属性识别过程示意图；

图4为本发明数据融合模型功能框架结构示意图；

图5为本发明数据仓库的层次划分结构示意图；

图6为本发明数据仓库数据模型架构结构示意图；

图7为本发明数据仓库建模的阶段划分结构示意图；

图8为本发明星型架构的结构示意图；

图9为本发明实体建模结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例1：本发明提供了如图1-9的一种共性监测平台的数据融合方法，包括如下步骤：

S1、对象状态估计包括：时空统一、误差补偿、数据关联、状态估计、状态预测；

所述时空统一具体为：对输入的感知设备采集数据、信号检测数据进行时间统一和空间变换；

所述误差补偿具体为：对多源输入数据，进行时间、空间和其他特征数据进行误差估计和补偿；

所述数据关联具体为：对补偿后的多源数据基于时间、空间及其它特征关系进行聚集，参照属性识别结果，生成同一对象的数据集合；

所述状态估计具体为：对数据关联形成的同一对象的数据集合进行估计、滤波等综合处理，生成该对象的状态参数估计及估计精度；

所述状态预测具体为：利用对象的状态估计参数，通过对象状态变化模型预测对象未知状态和精度；

S2、对象属性识别：将多源数据进行数据配准（包括时空统一、误差补偿）和数据关联后，然后参照对象状态估计信息生成同一对象的属性数据集合，对该数据集合进行融合，然后对融合属性数据进行特征提取和对象属性判定识别，形成该对象的融合属性说明。

具体的，所述时间统一是将输入的不同步时钟下的数据变换到融合系统的基准时标下；所述空间变换是将输入的各局部坐标系下的数据变换到融合系统的基准坐标系下，包括坐标变换、幅度变换和分辨率统一。

具体的，所述状态估计的输入信息是生态参量感知设备信息、监测系统输入以及支持数据库、融合数据库和对象属性识别结果；状态估计的输出是对象状态估计和估计精度。

具体的，所述支持数据库主要包含融合过程需要的对象状态、属性参数数据、先验信息。

具体的，所述融合数据库主要用于存储有重要意义的融合案例，作为后续融合和评估的依据。

数据融合过程的输入是各类感知设备的监测数据，结合支持数据库数据和融合数据库数据，支持数据库主要包含融合过程需要的对象状态、属性参数数据、先验信息等，融合数据库主要用于存储有重要意义的融合案例，作为后续融合和评估的依据；对象估计的输出是融合产品（对象状态和对象属性）。对象估计包括对象状态估计和对象属性识别，如图1所示。

如图2所示，对象状态估计包括：时空统一、误差补偿、数据关联、状态估计、状态预测；

所述时空统一具体为：对输入的感知设备采集数据、信号检测数据进行时间统一和空间变换；

所述误差补偿具体为：对多源输入数据，进行时间、空间和其他特征数据进行误差估计和补偿；

所述数据关联具体为：对补偿后的多源数据基于时间、空间及其它特征关系进行聚集，参照属性识别结果，生成同一对象的数据集合；

所述状态估计具体为：对数据关联形成的同一对象的数据集合进行估计、滤波等综合处理，生成该对象的状态参数估计及估计精度；

所述状态预测具体为：利用对象的状态估计参数，通过对象状态变化模型预测对象未知状态和精度；

如图3所示，将多源数据进行数据配准（包括时空统一、误差补偿）和数据关联后，然后参照对象状态估计信息生成同一对象的属性数据集合，对该数据集合进行融合，然后对融合属性数据进行特征提取和对象属性判定识别，形成该对象的融合属性说明。

数据融合模型功能设计：

一、功能架构：如图4所示。

二、功能设计：

1、数据建模：

数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。

在这里，数据模型表现的抽象的是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。

数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型，一般的来说，我们数据仓库模型分为如图5所示的几个层次。

我们能够很容易的看出在整个数据仓库得建模过程中，我们需要经历一般四个过程：

业务建模，生成业务模型，主要解决业务层面的分解和程序化。

领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。

逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。

物理建模，生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。

2、数据仓库数据模型架构：

数据仓库的数据模型的架构和数据仓库的整体架构是紧密关联在一起的，我们首先来了解一下整个数据仓库的数据模型应该包含的几个部分。从图6我们可以很清楚地看到，整个数据模型的架构分成 5 大部分，每个部分其实都有其独特的功能。

从图6我们可以看出，整个数据仓库的数据模型可以分为大概 5 大部分：

系统记录域（System of Record）：这部分是主要的数据仓库业务数据存储区，数据模型在这里保证了数据的一致性。

内部管理域（Housekeeping）：这部分主要存储数据仓库用于内部管理的元数据，数据模型在这里能够帮助进行统一的元数据的管理。

汇总域（Summary of Area）：这部分数据来自于系统记录域的汇总，数据模型在这里保证了分析域的主题分析的性能，满足了部分的报表查询。

分析域（Analysis Area）：这部分数据模型主要用于各个业务部分的具体的主题业务分析。这部分数据模型可以单独存储在相应的数据集市中。

反馈域（Feedback Area）：可选项，这部分数据模型主要用于相应前端的反馈数据，数据仓库可以视业务的需要设置这一区域。

通过对整个数据仓库模型的数据区域的划分，我们可以了解到，一个好的数据模型，不仅仅是对业务进行抽象划分，而且对实现技术也进行具体的指导，它应该涵盖了从业务到实现技术的各个部分。

3、数据仓库建模阶段划分：

我们前面介绍了数据仓库模型的几个层次，下面我们讲一下，针对这几个层次的不同阶段的数据建模的工作的主要内容：从图7我们可以清楚地看出，数据仓库的数据建模大致分为四个阶段：

业务建模，这部分建模工作，主要包含以下几个部分：

划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。

深入了解各个业务部门的内具体业务流程并将其程序化。

提出修改和改进业务部门工作流程的方法并程序化。

数据建模的范围界定，整个数据仓库项目的目标和阶段划分。

领域概念建模，这部分得建模工作，主要包含以下几个部分：

l 抽取关键业务概念，并将之抽象化。

l 将业务概念分组，按照业务主线聚合类似的分组概念。

l 细化分组概念，理清分组概念内的业务流程并抽象化。

l 理清分组概念之间的关联，形成完整的领域概念模型。

逻辑建模，这部分的建模工作，主要包含以下几个部分：

l 业务概念实体化，并考虑其具体的属性

l 事件实体化，并考虑其属性内容

l 说明实体化，并考虑其属性内容

物理建模，这部分得建模工作，主要包含以下几个部分：

l 针对特定物理化平台，做出相应的技术调整

l 针对模型的性能考虑，对特定平台作出相应的调整

l 针对管理的需要，结合特定的平台，做出相应的调整

l 生成最后的执行脚本，并完善之。

从我们上面对数据仓库的数据建模阶段的各个阶段的划分，我们能够了解到整个数据仓库建模的主要工作和工作量，希望能够对我们在实际的项目建设能够有所帮助。

4、数据仓库建模方法

数据仓库得建模方法同样也有很多种，每一种建模方法其实代表了哲学上的一个观点，代表了一种归纳，概括世界的一种方法。目前业界较为流行的数据仓库的建模方法非常多，这里主要介绍范式建模法，维度建模法，实体建模法等几种方法，每种方法其实从本质上讲就是从不同的角度看我们业务中的问题，不管从技术层面还是业务层面，其实代表的是哲学上的一种世界观。我们下面给大家详细介绍一下这些建模方法。

范式建模法（Third Normal Form，3NF）

范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由 Inmon所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。

范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也可称为规范化。在数据仓库的模型设计中目前一般采用第三范式，它有着严格的数学定义。从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件 :

每个属性值唯一，不具有多义性 ;

每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;

每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。

由于范式是基于整个关系型数据库的理论基础之上发展而来的，因此，本人在这里不多做介绍，有兴趣的读者可以通过阅读相应的材料来获得这方面的知识。

根据 Inmon 的观点，数据仓库模型得建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例话。

从业务数据模型转向数据仓库模型时，同样也需要有数据仓库的域模型，即概念模型，同时也存在域模型的逻辑模型。这里，业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于：

数据仓库的域模型应该包含企业数据模型得域模型之间的关系，以及各主题域定义。数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。

在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类，以及实体的关系等。

Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。但其缺点也是明显的，由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。

维度建模法：

维度建模法，Kimball 最先提出这一概念。其最简单的描述就是，按照事实表，维表来构建数据仓库，数据集市。这种方法的最被人广泛知晓的名字就是星型模式（Star-schema）。

图8的这个架构中是典型的星型架构。星型模式之所以广泛被使用，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。通过这些预处理，能够极大的提升数据仓库的处理能力。特别是针对 3NF 的建模方法，星型模式在性能上占据明显的优势。

同时，维度建模法的另外一个优点是，维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。这一点也是维度建模的优势。

但是，维度建模法的缺点也是非常明显的，由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。

另外一个维度建模法的缺点就是，如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。

因此，维度建模的领域主要适用与数据集市层，它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。

实体建模法：

实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。

虽然实体法粗看起来好像有一些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分，实体，事件和说明，如图9所示；

图9表述的是一个抽象的含义，如果我们描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。

从上面的举例我们可以了解，我们使用的抽象归纳方法其实很简单，任何业务可以看成 3 个部分：

实体，主要指领域模型中特定的概念主体，指发生业务关系的对象。

事件，主要指概念主体之间完成一次业务流程的过程，特指特定的业务过程。

说明，主要是针对实体和事件的特殊说明。

由于实体建模法，能够很轻松的实现业务模型的划分，因此，在业务建模阶段和领域概念建模阶段，实体建模法有着广泛的应用。从笔者的经验来看，再没有现成的行业模型的情况下，我们可以采用实体建模的方法，和客户一起理清整个业务的模型，进行领域概念模型的划分，抽象出具体的业务概念，结合客户的使用特点，完全可以创建出一个符合自己需要的数据仓库模型来。

但是，实体建模法也有着自己先天的缺陷，由于实体说明法只是一种抽象客观世界的方法，因此，注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。

因此，在创建数据仓库模型的时候，可以参考使用上述的三种数据仓库得建模方法，在各个不同阶段采用不同的方法，从而能够保证整个数据仓库建模的质量。

5、数据汇集：

提供数据抽取、转换、数据导入等功能，将中心前置库、基础库数据整合到汇集库。

数据抽取：

基于中心前置库和基础库数据，在充分理解数据抽取目标后，规划需要的数据源及数据定义，制定可操作的数据源，制定增量抽取的任务。

抽取任务配置：支持对数据抽取源、抽取方式、抽取时机、抽取周期、抽取内容等的配置。

抽取任务控制：可对抽取任务进行启动和停用控制。

数据转换：

提供丰富的数据处理组件，能够通过拖拽的方式快速完成各种复杂数据集成需求和集成的调度控制。提供的转换组件覆盖数据映射、数据丰富、数据计算、数据验证、数据排序、数据合并、数据拆分、数据生成、数据去重、数据分组、行列转换等复杂处理，提供的任务组件涵盖定时调度、周期循环调度等调度模式组件、以及数据处理的一些前置、后置检查操作等。

数据清洗：

按照一定规则过滤掉不符合要求的“脏数据”，包括不完整数据、错误数据、重复数据等。针对中心前置库数据可能出现的数据二义性、重复、不完整、违反业务规则等问题，允许通过试抽取，将有问题的纪录先剔除出来，根据实际情况调整相应的清洗操作。

格式转换：

完成对不规范数据的处理，使之符合汇集库数据存储要求。

支持根据不同的数据差异性定制不同的转换规则，可对转换后的数据进行校验。

数据导入：

将汇集后的数据导入到基于Hadoop的分布式数据库。

6、任务管理：

依据信息服务需求，通过对任务配置，建立相应的数据加工流程。支持任务的配置、任务调度、运行监控，支持整个任务过程的质量监控。

任务定义：

依据数据融合业务需求，定义语义层面的任务描述，创建融合任务。

任务调度：

依据任务配置，调度各任务的运行，并从引擎功能层获得运行状态。

质量管理：

从引擎功能层获得的运行状态，建立整个任务过程的质量监控。

任务监控：

监控任务的运行状态，产生数据加工的统计信息。

7、融合引擎：

提供数据融合引擎，执行数据加工流程，根据任务配置需求对相关数据进行关联、切分、聚合、统计分析及数据挖掘等。提供运行状态及质量数据接口，以便进行任务调度和质量管理。

数据关联：实现管理对象基础数据与各种业务状态数据的关联。

数据切分聚合：将管理对象基础信息和业务状态信息从时间、区域、部门、业务事件等多个维度进行切分聚合。

统计分析：基于分布式数据库，对存储于其内的海量数据进行普通的分析和分类汇总。

数据挖掘：基于海量分布式数据，根据业务需求，采用某种算法，实现预测等一些高级别数据分析的需求

8、融合规则管理：

提供数据处理规则的定义和查询，包括数据转换规则、关联规则、切分规则、聚合规则等。

规则的定义基于各部门、各系统对跨部门物联信息共享服务的各类查询、分析服务进行。为查询统计、趋势分析、多维分析等需要提供融合规则定义管理功能。

综上所述，与现有技术相比，本发明数据融合的模型可以将各种业务数据、空间数据整合起来，实现数据的统一存储、备份/恢复、复制、数据迁移、归档、辅助决策分析、存储资源管理和服务级的数据管理。解决了以前数据存贮杂乱、数据冗余、数据管理工作繁复等问题。实现了在网络环境下各主要业务系统的互联交换和资源共享。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换,凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (5)

1.一种共性监测平台的数据融合方法，其特征在于：包括如下步骤：

S1、对象状态估计包括：时空统一、误差补偿、数据关联、状态估计、状态预测；

所述时空统一具体为：对输入的感知设备采集数据、信号检测数据进行时间统一和空间变换；

所述误差补偿具体为：对多源输入数据，进行时间、空间和其他特征数据进行误差估计和补偿；

所述数据关联具体为：对补偿后的多源数据基于时间、空间及其它特征关系进行聚集，参照属性识别结果，生成同一对象的数据集合；

所述状态估计具体为：对数据关联形成的同一对象的数据集合进行估计、滤波等综合处理，生成该对象的状态参数估计及估计精度；

所述状态预测具体为：利用对象的状态估计参数，通过对象状态变化模型预测对象未知状态和精度；

S2、对象属性识别：将多源数据进行数据配准和数据关联后，然后参照对象状态估计信息生成同一对象的属性数据集合，对该数据集合进行融合，然后对融合属性数据进行特征提取和对象属性判定识别，形成该对象的融合属性说明。

2.根据权利要求1所述的一种共性监测平台的数据融合方法，其特征在于：所述时间统一是将输入的不同步时钟下的数据变换到融合系统的基准时标下；所述空间变换是将输入的各局部坐标系下的数据变换到融合系统的基准坐标系下，包括坐标变换、幅度变换和分辨率统一。

3.根据权利要求1所述的一种共性监测平台的数据融合方法，其特征在于：所述状态估计的输入信息是生态参量感知设备信息、监测系统输入以及支持数据库、融合数据库和对象属性识别结果；状态估计的输出是对象状态估计和估计精度。

4.根据权利要求3所述的一种共性监测平台的数据融合方法，其特征在于：所述支持数据库主要包含融合过程需要的对象状态、属性参数数据、先验信息。

5.根据权利要求3所述的一种共性监测平台的数据融合方法，其特征在于：所述融合数据库主要用于存储有重要意义的融合案例，作为后续融合和评估的依据。

Images