A knowledge graph backtracking method and device, electronic equipment and storage medium

Abstract

This application provides a knowledge graph backtracking method, apparatus, electronic device, and storage medium. The method includes: obtaining a backtracking request, the backtracking request including a backtracking time and a cluster identifier; obtaining a cluster snapshot at the most recently updated time corresponding to the backtracking time, the cluster snapshot being obtained by querying the cluster corresponding to the cluster identifier in the knowledge graph at the most recently updated time; obtaining an operation log between the most recently updated time and the backtracking time; and backtracking to the cluster at the backtracking time based on the cluster snapshot and the operation log. In the implementation of the above scheme, by backtracking to the cluster at the backtracking time based on the cluster snapshot at the most recently updated time corresponding to the backtracking time and the operation log between the most recently updated time and the backtracking time, the situation requiring a full backtracking of the knowledge graph database is improved, effectively enhancing the timeliness of knowledge graph backtracking.

Description

Technical Field

[0001] This application relates to the technical field of computer data processing and knowledge graphs, and more specifically, to a knowledge graph backtracking method, apparatus, electronic device, and storage medium. Background Technology

[0002] Currently, the common approach for knowledge graph databases is full backup, such as backing up the database to a distributed object storage device (OSD) or a remote storage server on the 1st of each month. However, in practice, when customers file complaints or need to conduct forensic investigations on the knowledge graph, it can take several days to fully retrieve the knowledge graph database from the OSD or remote storage server. Therefore, the timeliness of current knowledge graph retrieval is poor. Summary of the Invention

[0003] The purpose of this application is to provide a knowledge graph backtracking method, apparatus, electronic device, and storage medium to improve the problem of poor timeliness in knowledge graph backtracking.

[0004] This application provides a knowledge graph backtracking method, comprising: obtaining a backtracking request, the backtracking request including: a backtracking time and a cluster identifier; obtaining a cluster snapshot at the most recently updated time corresponding to the backtracking time, the cluster snapshot being obtained by querying the cluster corresponding to the cluster identifier in the knowledge graph at the most recently updated time; obtaining operation logs between the most recently updated time and the backtracking time; and backtracking to the cluster at the backtracking time based on the cluster snapshot and the operation logs. In the implementation of the above scheme, by backtracking to the cluster at the backtracking time based on the cluster snapshot at the most recently updated time corresponding to the backtracking time and the operation logs between the most recently updated time and the backtracking time, the need for a full backtracking of the knowledge graph database is improved, effectively enhancing the timeliness of knowledge graph backtracking.

[0005] Optionally, in this embodiment, before obtaining the cluster snapshot corresponding to the most recently updated time at the backtracking time, the method further includes: classifying the clusters corresponding to the cluster identifier to obtain cluster categories; determining whether the cluster category is a preset category; and if so, storing the cluster corresponding to the cluster identifier as a cluster snapshot. In the implementation of the above scheme, by storing the cluster corresponding to the cluster identifier as a cluster snapshot only when the cluster category is a preset category, storage space is saved, and the situation where too many cluster snapshots lead to slow graph backtracking is avoided, effectively improving the timeliness of knowledge graph backtracking.

[0006] Optionally, in this embodiment, before obtaining the cluster snapshot of the most recently updated time corresponding to the backtracking time, the method further includes: if the current time is the most recently updated time and the cluster corresponding to the cluster identifier has changed, then querying the cluster corresponding to the cluster identifier from the knowledge graph and storing the cluster corresponding to the cluster identifier as a cluster snapshot in the distributed database HBase. In the implementation of the above scheme, by storing the cluster corresponding to the cluster identifier as a cluster snapshot in the distributed database HBase only when the previous time was the most recently updated time and the cluster corresponding to the cluster identifier has changed, storage space is saved, and the situation where too many cluster snapshots cause slow graph backtracking is avoided, effectively improving the timeliness of knowledge graph backtracking.

