CN111639114A - 一种基于物联网平台的分布式数据融合管理系统 - Google Patents

一种基于物联网平台的分布式数据融合管理系统 Download PDF

Info

Publication number
CN111639114A
CN111639114A CN202010265594.4A CN202010265594A CN111639114A CN 111639114 A CN111639114 A CN 111639114A CN 202010265594 A CN202010265594 A CN 202010265594A CN 111639114 A CN111639114 A CN 111639114A
Authority
CN
China
Prior art keywords
data
module
distributed
subsystem
cluster
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010265594.4A
Other languages
English (en)
Inventor
程渤
章洋
陈俊亮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing University of Posts and Telecommunications
Original Assignee
Beijing University of Posts and Telecommunications
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing University of Posts and Telecommunications filed Critical Beijing University of Posts and Telecommunications
Priority to CN202010265594.4A priority Critical patent/CN111639114A/zh
Publication of CN111639114A publication Critical patent/CN111639114A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/258Data format conversion from or to a database
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2365Ensuring data consistency and integrity
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16YINFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y10/00Economic sectors
    • G16Y10/75Information technology; Communication

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明实施例提供一种基于物联网平台的分布式数据融合管理系统。该系统包括:数据融合平台子系统、分布式实时库管理子系统、客户端代理子系统、持久化存储子系统和元数据服务器子系统。本发明实施例提供了高可靠数据融合平台,按平台统一标准实现数据融合;并针对分布式物联网数据存取需要强实时性与一致性的要求,设计了分布式实时库管理架构;利用代理路由将采样后的历史数据路由到不同集群存储,在进一步提高响应速度的同时保障了数据存储的可靠。

Description

