CN112732821A

CN112732821A - 数据入库方法、装置、设备及存储介质

Info

Publication number: CN112732821A
Application number: CN202110344265.3A
Authority: CN
Inventors: 赵运枫; 严雪枫; 赵永亮; 高斌
Original assignee: Chengdu New Hope Finance Information Co Ltd
Current assignee: Chengdu New Hope Finance Information Co Ltd
Priority date: 2021-03-31
Filing date: 2021-03-31
Publication date: 2021-04-30
Anticipated expiration: 2041-03-31
Also published as: CN112732821B

Abstract

本申请提供了一种数据入库方法、装置、设备及存储介质，其中，该方法包括：对业务数据进行结构化处理，得到业务数据对应的待存储流式数据，根据预设的图数据库中已存储的流式数据，以及待存储流式数据，确定待存储流式数据的入库操作逻辑，根据入库操作逻辑，将待存储流式数据写入图数据库。本申请通过定义一种通用的入库操作逻辑，从而形成了一套统一的数据入库流程，开发成本低且效率高。

Description

数据入库方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种数据入库方法、装置、设备及存储介质。

背景技术

知识图谱指的是用可视化技术描述知识资源及其载体，用于挖掘、分析、构建、绘制和显示知识及它们之间的相互联系。知识图谱的应用场景愈加丰富，包括自然语言处理（Natural Language Processing，NLP）、信息挖掘，图像识别，人工智能等场景。

相关技术中，知识图谱在逻辑结构上可分为模式层与数据层两个层次，数据层主要是由一系列的事实组成，而知识将以事实为单位进行存储，如果用（实体1，关系，实体2）、（实体、属性，属性值）这样的三元组来表达事实，可选择图数据库作为存储介质，例如开源的Neo4j、Twitter的FlockDB、JanusGraph等，商业图数据库TigerGraph。

然而，由于每种图数据库的标准不同，目前还未提供有统一的数据入库流程。

发明内容

本申请的目的在于，针对上述现有技术中的不足，提供一种数据入库方法、装置、设备及存储介质，以针对不同的图数据库提供一种统一的数据入库方案。

为实现上述目的，本申请实施例采用的技术方案如下：

第一方面，本申请一实施例提供了一种数据入库方法，所述方法包括：

对业务数据进行结构化处理，得到所述业务数据对应的待存储流式数据；

根据预设的图数据库中已存储的流式数据，以及所述待存储流式数据，确定所述待存储流式数据的入库操作逻辑；

根据所述入库操作逻辑，将所述待存储流式数据写入所述图数据库。

可选地，所述对业务数据进行结构化处理，得到所述业务数据对应的待存储流式数据，包括：

对所述业务数据进行格式化处理，得到预设格式的业务数据；

将所述预设格式的业务数据写入预设节点数据结构中，得到所述业务数据对应的节点数据；

将所述节点数据写入预设流式数据结构中，得到所述待存储流式数据。

可选地，所述根据预设的图数据库中已存储的流式数据，以及所述待存储流式数据，确定所述待存储流式数据的入库操作逻辑，包括：

根据所述已存储的流式数据，以及所述待存储流式数据，确定所述业务数据对应节点的类型；

根据所述业务数据对应节点的类型，确定所述待存储流式数据的入库操作逻辑。

可选地，所述根据所述业务数据对应节点的类型，确定所述待存储流式数据的入库操作逻辑，包括：

若所述业务数据对应节点的类型为新增实体节点，则确定所述入库操作逻辑为：依次包括所述新增实体节点的增加操作和所述待存储流式数据的写入操作的操作逻辑。

若所述业务数据对应节点的类型为更新实体节点，则确定所述入库操作逻辑为：依次包括所述更新实体节点在所述图数据库中对应节点的流式数据的删除操作和所述待存储流式数据的写入操作的操作逻辑。

可选地，所述根据所述入库操作逻辑，将所述待存储流式数据写入所述图数据库，包括：