[0007] Optionally, in this embodiment, obtaining the cluster snapshot of the most recently updated time corresponding to the backtracking time includes: reading the cluster snapshot of the most recently updated time corresponding to the backtracking time from the distributed database HBase. In the implementation of the above scheme, by reading the cluster snapshot of the most recently updated time corresponding to the backtracking time from the distributed database HBase, the situation requiring a full backtracking of the knowledge graph database is improved, effectively enhancing the timeliness of knowledge graph backtracking.

[0008] Optionally, in this embodiment, before obtaining the operation log between the most recent update time and the backtracking time, the method further includes: if the cluster corresponding to the cluster identifier changes between the most recent update time and the backtracking time, then storing the operation log between the most recent update time and the backtracking time in the distributed database HBase. In the implementation of the above scheme, by storing the operation log between the most recent update time and the backtracking time in the distributed database HBase, the situation requiring a full backtracking of the knowledge graph database is improved, effectively enhancing the timeliness of knowledge graph backtracking.

[0009] Optionally, in this embodiment, obtaining the operation log between the most recent update time and the backtracking time includes: reading the operation log from the distributed database HBase via the message queue Kafka. In the implementation of the above scheme, reading the operation log from the distributed database HBase via the message queue Kafka improves the speed of reading the operation log from the distributed database HBase, effectively enhancing the timeliness of knowledge graph backtracking.

[0010] Optionally, in this embodiment, the backtracking request further includes: a user identifier; after backtracking to the cluster at the backtracking time based on the cluster snapshot and operation log, it further includes: determining whether the user corresponding to the user identifier is an authorized user; if so, then sending the cluster at the backtracking time to the user corresponding to the user identifier. In the implementation of the above scheme, by sending the cluster at the backtracking time to the user corresponding to the user identifier only if the user corresponding to the user identifier is an authorized user, the security of knowledge graph backtracking is effectively improved.

[0011] This application also provides a knowledge graph backtracking device, including: a backtracking request acquisition module, used to acquire a backtracking request, the backtracking request including: a backtracking time and a cluster identifier; a cluster snapshot acquisition module, used to acquire a cluster snapshot at the most recently updated time corresponding to the backtracking time, the cluster snapshot being obtained by querying the cluster corresponding to the cluster identifier in the knowledge graph at the most recently updated time; an operation log acquisition module, used to acquire operation logs between the most recently updated time and the backtracking time; and a graph cluster backtracking module, used to backtrack to the cluster at the backtracking time based on the cluster snapshot and the operation logs.

[0012] Optionally, in this embodiment of the application, the knowledge graph backtracking device further includes: a cluster category acquisition module, used to classify the clusters corresponding to the cluster identifier to obtain the cluster category; a preset category judgment module, used to judge whether the cluster category is a preset category; and a cluster snapshot processing module, used to store the cluster corresponding to the cluster identifier as a cluster snapshot if the cluster category is a preset category.

[0013] Optionally, in this embodiment of the application, the knowledge graph backtracking device further includes: a cluster snapshot storage module, used to query the cluster corresponding to the cluster identifier from the knowledge graph if the current time is the most recent update time and the cluster corresponding to the cluster identifier has changed, and store the cluster corresponding to the cluster identifier as a cluster snapshot in the distributed database HBase.

[0014] Optionally, in this embodiment of the application, the second acquisition module includes: a cluster snapshot reading submodule, used to read the cluster snapshot corresponding to the most recent update time from the distributed database HBase.

[0015] Optionally, in this embodiment of the application, the knowledge graph backtracking device further includes: an operation log storage module, used to store the operation log between the latest update time and the backtracking time in a distributed database HBase if the cluster corresponding to the cluster identifier changes between the latest update time and the backtracking time.

[0016] Optionally, in this embodiment of the application, the operation log acquisition module includes: an operation log processing submodule, used to read operation logs from the distributed database HBase through the message queue Kafka.

[0017] Optionally, in this embodiment of the application, the backtracking request further includes: a user identifier; the knowledge graph backtracking device further includes: an authorized user judgment module, used to determine whether the user corresponding to the user identifier is an authorized user; and a backtracking cluster sending module, used to send the cluster at the backtracking time to the user corresponding to the user identifier if the user corresponding to the user identifier is an authorized user.

[0018] This application also provides an electronic device, including a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the machine-readable instructions, when executed by the processor, perform the method described above.

[0019] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to perform the methods described above.

[0020] Other features and advantages of embodiments of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing embodiments of this application. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 The illustration shows a flowchart of the knowledge graph backtracking method provided in an embodiment of this application;

[0023] Figure 2 The diagram shown is a schematic representation of the cluster snapshot processing provided in an embodiment of this application.

[0024] Figure 3 The diagram shown is a structural schematic of the knowledge graph backtracking device provided in an embodiment of this application;

[0025] Figure 4 The diagram shows a structural schematic of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. The components of the embodiments of this application described and shown in the accompanying drawings can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed embodiments of this application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of the embodiments of this application.

[0027] It is understood that the terms "first" and "second" in the embodiments of this application are used to distinguish similar objects. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" are not necessarily different.

[0028] Before introducing the knowledge graph backtracking method provided in the embodiments of this application, let's first introduce some concepts involved in the embodiments of this application:

[0029] A knowledge graph is a method or tool that connects knowledge according to certain rules and can be displayed in the form of a graph. In the library and information science field, it is called a knowledge domain visualization knowledge domain mapping map. It is a series of different graphics that show the development process and structural relationships of knowledge. It uses visualization technology to describe knowledge resources and their carriers, and to mine, analyze, construct, draw and display knowledge and the interrelationships between them.

[0030] It should be noted that the knowledge graph backtracking method provided in this application embodiment can be executed by an electronic device. Here, electronic device refers to a device terminal or server with the function of executing computer programs. Device terminals include, for example, smartphones, personal computers, tablets, personal digital assistants, or mobile internet devices. Servers refer to devices that provide computing services through a network. Servers include, for example, x86 servers and non-x86 servers. Non-x86 servers include, for example, mainframes, minicomputers, and UNIX servers.

[0031] The following describes the applicable scenarios for this knowledge graph backtracking method. These scenarios include, but are not limited to, e-commerce, finance, and social networking. Taking e-commerce as an example, when staff receive user complaints (such as e-commerce fraud), since the knowledge graph is dynamically updated in real time, and staff need to backtrack the knowledge graph of the business system for business analysis, this knowledge graph backtracking method can be used to backtrack the clusters in the knowledge graph. Of course, staff can also use the clusters in the knowledge graph as evidence to explain and communicate, avoiding the need for staff to backtrack the entire knowledge graph database, effectively improving the timeliness of knowledge graph backtracking.

[0032] Please see Figure 1 The illustration shows a flowchart of a knowledge graph backtracking method provided in an embodiment of this application; this embodiment of the application provides a knowledge graph backtracking method, including:

[0033] Step S110: Obtain the backtracking request, which includes the backtracking time and cluster identifier.

[0034] The implementation methods of step S110 above include, but are not limited to: In the first implementation, the electronic device obtains a backtracking request from a terminal device. Specifically, for example, a user (e.g., a staff member handling business) operates on the terminal device, causing the terminal device to send a backtracking request to the electronic device via Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). After receiving the backtracking request sent by the user through the terminal device, the electronic device parses the required backtracking time and cluster identifier from the backtracking request. In the second implementation, the electronic device obtains a backtracking request from a server (e.g., a proxy server or load balancer). Specifically, for example, the proxy server or load balancer receives the backtracking request sent by the terminal device and forwards the backtracking request to the electronic device. After receiving the backtracking request sent by the proxy server or load balancer, the electronic device parses the required backtracking time and cluster identifier from the backtracking request.

