CN115309789A - 一种基于业务对象智能动态化实时生成关联数据图的方法 - Google Patents
一种基于业务对象智能动态化实时生成关联数据图的方法 Download PDFInfo
- Publication number
- CN115309789A CN115309789A CN202211237745.0A CN202211237745A CN115309789A CN 115309789 A CN115309789 A CN 115309789A CN 202211237745 A CN202211237745 A CN 202211237745A CN 115309789 A CN115309789 A CN 115309789A
- Authority
- CN
- China
- Prior art keywords
- data
- association
- graph
- real time
- real
- 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.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/242—Query formulation
- G06F16/2433—Query languages
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/901—Indexing; Data structures therefor; Storage structures
- G06F16/9024—Graphs; Linked lists
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Mathematical Physics (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种基于业务对象智能动态化实时生成关联数据图的方法,包括以下步骤:数据实时入湖,并通过存储组件进行存储;创建入湖数据触发器;实时从mq组件中读取增量数据,提取关键信息;提取关键信息形成数据体,使用图数据库存储数据之间的关联关系;利用实时技术及时获取变动的数据;实时变动数据,通过数据关联关系正向快速查询形成关联关系图;通过数据关联关系反向快速查询形成关联关系图。本发明通过触发器提出可用于创建关联关系的结构化数据,对结构化数据利用关联关系分析算法与存量数据进行关联分析,通过查询某一个数据,可以很快的根据数据的关联关系绘制数据关联的知识图谱,可方便快捷的为业务提供有用的数据。
Description
技术领域
本发明涉及大数据技术领域,具体来说,涉及一种基于业务对象智能动态化实时生成关联数据图的方法。
背景技术
在云原生大数据成熟技术的支撑下,数据也迎来了暴发式的增涨,数据的来源多种多样,数据存储量越来越大,同时数据的形式也更碎片化,数据间的关系也越来越复杂,如何在大数据量中快速找出数据间的关联关系,快速形成基于有价值的业务数据,当前技术主要存在以下问题:
1)在数据量大的场景中,查询语句spl(结构化查询语句)使用大量的关联操作会有巨大的性能损失,因为数据本身是被存放在指定的地方,查询本身只需要用到部分数据,但是关联操作本身会遍历整个数据库,这样就会导致查询效率低到让人无法接受,当超过5层以上的关联时,会导致无法获取关联的数据问题情况;
2)在大数据量下,反向查询如:反向查询一个员工的老板,需要通过员工的工号反查所在组织及其组织的负责人,再层层往上追查,最终找到最上层的关系,其间需要很多次的递归查询,非常消耗性能,无法快速查询到有关联的人与组织;
3)索引是可以加速查询的效率,如常见的索引包括B-树索引和哈希索引,B-树索引简单地来说就是给每个人一个可排序的独立ID,B-树本身是一个平衡多叉搜索树,这个树会将每个元素按照索引ID进行排序,从而支持范围查找,范围查找的复杂度是O(logN),其中N是索引的文件数目。但是索引并不能解决所有的问题,如果文件更新频繁或者有很多重复的元素,就会导致很大的空间损耗,此外索引的IO消耗也值得考虑,索引IO尤其是在机械硬盘上的IO读写性能上来说非常不理想,常规的B-树索引消耗四次IO随机读,当关联操作变得越来越多时,硬盘查找更可能发生上百次;
4)众多的相互有关系的大表中,基于某一条数据在多个大表中找到相关联的数据,需要通过多次的spl查询或多次的关联操作,耗时一般都需要10s及以上,对于部分过亿的大表关联时,还会出现内存溢出的情况,导致无法看到关联的数据;
5)目前大部分的操作都是人找数,特别是在继续查询相关的数据时,需要靠人的记忆层层关联往下找,耗时时间长,对数据使用人员非常的不友好,没有进行数据使用习惯的关联推荐,也没有对数据相关性进行推荐使用;
6)数据实时都是在发生地变化,数据很多时候因为没有实时更新关系,导致数据使用结果需要第二天或更长的时间才被发现或重新使用。
在万物互联的时代,各行各业、各类设备和应用都在不间断产生大量数据,数据的海量与多元化决定了从数据中获取有用的价值或有问题的数据变得越来越困难,如果无法从数据中获得益处或发现数据的问题,那么数据价值与问题发现就无从谈起。数据价值与问题的发现同数据处理、数据的关联关系创建有必然的联系,从海量与多元化的数据中建立数据的关系网,对获取有用或有问题的数据更加方便与容易,可以更好的协助数据价值的兑现与数据问题的发现。如下的场景:
场景一
在数仓建设过程中,需要对分层的数据进行跟踪分析,找出有问题的数据,如数据分层建仓的过程有:
1)明细数据有3条数据:id=1 pkey=101,score=90,org=1、id=2,pkey=101,score=20,org=1、id=3 pkey=101,score=70,org=2;
2)汇聚数据可多个维度如pkey维度:(pkey=101 score=180 avg=60),pkey,org维度:pkey=101,score=180,avg=70,org=2,pkey=101,score=180,avg=110 org=;
3)应用:pkey,org维度进数据关联时进行分析时,如pkey=101 score=180 avg=60对影响平均值的分数低的数据进行问题跟进分析;
实现此业务场景的现有的技术主要有:
1)利用关系型数据库如Mysql,oracle,Greenplum等进行关系表的设计,如明细表dwd_scores,并指定主键ID与外键(pkey,org),汇聚表设计为:dws_amount,按不同的维度(如pkey字段)进行汇聚数据,统计出:pkey=101 score=180 avg=60,根据score=180的值往下分析,查询到明细发现id=2 score=20;
2)利用Nosql列式数据如(Cassandra、HBase),进k-v表示数据之间的联系,一些属性值引用了数据库中其他聚合数据,聚合存储只是以内嵌映射结构的方式装饰在聚合数据之内,如:k=101 value=180 ids=(id=1,id=2,id=3);再通过ids中的key去查询明细,然后在内存中进行分批分析;
场景二
在社交关系中找某人的朋友的朋友们,实现方式:
1)通过关系型数据库对朋友关系的建模,创建Person(人员管理表),PersonFriends(人员的朋友管理表),查询朋友的朋友们的sql如下,需要进行多层的sql嵌套与关联:
SELECT p1.Person from Person p1 join(
SELECT p5.FriendID from PersonFriends p5 join
(SELECT p3.FriendID from Person p2 join PersonFriend p3 on p2.ID=p3.PersonID
WHERE p2.Person=’xxx’) p4 on p4.FriendID=p5.PersonID
)t6 on p1.ID=p6.FriendID
可以看到只是查询三度人脉的时候,sql查询语句已经开始非常复杂,而查询过程的复杂度也变得很高、查询效率开始恶化。
现有的技术为满足关联关系的实时创建与关系的秒级分析查询的能力,大多依赖不同类型数据库自身的处理能力以及事先设计好的关联关系,对海量多元数据下创建关联关系及秒级的关联关系分析存在以下的问题:
1)通过关系型数据库创建关联关系时,通常需要明确表与表之间的主外键的关系或字段名一致的隐含关系来实现关联,都是需要在设计时候指定关系,数据实时动态变化的时候无法实时识别数据之间的关联关系;
2)在关系型数据库中创建关系时,一旦关联的表的主键发生变更,需要轮询修改此主键关联的所有的外键或相同字段的值,耗时非常较长,关联表多的时候,有可能存在漏修改的情况,同时新增与删除表时候,需要同步修改关联的逻辑,耗费比较多的成本;
3)通过一个数据查询层层下钻查询找到最细力度的明细数据时,需要关联各种类型的大表,查询耗费的时间成本高,对多个大表join(关联)操作需要的计算资源也很多,执行的成本高;
4)实现数据的关联分析与查询时,通常通过设计关系型数据库的模型,如维度建模、星型模型等,合理利用主外键关联多表进行较深层次的数据分析,但对于过亿的大数据,如深度为3时,关系型数据库的响应时间30s,对数据使用的体验效果变得较差;当深度到4时,关系数据库需要近半个小时才能返回结果,对于在线数据处理系统影响较大,会导致无法使用;深度到5时,关系型数据库已经掉入深渊;
5)对于数据相关性的分析,主要靠人工维护,比如A用户使用数据集S1,也使用数据集S2,两者联合一起分析可以达到比较分析效果,用户B在使用数据集S1的时候,由于没有相关性的分析,也需要重新人工配置,当这样诉求较多,人工配置数据相关性的工作量越来越大,有些数据的关联关系人工也难以发现,不能很好的支撑数据的应用。
针对相关技术中的问题,目前尚未提出有效的解决方案。
发明内容
针对相关技术中的问题,本发明提出一种基于业务对象智能动态化实时生成关联数据图的方法,以克服现有相关技术所存在的上述技术问题。
为此,本发明采用的具体技术方案如下:
一种基于业务对象智能动态化实时生成关联数据图的方法,该方法包括以下步骤:
S1、通过实时或批量入湖的采集,将结构化、半结构及非结构化的数据实时入湖,并通过存储组件进行存储;
S2、创建入湖数据触发器,实时抓取入源的数据,并将数据按预设的格式存储至mq组件中;
S3、通过部署实时计算程序,实时从mq组件中读取增量数据,并对增量数据进行预处理,提取关键信息;
S4、将提取关键信息形成数据体,并基于数据体进行数据的关联关系分析;
S5、根据数据的关联关系找到对应的元数据及属性相关的数据,并使用图数据库存储数据之间的关联关系;
S6、利用实时技术及时获取变动的数据,并对数据进行联动分析;
S7、实时变动数据,并利用图数据库对变动的数据进行更新存储;
S8、通过数据关联关系正向快速查询形成关联关系图;
S9、通过数据关联关系反向快速查询形成关联关系图。
进一步的,所述存储组件包括Hudi存储组件和Ozone存储组件;
其中,所述Hudi存储组件用于存储结构化和半结构数据;
所述Ozone存储组件用于存储非结构与部分类型的半结构化数据;
进一步的,所述S3通过部署实时计算程序,实时从mq组件中读取增量数据,并对增量数据进行预处理,提取关键信息包括以下步骤:
S31、实时监听并逐条读取或小批次的读取增量数据;
S32、对读取到的增量数据进行数据格式的转换;
S33、在格式转换后,构建一张内存的表;
S34、通过sql语句对数据过滤;
S35、生成以表记录形式为主的数据体,并在内存中进行存储。
进一步的,所述S4中将提取关键信息形成数据体,并基于数据体进行数据的关联关系分析通过关联关系分析算法进行数据的关联关系识别。
进一步的,所述S5中根据数据的关联关系找到对应的元数据及属性相关的数据,并使用图数据库存储数据之间的关联关系包括以下步骤:
S51、根据当前的所述数据体,创建点的数据,所述点的数据包括点与标签;
S52、创建点的属性;
S53、创建数据的关联关系。
进一步的,所述S6利用实时技术及时获取变动的数据,并对数据进行联动分析包括以下步骤:
S61、利用实时技术实时抓取数据;
S62、将抓取的实时数据与历史的数据进行结合并利用关联关系分析算法重新分析;
S63、分析出当前实时数据与历史数据新的关联关系;
S64、加载数据现有的关联关系,同新的关联关系对比,找出不一样的关联关系;
S65、将不在新的关联关系中的数据进行删除;
S66、更新数据,所述数据包括节点、属性及新增的关联关系数据。
进一步的,所述S7中利用图数据库对变动的数据进行更新存储包括以下步骤:
S71、通过变动的数据体,利用图数据库的查询语句定位到要更新的数据;
S72、根据定位的数据,并通过set语句修改数据对应的属性数据;
S73、根据新的关联关系对点的关联关系进行更新。
进一步的,所述S8中通过数据关联关系正向快速查询形成关联关系图包括以下步骤:
S81、对数据本身以及元数据相关信息进行查询;
S82、对查询的数据关联出与数据相关的数据;
S83、基于关联出的数据进行数据的知识图谱绘制,并形成数据下上游的数据与数据间的关联关系图。
进一步的,所述S9中通过数据关联关系反向快速查询形成关联关系图包括以下步骤:
S91、通过关联关系最尾端的数据查询与其关联的上游数据;
S92、以上游的数据作为当前数据遍历其上游的数据;
S93、通过反向查询生成从下至上的数据关联关系图谱,并形成数据下上游的数据与数据间的关联关系图。
进一步的,所述实时技术包括flink技术或sparkstreaming技术中的至少一种。
本发明的有益效果为:
1、本发明实现在入湖的海量数据中建立数据的关联关系,通过识别库表元数据的关联关系、数据操作过程的关联关系、数据的依赖关系、数据关联关系算法找到数据的附属关系、以及数据实时变化等来建立点、边以及点属性的图形关系,通过创建好的图形的关系,并且可以动态维护图形关系,保障关联关系及时性;从数据出发,可以快速从过亿大数据中查询相关的数据,同时从关联数据的任一位置出发,可以在秒级内反查上下游相关的数据,在过亿的数据中关联5层及以上的关联操作也可以经轻松的秒级返回数据,同时通过智能的关联关系可以轻松的实现数据找人的能力。
2、本发明可以将原本数据湖中碎片化的数据,构建成有用的数据关联关系图,在数据入湖的时候,通过触发器提出可用于创建关联关系的结构化数据,对结构化数据利用关联关系分析算法与存量数据进行关联分析,计算出刚入湖的数据与存量的数据的关联关系,再通过图数据库存储数据以及数据之间的关系,当数据关系创建后,将数据湖中原本碎片化的数据,整理成一张相互有关系的关联关系大图,在业务使用的时候,通过查询某一个数据,可以很快的根据数据的关联关系绘制数据关联的知识图谱,可方便快捷的为业务提供有用的数据。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法的流程图;
图2是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法中数据关联分析全程图;
图3是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法中实时变动数据关系更新流程;
图4是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法中表的增量数据存储格式;
图5是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法中表的触发器处理逻辑;
图6是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法中数据关联关系计算过程图;
图7是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法中数据存储的关联关系图;
图8是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法中数据体的存储内容;
图9是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法中数据写入过程图;
图10是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法中变动数据获取过程图;
图11是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法中实时变动数据关系更新流程;
图12是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法中图数据关联关系正向查询过程图;
图13是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法中图数据关联关系反向查询过程图;
图14是根据本发明实施例的一种基于业务对象智能动态化实时生成关联数据图的方法中数据存储的关联关系图。
具体实施方式
为进一步说明各实施例,本发明提供有附图,这些附图为本发明揭露内容的一部分,其主要用以说明实施例,并可配合说明书的相关描述来解释实施例的运作原理,配合参考这些内容,本领域普通技术人员应能理解其他可能的实施方式以及本发明的优点,图中的组件并未按比例绘制,而类似的组件符号通常用来表示类似的组件。
根据本发明的实施例,提供了一种基于业务对象智能动态化实时生成关联数据图的方法。
现结合附图和具体实施方式对本发明进一步说明,如图1所示,根据本发明实施例的基于业务对象智能动态化实时生成关联数据图的方法,该方法包括以下步骤:
S1、通过实时或批量入湖的采集,将结构化、半结构及非结构化的数据实时入湖,并通过存储组件进行存储;
具体的,数据的格式主要有结构化、半结构及非结构化,数据采集入湖时,会统一存储各种格式的数据,入湖的数据都是单个的个体存在,直接使用时,由于数据无关联关系,无法将相关的数据作为整体进行业务活动的分析,这样无法高效发挥数据的价值,可以通过数据治理的清洗、整合等过程来创建数据间的关联关系,但在数据量大的时候数据治理往往花费较长的时间,投入人力成本高,更新不及时,无法实时提供关联数据快速使用的能力,为实现以上的目标,可通过如图2所示的步骤进行实现;
其中,结构化的数据:主要以库表形式的格式数据为主,如以下的样例数据(字段:值):offer_id:1,offer_name:xx,offer_desc:”189套餐”,offer_price:189;
非结构化数据:像图片、声音、视频等等,这类信息通常无法直接知道他的内容,对以后检索非常麻烦,会创建属性标签如编号、名称、用途、位置;
半结构化数据:介于完全结构化数据与非结构之间的非关系模型的数据,有基本固定结构模式的数据,它一般是自描述的数据的结构和内容混在一起,没有明显的区分,例如日志文件、XML文档、JSON文档、Email等;
其中,所述存储组件包括Hudi存储组件和Ozone存储组件;
其中,所述Hudi存储组件用于存储结构化和半结构数据;
所述Ozone存储组件用于存储非结构与部分类型的半结构化数据;
具体的,这两个存储组件都是基于hadoop体系,数据可以相互访问,其存储实施如下:
1)Hudi能够存储实时过来的结构化或半结构化的数据,实现crud的操作,保障数据更新的实时性,其中Hudi的结构化数据存储采用库表的形式,如下的建表语句创建order订单数据表:
CREATE TABLE hudi.orders(
uuid INT,
ts INT,
num INT,
PRIMARY KEY(uuid)
) WITH ( 'connector' = 'hudi',
'table.type' = 'MERGE_ON_READ');
对于hudi的表可以实时进行insert,update,delete的操作;
2)非结构化或部分半结构化的数据利用Ozone组件,Ozone是一个分布式Key-value对象存储系统,Ozone提供给用户的语义包含Volume, Bucket和Key;
Volume:概念与账户类似,类似于用户的Home目录,建议每个用户单独创建自己的Volume,Volume只有系统管理员才可以创建和删除,是存储管理的单位,比如配额管理,Volume用来存储Bucket,一个Volume下面可以包含任意多个Bucket;
Bucket:桶的概念类似于目录,用户可以在自己所在的卷下创建任意多的桶,Bucket下存储任意多的Key和Value;
Key:概念和文件类似,每个Key在Bucket中必须唯一,可以是任意字符串,用户的数据以Key-value的形式存储在Bucket下,用户通过key来读写数据;
数据写入:通过Ozone提供的api将数据拆分存储到Ozone中;
提供结构化数据:由于非结构化的,数据没有规律,不容易建立数据关联以及查询,需要提供半结构化与非结构化的名称、关键信息主键、描述、标签名称、属性名称、日期、存储位置等结构化信息存储到Hudi中。
S2、创建入湖数据触发器,实时抓取入源的数据,并将数据按预设的格式存储至mq组件中;
具体的,由于数据有批量、实时等入湖的情况,如果没有触发器,需要到存储组件全域扫描数据,耗时长也会对存储组件的使用造成一定的影响,通过部署存储组件Hudi、Ozone的触发器插件,实时抓取入源的数据,提取有用的结构化数据,并将数据按一定的格式存储mq组件中;
通过把半结构与非结构的数据都统一提供成结构化的数据存储到Hudi中,通过对结构化的数据分析来建立数据之间的关联关系;
其中,数据在写入Hudi时,通常是原始的数据,很多是沉默数据,不具备拿来建立数据的关联关系,需要在数据写入的时候实时提取关键的数据,需要在数据写入Hudi的时候通过触发器来获取变动的数据,可以实时触发并抓取关键的信息,如图3所示,触发器的实现如下;
1)数据写入Hudi时,除了写入数据本身,还会写入一个数据变动的记录的时间点,每次变动的记录均对应一个instant_time的时间点,其存储格式如图4所示;
其中,每次的instant_time的时间点就是一次commit的操作,每次的commit操作中包括内容主要有:
Action:操作的动作,主要表明对数据操作的动作如:insert(新增)、update(更新)、delete(删除)、cleans(清除操作)及rollback(回滚);
Data:此次操作关联的数据内容,主要记录数据或数据的地址,根据操作类型不同,数据内容不同,其中insert,update(数据的记录集)、delete(删除的数据条件集)、cleans(记录清除的数据对应的位置)、rollback(数据回滚的数据对应的位置);
Time:记录当前操作对应的时间,记录到时;分;秒;
State:记录当前操作所在的状态;
2)触发器创建:
通过创建实时计算任务,如图4所示的增量数据消费,根据增量的时间点读取增量的数据,来达到对增量数据消费的目标,其中触发器实现方式如图5所示;
其中,触发器采用常驻内存长期运行的程序,一次处理事务流程如下:
任务启动时,从redis中读取此任务对应的“存储的时间点”,若没有读取这个时间表示第一次运行,初始化一个最早的时间(如:2020-01-01 00:00:00)(begin_time);
标志当前所在的时间(current_time),程序读取[begin_time,current_time]间的增量数据;
读取数据处理并成功后,用“记录当前时间“更新”存储的时间点“下次读取的时候,又从“存储的时间点”拉到上步更新的时间,并赋能给”开始读取时间”;
S3、通过部署实时计算程序,实时从mq组件中读取增量数据,并对增量数据进行预处理,提取关键信息;
具体的,通过部署实时计算程序,实时从mq中读取增最数据,并对增量数据进行格式转换、数据清洗、格式归整等数据的预处理的工作,便于后续的数据关联关系分析;
具体的,所述S3通过部署实时计算程序,实时从mq组件中读取增量数据,并对增量数据进行预处理,提取关键信息包括以下步骤:
S31、实时监听并逐条读取或小批次的读取增量数据;
S32、对读取到的增量数据进行数据格式的转换;
具体的,此处主要是针对上步抓取到写入Hudi组件的结构化的数据,其形式如下:
db:default,table:t1,fields{{f1:v1:{isP:y,isNull:n},f2:v2,f3:v3,...},{...}}
其中,db表示数据库名称;
table表示表名;
fields表示字段以及对应的值的集合用{}框起来,其中fn为字段,vn表示字段值,字段其他属性也是用{}框起来如{isP(是否主键):y(是),isNull(是否可为空):n(不可为空)};
S33、在格式转换后,构建一张内存的表;
具体的,可用通用的sql创建如下:
create table default.t1(f1 string primaryKey not null, f2 string,f3string,...)
说明:通过建表语句create创建表名为default.t1的表,包括f1,f2,f3,...,的字段串类型的字段,其中f1为主键,值不能为空;
S34、通过sql语句对数据过滤;
具体的,如下所示:
select * from default.t1 where f2 is not null;过滤掉f2为空的无效数据,
对数据进行补全:
select t.*,u.name from default.t1 t left join mysql.user u on t1.f1=u.uid
//对内存的表数据,关联mysql数据库,补全一个name的字段数据;
S35、生成以表记录形式为主的数据体,并在内存中进行存储;
具体的,可以生成多条记录,并在内存中存储,其形式为:
Key:db.table values:{{key:f1,value:字段值}},{key:f1,value:字段值},..}
其中,Key表示存储表名;
Values表示存储的字段及数据集合,集合中的key表字段名称,value表示其对应的值;
S4、将提取关键信息形成数据体,并基于数据体进行数据的关联关系分析;
具体的,所述S4中将提取关键信息形成数据体,并基于数据体进行数据的关联关系分析通过关联关系分析算法进行数据的关联关系识别;
通过归整的实时数据同存储的历史数据结合,利用关联系分析算法智能识别数据的关联关系,关联分析就是从大规模数据中,发现数据之间隐含关系与规律的过程,用于寻找数据集中各数据之间的关联关系;根据所挖掘的关联关系,可以从一个属性的信息来推断另一个属性的信息;当置信度达到某一阈值时,可以认为数据的关联规则成立。
关联规则是反映一个事物与其他事物之间的相互依存性和关联性,是数据挖掘的一个重要技术,用于从大量数据中挖掘出有价值的数据项之间的相关关系;
关联规则如X→Y的蕴含表达式,其中X和Y是不相交的项集,X∩Y=∅;关联规则的强度可以用支持度(support)和置信度(confidence)度量;支持度确定规则可以用于给定数据集的频繁程度,而置信度确定Y在包含X的事务中出现的频繁程度。
其中,使用支持度和置信度原因是支持度很低的规则只能偶然出现,支持度通常用来删除那些无意义的规则;还具有一种期望的性质,可以用于关联规则的发现。
置信度度量通过规则进行推理具有可靠性;对于给定的规则,置信度越高,Y在包含X的事务中出现的可能性越大;置信度也可以估计Y在给定X的条件下概率。
在解析数据关联分析的结果时,规则做出去的推论并不必然蕴含因果关系,它只表示规则前件和后件中的数据明显地同时出现,可以用于表示数据之间经常性被使用时存在的关联关系,从而建立起数据之间的某种关联关系。
其中,通过对数据的关键信息形成数据体,基于数据体进行数据的关联关系分析,通过实时的数据与湖中存储的明细数据、被引用使用的数据等进行关联分析,就是从大规模数据中,发现对象之间隐含关系与规律,寻找数据集中各项之间的关联关系,可以从一个属性的信息来推断另一个属性的信息,当置信度达到某一阈值时,可以认为规则成立,其中关联规则主要从以下几个方面进行:
一、在频繁数据集的基础上,使用关联规则算法找出其中数据的关联结果,以下几个指标支撑数据关联关系的分析创建:
1)支持度
某数据在数据集中出现的概率;即数据中出现的次数,除以数据集中所有记录的数量;支持度体现的是某项集的频繁程度,只有某项集的支持度达到一定程度,我们才有研究该项集的必要。
support(A)=count(A)/count(dataset)=P(A)
其中,A表示数据A;
dataset表示数据集;
count(A)表示A数据出现的次数;
count(dataset)表示数据集的数据量;
support(A),P(A)表示支持度;
2)置信度
数据A发生,则数据B发生的概率;关联规则{A->B}中,A与B同时出现的次数,除以A出现的次数。
其中,confidence(A->B)表示数据A推导出数据B的置信度;
A,B表示数据A与B;
dataset表示数据集;
count(AB)表示A与B同时出现的次数;
count(A)表示A出现的次数;
count(dataset)表示数据集的数据量;
P(AB)表示数据A与B同时出现的支持度;
P(A)表示数据A支持度;
置信度体现的是关联规则的可靠程度,如果关联规则{A->B}的置信度较高,则说明当A发生时,B有很大概率也会发生。
3)提升度
关联规则{A->B}中,提升度是指{A->B}的置信度,除以B的支持度;
其中,lift(A->B)表示A到B的数据提升度;
confidence(A->B)表示A到B的数据置信度;
support(B)表示B的支持度;
其中,提升度体现的是组合(应用关联规则)相对不组合(不应用关联规则)的比值,如果提升度大于1,则说明应用该关联规则是有价值的。如果提升度小于1,说明应用该关联规则起到了负面影响;因此,我们应该尽可能让关联规则的提升度大于1,提升度越大,则应用关联规则的效果越好;如果两个事件相互独立,P(AB)=p(A)*P(B),提升度为1;
4)频繁项集与最小支持度
最小支持度是预先设置好的数据满足支持度的下限,用Min_sup表示,反映了所关注的数据的最低重要性;当数据X的支持度不小于最小支持度阈值时,X为频繁数据:
其中,X表示数据X;
dataset表示数据集;
count(X)表示X出现的次数;
count(dataset)表示数据集的数据量;
support(X)表示X的支持度;
Min_sup表示最小支持度阈值;
频繁数据中有两个重要的特性:
如果一个数据是频繁的,那么它的所有非空子集都是频繁的;
如果一个项集不是频繁的,那么它的所有超集也必然不是频繁的;
5)强关联规则与最小置信度
最小置信度是预先设置好的项集满足置信度的下限,用Min_conf表示,反映了所关注的项集的最低可靠程度,当关联规则R同时满足支持度与置信度不小于最小阈值,则称其为强关联规则:
其中,Support(A=>B)表示数据A与B同时出现的支持度;
confidence(A=>B)表示数据A推导出数据B的置信度;
Min_sup表示最小支持度阈值;
Min_conf表示最小置信度阈值;
挖掘关联规则的主要任务就是为了找出满足条件的各种强关联规则;
使用关联规则算法找出其中数据的关联结果。
二、数据关联分析的过程,从频繁项集中生成关联规则,具体为:
1)基于实时收集的数据,扫描存储的数据集,确定每个数据的支持度,通过支持度来作为判断频繁项集的标准,得到频繁数据的集合;
2)根据频繁数据的集合再逐层扫描,找到最大的K项频繁集;
3)频繁数据集产生依据:发现满足最小支持度阈值的所有项集,这些项集称作频繁项集;
4)在扫描的过程如果发现一个集合是频繁项集,则它的所有子集都是频繁项;否则,如果一个集合不是频繁项集,则它的所有超集都不是频繁项集。
例如:假设一个集合{A,B}是频繁项集,即A、B同时出现在一条记录的次数大于等于最小支持度min_support,则它的子集{A},{B}出现次数必定大于等于Min_sup(最小支持度),即它的子集都是频繁项集。
又如:假设集合{A}不是频繁项集,即A出现的次数小于Min_sup,则它的任何超集如{A,B}出现的次数必定小于Min_sup,因此其超集必定也不是频繁项集。
三、算法执行步骤
输入:数据集D(实时数据集+存储的历史数据集),支持度最小阈值α;
输出:最大的频繁k项集;
1)扫描整个数据集,得到所有出现过的数据,作为候选频繁1项集,k=1,频繁0项集为空集;
2)挖掘频繁k项集
a)扫描数据计算候选频繁k项集的支持度;
b)去除候选频繁k项集中支持度低于阈值的数据集,得到频繁k项集。如果得到的频繁k项集为空,则直接返回频繁k-1项集的集合作为算法结果,算法结束;如果得到的频繁k项集只有一项,则直接返回频繁k项集的集合作为算法结果,算法结束;
c)基于频繁k项集,连接生成候选频繁k+1项集;
3)令k=k+1,转入步骤2;
4)输出最大的频繁k项集;
具体的,如图6所示的流程,输出最终的数据关联关系;
S5、根据数据的关联关系找到对应的元数据及属性相关的数据,并使用图数据库存储数据之间的关联关系;
具体的,图的结构和语义类型信息是进一步构建更加复杂知识结构,可以快速构建数据的关联关系的存储图,如下描述:
1)通过图数据库实现数据间的关联关系存储,图由点和边组成,一个点就是一个数据,比如图7中的v1->v4,v5,v2->v3,v4(其v代表数据体),两个数据体之间的关系则用有方向或无方向的边来表示,存储格式如图7所示;
2)从一个数据体出发,持续存储数据体的直接数据、间接数据以及其关联数据的数据,形成数据的关联关系图,如图8所示,其存储主要包括对应的元数据、标签数据以及主键数据或索引字段以及数据,其元数据是用来描述点和边的属性信息的数据;
具体的,所述S5中根据数据的关联关系找到对应的元数据及属性相关的数据,并使用图数据库存储数据之间的关联关系包括以下步骤:
S51、根据当前的所述数据体,创建点的数据,所述点的数据包括点与标签;如数据为用户:create (1:user);
S52、创建点的属性;如(点:标签{字段名:字段值,字段名:字段名}),
其中{}表示属性:
create (1:user {id:1, name:"xxx",area:100,region:101})
S53、创建数据的关联关系;
如下创建用户1与用户2的同组关系为:
create (1)-[:group]->(2)
具体的,如图9所示,如果在写入频繁并且并发较大的时候,增加写队列的机制,步骤如下:
1)用户在写入数据时候,会在客户端配置写入的队列数,队列的长度,如wq_num:2(队列数),wq_len:10(队列长度);
2)在进行数据写入操作的数据会先写入队列中;
3)队列的处理程序会根据资源情况、队列的数据堆积多少自动开启并发处理的处理程序数量,智能利用资源加快入库的性能,保障数据均可以有效高效的写入图数据库中;
4)通过队列制可以快速接入写入的数据并缓存,根据目标的性能高效的写入数据,加强了数据写的能力。
S6、利用实时技术及时获取变动的数据,并对数据进行联动分析;
具体的,所述实时技术包括flink技术或sparkstreaming技术中的至少一种;
具体的,数据每时每刻的发生变化,其关联关系也时刻在变,对实时变动的数据,需要及时抓取到变动的数据,基于现有的关系上重新分析变动的数据对现有关联关系的影响,基于关联规则算法、元数据对应关系等方式,结合现有的数据对关联关系进行重新分析,形成新的数据关联关系;
其中,所述S6利用实时技术及时获取变动的数据,并对数据进行联动分析包括以下步骤:
S61、利用实时技术实时抓取数据;
S62、将抓取的实时数据与历史的数据进行结合并利用关联关系分析算法重新分析;
S63、分析出当前实时数据与历史数据新的关联关系;
S64、加载数据现有的关联关系,同新的关联关系对比,找出不一样的关联关系;
S65、将不在新的关联关系中的数据进行删除;
S66、更新数据,所述数据包括节点、属性及新增的关联关系数据;
其中,由于实时变动的数据会写入Hudi组件中存储,这其中会基于flink实时抓取Hudi的增量数据,具体实施操作如图10所示:
具体的,实时变动的数据会写入到数据湖组件Hudi中,而Hudi每次操作都会记录一个增量的时间点,并记录此时间点的数据,通过flink或sparkstreaming(常驻后台运行的实时计算程序)实时抓取Hudi的增量数据,flink或sparkstreaming程序实现过程如下描述:
1)程序启动时读取初始化最早的一个时间点(如:2022-01-01:00 00 00)或设定好(如:从缓存中根据key=r_begintime(开始读取时间) value=2022-08-08:00 00 00(时间))的时间点的数据;
2)对读取到的增时数据逐一进行格式转换,数据分析等处理动作;
3)完成对实时抓取的数据分析,更新缓存的key为r_begintime的读取时间增加1秒;
4)根据更新的时间点继续读取增量点的数据,回到第1步继续运行;
5)如果当前点没有数据并且缓存的时间大于等于当前时间,需要等待10s后面重新进行第1步;
S7、实时变动数据,并利用图数据库对变动的数据进行更新存储;
具体的,通过实时数据的关联关系分析后,其间包括非结构、半结构的数据,提炼出其对应的结构化数据以及关联的上游数据,基于结构化的数据定位到当前数据所在关系图中的位置,实时修改当前数据以及对应的上下游的关联关系,具体流程如图11所示;
具体的,图数据库相比关系数据库在数据更新具有以下优势:
1)图数据可以轻易地支持数据管理的频繁schema变更,关系型数据库改动schema频繁会变得很慢;
2)图数据库支持对大图形数据的实时更新,同时支持查询,关系型在数据较大更新越来越慢;
具体的,所述S7中利用图数据库对变动的数据进行更新存储包括以下步骤:
S71、通过变动的数据体,利用图数据库的查询语句定位到要更新的数据;
如下所示:如下语句:
match (u:user)where u.id=1 return u; //匹配到主键id=1的数据体;
S72、根据定位的数据,并通过set语句修改数据对应的属性数据;
具体的,由于数据主要存储地属性中,所以对数据体的修改,主要是修改属性即可,如下语句:
match(u:) set u.new_property = value remove u.old_proerty;
UPDATE VERTEX (u:user) SET u.property=value;
修改节点u的属性(property)的值,例如修改name的为’u9’;
UPDATE VERTEX (u:user) SET u.property=’u9’;
S73、根据新的关联关系对点的关联关系进行更新;
具体步骤操作如下:
1)先删除此顶点对应的所有关联关系,如下语句:
start u=node(*) match u-[r]-() deleter //删除图中u顶点关联的所有关系;
2)根据分析出的新的关联关系重新创建,创建数据的关联关系,如下语句:
FOR(r:relations) { //偱环关系
create (u)-[:r]->(r.n);
//创建顶点u与关系的点n的关联关系,其中n表示关联的数据体;
}。
S8、通过数据关联关系正向快速查询形成关联关系图;
具体的,所述S8中通过数据关联关系正向快速查询形成关联关系图包括以下步骤:
S81、对数据本身以及元数据相关信息进行查询;
S82、对查询的数据关联出与数据相关的数据;
S83、基于关联出的数据进行数据的知识图谱绘制,并形成数据下上游的数据与数据间的关联关系图;
具体的,通过图数据库存在数据的关联关系,图数据具有免索引邻接属性;免索引邻接是每个节点都会维护其对相邻节点的引用,因此每个节点都表现为其附近节点的微索引,比使用全局索引代价小很多,正向查询时间与图的整体规模无关,仅和所搜索图的数量成正比;相反,关系型数据库引擎使用索引连接各个节点,索引对每个遍历都添加一个间接层,正向查询时会导致更大的计算成本。
关系型数据正向查询关联关系时如有3张关联关系表:
1)表1:部门表Dep(字段:部门ID,部门名称);
2)表2:员工表E(字段:员工编号、姓名、所属部门ID);
3)表3:支付表P(字段:支付编号、员工编号、金额),当查询部门支付金额时,编写关联的sql语句:
selelct sum(p.金额)from dep d join e on e.所属部门ID=d.部门ID join pon p.员工编号=e.员工编号;
遍历Dep表,会把Dep表的每一个值都访问一遍,时间复杂度是|D|,遍历E表,时间复杂度是|E|,遍历P表,判断每一行数据的员工编号,假如有m个员工,进而得到支出金额,时间复杂度为m*|P|,汇总支出金额;如果探查一个部门的时间复杂度:|D|+|E|+m*|P|,如果分析所有部门,时间复杂度可达到|D|*|E|*|P|,如果E、P数据量大的时候,正向关联关系查询的时候消耗的时间更长。
图数据库(Graph Database)是使用图的结构来表现和存储具有图语义的数据,并快速的进行查询;图数据的关键在于存储的是图的数据,图的数据直接将节点与节点之间的关系也保存下来,这样使得在查询的时候,两个节点的数据可以进行直接的关联,有的甚至只需要关联一步就可以获取,图数据库能够直观的展示数据之间的关系,对于高度互联的数据非常的有用。
前面的步骤已完成数据的关联关系分析并将关联关系存储在图数据库中。图数据库采用免索引邻接的能力其正向查询是遍历物理关系的时间复杂度仅为O(1),如果要遍历一个m步的网络,图查询的成本仅为O(m)。当需要查询一个节点的关联节点时,直接从节点循着链接出发去寻找就可以了,而不需要遍历所有节点,大大节省了查询时间。
通过一个例子设计正向快速查询的过程,例如将部门、员工、支付记录作视为图数据库的实体,员工和部门之间通过“从属关系”的关系链接在一起,支付记录和员工通过“行为”关系链接在一起:
如图12所示,其中,Dep表示部门,en(n代表数字)表示员工,pn(n代表数字)表示支付记录;
快速查询部门Dep x的支出情况,查询遍历如图12所示的箭头的方向步骤如下:
1)通过部门编号定位到Dep x的部门,耗时为1;
2)Dep x为图数据库中的一个节点,直接遍历通过“从属关系”关系与该节点联结的节点(员工),耗时为m,m为部门Dep x的员工数;
3)围绕m个员工节点,遍历通过“行为”关系与这些节点联结的节点(支付记录);假设有n个支付事件与部门Dep x的m个员工相关,那么耗时为n;
4)计算得出的总的耗时时间为1+m+n;
5)m和n都远小于|E|和|P|,因此耗时远小于传统关系型数据库的耗时,即使是查询所有部门的支出情况,耗时为|D|+|E|+|P|,耗时远比|D|*|E|*|P|少;
其中,使用图数据库查询时,查询工作量仅与被查询的节点关系数有关,而与全局节点数无关,当全局节点数变多、图变大时,查询工作量不会有太大变化;另外,即使是查询层次变深,对于图数据库来说,只是多查了一层图,逻辑比较清晰,不会像传统关系型数据库那样增加sql的复杂度和表的遍历工作量,从而实现了正向快速的能力。
S9、通过数据关联关系反向快速查询形成关联关系图;
具体的,所述S9中通过数据关联关系反向快速查询形成关联关系图包括以下步骤:
S91、通过关联关系最尾端的数据查询与其关联的上游数据;
S92、以上游的数据作为当前数据遍历其上游的数据;
S93、通过反向查询生成从下至上的数据关联关系图谱,并形成数据下上游的数据与数据间的关联关系图。
具体的,通过在图数据库中创建了关联关系,并标明图的节点以及节点间的关联关系,反向查询时从子节点开始向上查询,通过遍历如图13所示的箭头的方向的数据所示:
图13中实现反向查询从数据B2找到其最开始的节点数据“数据A”的实现过程为:
1)通过数据标识定位到B2,耗时为1;
2)B2为图数据库中的一个节点,只遍历其上级的关联关系“扩展属性关系”找到上级节点数据A.2,耗时为1;
3)围绕A.2节点,只遍历其上级的关联关系“下属关系”,找到上级节点”数据A“,那么耗时为1;
4)计算得出的总的耗时时间为1+1+1,此时n层次,其查询耗时为n,远比数据型数据库的join操作耗时少,可以快速的实现反向查询的能力。
具体的,如下通过一个实际的例子讲解数据入湖时如何创建关联关系,并可以快速查询;
某大型的信息技术公司,在重要或紧急项目时候,可以及时找到合适的人员参与项目,同时也可以方便发现人员、项目、成本、管理之间的关联关系;日常生产过程中主要碎片化的数据有:人员信息、组织信息、工作UR单、工时填单报单、项目信息、项目费用信息等,实现上述描述的能力,可以快速在碎片化找到人员、项目、成本、管理之间的关联关系,及时分析关联出人员熟悉的技能,通过此发明实现创建数据的关联关系并可快速找到关联关系的数据步骤如下:
1)第一步数据入湖:将人员信息(人员ID、姓名、所属组织ID、年龄、参加工作时间)、组织信息(组织ID、组织名称、上级组织ID)、工作UR单(工单ID、所属项目ID、工作内容、所用技能)、工时填单报单(工时ID、人员ID、项目ID、工时数(小时)、工时日期、工作内容)、项目信息(项目ID、名称)、项目费用信息(项目ID、客户、销售额、合同ID、收款、欠款)通过实时或批量入湖的采集,将上述的数据存储到Hudi组件中;
2)第二步数据入湖触发增量消费处理:数据在入到Hudi组织中时,通过触发器及时获取增量数据,对增量数据进行处理,并提取成结构化数据形式,生成图的节点数据如下:
人员信息提取数据:e1:staff{人员ID、姓名、所属组织ID、年龄};
组织信息提取数据:o1:organize{组织ID、组织名称、上级组织ID};
工作UR单提取数据:ur1:utracer{工单ID、所属项目ID、所用技能};
工时填单报单提取数据:wt1:worktime{工时ID、人员ID、项目ID、工时数(小时)、工时日期、工作内容};
项目信息提取数据:p1:project{项目ID、名称};
项目费用信息提取数据:fee1:profee{项目ID、销售额、收款、欠款};
3)第三步:数据关联关系分析:针对入湖的数据基于关联关系分析算进行拆解分析;找出人参与的项目,以及工作的内容与所使用技能的关联关系;
4)第四步数据关联关系存储;
采用图数据存储顶点、关联关系(边)以及顶点的属性与标签数据,存储后的数据结构大致如图14所示:
其中,存储图的顶点数据主包括第一步说的字段数据,可以方便基于属于查询,同时保存点与点之间关联关系(如工作关系),有利于可以通过关系快速定位数据;
5)第五步数据关联关系正反向查询;
对上步中已创建好了人与技能关联关系后,通过查询可快速的关联出人员熟悉的技能语句:
Match(人员->{关系:会的技能}->工作技能);//说明match(表示匹配查询);
只需遍历一次(时间成本o(1))就可以找到人员熟悉的技能,同时反过来查询通过技能也可以找到熟悉的人,其时间成本也是o(1):
Match(工作技能->{关系:会的技能}->人员);
同时有了关联后也可以快速的查询人员到参与的项目以及项目的成本分析,查收款大于0的项目参与的人员;
Match(人员->{关系:所有关系}->项目)where项目.收款>0;
其查询的时间成本根据其图的关联关系的层级n,确定为o(n)。
具体的,通过采用图数据库存储数据的关联关系,图数据库与关系型数据库相反,后者的联合密集型查询性能会下降随着数据集变大,使用图数据库的性能趋于保持相对恒定,即使随着数据集的增长,在查询已本地化为图的一部分,每个查询的执行时间仅成比例为满足该查询而遍历的图形部分的大小,而不是整体图。
性能优势:在上例中通过人通过人员->技能->工作内容->工时->项目找到最大深度为5的人员到项目的路径上成本时投入情况时,其数据集包括10万人员,每个人员会10种以上的技能,工作内容:1000万的数据,工时数据:1500万,参与项目10万个,其查询性能如下表所示:
通过对比分析,利用图数据存储的关联关系,在大数据量下进行多个数据关联查询时,可以在秒级内返回查询结果,而关系型数据库在关联数据越多时,虽然每次join(关联)操作却只用到部分数据,反复join操作会导致大量的性能损失,如深度关联为5时,基本查询不能按时完成,而其于图数据库在创建好的关联关系下查询数据,可以在秒级内完成,并且不管是多大的数据量多深的层次均可以实现快速查询,满足很多复杂的业务场景用数需求,极大提升数据使用的价值。
综上所述,借助于本发明的上述技术方案,本发明实现在入湖的海量数据中建立数据的关联关系,通过识别库表元数据的关联关系、数据操作过程的关联关系、数据的依赖关系、数据关联关系算法找到数据的附属关系、以及数据实时变化等来建立点、边以及点属性的图形关系,通过创建好的图形的关系,并且可以动态维护图形关系,保障关联关系及时性;从数据出发,可以快速从过亿大数据中查询相关的数据,同时从关联数据的任一位置出发,可以在秒级内反查上下游相关的数据,在过亿的数据中关联5层及以上的关联操作也可以经轻松的秒级返回数据,同时通过智能的关联关系可以轻松的实现数据找人的能力;本发明可以将原本数据湖中碎片化的数据,构建成有用的数据关联关系图,在数据入湖的时候,通过触发器提出可用于创建关联关系的结构化数据,对结构化数据利用关联关系分析算法与存量数据进行关联分析,计算出刚入湖的数据与存量的数据的关联关系,再通过图数据库存储数据以及数据之间的关系,当数据关系创建后,将数据湖中原本碎片化的数据,整理成一张相互有关系的关联关系大图,在业务使用的时候,通过查询某一个数据,可以很快的根据数据的关联关系绘制数据关联的知识图谱,可方便快捷的为业务提供有用的数据。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种基于业务对象智能动态化实时生成关联数据图的方法,其特征在于,该方法包括以下步骤:
S1、通过实时或批量入湖的采集,将结构化、半结构及非结构化的数据实时入湖,并通过存储组件进行存储;
S2、创建入湖数据触发器,实时抓取入源的数据,并将数据按预设的格式存储至mq组件中;
S3、通过部署实时计算程序,实时从mq组件中读取增量数据,并对增量数据进行预处理,提取关键信息;
S4、将提取关键信息形成数据体,并基于数据体进行数据的关联关系分析;
S5、根据数据的关联关系找到对应的元数据及属性相关的数据,并使用图数据库存储数据之间的关联关系;
S6、利用实时技术及时获取变动的数据,并对数据进行联动分析;
S7、实时变动数据,并利用图数据库对变动的数据进行更新存储;
S8、通过数据关联关系正向快速查询形成关联关系图;
S9、通过数据关联关系反向快速查询形成关联关系图。
2.根据权利要求1所述的一种基于业务对象智能动态化实时生成关联数据图的方法,其特征在于,所述存储组件包括Hudi存储组件和Ozone存储组件;
其中,所述Hudi存储组件用于存储结构化和半结构数据;
所述Ozone存储组件用于存储非结构与部分类型的半结构化数据。
3.根据权利要求1所述的一种基于业务对象智能动态化实时生成关联数据图的方法,其特征在于,所述S3通过部署实时计算程序,实时从mq组件中读取增量数据,并对增量数据进行预处理,提取关键信息包括以下步骤:
S31、实时监听并逐条读取或小批次的读取增量数据;
S32、对读取到的增量数据进行数据格式的转换;
S33、在格式转换后,构建一张内存的表;
S34、通过sql语句对数据过滤;
S35、生成以表记录形式为主的数据体,并在内存中进行存储。
4.根据权利要求1所述的一种基于业务对象智能动态化实时生成关联数据图的方法,其特征在于,所述S4中将提取关键信息形成数据体,并基于数据体进行数据的关联关系分析通过关联关系分析算法进行数据的关联关系识别。
5.根据权利要求1所述的一种基于业务对象智能动态化实时生成关联数据图的方法,其特征在于,所述S5中根据数据的关联关系找到对应的元数据及属性相关的数据,并使用图数据库存储数据之间的关联关系包括以下步骤:
S51、根据当前的所述数据体,创建点的数据,所述点的数据包括点与标签;
S52、创建点的属性;
S53、创建数据的关联关系。
6.根据权利要求1所述的一种基于业务对象智能动态化实时生成关联数据图的方法,其特征在于,所述S6利用实时技术及时获取变动的数据,并对数据进行联动分析包括以下步骤:
S61、利用实时技术实时抓取数据;
S62、将抓取的实时数据与历史的数据进行结合并利用关联关系分析算法重新分析;
S63、分析出当前实时数据与历史数据新的关联关系;
S64、加载数据现有的关联关系,同新的关联关系对比,找出不一样的关联关系;
S65、将不在新的关联关系中的数据进行删除;
S66、更新数据,所述数据包括节点、属性及新增的关联关系数据。
7.根据权利要求6所述的一种基于业务对象智能动态化实时生成关联数据图的方法,其特征在于,所述S7中利用图数据库对变动的数据进行更新存储包括以下步骤:
S71、通过变动的数据体,利用图数据库的查询语句定位到要更新的数据;
S72、根据定位的数据,并通过set语句修改数据对应的属性数据;
S73、根据新的关联关系对点的关联关系进行更新。
8.根据权利要求1所述的一种基于业务对象智能动态化实时生成关联数据图的方法,其特征在于,所述S8中通过数据关联关系正向快速查询形成关联关系图包括以下步骤:
S81、对数据本身以及元数据相关信息进行查询;
S82、对查询的数据关联出与数据相关的数据;
S83、基于关联出的数据进行数据的知识图谱绘制,并形成数据下上游的数据与数据间的关联关系图。
9.根据权利要求1所述的一种基于业务对象智能动态化实时生成关联数据图的方法,其特征在于,所述S9中通过数据关联关系反向快速查询形成关联关系图包括以下步骤:
S91、通过关联关系最尾端的数据查询与其关联的上游数据;
S92、以上游的数据作为当前数据遍历其上游的数据;
S93、通过反向查询生成从下至上的数据关联关系图谱,并形成数据下上游的数据与数据间的关联关系图。
10.根据权利要求6所述的一种基于业务对象智能动态化实时生成关联数据图的方法,其特征在于,所述实时技术包括flink技术或sparkstreaming技术中的至少一种。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211237745.0A CN115309789B (zh) | 2022-10-11 | 2022-10-11 | 一种基于业务对象智能动态化实时生成关联数据图的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211237745.0A CN115309789B (zh) | 2022-10-11 | 2022-10-11 | 一种基于业务对象智能动态化实时生成关联数据图的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN115309789A true CN115309789A (zh) | 2022-11-08 |
CN115309789B CN115309789B (zh) | 2023-01-03 |
Family
ID=83868473
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211237745.0A Active CN115309789B (zh) | 2022-10-11 | 2022-10-11 | 一种基于业务对象智能动态化实时生成关联数据图的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115309789B (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115905291A (zh) * | 2022-12-12 | 2023-04-04 | 广州南方智能技术有限公司 | 基于图的数据处理方法、装置及存储介质 |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103533532A (zh) * | 2013-09-27 | 2014-01-22 | 武汉世纪金桥安全技术有限公司 | 基于时域分析的电子特征关联系统及关联方法 |
CN108875051A (zh) * | 2018-06-28 | 2018-11-23 | 中译语通科技股份有限公司 | 面向海量非结构化文本的知识图谱自动构建方法及系统 |
CN110033167A (zh) * | 2019-03-12 | 2019-07-19 | 国网福建省电力有限公司 | 一种基于数据资产的业务数据体系与监测业务映射关系的梳理分析方法 |
CN111324609A (zh) * | 2020-02-17 | 2020-06-23 | 腾讯云计算(北京)有限责任公司 | 知识图谱构建方法、装置、电子设备及存储介质 |
CN111597177A (zh) * | 2020-05-14 | 2020-08-28 | 重庆农村商业银行股份有限公司 | 用于提升数据质量的数据治理方法 |
CN112686679A (zh) * | 2020-12-31 | 2021-04-20 | 天津工业大学 | 一种客户关联关系智能分析系统及方法 |
CN113407600A (zh) * | 2021-08-18 | 2021-09-17 | 浩鲸云计算科技股份有限公司 | 一种动态实时同步多源大表数据的增强实时计算方法 |
CN113434634A (zh) * | 2021-06-28 | 2021-09-24 | 国网北京市电力公司 | 知识图谱构建方法、装置 |
WO2021190091A1 (zh) * | 2020-03-26 | 2021-09-30 | 深圳壹账通智能科技有限公司 | 基于知识节点所属度的知识图谱构建方法和装置 |
CN113918663A (zh) * | 2021-07-06 | 2022-01-11 | 中电科大数据研究院有限公司 | 一种基于命名规则和缓存机制的知识图谱构的操作方法 |
CN114090794A (zh) * | 2021-11-29 | 2022-02-25 | 中国平安人寿保险股份有限公司 | 基于人工智能的事理图谱构建方法及相关设备 |
-
2022
- 2022-10-11 CN CN202211237745.0A patent/CN115309789B/zh active Active
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103533532A (zh) * | 2013-09-27 | 2014-01-22 | 武汉世纪金桥安全技术有限公司 | 基于时域分析的电子特征关联系统及关联方法 |
CN108875051A (zh) * | 2018-06-28 | 2018-11-23 | 中译语通科技股份有限公司 | 面向海量非结构化文本的知识图谱自动构建方法及系统 |
CN110033167A (zh) * | 2019-03-12 | 2019-07-19 | 国网福建省电力有限公司 | 一种基于数据资产的业务数据体系与监测业务映射关系的梳理分析方法 |
CN111324609A (zh) * | 2020-02-17 | 2020-06-23 | 腾讯云计算(北京)有限责任公司 | 知识图谱构建方法、装置、电子设备及存储介质 |
WO2021190091A1 (zh) * | 2020-03-26 | 2021-09-30 | 深圳壹账通智能科技有限公司 | 基于知识节点所属度的知识图谱构建方法和装置 |
CN111597177A (zh) * | 2020-05-14 | 2020-08-28 | 重庆农村商业银行股份有限公司 | 用于提升数据质量的数据治理方法 |
CN112686679A (zh) * | 2020-12-31 | 2021-04-20 | 天津工业大学 | 一种客户关联关系智能分析系统及方法 |
CN113434634A (zh) * | 2021-06-28 | 2021-09-24 | 国网北京市电力公司 | 知识图谱构建方法、装置 |
CN113918663A (zh) * | 2021-07-06 | 2022-01-11 | 中电科大数据研究院有限公司 | 一种基于命名规则和缓存机制的知识图谱构的操作方法 |
CN113407600A (zh) * | 2021-08-18 | 2021-09-17 | 浩鲸云计算科技股份有限公司 | 一种动态实时同步多源大表数据的增强实时计算方法 |
CN114090794A (zh) * | 2021-11-29 | 2022-02-25 | 中国平安人寿保险股份有限公司 | 基于人工智能的事理图谱构建方法及相关设备 |
Non-Patent Citations (2)
Title |
---|
XINGYU PENG 等: "Distributed dynamic semantic query and reasoning for graph data", 《2021 6TH INTERNATIONAL SYMPOSIUM ON COMPUTER AND INFORMATION PROCESSING TECHNOLOGY (ISCIPT)》 * |
杨娟 等: "自适应学习系统中教育知识图谱模型构建研究", 《中国教育信息化》 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115905291A (zh) * | 2022-12-12 | 2023-04-04 | 广州南方智能技术有限公司 | 基于图的数据处理方法、装置及存储介质 |
CN115905291B (zh) * | 2022-12-12 | 2024-02-23 | 广州南方智能技术有限公司 | 基于图的数据处理方法、装置及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN115309789B (zh) | 2023-01-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11461294B2 (en) | System for importing data into a data repository | |
US11360950B2 (en) | System for analysing data relationships to support data query execution | |
US10678810B2 (en) | System for data management in a large scale data repository | |
CN108038222B (zh) | 用于信息系统建模和数据访问的实体-属性框架的系统 | |
CN106095862B (zh) | 集中式可扩展融合型多维复杂结构关系数据的存储方法 | |
Junghanns et al. | Management and analysis of big graph data: current systems and open challenges | |
CN109299100B (zh) | 管理内存数据及在内存中维护数据的方法和系统 | |
Moniruzzaman et al. | Nosql database: New era of databases for big data analytics-classification, characteristics and comparison | |
JP2017157229A (ja) | 半構造データのためのスケーラブルな分析プラットフォーム | |
Comyn-Wattiau et al. | Model driven reverse engineering of NoSQL property graph databases: The case of Neo4j | |
US9110970B2 (en) | Destructuring and restructuring relational data | |
CN115309789B (zh) | 一种基于业务对象智能动态化实时生成关联数据图的方法 | |
US12061579B2 (en) | Database gateway with machine learning model | |
Suri et al. | A comparative study between the performance of relational & object oriented database in Data Warehousing | |
CN116150436B (zh) | 一种基于节点树的数据展示方法与系统 | |
US10877998B2 (en) | Highly atomized segmented and interrogatable data systems (HASIDS) | |
Tseng et al. | D-tree: A multi-dimensional indexing structure for constructing document warehouses | |
Altın et al. | Analyzing The Encountered Problems and Possible Solutions of Converting Relational Databases to Graph Databases | |
Gidado et al. | Maximizing Bigdata Retrieval: Block as a Value for NoSQL over SQL | |
Arfaoui et al. | ASDeDaWaS: An Assistant System for the Design of Data Warehouse Schema | |
Jeevangekar et al. | Design and Implementation of a NoSQL Database for Decision Support in R&D Management | |
Sellami et al. | Normalized NoSQL Graph Data Warehouse. | |
JPH0582615B2 (zh) | ||
CN115221157A (zh) | 数据处理方法及装置、计算机可读存储介质和电子设备 | |
Sharma | A Relative Study Between The Performance of Relational & Object Oriented Database In Data Warehousing |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |