Method and apparatus for storing and processing fusion map

Abstract

The embodiment of the present specification provides a kind of storage and processing method of fusion atlas.According to the storage method, first and second service atlas are read from first file and second file respectively, determine the first-order neighbor relationship of several fusion nodes and of two service atlas, any fusion node is the node that one node from first service atlas and another node from second service atlas are fused.The node information of several fusion nodes and the edge information indicated by its first-order neighbor relationship are only stored to third file.In the processing stage, when it is determined that the task processing request involves the target fusion node in the fusion atlas, the fusion node information of the target fusion node is read from the third file storing the fusion result;And the third node information of third node is read from the first file storing the first service atlas, wherein the third node is the first-order neighbor node of the target fusion node;According to at least the fusion node information and the third node information, generate response message.

Description

Technical Field

[0001] This specification relates to one or more embodiments of a knowledge graph platform, and more particularly to a method and apparatus for storing and processing a fused knowledge graph. Background Technology

[0002] A knowledge graph is a semantic network that describes various entities and their relationships in the real world using a graph model. Nodes in this semantic network correspond to entities, and edges correspond to relationships between entities. By combining expert experience and prior data, knowledge graphs can be used to explain the correctness of relationships and rules within the graph, as well as to infer relationships and rules not present in the graph.

[0003] A knowledge graph platform is a middleware with knowledge graphs as its core capability, providing various businesses with the capabilities of knowledge management, knowledge reasoning, and knowledge services, as well as graph solutions to support these capabilities.

[0004] To enrich the content of knowledge graphs and thus improve the knowledge service capabilities of knowledge graph platforms, it is sometimes necessary to obtain multiple business graphs from multiple business platforms and then merge them. Each individual business graph records the entity relationship network maintained by its corresponding business platform, and sometimes also includes the platform's private data. Therefore, how to more effectively store and process the merged graphs becomes a challenge and problem faced by knowledge graph platforms. Summary of the Invention

[0005] In view of the above problems, this specification provides a storage method and a processing method for fused graphs; in the storage stage, redundant storage is avoided by storing only entities directly related to the fusion in the fusion result; in the processing stage, the full graph information is obtained by merging and reading, without affecting the task processing of the fused graph, thereby improving the storage utilization and performance of the knowledge graph platform.

[0006] According to the first aspect, a fusion map storage method is provided, including:

[0007] Read the first service map from the first file and the second service map from the second file respectively;

[0008] Determine several fusion nodes and their first-order neighbor relationships in the first service graph and the second service graph. Any fusion node is a node that merges a node from the first service graph and another node from the second service graph.

[0009] Only the node information of the aforementioned fused nodes, and the edge information indicating their first-order neighbor relationships, are stored in the third file.

[0010] According to one implementation, the first service graph and / or the second service graph are directed graphs; the edge information indicated by the first-order neighbor relationship includes at least the edge direction of the connecting edge with the fusion node as one of the endpoints, and the index information of the connected nodes.

[0011] In one embodiment, the plurality of fusion nodes include a target fusion node obtained by fusion of a first node in a first service graph and a second node in a second service graph; the edge information indicating the first-order neighbor relationship includes edge information of the connection edge between the target fusion node and a third node, wherein the third node is a node in the first service graph connected to the first node, or a node in the second service graph connected to the second node; the third file does not contain node information of the third node.

[0012] In one embodiment, the first file, the second file, and the third file are stored in different storage locations.

[0013] According to one implementation, determining a plurality of fusion nodes and their first-order neighbor relationships in a first service graph and a second service graph specifically includes: performing entity linking operations between each node in the first service graph and each node in the second service graph to determine the plurality of fusion nodes.

[0014] In one embodiment, the target fusion node may indicate a single entity whose node information is obtained by merging the attribute features of the first node and the second node respectively; or, the target fusion node may indicate a class of entities whose node information includes the target entity type of the class of entities and instance identification information of a plurality of instances belonging to the target entity type, wherein the target entity type is obtained by merging the entity type of the first node and the entity type of the second node; and the instance identification information is a combination of instance identifiers belonging to the first node and instance identifiers belonging to the second node.

[0015] According to the second aspect, a method for processing graph tasks is provided, including:

[0016] Receive task processing requests for the fusion graph of the first service graph and the second service graph;

[0017] In response to determining that the task processing request involves a target fusion node in the fusion graph, the fusion node information of the target fusion node is read from a third file storing the fusion results; and the third node information of the third node is read from a first file storing the first service graph, wherein the target fusion node is a node obtained by fusion of a first node in the first service graph and a second node in the second service graph; and the third node is connected to the first node in the first service graph.