[0035] Step S120: Obtain the cluster snapshot corresponding to the most recent update time at the backtracking time. The cluster snapshot is obtained by querying the cluster identifier corresponding to the cluster in the knowledge graph at the most recent update time.

[0036] Please see Figure 2The illustration shows a schematic diagram of cluster snapshot processing provided in this application embodiment. It can be understood that, in specific implementation, a cluster snapshot can be triggered when the number of nodes in the cluster exceeds a node threshold or the total number of edges in the cluster exceeds a preset threshold. In other words, the number of nodes, the number of edges, or a preset time interval can be combined to set the trigger condition for storing a cluster snapshot. Here, we take the combination of the number of nodes and the preset time interval as an example. Specifically, when the number of nodes in the cluster is greater than or equal to 2 (in practice, it can also be set to 20 or 50, etc.), a cluster snapshot at the first update time is triggered on day 1. Subsequently, a cluster snapshot is stored every preset duration (e.g., 5 days or 7 days). Assuming it is stored every 5 days, then the cluster snapshot at the second update time is stored on day 6, and the operation log between the first and second update times is stored in a database (e.g., a distributed database HBase or OceanBase, etc.). Similarly, Figure 2 The cluster snapshot at the third update time will be stored on day 11, and the cluster snapshot at the fourth update time will be stored on day 15. These two cluster snapshots are also stored using similar technical principles as described above, so they will not be described in detail here.

[0037] Step S130: Obtain the operation log between the most recent update time and the backtracking time.

[0038] It is understandable that, in practice, the cluster snapshots and operation logs mentioned above can be stored in distributed databases such as HBase or OceanBase, or in distributed file systems (DFS). DFS includes, but is not limited to, Hadoop Distributed File System (HDFS), Ceph, Lustre, MogileFS, MooseFS, FastDFS, TFS, and GridFS.

[0039] Step S140: Backtrack to the cluster at the backtracking time based on the cluster snapshot and operation log.

[0040] Understandably, since the backtracking time and the update time stored in the cluster snapshot are likely different, after obtaining the cluster snapshot at the most recent update time, it is also necessary to obtain the operation log between the most recent update time and the backtracking time in order to restore the cluster snapshot at the backtracking time based on the cluster snapshot and the operation log. For example, assuming the backtracking time is day 7, the most recent update time corresponding to day 7 is the second update time of day 6. Therefore, it is necessary to first obtain the cluster snapshot stored at the second update time of day 6, and then obtain the operation log between the second update time of day 6 and the backtracking time of day 7. Finally, based on the cluster snapshot stored at the second update time of day 6 and the operation log between the second update time of day 6 and the backtracking time of day 7, the cluster snapshot at the backtracking time of day 7 can be restored.

[0041] In the above implementation process, by using the cluster snapshot of the most recently updated time corresponding to the backtracking time, and the operation log between the most recently updated time and the backtracking time, the backtracking is performed to the cluster at the backtracking time, thereby improving the situation where a full backtracking of the knowledge graph database is required, and effectively improving the timeliness of knowledge graph backtracking.

[0042] As an optional implementation of step S120 above, before obtaining the cluster snapshot corresponding to the most recently updated time at the backtracking time, it can be determined that it belongs to a preset category (e.g., large cluster) before storing it as a cluster snapshot, including:

[0043] Step S121: Classify the clusters corresponding to the cluster identifiers to obtain the cluster categories.