将所述入库操作逻辑翻译为预设语言的可执行逻辑，所述可执行逻辑的逻辑执行步骤少于所述入库操作逻辑的逻辑执行步骤；

根据所述可执行逻辑，将所述待存储流式数据写入所述图数据库。

基于两阶段提交协议，向多个分布式节点发送数据写入请求；

若接收到所述多个分布式节点返回的接收确认响应，则向所述多个分布式节点发送数据入库通知，以便所述多个分布式节点根据所述入库操作逻辑，将所述待存储流式数据写入所述图数据库。

第二方面，本申请另一实施例提供了一种数据入库装置，所述装置包括：

处理模块，用于对业务数据进行结构化处理，得到所述业务数据对应的待存储流式数据；

确定模块，用于根据预设的图数据库中已存储的流式数据，以及所述待存储流式数据，确定所述待存储流式数据的入库操作逻辑；

写入模块，用于根据所述入库操作逻辑，将所述待存储流式数据写入所述图数据库。

可选地，处理模块，具体用于：

可选地，确定模块，具体用于：

可选地，写入模块，具体用于：

第三方面，本申请另一实施例提供了一种计算机设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的计算机程序，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述处理器执行所述计算机程序，以执行上述第一方面任一项所述的方法。

第四方面，本申请另一实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述第一方面任一项所述的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的数据入库方法的流程示意图一；

图2示出了本申请实施例提供的数据入库方法的流程示意图二；

图3示出了本申请实施例提供的数据入库方法的流程示意图三；

图4示出了本申请实施例提供的数据入库方法的流程示意图四；

图5示出了本申请实施例提供的数据入库方法的流程示意图五；

图6示出了本申请实施例提供的数据入库装置的结构示意图；

图7示出了本申请实施例提供的计算机设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

在知识图谱中，通常以图数据库作为数据的存储介质，例如开源的Neo4j、Twitter的FlockDB、JanusGraph等，商业图数据库TigerGraph，其中，由于每种图数据的标准不同，数据查询、入库的工具与技术方案相差很大，例如Neo4j使用Cypher作为查询语言、JanusGraph使用Gremlin作为查询工具、TigerGraph用GSQL作为查询语言。这些工具与语言分别有各自适用的场景，通常情况下，开发人员可以根据需要解决的问题来选择适用哪种工具，但没有形成一套统一的端到端的数据入库方案与流程；同时针对单节点数据库或分布式数据库，如何保证写入数据的事务性，以及如何满足CAP定理也是一个亟待解决的问题。

可以理解的是，数据事务性具有以下四大特性：原子性、一致性、隔离性以及持久性，原子性指的是事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响；一致性指的是事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态；隔离性指的是当多个开发者并发访问数据库时，比如操作同一张表时，数据库为每一个开发者开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离；持久性指的是一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

CAP定理指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），这三个要素最多只能同时实现两点，不可能三者兼顾。

基于此问题，本申请通过形成一套统一的数据入库流程，将系统与数据库交互的细节屏蔽，同时通过技术手段实现数据入库的事务性，该方案的优势在于，对入库数据量不敏感，可伸缩性强，同时能够实现数据入库，对开发者友好，将知识图谱的入库逻辑进行屏蔽使开发者不需深入了解图数据库的读写特性以及细节即可完成数据入库，开发成本低且开发效率高。

下面结合几个具体实施例对本申请提供的数据入库方法进行详细说明。

图1示出了本申请实施例提供的数据入库方法的流程示意图一，本实施例的执行主体可以为计算机设备，例如可以为终端设备、服务器等。如图1所示，该方法可以包括：

S101、对业务数据进行结构化处理，得到业务数据对应的待存储流式数据。

其中，业务数据可以为任意一种业务领域所产生的业务数据，为实现数据存储，首先可以对业务数据进行结构化处理，以得到业务数据对应的待存储流式数据，其中，待存储流式数据的数据结构可以为流式计算引擎对应的数据结构，也即，通过对业务数据进行结构化处理，以将业务数据转换为流式计算引擎的内部对象。其中，该业务数据可以为三元组数据。

可以理解的是，该流式计算引擎可以为streaming，streaming分为spark与flink，flink本身提供了2PC两阶段提交协议的事物提交方式提交了框架，但没有针对图数据库做客户端的定制化适配。

S102、根据预设的图数据库中已存储的流式数据，以及待存储流式数据，确定待存储流式数据的入库操作逻辑。

其中，预设的图数据库可以为任意一种标准的图数据库，采用属性图的形式存储实体节点之间的关系信息，预设的图数据库例如可以为开源的Neo4j、Twitter的FlockDB、JanusGraph、商业图数据库TigerGraph等中的任意一种，本实施例对预设的图数据库不做特别限定。

预设的图数据库用于以实体节点的形式存储流式数据，因此，根据预设的图数据库中已存储的流式数据，以及待存储流式数据，可以确定需要在图数据库中新增实体节点还是更新图数据库中已存储的实体节点，也即，确定待存储流式数据的入库操作逻辑，入库操作逻辑包括两种逻辑，一种是针对新增实体节点，新增实体节点并将待存储流式数据写入到新增实体节点，其中，将待存储流式数据写入到新增实体节点的同时还可以根据待存储流式数据在图数据库中绘制新增实体节点与图数据库中其他实体节点之间的关系边；一种是针对更新实体节点，将预设的图数据库中对应的已存储的流式数据删除，并将待存储流式数据写入该更新实体节点中，其中，将待存储流式数据写入该更新实体节点的同时还可以根据待存储流式数据，绘制更新实体节点与图数据库中其他实体节点之间的关系边。

需要说明的是，在得到业务数据对应的待存储流式数据之后，还可以将待存储流式数据存储到消息中间件中，例如kafka，这样可以使数据可回放，不会丢失。在确定待存储流式数据的入库操作逻辑之前，可以从消息中间件中获取待存储流式数据。

S103、根据入库操作逻辑，将待存储流式数据写入图数据库。

入库操作逻辑用于指示待存储流式数据的入库操作流程，因此在获得入库操作逻辑之后，可以根据入库操作逻辑，将待存储流式数据写入图数据库中，具体地，待存储流式数据写入图数据库的方式可以为将待存储流式数据写入新增实体节点中，或者更新实体节点中，在写入图数据库的同时，还需要根据待存储流式数据绘制新增实体节点与图数据库中其他实体节点之间的关系边，以及更新实体节点与图数据库中其他实体节点之间的关系边。

需要说明的是，步骤S103可以包括：根据入库操作逻辑，获取入库操作逻辑对应的有向无环图，根据有向无环图，将待存储流式数据写入图数据库。

在一些情况下，在业务数据的数量较多、节点更新比较复杂、在一个事务中可能有多个环节的情况下，还可以根据每个待存储流式数据的入库操作逻辑获取对应的有向无环图（Directed acyclic graph，DAG），在DAG中各个环节是按照顺序运行的，因此可以确保每一步执行逻辑准确无误。

本实施例的数据入库方法，对业务数据进行结构化处理，得到业务数据对应的待存储流式数据，根据预设的图数据库中已存储的流式数据，以及待存储流式数据，确定待存储流式数据的入库操作逻辑，根据入库操作逻辑，将待存储流式数据写入图数据库。通过定义一种通用的入库操作逻辑，从而形成了一套统一的数据入库流程，开发成本低且效率高。

下面结合图2实施例对步骤S101的一种可能的实施方式进行说明，图2示出了本申请实施例提供的数据入库方法的流程示意图二，如图2所示，步骤S101可以包括：

S201、对业务数据进行格式化处理，得到预设格式的业务数据。

S202、将预设格式的业务数据写入预设节点数据结构中，得到业务数据对应的节点数据。

其中，格式化处理可以为对业务数据进行JS对象简谱(JavaScript ObjectNotation，JSON)处理，预设格式可以为JSON格式。

在本实施例，将业务数据格式化为预设格式的业务数据，然后将预设格式的业务数据写入预设节点数据结构中，得到业务数据对应的节点数据，这样可以提前统一数据结构，降低后续计算复杂度。

其中，预设节点数据结构可以为“节点”、“节点属性”、“节点标签”、“关系数据”，其中，“关系数据”指的是预设格式的业务数据与图数据库中其他实体节点之间的关联关系，也就是，按照“节点”、“节点属性”、“节点标签”、“关系数据”的节点数据结构，将预设格式的业务数据转换为节点数据。

例如，针对两个JSON格式的业务数据（一个为待存储的JSON格式的业务数据，一个为图数据库中对应实体节点对应的JSON格式的业务数据），写入“节点”、“节点属性”、“节点标签”、“关系数据”的节点数据结构中，得到的节点数据包括：{"node":[{"id":"12","property":{"name":"张三","age":18},"label":"PERSON"},{"id":"20","property":{"name":"李四","age":28}},"label":"PERSON"],"relation":[{"id":"rel1","from": "12","to":"20","property":{"relationship":"朋友"}}]}。

其中，node表示节点，id表示节点标识，上述示例包括节点12和节点20，property表示节点属性表示，上述示例包括名字（name）和年龄（age）两个节点属性，label表示节点标签，上述示例为人（PERSON），relation表示关系数据，上述示例表示节点12与节点20之间是朋友关系。

S203、将节点数据写入预设流式数据结构中，得到待存储流式数据。

预设流式数据结构可以为流式计算引擎对应的数据结构，预设流式数据结构可以为“实体节点（EntityNode）”、“实体关系（EntityRelation）”、“实体属性（EntityProperty）”。因此，在统一了业务数据的数据结构之后，可以采用流式计算引擎提供的入库转换器将节点数据写入预设流式数据结构中，得到待存储流式数据。

其中，预设流式数据结构可以与预设节点数据结构具有对应关系，若预设节点数据结构可以为“节点”、“节点属性”、“节点标签”、“关系数据”，那么预设流式数据结构中的“实体节点”可以包括预设节点数据结构中的“节点”和“节点标签”，预设流式数据结构中的“实体关系”可以包括预设节点数据结构中的“关系数据”，预设流式数据结构中的“实体属性”可以包括预设节点数据结构中的“节点属性”。

本实施例的数据入库方法，对业务数据进行格式化处理，得到预设格式的业务数据，将预设格式的业务数据写入预设节点数据结构中，得到业务数据对应的节点数据，将节点数据写入预设流式数据结构中，得到待存储流式数据。通过统一的数据结构，从而降低后续计算复杂度。

下面结合图3实施例对待存储流式数据的入库操作逻辑的一种可能的实施方式进行说明，图3示出了本申请实施例提供的数据入库方法的流程示意图三，如图3所示，步骤S102包括：

S301、根据已存储的流式数据，以及待存储流式数据，确定业务数据对应节点的类型。

S302、根据业务数据对应节点的类型，确定待存储流式数据的入库操作逻辑。

采用流式计算引擎提供的基础算子（BaseOperator）、删除算子（DeleteOperate）以及组合算子（CompositeOperate），可以实现增查改删（CRUD）功能，其中，CRUD是指在做计算处理时的增加(Create)、检索(Retrieve)、更新(Update)和删除(Delete)几个单词的首字母简写。

具体地，采用基础算子可以在图数据库中已存储的流式数据中进行检索，根据已存储的流式数据，以及待存储流式数据，可以确定业务数据对应节点的类型，根据业务数据对应节点的类型，可以确定待存储流式数据的入库操作逻辑。

可以理解的是，在根据入库操作逻辑将待存储流式数据写入图数据库的过程中，若存在数据删除的情况，则可以采用删除算子删除数据，若存在数据新增的情况，则可以采用基础算子插入数据，若存在多个待存储流式数据，则可以采用组合算子依次新增实体节点或更新实体节点，并绘制实体节点之间的关系边。

可选地，步骤S302可以包括：

若业务数据对应节点的类型为新增实体节点，则确定入库操作逻辑为：依次包括新增实体节点的增加操作和待存储流式数据的写入操作的操作逻辑。

根据已存储的流式数据，以及待存储流式数据可以确定业务数据对应节点的类型，若已存储的流式数据不包括待存储流式数据，则说明业务数据对应节点的类型为新增实体节点，则确定入库操作逻辑为：依次包括新增实体节点的增加操作和待存储流式数据的写入操作的操作逻辑，也就是，在图数据库中新增实体节点，并将待存储流式数据的写入该新增实体节点中。

其中，在将待存储流式数据写入新增实体节点的同时，还可以绘制新增实体节点与图数据库中其他实体节点之间的关系边。关于关系边的绘制过程可以参见现有技术中的相关描述，在此不再赘述。

可选地，步骤S302可以包括：

若业务数据对应节点的类型为更新实体节点，则确定入库操作逻辑为：依次包括更新实体节点在图数据库中对应节点的流式数据的删除操作和待存储流式数据的写入操作的操作逻辑。

根据已存储的流式数据，以及待存储流式数据可以确定业务数据对应节点的类型，若确定待存储流式数据为对已存储的流式数据的更新，则说明业务对应节点的类型为更新实体节点，则确定入库操作逻辑为：依次包括更新实体节点在图数据库中对应节点的流式数据的删除操作和待存储流式数据的写入操作的操作逻辑，也就是，在图数据库中删除对应节点的流式数据，并将待存储流式数据该节点中，其中，可以采用删除算子实现数据删除。

其中，在将待存储流式数据写入节点的同时，还可以根据待存储流式数据，绘制该节点与图数据库中其他实体节点之间的关系边。关于关系边的绘制过程可以参见现有技术中的相关描述，在此不再赘述。

当然，若存在多个新增实体节点或更新实体节点，还可以采用组合算子实现多条关系边的绘制。

本实施例的数据入库方法，根据已存储的流式数据，以及待存储流式数据，确定业务数据对应节点的类型，根据业务数据对应节点的类型，确定待存储流式数据的入库操作逻辑。通过根据节点类型，从而提供了一种通用的入库操作逻辑。

下面结合图4实施例对步骤S103的一种可能的实施方式进行说明，图4示出了本申请实施例提供的数据入库方法的流程示意图四，如图4所示，步骤S103包括：

S401、将入库操作逻辑翻译为预设语言的可执行逻辑。

S402、根据可执行逻辑，将待存储流式数据写入图数据库。

其中，预设语言可以为CypherToNeo4j、GremlinToJanusGraph、GsqlToTigerGraph中的任意一种。

将入库操作逻辑翻译为预设语言的可执行逻辑，然后根据可执行逻辑，将待存储流式数据写入图数据库中，其中，可执行逻辑的逻辑执行步骤少于入库操作逻辑的逻辑执行步骤。

也就是，根据每一预设语言的特性优化入库操作逻辑，以减少入库操作逻辑的执行步骤，例如，入库操作逻辑中包括步骤1至步骤5，可以采用流式计算引擎提供的入库转换器，将入库操作逻辑翻译为预设语言的可执行逻辑，得到的可执行逻辑中将步骤1和步骤3合并到一个步骤执行，那么可执行逻辑的执行步骤为4个，而入库操作逻辑的执行步骤为5个，可见，可执行逻辑的逻辑执行步骤少于入库操作逻辑的逻辑执行步骤，如此，将数据入库的逻辑层（入库操作逻辑的获取过程）与物理层（翻译过程）进行了统一，大大提高了数据入库效率。

下面结合图5实施例对步骤S103的一种可能的实施方式进行说明，图5示出了本申请实施例提供的数据入库方法的流程示意图五，如图5所示，步骤S103包括：

S501、基于两阶段提交协议，向多个分布式节点发送数据写入请求。