[0018] A response message for the task processing request is generated based at least on the fusion node information and the third node information.

[0019] In one embodiment, the method further includes: in response to determining that the task processing request only involves the first business graph, reading relevant data of the target entity node specified in the task processing request from the first file, and generating a response message based on the relevant data.

[0020] In one embodiment, the task processing request indicates processing the first-order neighbor node information of the third node; determining the target fusion node in the fusion result of the first service graph and the second service graph involved in the task processing request includes: determining that the first-order neighbor nodes of the third node include the target fusion node.

[0021] In another embodiment, the task processing request instructs the processing of at least one-order neighbor node information of the target fusion node, or instructs the processing of at least two-order neighbor node information of the third node; the method further includes: reading the first-order neighbor relationship information of the target fusion node from the third file, and reading the fourth node information of the fourth node from the second file storing the second service graph based on the first-order neighbor relationship information, wherein the fourth node is connected to the second node in the second service graph; correspondingly, determining the response message of the task processing request includes: determining the response message based on the fusion node information, the third node information and the fourth node information.

[0022] In one embodiment, generating a response message for the task processing request specifically includes including at least the fusion node information and the third node information in the response message.

[0023] In another embodiment, generating a response message for the task processing request includes: performing graph processing based at least on the fused node information and the third node information, and including the graph processing result in the response message.

[0024] According to one embodiment, the method further includes: receiving a first update request to update the node information of the target fusion node and / or its first-order neighbor relationships; and updating the third file in response to the first update request.

[0025] According to one embodiment, the method further includes receiving a second update request, requesting to update the node information of a fifth node in the first service graph, wherein the fifth node does not belong to the fusion result; and updating the first file in response to the second update request.

[0026] According to a third aspect, a fusion map storage device is provided, comprising:

[0027] The reading unit is configured to read the first service map from the first file and the second service map from the second file, respectively.

[0028] The determining unit is configured to determine a number of fusion nodes and their first-order neighbor relationships in the first service graph and the second service graph. Any fusion node is a node that merges a node from the first service graph and another node from the second service graph.

[0029] The storage unit is configured to store only the node information of the plurality of fused nodes and the edge information indicating their first-order neighbor relationships into a third file.

[0030] According to the fourth aspect, a method for processing graph tasks is provided, including:

[0031] The receiving unit is configured to receive a task processing request for a fusion graph of the first service graph and the second service graph.

[0032] The reading unit is configured to, in response to determining that the task processing request involves a target fusion node in the fusion graph, read fusion node information of the target fusion node from a third file storing fusion results; and read third node information of a third node from a first file storing a first service graph, wherein the target fusion node is a node obtained by merging a first node in the first service graph and a second node in the second service graph; and the third node is connected to the first node in the first service graph.

[0033] The generation unit is configured to generate a response message for the task processing request based at least on the fusion node information and the third node information.

[0034] According to a fifth aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first or second aspect.

[0035] According to a sixth aspect, a computing device is provided, including a memory and a processor, characterized in that the memory stores executable code, and when the processor executes the executable code, it implements the method described in the first aspect or the second aspect.

[0036] In the embodiments of this specification, during the storage stage, redundant storage is avoided by storing only entities directly related to the fusion in the fusion result; during the processing stage, the full graph information is obtained by merging and reading, which does not affect the task processing of the fused graph and improves the storage utilization and performance of the knowledge graph platform. Attached Figure Description

[0037] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 A schematic diagram illustrating map fusion according to one embodiment is shown;

[0039] Figure 2 A schematic diagram of a spectrum storage method is shown;

[0040] Figure 3 A flowchart illustrating a fusion graph storage method according to one embodiment is shown;

[0041] Figure 4 A schematic diagram of a graph fusion storage according to one embodiment is shown;

[0042] Figure 5 The result file of the map fusion storage is displayed more clearly;

[0043] Figure 6 A flowchart of a method for processing a graph task according to one embodiment is shown;

[0044] Figure 7 A schematic block diagram of a fusion map storage device according to one embodiment is shown;

[0045] Figure 8 A schematic block diagram of a map task processing apparatus according to one embodiment is shown. Detailed Implementation

[0046] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0047] As mentioned earlier, in order to enrich the content of knowledge graphs and thus improve the knowledge service capabilities of knowledge graph platforms, these platforms often acquire multiple business graphs from various business platforms and merge them to obtain a fused graph. This fused graph, as a more comprehensive graph, can then be used for subsequent knowledge graph-based task processing.