[0044] The implementation methods of step S121 above include, but are not limited to: A first implementation method involves classifying the clusters corresponding to the cluster identifiers using a neural network model. Specifically, this includes using neural network models such as Text-Convolutional Neural Network (Text-CNN), LeNet, AlexNet, VGG, GoogLeNet, and ResNet to classify the clusters corresponding to the cluster identifiers and obtain cluster categories. These cluster categories include microclusters (also known as small clusters) and superclusters (also known as large clusters). A second implementation method involves determining the cluster category based on the number of nodes in the cluster corresponding to the cluster identifier. Specifically, this includes determining whether the number of nodes in the cluster corresponding to the cluster identifier exceeds a node threshold. If the number of nodes in the cluster corresponding to the cluster identifier exceeds the node threshold, then the cluster corresponding to the cluster identifier is identified as a supercluster (also known as a large cluster); if the number of nodes in the cluster corresponding to the cluster identifier does not exceed the node threshold, then the cluster corresponding to the cluster identifier is identified as a microcluster (also known as a small cluster). The third implementation determines the cluster category based on the number of edges in the cluster corresponding to the cluster identifier. Specifically, it checks whether the number of edges in the cluster corresponding to the cluster identifier exceeds a preset threshold. If the number of edges exceeds the preset threshold, the cluster corresponding to the cluster identifier is identified as a supercluster (also known as a large cluster); if the number of edges does not exceed the preset threshold, the cluster corresponding to the cluster identifier is identified as a microcluster (also known as a small cluster). The fourth implementation combines the second and third implementations, determining the cluster category based on the number of nodes and edges in the cluster corresponding to the cluster identifier. The technical principle of this implementation is similar to the second and third implementations, and therefore will not be elaborated further.

[0045] Step S122: Determine whether the cluster category is a preset category.

[0046] For example, the implementation of step S122 above involves using an executable program compiled or interpreted in a preset programming language to determine whether the cluster category is a preset category; wherein, the programming languages ​​that can be used include, for example, C, C++, Java, BASIC, JavaScript, LISP, Shell, Perl, Ruby, Python, and PHP, etc.

[0047] Step S123: If the cluster category is a preset category, then store the cluster corresponding to the cluster identifier as a cluster snapshot.

[0048] The implementation of step S123 above can be exemplified as follows: Assuming the preset category is a supercluster (also known as a large cluster), if the cluster category is determined to be a supercluster, then storing the cluster corresponding to the cluster identifier as a cluster snapshot can be triggered. In specific implementation, storing a cluster snapshot can be triggered when the number of nodes in the cluster exceeds a node threshold or the total number of edges in the cluster exceeds a preset threshold. That is, the number of nodes, the number of edges, or a preset time interval can be combined to set the trigger conditions for storing a cluster snapshot. When storing the cluster corresponding to the cluster identifier as a cluster snapshot, a command can be used for storage. For example, the command here is: `create 'graph_id', {NAME=> 'f1'}`; where `graph_id` represents the cluster identifier, and `f1` represents the filename of the stored cluster snapshot.

[0049] As an optional implementation of step S120 above, before obtaining the cluster snapshot at the most recently updated time corresponding to the backtracking time, the cluster snapshot can be stored in a distributed database HBase or OceanBase. This implementation may include:

[0050] Step S124: If the current time is the most recent update time and the cluster corresponding to the cluster identifier has changed, then query the cluster corresponding to the cluster identifier from the knowledge graph and store the cluster corresponding to the cluster identifier as a cluster snapshot in the distributed database HBase or OceanBase.

[0051] It is understood that the knowledge graph in the embodiments of this application is also referred to as a graph database, and may specifically be a Nebula, Neo4j graph database or Grakn knowledge graph system, etc.

[0052] Step S125: If the current time is the most recent update time and the cluster corresponding to the cluster identifier has not changed, then create a file link corresponding to the last stored cluster snapshot in the distributed database HBase or OceanBase, and determine the file link as the access method for this cluster snapshot.