S502、若接收到多个分布式节点返回的接收确认响应，则向多个分布式节点发送数据入库通知，以便多个分布式节点根据入库操作逻辑，将待存储流式数据写入图数据库。

分布式系统中包括多个分布式节点，各分布式节点可以存储有图数据库，各分布式节点存储的图数据库是相互隔离的。

为将待存储流式数据写入各分布式节点的图数据库中，可以基于两阶段提交协议（Two Phase Commitment Protocol，2PC），向多个分布式节点发送数据写入请求，若接收到多个分布式节点返回的接收确认响应，则向多个分布式节点发送数据入库通知，以便多个分布式节点根据入库操作逻辑，将待存储流式数据写入图数据库，其中，接收确认响应用于指示各分布式节点接收到数据写入请求，数据入库通知中封装有入库操作逻辑。关于2PC可以参见现有技术中的相关描述，在此不再赘述。

本实施例的数据入库方法，基于两阶段提交协议，向多个分布式节点发送数据写入请求，若接收到多个分布式节点返回的接收确认响应，则向多个分布式节点发送数据入库通知，以便多个分布式节点根据入库操作逻辑，将待存储流式数据写入图数据库。通过提供一个完整的闭环处理逻辑将知识图谱入库的过程简化，确保写入无误，并且将不同的底层数据库隔离，提供了一套数据入库的解决方案，完成跨数据库的事务一致性保证，以及通过引入入库转换器与两阶段提交，将知识图谱的入库逻辑进行屏蔽，降低开发者使用成本，使开发者不需深入了解图数据库的读写特性以及细节即可完成数据入库。

图6示出了本申请实施例提供的数据入库装置的结构示意图，数据入库装置可以集成在计算机设备中。如图6所示，数据入库装置60可以包括：

处理模块601，用于对业务数据进行结构化处理，得到所述业务数据对应的待存储流式数据；

确定模块602，用于根据预设的图数据库中已存储的流式数据，以及所述待存储流式数据，确定所述待存储流式数据的入库操作逻辑；

写入模块603，用于根据所述入库操作逻辑，将所述待存储流式数据写入所述图数据库。

可选地，处理模块601，具体用于：

可选地，确定模块602，具体用于：

可选地，写入模块603，具体用于：

本实施例提供的数据入库装置，实现过程和实现原理与上述方法实施例提供的数据入库方法类似，在此不再赘述。

图7示出了本申请实施例提供的计算机设备的结构示意图，如图7所示，计算机设备70包括：处理器701、存储器702和总线703，所述存储器702存储有所述处理器701可执行的计算机程序，当计算机设备70运行时，所述处理器701与所述存储器702之间通过总线703通信，所述处理器701执行所述计算机程序，以执行上述方法实施例。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述方法实施例。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，RandomAccess Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。

Claims

1.一种数据入库方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，所述对业务数据进行结构化处理，得到所述业务数据对应的待存储流式数据，包括：

3.根据权利要求1所述的方法，其特征在于，所述根据预设的图数据库中已存储的流式数据，以及所述待存储流式数据，确定所述待存储流式数据的入库操作逻辑，包括：

4.根据权利要求3所述的方法，其特征在于，所述根据所述业务数据对应节点的类型，确定所述待存储流式数据的入库操作逻辑，包括：

5.根据权利要求3所述的方法，其特征在于，所述根据所述业务数据对应节点的类型，确定所述待存储流式数据的入库操作逻辑，包括：

6.根据权利要求1所述的方法，其特征在于，所述根据所述入库操作逻辑，将所述待存储流式数据写入所述图数据库，包括：

7.根据权利要求1所述的方法，其特征在于，所述根据所述入库操作逻辑，将所述待存储流式数据写入所述图数据库，包括：

8.一种数据入库装置，其特征在于，包括：

9.一种计算机设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的计算机程序，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述处理器执行所述计算机程序，以执行权利要求1至7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行权利要求1至7任一项所述的方法。