一种基于物联网平台的分布式数据融合管理系统
技术领域
本发明涉及数据融合技术领域,尤其涉及一种基于物联网平台的分布式数据融合管理系统。
背景技术
物联网是指在互联网的基础上,用户可以拓展到任何物体的网络。在物联网的世界中,任何物体都可以进行信息传递,大到建筑物,小到橡皮铅笔都可通过网络连接起来,这就是“万物互联”。如今“万物互联”的蓝图正在逐渐变为现实,现在很多场合已经有了物联网的影子,例如智能家居,智慧穿戴、车联网等,以及现在正在建设的集智能家居、智慧医疗、交通、工业、物流、安防于一体的智慧城市。
虽然万物互联即将在未来不久成为现实,但当前环境下,还有许多问题亟待解决。因为各行业的管理系统仍是互相单一、互不关联的,信息孤岛现象非常严重,而随着物联网与信息技术的发展,物联网底层传感器传输的数据也会更加复杂。数据规模庞大,获取方式多样,数据格式不统一,同名异义,同义异名等一系列的问题也越来越多。
为了解决这些问题,数据处理的需求逐渐上升,通过何种渠道获取有效数据以及搭建完善的数据存储平台是解决问题的关键,当然数据的处理并不是一个简单的事情,需要解决例如技术壁垒,数据标准,数据可靠等问题。在该过程中数据存储也是非常重要的一环,因为目前随着数据堆积越来越多,单机的存储容量已经不再满足数据的存储需求,同时单机存储数据量的增大也降低了数据查询的速度。在此现状下,传统“集中计算”的理念正在向分布式架构的“分布计算”发展。
因此,存在如下尚未被解决的问题:
(1)感知数据获取方式多样且没有统一的数据标准格式,不同传感数据存在同名异义,同义异名等问题;
(2)数据规模庞大造成数据查询缓慢,单机存储限制了分布式集群的计算性能;
(3)目前的系统还无法很好地稳定运行,也无法解决分布式系统的强实时性与一致性问题,并保证数据可靠。
发明内容
本发明实施例提供一种基于物联网平台的分布式数据融合管理系统,用以解决上述问题或至少部分解决上述问题,包括:
数据融合平台子系统、分布式实时库管理子系统、客户端代理子系统、持久化存储子系统和元数据服务器子系统;其中:
所述数据融合平台子系统用于将多源传感器采集的不同格式数据进行统一转化处理,并将处理后的数据缓存至本地的内存库中;
所述分布式实时库管理子系统用于对所述内存库进行分片启动、部署、管理和邻居内存数据库数据对齐,实现一致性更新,并提供分布式数据库界面进行操作;
所述客户端代理子系统用于向分布式架构提供中间路由来管理分布在不同物理地点的数据节点;
所述持久化存储子系统用于将所述内存库中的数据经采样后,进行持久化存储至集群中;
所述元数据服务器子系统用于管理整个分布式数据融合管理系统,并监控系统所有节点和提供配置信息下载。
优选地,所述数据融合平台子系统包括数据采集模块、数据格式转化模块和数据传输模块;其中:
所述数据采集模块用于负责采集不同来源的数据;
所述数据格式转化模块用于将采集到的不同格式数据统一转换为结构化表格式,并处理数据同义异名和数据同名异义问题;
所述数据传输模块用于将所述数据采集模块采集的数据传输到持久化库。
优选地,所述分布式实时库管理子系统包括分布式数据库界面模块、内存库分片管理模块、邻居内存库数据对齐模块、数据采样模块和一致性更新模块;其中:
所述分布式数据库界面模块用于为用户提供交互界面和底层架构;
所述内存库分片管理模块用于提供内存库初始化功能;
所述邻居内存库数据对齐模块用于当存在内存库宕机或与邻居内存库进行数据对齐时,提供数据对齐算法;
所述数据采样模块用于每隔预设采样间隔时间内进行数据采集,并将系统的模拟信号转化为离散信号;
所述一致性更新模块用于使分布式数据库保持一致性。
优选地,所述客户端代理子系统包括数据切分路由模块、报告心跳模块和更新路由状态模块;其中:
所述数据切分路由模块用于将不同集群数据库的结果合并或将数据路由到不同集群;
所述报告心跳模块用于按照预设报告间隔向元数据服务器发送心跳信息;
所述更新路由状态模块用于实时更新数据路由状态。
优选地,所述持久化存储子系统包括持久化数据存储模块、读写分离模块、主从备份模块和异地灾备模块;其中:
所述持久化数据存储模块用于通过内存库和持久化库提供不间断数据服务;
所述读写分离模块用于采用主节点完成写操作,从节点完成读操作;
所述主从备份模块用于使所述主节点的数据库和所述从节点的数据库保持自动同步;
所述异地灾备模块用于在同一集群中采用同城双活及异地灾备的灾难恢复策略。
优选地,所述元数据服务器子系统包括检测集群磁盘占用情况模块、实时库分片信息管理模块、监控代理路由状态模块和后台配置修改自动更新模块;其中:
所述检测集群磁盘占用情况模块用于检测所述持久化存储子系统中集群的磁盘使用情况;
所述实时库分片信息管理模块用于监测所述客户端代理子系统的路由状态;
所述后台配置修改自动更新模块用于运维人员进行查看后台配置信息并修改更新所述后台配置信息。
优选地,还包括:系统功能测试、系统性能测试和系统可靠性测试。
优选地,所述系统功能测试包括分布式数据库界面测试、分布式实时库管理测试、数据融合平台测试、元数据服务器测试、客户端代理测试和分布式持久化存储测试。
优选地,所述系统性能测试包括单节点性能测试和集群性能测试。
本发明实施例提供的基于物联网平台的分布式数据融合管理系统,通过提供了高可靠数据融合平台,按平台统一标准实现数据融合;并针对分布式物联网数据存取需要强实时性与一致性的要求,设计了分布式实时库管理架构;利用代理路由将采样后的历史数据路由到不同集群存储,在进一步提高响应速度的同时保障了数据存储的可靠。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的系统整体结构图;
图2为本发明实施例提供的数据融合平台功能架构图;
图3为本发明实施例提供的数据处理体系结构图;
图4为本发明实施例提供的数据融合过程流程图;
图5为本发明实施例提供的客户端界面流程图;
图6为本发明实施例提供的内存库初始化流程图;
图7为本发明实施例提供的邻居数据对齐流程图;
图8为本发明实施例提供的订阅消息格式图;
图9为本发明实施例提供的客户端代理流程图;
图10为本发明实施例提供的Mycat切片模式图;
图11为本发明实施例提供的集群功能架构图;
图12为本发明实施例提供的元数据服务器功能架构图;
图13为本发明实施例提供的元数据服务器流程图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
针对目前存在的问题,本发明实施例完成了基于物联网平台数据融合管理系统的设计与实现。在复杂感知数据环境下,如何对数据进行有效采集处理、实现快速查询、完成数据共享、并保证数据可靠。
本发明实施例采用的分布式数据融合管理系统,主要目标是对于多源传感器感知数据的获取、转化、存储、查询和操作。重点是将来源不同,格式化不同的数据进行处理,并存储到分布式集群,分布式集群包括分布式实时库与分布式持久化库。对于需要实现的功能进行具体需求分析,将分布式数据融合管理系统分为五大部分。首先是数据融合平台,数据融合平台负责将多源传感器采集的数据进行处理,不同格式数据进行统一转化处理,将处理后的数据缓存到本地的内存库中;其次是分布式实时库管理子系统,所有的内存库组成了一个分布式的结构,有着实现数据强实时性并保证数据一致性的要求,主要功能是对内存库进行分片启动、部署、管理,邻居内存库数据对齐,并实现一致性更新,并提供了一个分布式数据库界面来对其增删改查;之后是客户端代理,持久化存储的分布式架构需要一个中间的路由代理来管理分布在各个不同物理地点的数据节点,相当于一个中间路由,有着分发上层数据的主要功能;然后是持久化存储,内存库中的数据经采样后持久化存储到集群中,有逻辑视图和物理视图两部分,逻辑视图是基于完整结构化数据表,物理视图是基于不同物理地点的集群配置的;最后是元数据服务器节点,负责管理整个分布式数据融合管理系统,有两个最主要功能,监控系统各节点,提供配置信息下载。
对于分布式数据融合管理系统,主要有两类使用人员,一类是用户,主要是通过分布式数据库界面来对分布式实时库中的实时数据进行增删改查,同时访问各集群中的历史数据;另一类是运维和管理人员,管理人员主要是操作元数据服务器来管理其他功能模块,监控各数据中心与代理路由,管理配置文件。
通过对比可以发现,现在数据处理的系统存在许多待解决的问题,本发明实施例需要解决问题分析如下:
1)数据量庞大,单机数据存储压力大;
2)数据融合后数据查找困难、速度慢;
3)提高数据融合实时性;
4)提高数据可靠。
图1为本发明实施例提供的系统整体结构图,如图1所示,包括:
数据融合平台子系统、分布式实时库管理子系统、客户端代理子系统、持久化存储子系统和元数据服务器子系统;其中:
所述数据融合平台子系统用于将多源传感器采集的不同格式数据进行统一转化处理,并将处理后的数据缓存至本地的内存库中;
所述分布式实时库管理子系统用于对所述内存库进行分片启动、部署、管理和邻居内存数据库数据对齐,实现一致性更新,并提供分布式数据库界面进行操作;
所述客户端代理子系统用于向分布式架构提供中间路由来管理分布在不同物理地点的数据节点;
所述持久化存储子系统用于将所述内存库中的数据经采样后,进行持久化存储至集群中;
所述元数据服务器子系统用于管理整个分布式数据融合管理系统,并监控系统所有节点和提供配置信息下载。
具体地,数据首先通过MessageReceiver从消息总线订阅消息,并存储到本地内存库中,数据融合平台负责将内存库中数据进行处理,当然还包括其他途径获取的数据。数据处理过程包括格式化转换,同义同名转化,统一为结构化表结构并实时存储到内存库中,多内存库在MessageReceiver的统筹管理之下形成了一个分布式的实时库集群,实现内存库分片启动、分布部署、管理,邻居内存库数据对齐,并保证分布式数据库的一致性。实时的数据存储到分布式实时库,经一定规则的数据采样之后通过客户端代理存储到持久化数据库集群。客户端代理位于持久化存储子系统与数据库界面之间,用户访问数据库需要经过代理中心,有着路由数据到持久化存储子系统和整合数据到上层用户的主要功能。集群包括内存库集群与持久化库集群,持久化数据存储是整个系统的底层,承载着存储历史数据的重任。持久化存储子系统配置了读写分离来减轻单节点的压力;同时我们设置了主从备份与异地灾备,尽最大可能的保障数据的可靠。进一步地,为了提供给用户良好的交互界面,开发了分布式数据库界面为用户蔽了复杂的系统架构,用户可以方便的对内存库中的实时数据增删改查与查看集群中的历史数据。元数据服务器负责统筹整个分布式数据融合管理系统,各模块也需要元数据服务器进行监测与管理,客户端在启动时需要从元数据服务器获取初始的配置文件,主要为运行中Mycat列表与持久化存储子系统的集群列表;分布式实时库启动时的初始化分片信息也由元数据服务器来发送;实时检测客户端代理的运行状态,并在配置文件更新后推送到具体的客户端代理,客户端代理也是每隔一分钟向元数据服务器报告自己的心跳信息,若宕机后,元数据服务器可以及时将该代理从Mycat运行列表中删除;同时监测持久化存储子系统的运行状态,并查看持久化存储子系统的磁盘占用情况,可以适时调整规则,统筹负载均衡。
本发明实施例通过提供了高可靠数据融合平台,按平台统一标准实现数据融合;并针对分布式物联网数据存取需要强实时性与一致性的要求,设计了分布式实时库管理架构;利用代理路由将采样后的历史数据路由到不同集群存储,在进一步提高响应速度的同时保障了数据存储的可靠。
基于上述实施例,所述数据融合平台子系统包括数据采集模块、数据格式转化模块和数据传输模块;其中:
所述数据采集模块用于负责采集不同来源的数据;
所述数据格式转化模块用于将采集到的不同格式数据统一转换为结构化表格式,并处理数据同义异名和数据同名异义问题;
所述数据传输模块用于将所述数据采集模块采集的数据传输到持久化库。
具体地,数据融合平台子系统主要由三大部分组成。数据采集,数据格式转化部分和数据传输部分,功能架构图如图2所示。终端检测负责接入多源传感器或其他中间件,即负责采集不同来源的数据,数据格式化转换即将采集到的数据进行处理,包括不同格式数据源统一为结构化表格式和数据同义异名和同名异义的问题,例如不同来源数据中设备号与ID其实是同一字段需要进行统一,并将元数据表存储。数据采样传输即将数据采集部分数据传输到持久化库。
面向物联网环境,主要是传感器与平台的数据交互,即数据的获取,所有数据的来源主要可以总结为三种方式:
(1)通过MessageReceiver中的发布订阅来获取消息总线的数据,数据格式是wsn消息的格式,即XML格式;
(2)从其他平台下载数据,需要与服务器之间建立连接来进行数据传输,因为各平台数据并不标准,主要是JSON格式数据,还有部分其他格式;
(3)通过接入内存库中获取数据,获取的数据一般都是经过处理后的数据,也可能是未经过处理的数据,该部分也可以直接连接其他集群的内存库来获取数据,处理后存储到内存库的数据都是结构化表格式的数据。
本发明实施例设定标准格式为数据库表的形式,最终持久化存储子系统中存储的也是数据库表的格式,此处设定了一种标准数据格式如表1所示,所有格式的数据最终都将转换为此格式。
表1
Figure BDA0002441171760000091
另一方面,数据格式转换部分还需要进行处理的就是不同来源、不同结构的数据同义异名和同名异义的问题,系统在理解源数据的同时,对不同表的属性名会根据他的属性含义重新映射到我们存储的表中的名字,同时,属性名规则元数据表也存储在内存库中以供用户查看。之后数据在进行数据融合处理的时候,数据格式转换组件就可以自动的根据元数据表将不同来源数据的的字段名转换为新定义的字段名,最终获得数据融合之后的表实现同名同义。
数据格式转换底层使用的是ETL工具kettle。Kettle是一款强大的开源ETL(Extract,Transform,Load)工具,能够实现海量空间数据及非空间数据的分类、清洗、转换和加载,建立相关业务表之间联系。Kettle是纯java编写的,因此也易于我们对其进行二次开发和使用。Kettle的中文名是“水壶”的意思,它的主程序开发者的设计思想是希望把各种数据放到一个水壶里,然后以一种格式流出,这种设计理念也确实是对于数据融合的预想。Kettle主要有两种脚本文件组成。Transformation和Job,Transformation的功能是将最小、最基本的数据进行转换,Transaction是比Job更小的组件,它定义了对数据的采集、转换、去重等具体操作。一般一个步骤(Step)是一个转换,像是表的输入、表输出等基本操作。而Job才是整个工作的控制组件,负责将一个个Transformation串联在一起,把大的任务会分解为几个Job来进行,然后将Job分解为一个或多个Transformation,每个Transformation只完成一部分的工作,Kettle数据处理体系结构如图3所示。
综上所述,数据融合的总过程流程图如图4所示。
基于上述任一实施例,所述分布式实时库管理子系统包括分布式数据库界面模块、内存库分片管理模块、邻居内存库数据对齐模块、数据采样模块和一致性更新模块;其中:
所述分布式数据库界面模块用于为用户提供交互界面和底层架构;
所述内存库分片管理模块用于提供内存库初始化功能;
所述邻居内存库数据对齐模块用于当存在内存库宕机或与邻居内存库进行数据对齐时,提供数据对齐算法;
所述数据采样模块用于每隔预设采样间隔时间内进行数据采集,并将系统的模拟信号转化为离散信号;
所述一致性更新模块用于使分布式数据库保持一致性。
具体地,系统为了提高数据处理的响应速度,提供了两套分布式系统,分布式实时库与分布式持久化库,内存库采用的是开源内存数据库Voltdb,持久化数据库采用的是关系型数据库Mysql,分布式实时库主要负责缓存实时数据,具有高并发的性能。
分布式数据库界面为用户提供了良好的交互界面,并为用户提供了底层复杂架构,使用户通过简单的可视化界面来操作数据,用户可以对内存库实时数据进行增删改查与访问持久库中数据。界面启动后会通过元数据服务器的配置管理下载本地的数据服务列表和正在运行的客户端代理列表。当分布式数据库界面想要查看内存库中数据时,若此时内存库并未启动还需要从元数据服务器下载所需要的分片配置信息和内存库初始化信息,将内存库启动。当客户端需要访问本地机器的数据库时可以直接连接即可访问数据内容。若访问远程持久化存储子系统时,客户端需要经过客户端代连接到数据所在集群,对数据进行访问,当然该部分对客户端透明,客户端只需要只读远程持久化存储子系统的地址即可连接,不关心客户端代理的操作。分布式数据库界面操作流程图如图5所示。
此外,分布式数据库界面是基于开源Coolsql实现,Coolsql是一个客户端管理工具,它支持许多数据库,例如DB2、oracle、Mysql、Microsoft SQL Server、Derby等。为用户提供了友好易懂的界面。支持Sql结果查询,支持将表导出为文本文件,Excel和HTML。还提供了收藏功能,和中英文两种语言。Coolsql开源数据库管理工具提供了基本的功能,但是不能满足本系统的所要的所有需求,因此我们对Coolsql进行了二次开发,增加了我们所需的功能,增加的功能主要有:
1、提供了连接Mysql数据库与Voltdb内存库的接口。原始数据库管理工具不支持内存库Voltdb的连接,通过更改连接方式,使其可以连接Voltdb内存库;
2、将界面左侧分为主机列表与本地配置列表,主机列表是显示集群与内存库列表,可以通过添加标签来新建内存库与历史库连接。配置管理主要是显示配置文件库,配置文件包括域名表、库名表和表名表;
3、在主机列表一列增加了刷新选择键,选中后结果集的数据会进行实时刷新并显示出来,不选中不会进行实时刷新,刷新键主要是满足我们访问内存库实时数据的支持,可以保证用户看到最新的数据;
4、菜单栏增加了创建视图功能,因为有时数据表会特别大但用户不会关心所有的字段,所以需要创建视图来显示部分列的数据;
5、结果集展示部分,当我们修改数据时数据会变色,给用户一个明显的提示,同时像是一些变化比较频繁的字段,例如监测值我们也进行了变色处理便于观察。
内存库启动时,数据库中并不保存历史数据,因此需要提供一个内存库初始化的功能,来将内存库所需要的表结构和部分数据导入数据库中。本文提供了两套分布式数据库系统,每台机器都安装内存库与持久化库两种数据库,所以初始化时一般是从本地持久化库中导入所需要的历史数据表结构与数据。该部分如果手工操作会非常复杂繁琐,所以我们设置了一个内存库初始化界面来完成数据的自动导入。需要初始化的内存库首先从元数据服务器下载所需要的分片信息,之后按照分片规则从历史数据库中导入表结构与数据,内存库初始化流程图如图6所示。
所有内存库共同构成了一个分布式的内存库架构,当有的内存库宕机时或者需要与邻居内存库中数据对齐时,此时需要数据对齐技术。若内存库宕机会向周围邻居发送一个消息,发送需要被接管数据的请求,此时邻居若接收到消息后,就根据此时宕机的内存库的分片规则从持久化库中将数据再次导入到本地内存库中,实现暂时接替邻居内存库的功能。邻居内存库数据对齐流程图如图7所示。
数据采样是指在信号系统中每隔一定时间采集一次数据值,然后将信号系统的模拟信号变为离散信号的过程称为采样过程。同样在数据处理过程中也有采样的概念,即对总体的数据进行实验时,因为效率或机制等问题无法对全部的数据进行处理,这时则需要对数据进行采样。
本发明实施例中,因实时数据量庞大且大部分数据重复较多,大量冗余数据的价值并不高,因此在数据持久化存储的时候我们对数据进行了采样,按不同规则采集数据来进行存储。
(1)平均值采样
例如对于一个传感器设备只需要输出一条数据,那么设备的检测值选择该传感器设备的所有检测值的平均进行采样。这是最简单的采样方式,但是对于一些检测值少,且变化不大的传感器类型来说,这种采样方式在通常场景下是最常用的。
(2)最大值
在一定采样周期内,获取检测值的最大值作为历史数据保存到持久化库。
(3)最小值
在一定采样周期内,获取检测值的最小值作为历史数据保存到持久化库。
采样后的数据需要传输到集群中心进行持久化存储,以便于信息共享。经过客户端代理将数据分片存储到集群数据中心分类存储。
分布式数据库保持一致性一直是分布式架构研究的重点。著名的理论CAP理论即通过定义分布式环境中一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)三者不可兼得最多实现其中两种,因为分区容错性是最基础的,所以分布式环境一般在一致性与可用性之间进行权衡,所以系统从两个方面实现了数据一致性,包括需要强一致性的部分和弱一致性的部分。在系统中设计了MessageReceiver组件,每个集群都安装该组件,MessageReceiver通过发布订阅来订阅消息并缓存到内存库中,每个机器上订阅的消息不同缓存的消息也不同,若两个集群订阅主题相同则获取的数据将完全一致,即可保证初始化时数据的强一致性。订阅消息格式如图8所示,其中topic标签中定义的主题即与自身相关,topic相同的MessageReceiver将会收到相同的是数据。Values标签中即实际传输的数据,数据将以子标签的形式在里面定义,包括字段名,数据类型,数据值。
若用户通过分布式数据库界面对某一台内存库的数据进行了修改,此时分布式内存库界面会向邻居内存库广播该条数据,与该内存库订阅主题相同的邻居内存库进行接收到广播消息后会自动将更新到库里,以此来保证更新后的数据一致性。通过两种机制共同保证分布式内存库的数据一致性。因为广播会有延迟,所以数据的更新可能不会非常及时但因为是对于物联网中感知数据的实时存储,所以数据刷新非常频繁,所以几条数据的丢失不会对系统造成大的损失,因此最终会实现数据的弱一致性。
基于上述任一实施例,所述客户端代理子系统包括数据切分路由模块、报告心跳模块和更新路由状态模块;其中:
所述数据切分路由模块用于将不同集群数据库的结果合并或将数据路由到不同集群;
所述报告心跳模块用于按照预设报告间隔向元数据服务器发送心跳信息;
所述更新路由状态模块用于实时更新数据路由状态。
具体地,客户端代理位于上层用户与持久化存储子系统之间,实际上相当于一个sql路由,具有读写分离,负载均衡,数据切片和并发请求等多种功能,同时负责将不同集群数据库的结果进行合并或将数据路由到不同集群。底层的数据对于上层客户端而言是透明的,用户访问集群时需要经过客户端代理,但不需要了解其运行原理。客户端代理需要定期向元数据服务器发送心跳信息以证明自己正常运行,若一定时间元数据服务器没有收到客户端代理的心跳信息那么就认为它宕机了,将它从客户端代理列表中删除。客户端代理的流程图如图9所示。
客户端代理是多源传感器历史数据最终存入持久化存储子系统的接口,但是单个中心代理难以负载所有数据的压力,因此客户端代理进行了水平切分,不同类型数据通过不同客户端代理接入持久化存储子系统。例如水力遥感数据,城市自来水的质量检测数据通过客户端代理1路由数据,河流污染监测数据通过客户端代理2路由数据。
本发明实施例中客户端代理采用Mycat服务,Mycat是一个面向企业级应用的大型数据库集群,能够满足数据库数据的大量存储,分散单机负载,保障负载均衡,提高查询性能。它支持事务、ACID,可以用来代替昂贵的Oracle集群。Mycat的核心技术即通过某种特定的条件将我们存放在数据库中的数据分散存储在不同物理数据中心,以完成分布式存储的目的,如图10所示的Mycat切片模式。
基于上述任一实施例,所述持久化存储子系统包括持久化数据存储模块、读写分离模块、主从备份模块和异地灾备模块;其中:
所述持久化数据存储模块用于通过内存库和持久化库提供不间断数据服务;
所述读写分离模块用于采用主节点完成写操作,从节点完成读操作;
所述主从备份模块用于使所述主节点的数据库和所述从节点的数据库保持自动同步;
所述异地灾备模块用于在同一集群中采用同城双活及异地灾备的灾难恢复策略。
具体地,持久化存储子系统作为承载所有最终历史数据的基础设施,承担稳定运行的重任,需要提供不间断的服务,集群功能架构如图11所示。在数据持久化存储方面不同数据通过客户端代理存储不同的持久化存储子系统,因此数据库表需要划分片键,客户端代理根据片键划分水平切割数据库表。
因为在物联网平台下,持久化存储后的数据一般是写少读多,此时数据库读会成为数据库访问的瓶颈,而在分布式系统中,响应速度却是非常重要的性能,因此我们采用了读写分离架构来提升数据库的读性能,一个集群采用一写两读架构模式,写操作有Master节点完成,读操作由Slave节点完成,降低了单数据节点的存取压力,提升了数据读取速度。为了保证数据的读写一致我们在读写分离的基础上配置了主从备份,主从备份即保持两个数据库状态的自动同步,对一个数据库的每一步操作都自动移动到另一台数据库上,数据写操作时写入Master库,然后其余两台Slave会进行自动同步。
本发明实施例采取了一主两从的架构模式,如果运行过程中Master宕机则需要从其他两台Slave机器中选取出一台作为Master,若两台Slave中的其中一个宕机均不影响系统的正常运行。提高了系统的稳定性与可靠性,同时将来自客户端的请求分散负担到三台机器上,对网络吞吐量也有一定提升。
为了进一步提升系统的可靠性,采用了“同城双活+异地灾备”的灾难恢复解决方案,即同一集群共三个备份,同城两个,异地一个。可以满足不同灾难场景下的业务连续请求。该措施主要是用于防范机房灾难,异地灾备主要防范大范围区域内灾难。以此来实现数据的双重保护,确保数据的完整性。
基于上述任一实施例,所述元数据服务器子系统包括检测集群磁盘占用情况模块、实时库分片信息管理模块、监控代理路由状态模块和后台配置修改自动更新模块;其中:
所述检测集群磁盘占用情况模块用于检测所述持久化存储子系统中集群的磁盘使用情况;
所述实时库分片信息管理模块用于监测所述客户端代理子系统的路由状态;
所述后台配置修改自动更新模块用于运维人员进行查看后台配置信息并修改更新所述后台配置信息。
具体地,元数据服务器架构在本系统中充当着中心管理者的角色,负责统筹管理客户端代理,检测持久化存储子系统磁盘使用情况,管理分布式内存库分片配置信息,管理持久化库基本信息等主要功能,具体功能架构如图12所示。
当内存库启动时,需要加载初始化信息,也需要从元数据服务器拉取分片配置信息,从而初始化数据库。元数据服务器还管理持久化库的基本信息,包括对集群分类归为不同席位,不同席位的集群有着不同的功能。同时客户端代理需要定期向元数据服务器发送心跳信息,而元数据服务器则可以列出正在运行的客户端代理列表,若一定时间没有收到该代理的心跳信息,那么将其从代理列表中删除。所以用户就不会通过该客户端代理来访问持久化存储子系统。元数据服务器负责监控集群磁盘的使用情况,方便重新划分分片规则,便于负载均。元数据服务器流程图如图13所示。
基于上述任一实施例,还包括:系统功能测试、系统性能测试和系统可靠性测试。
其中,所述系统功能测试包括分布式数据库界面测试、分布式实时库管理测试、数据融合平台测试、元数据服务器测试、客户端代理测试和分布式持久化存
其中,所述系统性能测试包括单节点性能测试和集群性能测试。
具体地,为了验证系统的可用性,需要对系统的功能与性能进行了详细测试。
首先,需要搭建三个集群,每个集群上有三台机器,使用了三台pc和pc上的两台虚拟机进行测试。为了方便配置,使用交换机配置了网段192.168.101.0,所有机器都在同一网络下。主机作为Master,两台虚拟机作为Slave,Master与Slave上都安装了关系型数据库Mysql与内存库Voltdb。Mysql数据库在Master与Slave之间配置主从备份,Master上的Mysql数据库为主,Slave上的数据库为从,可进行数据间的同步。
其次,为了验证Mycat客户端代理的性能,分别在集群一与集群三的Master上共安装了两个Mycat,集群一的Mycat对集群一、集群二、集群三的数据库进行管理,集群三Master的Mycat对集群二与集群三数据库表进行管理,同时配置了读写分离,每个集群的Master负责写操作,两个Slave负责读操作,降低了单节点的压力,共同承担集群的负载均衡。对于集群中三台主机与六台虚拟机的硬件环境如表2所示,安装的软件环境包括操作系统和系统运行所需要的环境如表3所示。
表2
主机处理器 Intel(R)Core(TM)i5
主机系统内存 16G
主机系统硬盘 500G
虚拟机 Vmware Workstation
虚拟机安装系统 Centos 6.8
虚拟机内存 2G
虚拟机硬盘 20G
表3
Figure BDA0002441171760000171
在此基础上,本发明实施例从六大部分进行系统测试:
(1)分布式数据库界面测试,测试客户端是否可以正常运行,可连接Mysql与Voltdb,并能够实现管理数据库的基本功能增删改查,实现实时刷新,显示部分数据,更新后向邻居内存库广播数据,以及从元数据服务器下载配置信息,测试结果如表4所示:
表4
Figure BDA0002441171760000172
Figure BDA0002441171760000181
(2)数据融合平台测试,测试发布订阅可正常接收消息,数据格式化转换部分正常运行,处理后数据传输到内存库,测试结果如表5所示:
表5
Figure BDA0002441171760000182
Figure BDA0002441171760000191
(3)分布式实时库管理子系统测试,测试内存库分片管理、邻居内存库数据对齐、数据采样是否正常运行,测试结果如表6至表8所示:
表6
Figure BDA0002441171760000192
表7
Figure BDA0002441171760000193
Figure BDA0002441171760000201
表8
Figure BDA0002441171760000202
(4)元数据服务器测试,测试元数据服务器四大功能正常运行,可接收Mycat心跳并更新Mycat列表并推送配置文件到Mycat,可显示集群磁盘空间使用情况,可初始化内存库,可对数据库服务器与内存库进行配置,并将配置信息推送到分布式数据库界面,测试结果如表9所示:
表9
Figure BDA0002441171760000203
Figure BDA0002441171760000211
(5)客户端代理测试,测试客户端代理服务正常启动,可接收元数据服务,测试结果如表10所示:
表10
Figure BDA0002441171760000212
Figure BDA0002441171760000221
(6)集群中心测试,测试集群正常稳定运行,元数据服务器可监测集群中心的磁盘占用情况,实现读写分离,主从备份,异地灾备,测试结果如表11所示:
表11
Figure BDA0002441171760000222
Figure BDA0002441171760000231
在完成上述功能测试后,还需要对系统进行性能测试,包括单节点性能测试和集群性能测试。
分析单节点在面对不同数据量时的处理性能是否能够满足需求,即在处理的数据增加时,其计算效率是否也能保持增长。主要测试为,Voltdb与Mysql数据库的数据访问性能,测试单独读写QPS(每秒查询率QPS),测试单独查询QPS,更新QPS。
对于集群的性能测试,主要是测试客户端代理的性能,使用的Mycat自带的基准性能测试工具,分片表插入性能测试、分片表查询性能测试、更新性能测试、全局表插入性能测试等基准测试工具。分片表的性能取决于物理机的个数,在本次试验中我们共使用了六台物理机,并设置了读写分离,其中三台用于写操纵,另外三台用于读操作。测试用表为lora_telemetry。分片规则是按列“ISN_ID”分片,“ISN_ID”为“102”,“108”分到一台物理机,“10E”,“112”分到一台物理机,其他分到最后一台物理机。
经过对Mycat的测试,得出如下结论:
1.比较单台数据库,系统使用分布式Mycat后集群响应时间明显低于单台单库的响应时间,而且随着数据量增长,分布式集群响应时间基本不变,而单台单库数据库响应能力却下降比较大,所以使用分布式模式,集群的性能得到了极大提高;
2.对于单台数据库的存储情况,查询性能随着数据量呈负增长;
3.Mycat管理下的Mysql实例越多,性能提升越大。
最后,进行系统可靠性测试,分布式数据库界面数据实时接收情况与Mysql存储情况,每天的数据更新量在50万-65万之间,Voltdb处理量在25万-30万之间,在此数据量的情况下,数据能够接收正常,转化与存储。同时集群为数据的可靠性配置了完整的策略,集群通过元数据服务器进行统筹管理,元数据服务器会定时向所有Mycat发送心跳检测,如果一定时间内未收到Mycat的心跳响应,那么元数据服务器就将该Mycat从Mycat列表中删去,该Mycat被标记为不可用,在分发数据任务时,不可用的节点将不再考虑。这种机制可以保障定期删除失效或宕机的Mycat,避免资源的浪费。
若执行任务期间,数据节点产生了宕机的情况,集群配置了主从备份,若宕机的是Slave,那么集群继续运行,若宕机的是Master,集群可以快速检测并从其Slave中选举出一个Master保证任务的重新执行。若整个集群发生灾难性灾害时,配置了异地灾备也能保证数据不丢失,最大程度的保障了数据的可靠性。以上证明该系统的可靠性比较高,可以满足持续运行与数据的可靠。
以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (9)

1.一种基于物联网平台的分布式数据融合管理系统,其特征在于,包括:数据融合平台子系统、分布式实时库管理子系统、客户端代理子系统、持久化存储子系统和元数据服务器子系统;其中:
所述数据融合平台子系统用于将多源传感器采集的不同格式数据进行统一转化处理,并将处理后的数据缓存至本地的内存库中;
所述分布式实时库管理子系统用于对所述内存库进行分片启动、部署、管理和邻居内存数据库数据对齐,实现一致性更新,并提供分布式数据库界面进行操作;
所述客户端代理子系统用于向分布式架构提供中间路由来管理分布在不同物理地点的数据节点;
所述持久化存储子系统用于将所述内存库中的数据经采样后,进行持久化存储至集群中;
所述元数据服务器子系统用于管理整个分布式数据融合管理系统,并监控系统所有节点和提供配置信息下载。
2.根据权利要求1所述的基于物联网平台的分布式数据融合管理系统,其特征在于,所述数据融合平台子系统包括数据采集模块、数据格式转化模块和数据传输模块;其中:
所述数据采集模块用于负责采集不同来源的数据;
所述数据格式转化模块用于将采集到的不同格式数据统一转换为结构化表格式,并处理数据同义异名和数据同名异义问题;
所述数据传输模块用于将所述数据采集模块采集的数据传输到持久化库。
3.根据权利要求1所述的基于物联网平台的分布式数据融合管理系统,其特征在于,所述分布式实时库管理子系统包括分布式数据库界面模块、内存库分片管理模块、邻居内存库数据对齐模块、数据采样模块和一致性更新模块;其中:
所述分布式数据库界面模块用于为用户提供交互界面和底层架构;
所述内存库分片管理模块用于提供内存库初始化功能;
所述邻居内存库数据对齐模块用于当存在内存库宕机或与邻居内存库进行数据对齐时,提供数据对齐算法;
所述数据采样模块用于每隔预设采样间隔时间内进行数据采集,并将系统的模拟信号转化为离散信号;
所述一致性更新模块用于使分布式数据库保持一致性。
4.根据权利要求1所述的基于物联网平台的分布式数据融合管理系统,其特征在于,所述客户端代理子系统包括数据切分路由模块、报告心跳模块和更新路由状态模块;其中:
所述数据切分路由模块用于将不同集群数据库的结果合并或将数据路由到不同集群;
所述报告心跳模块用于按照预设报告间隔向元数据服务器发送心跳信息;
所述更新路由状态模块用于实时更新数据路由状态。
5.根据权利要求1所述的基于物联网平台的分布式数据融合管理系统,其特征在于,所述持久化存储子系统包括持久化数据存储模块、读写分离模块、主从备份模块和异地灾备模块;其中:
所述持久化数据存储模块用于通过内存库和持久化库提供不间断数据服务;
所述读写分离模块用于采用主节点完成写操作,从节点完成读操作;
所述主从备份模块用于使所述主节点的数据库和所述从节点的数据库保持自动同步;
所述异地灾备模块用于在同一集群中采用同城双活及异地灾备的灾难恢复策略。
6.根据权利要求1所述的基于物联网平台的分布式数据融合管理系统,其特征在于,所述元数据服务器子系统包括检测集群磁盘占用情况模块、实时库分片信息管理模块、监控代理路由状态模块和后台配置修改自动更新模块;其中:
所述检测集群磁盘占用情况模块用于检测所述持久化存储子系统中集群的磁盘使用情况;
所述实时库分片信息管理模块用于监测所述客户端代理子系统的路由状态;
所述后台配置修改自动更新模块用于运维人员进行查看后台配置信息并修改更新所述后台配置信息。
7.根据权利要求1所述的基于物联网平台的分布式数据融合管理系统,其特征在于,还包括:系统功能测试、系统性能测试和系统可靠性测试。
8.根据权利要求7所述的基于物联网平台的分布式数据融合管理系统,其特征在于,所述系统功能测试包括分布式数据库界面测试、分布式实时库管理测试、数据融合平台测试、元数据服务器测试、客户端代理测试和分布式持久化存储测试。
9.根据权利要求7所述的基于物联网平台的分布式数据融合管理系统,其特征在于,所述系统性能测试包括单节点性能测试和集群性能测试。
CN202010265594.4A 2020-04-07 2020-04-07 一种基于物联网平台的分布式数据融合管理系统 Pending CN111639114A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010265594.4A CN111639114A (zh) 2020-04-07 2020-04-07 一种基于物联网平台的分布式数据融合管理系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010265594.4A CN111639114A (zh) 2020-04-07 2020-04-07 一种基于物联网平台的分布式数据融合管理系统

Publications (1)

Publication Number Publication Date
CN111639114A true CN111639114A (zh) 2020-09-08

Family

ID=72329397

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010265594.4A Pending CN111639114A (zh) 2020-04-07 2020-04-07 一种基于物联网平台的分布式数据融合管理系统

Country Status (1)

Country Link
CN (1) CN111639114A (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112131245A (zh) * 2020-09-23 2020-12-25 华东计算技术研究所(中国电子科技集团公司第三十二研究所) 拟态防御架构的高性能数据访问系统及方法
CN112307064A (zh) * 2020-10-29 2021-02-02 上海达梦数据库有限公司 一种数据管理系统、方法及存储介质
CN112650630A (zh) * 2020-12-31 2021-04-13 广州技象科技有限公司 一种智能电表运行参数的分布式备份方法及装置
CN112866366A (zh) * 2021-01-12 2021-05-28 航天科工智能运筹与信息安全研究院(武汉)有限公司 数据感知融合方法和装置
CN113177036A (zh) * 2021-04-14 2021-07-27 中国电力工程顾问集团中南电力设计院有限公司 一种监测数据的存储方法、查询方法、显示方法
CN113515499A (zh) * 2021-03-25 2021-10-19 中国雄安集团数字城市科技有限公司 一种数据库服务方法及系统
CN114172918A (zh) * 2021-12-08 2022-03-11 天翼物联科技有限公司 数据同步方法、装置、计算机设备及存储介质
CN114827140A (zh) * 2022-04-02 2022-07-29 中国兵器装备集团自动化研究所有限公司 一种用于风洞现场的实时数据集中管控系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101577735A (zh) * 2009-06-24 2009-11-11 成都市华为赛门铁克科技有限公司 一种接管故障元数据服务器的方法、装置及系统
CN110442814A (zh) * 2019-06-19 2019-11-12 中国电力科学研究院有限公司 一种泛在电力物联网智能终端的数据交互系统及方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101577735A (zh) * 2009-06-24 2009-11-11 成都市华为赛门铁克科技有限公司 一种接管故障元数据服务器的方法、装置及系统
CN110442814A (zh) * 2019-06-19 2019-11-12 中国电力科学研究院有限公司 一种泛在电力物联网智能终端的数据交互系统及方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
殷齐林: ""物联网服务平台中分布式数据存储方案的设计与实现"" *
陈小杰: ""物联网服务平台中的分布式数据服务的研究与实现"" *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112131245A (zh) * 2020-09-23 2020-12-25 华东计算技术研究所(中国电子科技集团公司第三十二研究所) 拟态防御架构的高性能数据访问系统及方法
CN112307064A (zh) * 2020-10-29 2021-02-02 上海达梦数据库有限公司 一种数据管理系统、方法及存储介质
CN112650630A (zh) * 2020-12-31 2021-04-13 广州技象科技有限公司 一种智能电表运行参数的分布式备份方法及装置
CN112866366A (zh) * 2021-01-12 2021-05-28 航天科工智能运筹与信息安全研究院(武汉)有限公司 数据感知融合方法和装置
CN113515499A (zh) * 2021-03-25 2021-10-19 中国雄安集团数字城市科技有限公司 一种数据库服务方法及系统
CN113515499B (zh) * 2021-03-25 2023-04-28 中国雄安集团数字城市科技有限公司 一种数据库服务方法及系统
CN113177036A (zh) * 2021-04-14 2021-07-27 中国电力工程顾问集团中南电力设计院有限公司 一种监测数据的存储方法、查询方法、显示方法
CN114172918A (zh) * 2021-12-08 2022-03-11 天翼物联科技有限公司 数据同步方法、装置、计算机设备及存储介质
CN114172918B (zh) * 2021-12-08 2023-08-01 天翼物联科技有限公司 数据同步方法、装置、计算机设备及存储介质
CN114827140A (zh) * 2022-04-02 2022-07-29 中国兵器装备集团自动化研究所有限公司 一种用于风洞现场的实时数据集中管控系统

Similar Documents

Publication Publication Date Title
CN111639114A (zh) 一种基于物联网平台的分布式数据融合管理系统
CN111723160B (zh) 一种多源异构增量数据同步方法及系统
EP3077917B1 (en) Distributing data on distributed storage systems
CN102770849B (zh) 当应用基于用户的安全性时优化数据高速缓存
CN101645032B (zh) 应用服务器的性能分析方法和应用服务器
CN107180113B (zh) 一种大数据检索平台
CN112148718A (zh) 一种用于城市级数据中台的大数据支撑管理系统
CN102937964B (zh) 基于分布式系统的智能数据服务方法
CN103440290A (zh) 大数据加载系统和方法
CN104239377A (zh) 跨平台的数据检索方法及装置
Naheman et al. Review of NoSQL databases and performance testing on HBase
CN110008272B (zh) 面向传感器数据的NoSQL数据库评测系统及其构建方法
CN112148578A (zh) 基于机器学习的it故障缺陷预测方法
US20160041859A1 (en) Synchronization testing of active clustered servers
Bellini et al. Data flow management and visual analytic for big data smart city/IOT
KR20220052654A (ko) 메시지 전송 버스를 이용한 고가용성 배전 지능화 시스템 및 지능화 클러스터 시스템
CN112100160B (zh) 一种基于Elastic Search的双活实时数据仓库建设方法
CN115391361A (zh) 一种基于分布式数据库的实时数据处理方法及其装置
CN114020819A (zh) 一种多系统参数同步方法及装置
CN117111856A (zh) 一种数据湖数据处理方法、装置、系统、设备及介质
CN111414355A (zh) 一种海上风电场数据监测存储系统及方法、装置
CN115168474B (zh) 一种基于大数据模型的物联中台系统搭建方法
CN115391286A (zh) 一种链路追踪数据管理方法、装置、设备及存储介质
CN115238006A (zh) 检索数据同步方法、装置、设备及计算机存储介质
CN114003580A (zh) 一种运用于分布式调度系统的数据库构建方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20200908