[0048] Figure 1 This diagram illustrates a spectrum fusion process according to one embodiment. Figure 1 As shown, business graph A can come from business platform A, such as an e-commerce platform; business graph B can come from business platform B, such as an electronic payment platform. The knowledge graph platform obtains the corresponding business graphs A and B from business platform A and business platform B respectively, and then merges them.

[0049] The process of graph fusion can be mainly achieved through entity chaining and entity normalization.

[0050] Entity chaining refers to the process of inferring, from a business application perspective, whether any two business entities in a graph share the same characteristics. For example, whether two users (as business entities) belong to the same household, two payment codes (as business entities) belong to the same store, or two accounts (as business entities) belong to the same individual, and so on. In practice, entity chaining typically involves representing each entity as a vector, determining the distance between vectors to ascertain the similarity or matching degree between entities, and identifying multiple entity nodes with high similarity or matching degrees as entities possessing the same characteristics.

[0051] Entity unification refers to further processing multiple entities identified as having the same characteristics based on the entity chaining results, to obtain a unique entity. In a graph, this can be represented by merging multiple entities obtained from entity chaining into a single entity node. Specific merging processes include merging entity attributes, merging relationships, and so on. Relationships between multiple entities before unification will be merged and attached to the unified entity after unification.

[0052] exist Figure 1 In the example, assume that through entity chaining, a node N1 (hereinafter referred to as the first node) in business graph A is determined to have the same characteristics as a node N2 (hereinafter referred to as the second node) in business graph B. Entity normalization merges the first node N1 and the second node N2 to obtain a fused node T, which serves as an entity node in the fused graph. Correspondingly, the neighboring nodes N3 and N5 of the first node N1 in business graph A, and the neighboring nodes N4 and N6 of the second node N2 in business graph B, will all become neighbors of the fused node T and be connected to it. Thus, by normalizing and merging entities with the same characteristics obtained through entity chaining, a fused graph is obtained. It can be seen that some nodes in this fused graph are fused nodes obtained by merging entity nodes from different business graphs, while other nodes are original nodes from a single business graph.

[0053] In practice, each business platform continuously maintains, builds, and updates its business graph. For example, business platform A may continuously update its business graph A. To avoid the interference of graph fusion on the construction of the business graph itself, one related technology stores the fused graph and each individual business graph independently.

[0054] Figure 2 This diagram illustrates one method of storing a graph. For example... Figure 2As shown, business graph A is stored in file A, business graph B is stored in file B, and the entire fused graph is stored in file C. These three files are independent of each other and stored in different locations on the knowledge graph platform. This ensures independent storage of each graph, avoiding interference from graph fusion on the construction of the business graph itself.

[0055] However, the inventors found that the above storage method is still not ideal. It's understandable that the entire fusion graph actually contains all the information from the various business graphs (A and B) participating in the fusion. Therefore, file C repeatedly stores a large amount of information from the original nodes in files A and B, resulting in significant data redundancy and consuming a large amount of storage space. Furthermore, the process of generating the fusion graph or storing it in file C involves numerous operations of copying the original node data from files A and B to file C, increasing the runtime of the graph fusion task itself and reducing the performance of the knowledge graph platform. In addition, since the fusion graph stores the entire graph data, if any entity or relationship in any source business graph (graph A or graph B) changes and needs to be updated, both the source business graph and the fusion graph need to be updated synchronously, causing frequent updates to the fusion graph and impacting the performance of the knowledge graph platform.

[0056] In view of this, this specification proposes an improved scheme. In the storage stage, only entities directly related to the fusion are stored in the fusion result, avoiding redundant storage. In the processing stage, the entire graph information is obtained through merge reading, without affecting the task processing of the fused graph, thereby improving the storage utilization and performance of the knowledge graph platform. The implementation of this improved scheme is described in detail below.

[0057] Figure 3 A flowchart illustrating a fusion graph storage method according to one embodiment is shown. This method can be executed through a computing platform, which can be any computing unit, server, device, device cluster, etc., with computing and processing capabilities. In a specific example, the computing platform is a knowledge graph platform. Figure 4 A schematic diagram of a graph fusion storage according to one embodiment is shown below. Figure 4 ,describe Figure 3 The steps of the method shown are as follows.

[0058] First, in step 31, the first service map is read from the first file and the second service map is read from the second file.

[0059] It's understandable that both the first and second business graphs are knowledge graphs with business entities as nodes. A single node corresponding to a business entity in the graph can represent a single specific entity, such as a user, a merchant, or a product, or it can indicate a class of entities, such as programmers, salespeople, etc. When an entity node indicates a single entity, the corresponding node information can include the attribute characteristics of that single entity, such as the basic attribute characteristics of a single user. When an entity node indicates a class of entities, the corresponding node information can include the entity type of that class of entities, and instance identifier information for several instances belonging to that entity type. For example, if the entity type of an entity node is "programmer," the corresponding instance identifier information can include Zhang San, Li Si, etc., whose identities are programmers. Business graphs are typically directed graphs. Therefore, the edge information of the connecting edges between entity nodes generally includes the direction of the edge, the index of the connected node, and the relationship type between the entities indicated by the edge.

[0060] exist Figure 4 In the example, the first business graph and the second business graph are represented as business graph A and business graph B, respectively. In one embodiment, business graph A and business graph B come from different business platforms. For example, as mentioned above, business graph A comes from business platform A, and business graph B comes from business platform B. Of course, business graph A and business graph B can also be different graphs maintained by the same business platform from different business perspectives, which is not limited here.

[0061] Before the fusion and storage of the knowledge graphs, each source business graph is stored in its corresponding file; that is, the first business graph is stored in the first file, and the second business graph is stored in the second file. Each file stores the node information of each entity node in the corresponding business graph, and the edge information of the connecting edges between entity nodes. The first and second files are independent files, stored in different storage locations on the knowledge graph platform. The file format and form are any format and form suitable for storing graph data in this field, and are not limited here.

[0062] Based on this, in step 32, several fusion nodes of the first service graph and the second service graph and their first-order neighbor relationships are determined. Any fusion node is a node that merges a node from the first service graph and another node from the second service graph.

[0063] The above fusion process can be achieved through the entity chaining operation and entity normalization operation described earlier. It should be noted that the entity chaining operation performed in this step is applied to nodes from two different business graphs, and the resulting fused node is obtained by merging nodes from the two different business graphs. The first-order neighbor relationships of the fused node can be obtained based on the entity normalization operation.

[0064] Then, in step 33, only the node information of a number of merged nodes and the edge information indicating their first-order neighbor relationships are stored in the third file. In other words, the node information of the original nodes other than the merged nodes, as well as the connection relationships between the original nodes, are not stored in the third file.

[0065] Combination Figure 4 Explanation will be provided. In Figure 4 In this context, it is still assumed that the first node N1 in business graph A and the second node N2 in business graph B have the same characteristics. They are merged through entity normalization to obtain a fused node T, which serves as the entity node in the fused graph. Figure 2 The difference is that the third file used to store the fusion results only stores the node information of the fused node T itself, and the edge information corresponding to the first-order neighbor relationships of the fused node T. Figure 4 In the example, the edges corresponding to the first-order neighbors of node T include, for example, E3, E4, E5, and E6. Therefore, the third file can store the node information of node T, as well as the edge information of edges E3, E4, E5, and E6. That is, only the nodes and edges shown by solid lines are stored.

[0066] More specifically, if the fusion node T indicates a single entity, the node information of node T may include the attribute characteristics of that single entity, which can be obtained by merging the attribute characteristics of the source nodes being merged. For example, if the first node N1 indicates account 1 and the second node indicates account 2, both indicating the same natural person, then the attribute characteristics of the fusion node T can be the attribute characteristics of the natural person obtained by merging the attribute characteristics of account 1 and account 2. If the fusion node T indicates a class of entities, the node information of node T includes the entity type of that class of entities, and the instance identifier information of several instances belonging to that entity type. It should be noted that when each node corresponds to a class of entities, the entity type of the fusion node T is generally a new entity type obtained by merging the entity types of the source nodes being merged. For example, assuming the first node N1 indicates a programmer and the second node N2 indicates a father, then the entity type of the fusion node T can represent an entity type that is both a programmer and a father, and the instance identifier information contained therein is a combination of the instance identifiers belonging to the first node and the instance identifiers belonging to the second node (which can be set as intersection or union, etc., as needed).

[0067] The edge information stored in the fusion result may include the direction of the edge (e.g., outgoing edge, incoming edge) and the index information of the connected node. For example, the edge information of edge E3 may include (outgoing edge, node N3). In one embodiment, the edge information stored in the fusion result may also include the relationship type information between the entities corresponding to the edge. In another embodiment, the edge information stored in the third file is only used to locate the first-order neighbor nodes directly connected to the fusion node, and does not include the relationship type information corresponding to each connecting edge; the aforementioned relationship type information may be stored in the file of the original business graph.

[0068] As can be seen, the third file does not store node information for any other original nodes that are not merged nodes, including nodes directly connected to the corresponding node of the merged node in business graph A or business graph B, or in other words, the first-order neighbor nodes of the merged node. For example, node N3 in business graph A is connected to the first node N1 (the corresponding node of merged node T in business graph A), therefore, node N3 is a first-order neighbor node of merged node T. However, the third file only stores the edge information of edge E3 pointing to node N3, and does not store the node information of the neighbor node N3 itself. Furthermore, the third file does not store node information for other original nodes unrelated to the merged node. That is to say, Figure 4 The nodes and edges shown by the dashed lines in the figure below are stored only in their source graph files, not in the fusion result file.

[0069] Figure 5 The result file of the graph fusion storage is shown more clearly. It can be seen that the third file only stores the node information of the fused node T and the edge information of edges E3, E4, E5, and E6, without storing the node information of any original nodes that are not fused nodes, nor the connection relationships between the original nodes. This node information and connection relationship information between the original nodes are only stored in the corresponding source business graph file (the first or second file). This greatly reduces the amount of redundant data storage and saves storage space. Since only the entity nodes directly related to the fusion and their first-order neighbor relationships need to be stored, there is no need to copy a large amount of data from other nodes from the source business graph file, accelerating the execution of the fusion task and improving platform efficiency.

[0070] The above description pertains to a single fusion node T. It is readily understood that the fusion result can include multiple fusion nodes; the storage of each fusion node can refer to the above method. Furthermore, it is understood that although the above embodiments are described using two business graphs A and B as examples, the above storage method concept can be applied to the fusion of more business graphs.

[0071] The above storage method saves storage space and accelerates the fusion task without affecting the use of the fused graph. By using a merge read method, graph tasks based on the fused graph can still be processed effectively. The graph reading and graph task processing process is described below.

[0072] Figure 6 A flowchart illustrating a method for processing a knowledge graph task according to one embodiment is shown. This method can be executed through a knowledge graph platform, which can be manifested as any computing unit, server, device, device cluster, etc., with computing and processing capabilities. Figure 6 As shown, the map processing task may include the following steps.

[0073] In step 61, a task processing request for the fusion graph of the first and second service graphs is received. This task processing request may be sent by an application using the knowledge graph platform or by a user.

[0074] According to the aforementioned storage method, the graph data of the first business graph A is stored in the first file A, the graph data of the second business graph B is stored in the second file, and the fusion result of the first business graph A and the second business graph B is stored in the third file. The third file only stores node information of several fused nodes and edge information indicating the first-order neighbor relationships of each fused node. The graph processing task requested in the above task processing request can be an entity reading task, an entity reasoning task, etc. Generally, the task processing request will specify the target entity node to be processed. As a graph processing task, in order to process the target entity node, it is usually also necessary to obtain the neighbor node information related to the target entity node.

[0075] Next, in step 62, it is determined whether the task processing request involves a fusion node. Cases where the task processing request involves a fusion node include situations where the target entity node to be processed is itself a fusion node, or where the target entity node is not a fusion node, but its neighboring nodes include fusion nodes. If the task processing request does not involve a fusion node and only involves a single source service graph, such as an entity node in the first service graph, then in step 63, relevant data of the target entity node is read from the storage file corresponding to the source service graph, such as the first file A, and a response message is generated based on this relevant data.

[0076] If it is determined that the task processing request involves a certain fusion node in the fusion result, hereinafter referred to as the target fusion node, then in step 64, the fusion node information of the target fusion node is read from the third file storing the fusion result; and the third node information of the third node is read from the first file storing the first service graph. It is assumed that the target fusion node is the node obtained by merging the first node in the first service graph and the second node in the second service graph; and the third node is connected to the first node in the first service graph, that is, the third node is a first-order neighbor node of the target fusion node.

[0077] The following is combined Figure 4 This describes various scenarios involving fusion nodes in the task processing request, and the specific execution method of step 64 under different scenarios.

[0078] In one embodiment, the target entity node in the task processing request is the aforementioned third node (which is not itself a fusion node), and the task processing request indicates the processing of the first-order neighbor node information of this third node. Combined with... Figure 4 The third node could be, for example, node N3 in business graph A. Node N3 itself is not a fusion node, but its first-order neighbor includes node N1. Node N1 (the first node) and node N2 (the second node) in business graph B are merged to form fusion node T. Therefore, the first-order neighbor of N3 includes the fusion node, and the task processing request involves the fusion node.

[0079] In this case, in step 64, it is necessary to read the node information of the third node N3 from the first file, and the node information of the merged node T from the third file. If N3 has other first-order neighbor nodes that are not merged, then it is also necessary to read the first-order neighbor node information of these non-merged nodes from the first file.

[0080] In another embodiment, the target entity node in the task processing request is the aforementioned third node (which is not itself a fusion node), such as node N3 in service graph A; and the task processing request indicates processing the second-order (or higher) neighbor node information of the third node. Figure 4 As can be seen, the first-order neighbor nodes of node N3 include the fused node T, which is obtained by merging node N1 in graph A and node N2 in graph B. This task processing request clearly involves the fused node. Furthermore, using fused node T as a bridge and intermediate node, the second-order neighbor nodes of the third node N3 will also include nodes from the business graph B.

[0081] In this case, in step 64, in addition to reading the node information of the third node N3 from the first file and the node information of the fusion node T from the third file, it is also necessary to read the first-order neighbor relationship information of the target fusion node from the third file. As mentioned earlier, the first-order neighbor relationship information is the edge information of the fusion node, which includes the direction of the edge and the index of the connected node. Therefore, based on this first-order neighbor relationship information, the direct neighbor node of the target fusion node in another service graph can be determined as the second-order neighbor node of the aforementioned third node. Therefore, based on the first-order neighbor relationship information of the aforementioned target fusion node, the fourth node information of the fourth node can be read from the second file storing the second service graph, wherein the fourth node is connected to the second node (N2) in the second service graph. Figure 4 In the graph B, the fourth node can include N4 and N6, both of which are directly connected to the source node N2 (the second node) of the fusion node T. Therefore, nodes N4 and N6 should also be considered as second-order neighbors of the third node N3.

[0082] Of course, if there are other non-fusion node neighbor nodes of node N3 in business graph A, then these non-fusion nodes and their connection information need to be read from the first file.

[0083] In yet another embodiment, the target entity node in the task processing request is the fusion node itself, for example, it is... Figure 4 The fusion node T in the target fusion node, and the task processing request indicates that at least one-order neighbor node information (which may be first-order, second-order or above) of the target fusion node be processed.

[0084] In this case, step 64 requires reading the node information of the target fusion node T, as well as its first-order neighbor information, from the third file. Based on this first-order neighbor information, the first-order neighbors of the target fusion node T in service graphs A and B can be determined. Thus, the direct neighbor nodes of the target fusion node in the first service graph read from the first file are called the third nodes; the direct neighbor nodes of the target fusion node in the second service graph read from the second file are called the fourth nodes. Combined with... Figure 4 In this embodiment, the third node may include N3 and N5, which are connected to the source node N1 (first node) of the fusion node T in graph A; the fourth node may include N4 and N6, which are connected to the source node N2 (second node) of the fusion node T in graph B.

[0085] If the task processing request requests the processing of first-order neighbor node information of the target fusion node, then reading the node information of the fusion node T, the node information of the third node, and the node information of the fourth node will satisfy the conditions for executing the task. If the task processing request requests the processing of second-order (or higher) neighbor node information of the target fusion node, then it is also necessary to read the further neighbor node information of the third node from the first file and the further neighbor node information of the fourth node from the second file.

[0086] Considering the above situations, if the task processing request involves a target fusion node, then in step 64, at least the fusion node information of the target fusion node needs to be read from the third file; and at least one direct neighbor node (third node) of the target fusion node in the source service graph needs to be read from the storage file of a source service graph. Of course, in different specific situations of different embodiments, in addition to the above basic data, it may be necessary to read more other data, which is not limited here.

[0087] Based on the data read in step 64, in step 65, at least based on the fusion node information and the third node information, a response message for the task processing request is generated.

[0088] In one embodiment, the data read in step 64, including at least the fusion node information and the third node information, can be included in the response message. In another embodiment, graph processing is performed based on the data read in step 64, including at least the fusion node information and the third node information, and the graph processing result is included in the response message. This graph processing may include reasoning, computation, and other processing procedures of the knowledge graph, which are not limited here.

[0089] In the above process, response messages are generated by reading fusion node information from the third file and third node information from the first file. Although the first file, third file, and other files are stored independently, through the above merging and processing, the response message includes information from the fusion graph. Therefore, the content of the generated response message is no different from that generated based on the fully stored fusion graph. Thus, when the generated response message is returned to the requester (an application or a user), the user experience is identical to that of the fully stored fusion graph.

[0090] Furthermore, in one implementation, during the graph task processing phase, the knowledge graph platform may also receive update requests regarding the business graph. These update requests may originate from data updates on the source business platform of the business graph, such as updates to entity nodes, updates to relationships between entities, and so on. Figure 5 The graph storage method shown will also be very advantageous for handling update requests.

[0091] Specifically, in one example, the knowledge graph platform receives a first update request, which requests updates to the node information and / or first-order neighbor relationships of the fused node. For example, this first update request could originate from business platform A, requesting updates to the node information and / or connection relationships of node N1 in business graph A. Since node N1 is the source node of fused node T, this update request actually needs to update the node information and / or first-order neighbor relationships of the fused node. In such a case, in response to this update request, the aforementioned third file is updated. Optionally, corresponding information in the first file can also be updated accordingly.