[0053] For example, the implementation of steps S124 to S125 above is as follows: If the cluster corresponding to the cluster identifier changes at the second update time on the 6th day, then the cluster corresponding to the cluster identifier is queried from the knowledge graph, and the cluster corresponding to the cluster identifier is stored as a cluster snapshot file in the distributed database HBase or OceanBase. If the cluster corresponding to the cluster identifier does not change at the second update time on the 6th day, then a file link can be created based on the cluster snapshot file stored at the previous update time. That is, a file link is created to store the cluster snapshot at the first update time on the 1st day, and the file link of the cluster snapshot at the first update time is determined as the access method for the cluster snapshot at the second update time on the 6th day, so that when accessing the cluster snapshot at the second update time on the 6th day, the cluster snapshot stored at the first update time on the 1st day can be accessed directly.

[0054] As an optional implementation of step S120 above, when obtaining the cluster snapshot corresponding to the most recently updated time at the backtracking time, the cluster snapshot can be read from the distributed database HBase or OceanBase. This implementation may include:

[0055] Step S126: Read the cluster snapshot corresponding to the most recent update time from the distributed database HBase or OceanBase.

[0056] For example, when reading the cluster snapshot of the most recently updated time corresponding to the backtracking time from the distributed database HBase or OceanBase, commands such as scan can be used to read the cluster snapshot of the most recently updated time corresponding to the backtracking time from the distributed database HBase or OceanBase.

[0057] As an optional implementation of step S130 above, before obtaining the operation log between the most recent update time and the backtracking time, the operation log can also be stored in a distributed database, including:

[0058] Step S131: If the cluster corresponding to the cluster identifier changes between the most recent update time and the backtracking time, then store the operation log between the most recent update time and the backtracking time in the distributed database.

[0059] For example, if the cluster corresponding to the cluster identifier changes between the most recent update time and the backtracking time, the operation log between the most recent update time and the backtracking time is stored in a distributed database (DDB) such as HBase or OceanBase.

[0060] As an optional implementation of step S130 above, when obtaining the operation log between the most recent update time and the backtracking time, the operation log can be read from HBase or OceanBase through the message queue Kafka. This implementation may include:

[0061] Step S132: Read operation logs from the distributed database via the message queue Kafka.

[0062] For example, step S132 can be implemented by reading operation logs from distributed databases such as HBase or OceanBase via a message queue Kafka. These operation logs can be collected using the Flink data stream tool. Flink is an open-source stream processing framework whose core is a distributed stream data stream engine written in Java and Scala. Flink executes arbitrary stream data programs in a data parallel and pipeline manner. Flink's pipeline runtime system can execute batch processing and stream processing programs.

[0063] As an optional implementation of the aforementioned knowledge graph backtracking method, the backtracking request may further include: a user identifier; after backtracking to the cluster at the backtracking time based on the cluster snapshot and operation log, the cluster at the backtracking time may also be sent to the authorized user. This implementation may include:

[0064] Step S150: Determine whether the user corresponding to the user identifier is an authorized user.

[0065] For example, the implementation of step S150 above involves using an executable program compiled or interpreted in a preset programming language to determine whether the user corresponding to the user identifier is an authorized user; among which, the programming languages ​​that can be used include: C, C++, Java, BASIC, JavaScript, LISP, Shell, Perl, Ruby, Python, and PHP, etc.

[0066] Step S160: If the user ID corresponds to an authorized user, then send the cluster at the backtracking time to the user ID.

[0067] For example, the implementation of step S160 above is as follows: query the user information corresponding to the user identifier from the relational database, and parse the user type from the user information. If the user type corresponding to the user identifier is an authorized user, then send the cluster of the backtracking time to the user corresponding to the user identifier (e.g., staff). The relational database that can be used is, for example, MySQL, PostgreSQL, Oracle, and SQL Server.

[0068] Please see Figure 3The diagram shown is a structural schematic of the knowledge graph backtracking device provided in an embodiment of this application; this embodiment of the application provides a knowledge graph backtracking device 200, including:

[0069] The backtracking request acquisition module 210 is used to acquire backtracking requests, which include: backtracking time and cluster identifier.