[0092] In another example, the knowledge graph platform receives a second update request, requesting an update to the node information of a node in the first business graph that does not belong to the fusion result; this node will be referred to below as the fifth node. For example, combining... Figure 4 The fifth node can be node N3, N5, or N7. In this case, in response to the second update request, the first file is updated to record the new node information of the fifth node. That is, when the node to be updated is not a fusion node, only the storage file of the business graph to which the node belongs needs to be updated, and the third file storing the fusion results does not need to be updated.

[0093] In practice, fusion nodes only account for a small portion of the total nodes in the business graph. (Review) Figure 2 The relevant scheme stipulates that an update to any node in any graph will trigger an update to the third file storing the fused graph; and in Figure 5 In the storage scheme shown, only in the rare cases where the node to be updated is a fusion node does the fusion result file (third file) need to be updated; in most cases where the node to be updated is not a fusion node, only the source service graph file needs to be updated. Compared to Figure 2 The proposed solution significantly reduces the frequency of updating the fusion result files and greatly improves the efficiency of the fusion process, resulting in a significant improvement in the overall performance of the knowledge graph platform.

[0094] According to another embodiment, with Figure 3 Corresponding to the storage method shown, this specification also provides a fusion graph storage device, which can be deployed in a knowledge graph platform. The knowledge graph platform can be any computing unit, platform, server, device, device cluster, etc., with computing and processing capabilities. Figure 7 A schematic block diagram of a fused map storage device according to one embodiment is shown. Figure 7 As shown, the device 700 includes:

[0095] Reading unit 71 is configured to read a first service map from a first file and a second service map from a second file, respectively.

[0096] The determining unit 72 is configured to determine a number of fusion nodes and their first-order neighbor relationships in the first service graph and the second service graph. Any fusion node is a node that merges a node from the first service graph and another node from the second service graph.

[0097] Storage unit 73 is configured to store only the node information of the plurality of fused nodes and the edge information indicating their first-order neighbor relationships into a third file.

[0098] Each unit of the above device can be configured to perform... Figure 3 The method and steps, and the specific execution process, can be referred to in conjunction with the previous steps. Figure 3 The description is omitted.

[0099] According to yet another embodiment, with Figure 6 Corresponding to the processing method shown, this specification also provides an apparatus for processing graph tasks. This apparatus can be deployed in a knowledge graph platform, which can be any computing unit, platform, server, device, device cluster, etc., with computing and processing capabilities. Figure 8 A schematic block diagram of a map task processing apparatus according to one embodiment is shown. Figure 8 As shown, the device 800 includes:

[0100] The receiving unit 81 is configured to receive a task processing request for a fusion graph of the first service graph and the second service graph.

[0101] The reading unit 82 is configured to, in response to determining that the task processing request involves a target fusion node in the fusion graph, read fusion node information of the target fusion node from a third file storing fusion results; and read third node information of a third node from a first file storing a first service graph, wherein the target fusion node is a node obtained by merging a first node in the first service graph and a second node in the second service graph; and the third node is connected to the first node in the first service graph.

[0102] The generation unit 83 is configured to generate a response message for the task processing request based at least on the fusion node information and the third node information.

[0103] According to other embodiments, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform the aforementioned combination. Figure 3 or Figure 6 The method described.

[0104] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to achieve the foregoing combination. Figure 3 or Figure 6 The method described.

[0105] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0106] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for storing fused graphs, comprising: Read the first service map from the first file and the second service map from the second file respectively; Determine several fusion nodes and their first-order neighbor relationships in the first service graph and the second service graph. Any fusion node is a node that merges a node from the first service graph and another node from the second service graph. Only the node information of the aforementioned fused nodes, and the edge information indicating their first-order neighbor relationships, are stored in the third file.

2. The method according to claim 1, wherein, The first service graph and / or the second service graph are directed graphs; the edge information indicated by the first-order neighbor relationship includes at least the edge direction of the connecting edge with the fusion node as one of the endpoints, and the index information of the connected nodes.

3. The method according to claim 1, wherein, The plurality of fusion nodes include a target fusion node obtained by fusing a first node in the first service graph and a second node in the second service graph; The edge information indicated by the first-order neighbor relationship includes the edge information of the connection edge between the target fusion node and the third node, wherein the third node is a node in the first service graph that is connected to the first node, or a node in the second service graph that is connected to the second node. The third file does not contain node information for the third node.

4. The method according to claim 1, wherein, The first file, the second file, and the third file are stored in different storage locations.