[0070] The cluster snapshot acquisition module 220 is used to obtain the cluster snapshot at the most recent update time corresponding to the backtracking time. The cluster snapshot is obtained by querying the cluster identifier corresponding to the cluster in the knowledge graph at the most recent update time.

[0071] The operation log acquisition module 230 is used to acquire the operation log between the most recent update time and the backtracking time.

[0072] The graph cluster backtracking module 240 is used to backtrack to the cluster at the backtracking time based on the cluster snapshot and operation log.

[0073] Optionally, in this embodiment of the application, the knowledge graph backtracking device further includes:

[0074] The cluster category acquisition module is used to classify the clusters corresponding to the cluster identifiers and obtain the cluster categories.

[0075] The preset category judgment module is used to determine whether the cluster category is a preset category.

[0076] The cluster snapshot processing module is used to store the cluster corresponding to the cluster identifier as a cluster snapshot if the cluster category is a preset category.

[0077] Optionally, in this embodiment of the application, the knowledge graph backtracking device further includes:

[0078] The cluster snapshot storage module is used to query the cluster corresponding to the cluster identifier from the knowledge graph if the current time is the most recent update time and the cluster corresponding to the cluster identifier has changed, and then store the cluster corresponding to the cluster identifier as a cluster snapshot in the distributed database HBase.

[0079] Optionally, in this embodiment of the application, the second acquisition module includes:

[0080] The cluster snapshot reading submodule is used to read the cluster snapshot corresponding to the most recent update time from the distributed database HBase.

[0081] Optionally, in this embodiment of the application, the knowledge graph backtracking device further includes:

[0082] The operation log storage module is used to store the operation log between the most recent update time and the backtracking time in the distributed database HBase if the cluster corresponding to the cluster identifier changes between the most recent update time and the backtracking time.

[0083] Optionally, in this embodiment of the application, the operation log acquisition module includes:

[0084] The operation log processing submodule is used to read operation logs from the distributed database HBase via the message queue Kafka.

[0085] Optionally, in this embodiment, the backtracking request further includes: a user identifier; the knowledge graph backtracking device further includes:

[0086] The authorized user determination module is used to determine whether the user corresponding to the user identifier is an authorized user.

[0087] The backtracking cluster sending module is used to send the cluster at the backtracking time to the user corresponding to the user identifier if the user identifier is an authorized user.

[0088] It should be understood that this device corresponds to the knowledge graph backtracking method embodiment described above and is capable of executing the various steps involved in the above method embodiment. The specific functions of this device can be found in the description above, and detailed descriptions are omitted here to avoid repetition. The device includes at least one software functional module that can be stored in memory or embedded in the device's operating system (OS) in the form of software or firmware.

[0089] Please see Figure 4 The diagram shows a structural schematic of an electronic device provided in an embodiment of this application. An electronic device 300 provided in this application includes a processor 310 and a memory 320. The memory 320 stores machine-readable instructions executable by the processor 310. When the machine-readable instructions are executed by the processor 310, the method described above is performed.

[0090] This application embodiment also provides a computer-readable storage medium 330, on which a computer program is stored. This computer program is executed by a processor 310 to perform the methods described above. The computer-readable storage medium 330 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0091] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0092] It should be understood that the disclosed apparatus and methods can also be implemented in other ways, as provided in the embodiments of this application. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the accompanying drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending primarily on the functions involved.

[0093] Furthermore, the functional modules of each embodiment in this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part. In addition, in the description of this specification, the reference to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., means that the specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0094] The above description is only an optional implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application.

Claims