5. The method according to claim 1, wherein, Determine several fusion nodes of the first and second service graphs and their first-order neighbor relationships, including: For each node in the first service graph, an entity linking operation is performed with each node in the second service graph to determine the plurality of fusion nodes.

6. The method according to claim 3, wherein, The target fusion node indicates a single entity whose node information is obtained by merging the attribute features of the first and second nodes; or... The target fusion node indicates a type of entity, and its node information includes the target entity type of the type of entity, and instance identification information of several instances belonging to the target entity type, wherein the target entity type is obtained by merging the entity type of the first node and the entity type of the second node. The instance identification information is a combination of the instance identifier belonging to the first node and the instance identifier belonging to the second node.

7. A method for processing graph tasks, comprising: Receive task processing requests for the fusion graph of the first service graph and the second service graph; In response to determining that the task processing request involves a target fusion node in the fusion graph, the fusion node information of the target fusion node is read from a third file storing the fusion results; And read the third node information of the third node from the first file storing the first service graph, wherein the target fusion node is the node obtained by fusion of the first node in the first service graph and the second node in the second service graph; the third node is connected to the first node in the first service graph; the third file only stores the node information of several fusion nodes and the edge information indicating the first-order neighbor relationship of each fusion node; A response message for the task processing request is generated based at least on the fusion node information and the third node information.

8. The method according to claim 7, further comprising: In response to determining that the task processing request only involves the first business graph, relevant data of the target entity node specified in the task processing request is read from the first file, and a response message is generated based on the relevant data.

9. The method according to claim 7, wherein, The task processing request indicates the processing of the first-order neighbor node information of the third node; Determining that the task processing request involves a target fusion node in the fusion graph includes: determining that the first-order neighbor nodes of the third node include the target fusion node.

10. The method according to claim 7, wherein, The task processing request indicates processing at least one first-order neighbor node information of the target fusion node, or indicates processing at least two second-order neighbor node information of the third node. The method further includes: reading the first-order neighbor relationship information of the target fusion node from the third file, and reading the fourth node information of the fourth node from the second file storing the second service graph based on the first-order neighbor relationship information, wherein the fourth node is connected to the second node in the second service graph; Generating a response message for the task processing request includes: generating the response message based on the fusion node information, the third node information, and the fourth node information.

11. The method according to claim 7, wherein, Generate a response message for the task processing request, including: The fusion node information and the third node information should be included in the response message at least.

12. The method according to claim 7, wherein, Generate a response message for the task processing request, including: Graph processing is performed based at least on the fused node information and the third node information, and the graph processing result is included in the response message.

13. The method according to claim 7, wherein, The target fusion node indicates a single entity whose node information is obtained by merging the attribute features of the first and second nodes; or... The target fusion node indicates a type of entity, and its node information includes the target entity type of the type of entity, and instance identification information of several instances belonging to the target entity type, wherein the target entity type is obtained by merging the entity type of the first node and the entity type of the second node. The instance identification information is a combination of the instance identifier belonging to the first node and the instance identifier belonging to the second node.

14. The method of claim 7, further comprising: Receive a first update request, requesting an update of the node information of the target fusion node and / or its first-order neighbor relationships; In response to the first update request, the third file is updated.

15. The method of claim 7, further comprising: Receive a second update request, requesting to update the node information of the fifth node in the first service graph, wherein the fifth node does not belong to the fusion result; In response to the second update request, the first file is updated.

16. A fused map storage device, comprising: The reading unit is configured to read the first service map from the first file and the second service map from the second file, respectively. The determining unit is configured to determine a number of fusion nodes and their first-order neighbor relationships in the first service graph and the second service graph. Any fusion node is a node that merges a node from the first service graph and another node from the second service graph. The storage unit is configured to store only the node information of the plurality of fused nodes and the edge information indicating their first-order neighbor relationships into a third file.

17. An apparatus for processing map tasks, comprising: The receiving unit is configured to receive a task processing request for a fusion graph of the first service graph and the second service graph. The reading unit is configured to read the fusion node information of the target fusion node from a third file storing the fusion results in response to determining that the task processing request involves a target fusion node in the fusion graph; And read the third node information of the third node from the first file storing the first service graph, wherein the target fusion node is the node obtained by fusion of the first node in the first service graph and the second node in the second service graph; the third node is connected to the first node in the first service graph; the third file only stores the node information of several fusion nodes and the edge information indicating the first-order neighbor relationship of each fusion node; The generation unit is configured to generate a response message for the task processing request based at least on the fusion node information and the third node information.

18. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-15.

19. A computing device, comprising a memory and a processor, characterized in that, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-15.

Images