1. A knowledge graph backtracking method, characterized in that, include: Obtain a backtracking request, the backtracking request including: backtracking time and cluster identifier; Obtain a cluster snapshot corresponding to the most recently updated time at the backtracking time. The cluster snapshot is obtained by querying the knowledge graph for the cluster corresponding to the cluster identifier at the most recently updated time. Obtain the operation log between the most recent update time and the backtracking time; Based on the cluster snapshot and the operation log, the cluster is traced back to the traceback time. Before obtaining the cluster snapshot corresponding to the most recently updated time at the backtracking time, the method further includes: classifying the clusters corresponding to the cluster identifier to obtain cluster categories; determining whether the cluster category is a preset category; if so, storing the cluster corresponding to the cluster identifier as the cluster snapshot. The classification of clusters corresponding to the cluster identifier includes: determining whether the number of nodes and edges in the cluster corresponding to the cluster identifier exceeds a node threshold; if the number of nodes and edges in the cluster corresponding to the cluster identifier exceeds the node threshold, then the cluster corresponding to the cluster identifier is identified as a supercluster; if the number of nodes and edges in the cluster corresponding to the cluster identifier does not exceed the node threshold, then the cluster corresponding to the cluster identifier is identified as a microcluster.

2. The method according to claim 1, characterized in that, Before obtaining the cluster snapshot corresponding to the most recently updated time at the backtracking time, the method further includes: If the current time is the most recent update time, and the cluster corresponding to the cluster identifier has changed, then query the cluster corresponding to the cluster identifier from the knowledge graph, and store the cluster corresponding to the cluster identifier as a cluster snapshot in the distributed database HBase.

3. The method according to claim 2, characterized in that, Obtaining the cluster snapshot corresponding to the most recently updated time at the backtracking time includes: Read the cluster snapshot of the most recent update time corresponding to the backtracking time from the distributed database HBase.

4. The method according to claim 2, characterized in that, Before obtaining the operation log between the most recent update time and the backtracking time, the method further includes: If the cluster corresponding to the cluster identifier changes between the most recent update time and the backtracking time, the operation log between the most recent update time and the backtracking time is stored in the distributed database HBase.

5. The method according to claim 4, characterized in that, The step of obtaining the operation log between the most recent update time and the backtracking time includes: The operation logs are read from the distributed database HBase via the message queue Kafka.

6. The method according to claim 1, characterized in that, The backtracking request further includes: a user identifier; and after backtracking to the cluster at the backtracking time based on the cluster snapshot and the operation log, it further includes: Determine whether the user corresponding to the user identifier is an authorized user; If so, the cluster of the backtracking time is sent to the user corresponding to the user identifier.

7. A knowledge graph backtracking device, characterized in that, include: The backtracking request acquisition module is used to acquire backtracking requests, which include: backtracking time and cluster identifier; The cluster snapshot acquisition module is used to acquire the cluster snapshot corresponding to the most recent update time at the backtracking time. The cluster snapshot is obtained by querying the knowledge graph for the cluster corresponding to the cluster identifier at the most recent update time. The operation log acquisition module is used to acquire the operation log between the most recent update time and the backtracking time. The graph cluster backtracking module is used to backtrack to the cluster at the backtracking time based on the cluster snapshot and the operation log; Before obtaining the cluster snapshot corresponding to the most recently updated time at the backtracking time, the method further includes: classifying the clusters corresponding to the cluster identifier to obtain cluster categories; determining whether the cluster category is a preset category; if so, storing the cluster corresponding to the cluster identifier as the cluster snapshot. The classification of clusters corresponding to the cluster identifier includes: determining whether the number of nodes and edges in the cluster corresponding to the cluster identifier exceeds a node threshold; if the number of nodes and edges in the cluster corresponding to the cluster identifier exceeds the node threshold, then the cluster corresponding to the cluster identifier is identified as a supercluster; if the number of nodes and edges in the cluster corresponding to the cluster identifier does not exceed the node threshold, then the cluster corresponding to the cluster identifier is identified as a microcluster.

8. An electronic device, characterized in that, include: A processor and a memory, the memory storing machine-readable instructions executable by the processor, which, when executed by the processor, perform the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the method as described in any one of claims 1 to 6.

Images