A method, apparatus and computer-readable storage medium for managing blood relations

Abstract

A lineage management method, apparatus, and computer-readable storage medium relate to the field of data management. The method includes: executing a first SQL statement, which instructs the generation of a downstream table based on a temporary table; obtaining a lineage graph of multiple data tables, the lineage graph describing the lineage relationships between these multiple data tables generated during the execution of multiple SQL statements, including the first SQL statement; querying upwards in the lineage graph from the node identified by the temporary table, layer by layer, until all data tables in the queried layer are permanent tables, at which point the query stops; recording the lineage relationships between all permanent tables returned by the query and the downstream table in the lineage graph. A lineage relationship is also established between the permanent tables in the upstream lineage relationship of the temporary table and the downstream table. Even after the lineage relationship of the temporary table is deleted, the lineage relationship between the downstream table and the permanent tables in the upstream lineage relationship remains traceable.

Description

Technical Field

[0001] This application relates to the field of data management, and more specifically, to a method, apparatus and computer-readable storage medium for managing blood relations. Background Technology

[0002] With the explosive growth of data volume, data management has become increasingly complex, and the management of data lineage is particularly important. Data lineage analysis is a technique that analyzes the relationships between data to understand its source, destination, and transformation. Data lineage analysis is a commonly used technique in data management, helping enterprises better understand and manage their data, thereby increasing the value of their data assets. Performing data lineage analysis in Hive (an open-source data warehouse tool) can help data warehouse administrators and data analysts understand data flow, thereby optimizing data warehouse design and performance.

[0003] One known method for managing the lineage of temporary tables in Hive involves recording the lineage of a temporary table after it has been identified, and periodically performing batch cleanup of these lineages. The drawback of this method is that deleting the lineage of a temporary table may disrupt the corresponding lineage chain, making it impossible to trace the lineage of permanent tables, thus affecting the normal use of the data system.

[0004] Therefore, it is desirable to provide a method to ensure the availability of the data system by maintaining a complete and traceable lineage even after a temporary table is deleted. Summary of the Invention

[0005] This application provides a lineage management method, apparatus, and computer-readable storage medium to ensure that the lineage chain remains complete and traceable even after a temporary table is deleted, thereby ensuring the availability of the data system.

[0006] In a first aspect, this application provides a lineage management method, the method comprising: executing a first structured query language (SQL) statement, the first SQL statement instructing the generation of a downstream table based on a temporary table; obtaining a lineage graph between multiple data tables, the lineage graph describing the lineage relationships between the multiple data tables generated during the execution of multiple SQL statements, the multiple SQL statements including the first SQL statement, the lineage graph including: multiple nodes corresponding to the multiple data tables, and edges connecting parent nodes and child nodes among the multiple nodes, each edge pointing from a parent node to a child node, indicating that the data table corresponding to each child node is generated based on the connected parent node; querying upwards layer by layer in the lineage graph starting from the node identified by the temporary table, until all data tables in the queried layer are permanent tables, at which point the query stops; and recording the lineage relationships between all permanent tables returned by the query and the downstream tables in the lineage graph.

[0007] Based on the above scheme, by tracing back to the permanent table in the upstream lineage of the temporary table, a lineage relationship is also established between the permanent table in the upstream lineage and the downstream table of the temporary table. Even if the temporary table is deleted from the lineage relationship, the lineage relationship between the downstream table of the temporary table and the permanent table in the upstream lineage of the temporary table is still traceable, thereby ensuring the availability of the data system.

[0008] Optionally, the node identifier of the node corresponding to the temporary table includes: the table name of the temporary table and the session identifier of the session in which the second SQL statement is located, wherein the second SQL statement indicates the generation of the temporary table.

[0009] Optionally, the method further includes: periodically searching for a target node in the lineage graph, the target node corresponding to a temporary table, and the identifier of the target node containing a session identifier of a closed session; and deleting the target node and the edges connected to the target node from the lineage graph.

[0010] Optionally, the method further includes: periodically determining the closed session based on the node identifier of the target node corresponding to each temporary table in the lineage graph and the session identifier of the unclosed session stored under the specified path.

[0011] Optionally, the method further includes: based on each of the plurality of SQL statements, obtaining at least one of the following: operation-related information corresponding to the SQL statement, and data table-related information involved in the SQL statement. The operation-related information includes one or more of the following: operation type, operation identifier, session, Internet Protocol (IP) address of the machine performing the operation, creation time, or user submitting the operation request. The data table-related information includes one or more of the following: table name, type, database, cluster, owner of the data table, fields included in the data table, field types, partition where the data table is located, creation time, or update time.

[0012] Optionally, each operation type corresponds to a relation template, and the operation-related information corresponding to each operation type is recorded through the corresponding relation template.

[0013] Optionally, the operation type includes at least one of the following: creating a data table, creating a view table, modifying a table name, downloading, exporting, importing, deleting a table, or querying.

[0014] Secondly, a kinship management apparatus is provided, comprising modules or units for implementing the kinship management method described in the first aspect and any one of the first aspects. It should be understood that each module or unit can implement its respective function by executing a computer program.

[0015] Thirdly, a kinship management device is provided, including a processor for performing the kinship management method described in the first aspect and any one of the first aspects.

[0016] The device may further include a memory for storing instructions and data. The memory is coupled to the processor, and when the processor executes the instructions stored in the memory, it can implement the method described in the first aspect above. The device may also include a communication interface for communicating with other devices; exemplaryly, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface.

[0017] Fourthly, a computer-readable storage medium is provided, including instructions that, when executed on a computer, cause the computer to implement the method described in the first aspect and any one of the first aspects.

[0018] Fifthly, a computer program product is provided, the computer program product comprising: a computer program (also referred to as code or instructions), which, when run, causes a computer to perform the method described in the first aspect and any one of the first aspects.

[0019] It should be understood that the second to fifth aspects of this application correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0020] Figure 1 This is an operational diagram of a known method for managing lineage relationships using temporary tables;

[0021] Figure 2 This is a schematic block diagram of a blood relationship management device provided in an embodiment of this application;

[0022] Figure 3 This is a schematic flowchart of a blood relationship management method provided in an embodiment of this application;

[0023] Figure 4 This is a schematic diagram illustrating the operation of the blood relationship management method provided in the embodiments of this application;

[0024] Figure 5 This is a schematic diagram of the relationship template provided in the embodiments of this application;

[0025] Figure 6 This is another illustrative flowchart of the blood relationship management method provided in the embodiments of this application;

[0026] Figure 7 This is another schematic block diagram of the blood relationship management device provided in the embodiments of this application;

[0027] Figure 8 This is another schematic block diagram of the blood relationship management device provided in the embodiments of this application. Detailed Implementation

[0028] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0029] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0030] To facilitate understanding of the embodiments of this application, some terms or vocabulary involved in this application will be briefly explained below.

[0031] 1. Data lineage (hereinafter referred to as lineage): From the generation, processing, and circulation of data to its eventual destruction, each stage inevitably involves a certain connection, which is the data lineage. Data lineage is a record of the flow and transformation of data within a system, between systems, and between business lines. Through this record, one can trace the source of the data, track its flow history, view its state at a specific moment, and find its final destination.

[0032] 2. Data system: This refers to a system composed of data acquisition, data storage, data updating, data circulation, and data mining, distributed across different levels. This allows us to quickly, completely, vividly, and at varying scales understand various macro and micro situations, and fully utilize the value of this data. In this application, the data system refers to Hive.

[0033] 3. Hive: An open-source data warehouse tool based on Hadoop, Hive can be used for data extraction, transformation, and loading. It is a mechanism for storing, querying, and analyzing large-scale data stored in Hadoop. Hive data warehouse tools can map structured data files to a database table and provide SQL query functionality.

[0034] 4. Session: In Hive, a session refers to the interaction process between a user and the Hive server. When a user connects to the Hive server, Hive creates a session, which maintains the communication state between the user and the Hive server. During the session, the user can execute multiple Hive commands and perform queries using the same context and settings. Once the user exits the Hive server, the session is closed, and the context and settings are reset. Temporary tables created are only visible to the current session; data is stored in the user's corresponding directory and is automatically deleted when the session ends.

[0035] 5. Remote dictionary server (Redis); is an open-source storage system, which can also be understood as an open-source database.

[0036] With the explosive growth of data volume, data management has become increasingly complex, with data lineage management being particularly important. Data lineage analysis is a technique that analyzes the relationships between data to understand its source, destination, and transformation. Data lineage analysis is a commonly used technique in data management, helping enterprises better understand and manage their data, thereby increasing the value of their data assets. Performing data lineage analysis in Hive can help data warehouse administrators and data analysts understand data flow, thereby optimizing data warehouse design and performance.

[0037] Figure 1 This is a schematic diagram of a known method for managing lineage relationships using temporary tables.

[0038] like Figure 1 As shown, operation 1 is to open session A; operation 2 is to process data from permanent tables a and b to generate temporary table c; operation 3 is to process data from temporary table c and permanent table e to generate temporary table d; operation 4 is to process data from temporary table d to generate permanent table f; operation 5 is to close session A (the corresponding temporary tables c and d will also be automatically deleted). In this method of managing the lineage of temporary tables in Hive, after the management device determines that a table is temporary, it records the lineage of the temporary table and performs batch cleanup periodically. The disadvantage of this method is that temporary tables (e.g.) Figure 1 If the lineage of temporary table c or temporary table d is deleted, the corresponding lineage link may be interrupted, which will make it impossible to trace the lineage of the permanent table and affect the normal use of the data system.

[0039] To address the aforementioned issues, this application provides a lineage management method, apparatus, and computer-readable storage medium. By tracing back to the permanent tables in the upstream lineage of a temporary table, a lineage relationship is also established between the permanent tables in the upstream lineage and the downstream tables of the temporary table. Even if the temporary table is deleted from the lineage relationship, the lineage relationship between the downstream tables of the temporary table and the permanent tables in the upstream lineage of the temporary table remains traceable, thereby ensuring the availability of the data system.

[0040] Before detailing the blood relationship management method provided in the embodiments of this application, let's first combine it with... Figure 2 The blood relationship management device provided in the embodiments of this application will be described by way of example.

[0041] Figure 2 This is a schematic block diagram of a blood relationship management device provided in an embodiment of this application.

[0042] like Figure 2As shown, the bloodline management device 200 may include an information acquisition module 210, a relationship parsing module 220, a logical bloodline reasoning module 230, an image input module 240, and a temporary table bloodline clearing module 250.

[0043] The information acquisition module 210 can be used to collect the original data lineage information corresponding to each SQL statement. The original data lineage information can include operation-related information corresponding to the SQL statement, and information about the data tables (including input and / or output tables) involved in the SQL statement. Operation-related information includes one or more of the following: operation type, operation identifier, session, IP address of the machine executing the operation, creation time, or user who submitted the operation request. Different sessions can be distinguished by a session ID. Data table-related information includes one or more of the following: table name, type, database, cluster, owner of the table (the user who submitted the operation request is the owner of the table), fields included in the table, field types, partition where the table is located, and creation or update time. In one possible implementation, the information acquisition module 110 can use the customized Hive hook application programming interface (API) of this application to read the interface of the data system (here referring to Hive), analyze the process through the interface to obtain process data, and integrate the process data to obtain the changes in the metadata information of the data system, that is, to obtain the original data lineage information corresponding to the executed SQL statement in real time.

[0044] The relation parsing module 220 contains multiple preset relation templates. Based on the relation template corresponding to the operation type of the SQL statement, the module 220 can parse the original data lineage information of the SQL statement to obtain the lineage relationships between tables, and / or the relationships between tables and other entities, and between other entities and other entities. Other entities include, but are not limited to, the user submitting the operation request, the operation type, the Hive server, the database, or the cluster. In other words, the relation parsing module 220 can not only parse the lineage relationships between tables, but also the relationships between tables and other entities, and between other entities and other entities. The lineage relationships between tables, and the relationships between tables and other entities, and between other entities and other entities, can all be stored in a graph database as a point-edge relationship graph. For a detailed description of the relation templates, please refer to the relevant content later.

[0045] When the relation parsing module 220 parses out a temporary table as input for an operation and generates (or outputs) another table (which can be denoted as the downstream table of the temporary table) based on the temporary table, it can call the logical lineage reasoning module 230. The logical lineage reasoning module 230 can respond to the call of the relation parsing module by querying the upstream lineage relationship of the temporary table in the graph database, recursively finding the upstream permanent tables of the temporary table, taking these upstream permanent tables as the logical upstream lineage of the downstream table of the temporary table, and recording the lineage relationship between these upstream permanent tables and the downstream table of the temporary table in the lineage relationship graph.

[0046] In one possible implementation, the logical lineage reasoning module 230 may include a query submodule (also called a query interface), a graph query statement submodule, and an integration submodule. Specifically, when the relation parsing module 220 parses a temporary table as input to an operation, and another table (which can be considered a downstream table of the temporary table) is generated (or output) based on this temporary table, the relation parsing module 220 can pass the table name of the temporary table to the query interface. The query interface can then respond to the table name passed by the relation parsing module 220 by sending a request (including but not limited to a POST request) containing the lineage information of the temporary table to the graph database using the Hypertext Transfer Protocol (HTTP), and invoking the graph query statement submodule loaded on the graph database to perform a query. The graph query statement submodule can be used to traverse the graph database hierarchically to query the upstream lineage of a temporary table. For example, when all the tables at the upper level of the temporary table are permanent tables, the query ends, and these permanent tables are returned to the integration submodule. If there are temporary tables at the upper level of the temporary table, the query continues recursively to the tables at the next higher level until all the tables returned by the query are permanent tables, and the query stops when all the tables at the queried level are permanent tables. It is understood that the graph query statement submodule can return the query results of each level to the integration submodule after each query, or it can return the query results of one or more levels at a time after the query stops; this application does not impose any limitations on this. The integration submodule can integrate all the permanent tables returned by the graph query statement submodule into table entities representing the logical upstream lineage of the downstream tables of the temporary table, recording the lineage relationships between all the permanent tables returned by the query and the downstream tables of the temporary table.

[0047] The graph input module 240 can be used to encapsulate the relationships (including lineage relationships between tables) resolved by the relationship resolution module 220 into a format acceptable to the graph database and push it into the graph database for storage. For example, the graph input module 240 can encapsulate the information of various nodes and edges resolved by the relationship resolution module 220 into information in a fixed format (e.g., JSON format), and send a request containing lineage relationship information to the graph database using HTTP to perform the storage input operation. In one possible implementation, when the lineage relationships resolved by the relationship resolution module 220 include temporary tables, the graph input module 240 can also record the session ID corresponding to the temporary table in Redis to facilitate subsequent filtering of closed sessions.

[0048] In actual data production, a large number of temporary tables are generated daily, and these temporary tables are automatically deleted when the session is closed. However, storing the lineage relationships of all generated temporary tables in a graph database consumes significant storage resources, impacting database computation and query efficiency, and generating a lot of outdated lineage relationship data for temporary tables that no longer exist. However, if... Figure 1 Similar to the known method of managing the lineage of temporary tables, periodically deleting the lineage of temporary tables in batches can cause the deletion of lineages of temporary tables still existing in some open sessions. This results in data loss and accidental deletion, affecting the normal use of the data system. To solve the above problems, the temporary table lineage cleanup module 250 included in the lineage management device 200 provided in this application can monitor the status of active sessions to filter out closed sessions, and then further delete the lineages of temporary tables generated in these sessions, without accidentally deleting the lineages of temporary tables in open sessions, thus ensuring the availability of the data system.

[0049] In one possible implementation, the temporary table lineage cleanup module 250 may also include a path scanning submodule (also known as a path scanning script), a closed session filtering submodule, and a temporary table lineage deletion submodule.

[0050] The data system stores information such as the session ID and session creation time of unclosed sessions in a fixed path. For example, in Hive, the session IDs of all unclosed sessions are stored in a file at the path " / tmp / Hive" in the Hadoop Distributed File System (HDFS). This application provides a script that can traverse files under the " / tmp / Hive" path by date; that is, a path scanning submodule. The path scanning submodule can periodically scan files under this path to obtain session IDs; it can also scan files that have not been closed within a preset time period (e.g., 10 days, 20 days, one month, 2 months, etc.) and obtain the session IDs in the files. The reason for filtering unclosed sessions within a preset time period is that the lifespan of a session is generally short during normal production operations. Files that exist in this path for a long time may be files corresponding to sessions that were abnormally closed (such as when production operations were interrupted due to abnormal power failure of the equipment). Files from abnormally closed sessions may still exist in this path. Therefore, by controlling the filtering time period, these abnormally closed sessions can be filtered out so that the lineage of temporary tables generated in these abnormally closed sessions can be clearly identified later.

[0051] The closed session filtering submodule can retrieve currently existing session IDs from the graph database or Redis and compare them with the session IDs scanned by the path scanning submodule. It filters out session IDs that only exist in the graph database or Redis and not in the " / tmp / Hive" path. In other words, the sessions corresponding to these session IDs are sessions that have actually been closed.

[0052] The temporary table lineage deletion submodule can delete the lineage relationships of temporary tables generated in closed sessions (filtered by the closed session filtering submodule) from the graph database, and can also delete the session IDs of closed sessions (filtered by the closed session filtering submodule) from Redis. The temporary table lineage deletion submodule can also delete the lineage relationships of temporary tables generated in sessions that have not been closed within a preset time period (obtained by the path scanning submodule) from the graph database, and can also delete the session IDs of these sessions from Redis.

[0053] The following combination Figure 3 This application provides a detailed description of the blood relationship management method.

[0054] Figure 3This is a schematic flowchart of a blood relationship management method provided in the embodiments of this application.

[0055] like Figure 3 As shown, method 300 may include steps 310 to 340. The steps of method 300 may be executed by a kinship management device, or by a component (such as a chip, chip system, etc.) configured in the kinship management device, or by a logic module or software capable of implementing all or part of the functions of the kinship management device; this application embodiment does not limit this. The kinship management device may have, for example, […]. Figure 2 The structure shown is not limited to the embodiments of this application. The following describes... Figure 3 Each step in the process will be explained in detail.

[0056] In step 310, a first SQL statement is executed, which instructs the generation of a downstream table based on a temporary table.

[0057] The lineage management device can respond to a user's operation request corresponding to a first SQL statement, and execute the first SQL statement to generate a downstream table based on a temporary table.

[0058] By way of example and not limitation, the first SQL statement may include, for example, SQL statements that create a data table (e.g., CreateTableAsSelect), SQL statements that create a view table (e.g., CreateView), SQL statements that modify a table name (e.g., AlterTableRename), or SQL statements that perform queries (e.g., Query), all of which may output (or generate) another table based on a temporary table, and this application does not limit them in any way.

[0059] In step 320, a lineage diagram between multiple data tables is obtained.

[0060] The lineage graph is used to describe the lineage relationships between multiple data tables generated during the execution of multiple SQL statements, including the first SQL statement. The lineage graph can include multiple nodes corresponding to these multiple data tables, and edges connecting parent nodes and child nodes among these multiple nodes. Each edge points from the parent node to the child node, indicating that the data table corresponding to each child node is generated based on the connected parent node.

[0061] For example, the lineage management device can, based on the relationship parsing module 220, when a temporary table appears as the input of the operation and a downstream table is generated (or output) based on the temporary table, call the logical lineage reasoning module 230 to obtain the lineage relationship diagram between the temporary table and one or more data tables generated by one or more SQL statements executed before the execution of the first SQL statement.

[0062] In step 330, the kinship graph is queried layer by layer upwards from the node identified by the temporary table until all data tables in the queried layer are permanent tables, at which point the query stops.

[0063] For example, the bloodline management device can use the logical bloodline reasoning module 230 to query the upstream bloodline relationship of the temporary table in the graph database and recursively search for the upstream permanent table of the temporary table. For instance, when all the data tables in the upper level of the temporary table are permanent tables, the query ends and one or more permanent tables are returned as results; if there are temporary tables in the upper level of the temporary table, the query continues recursively to the data tables in the next upper level until all the data tables returned by the query are permanent tables, and the query stops and the query results are returned.

[0064] In step 340, the lineage relationships between all permanent tables returned by the query and the downstream table are recorded in the lineage graph.

[0065] For example, the lineage management device can record the lineage relationships between all permanent tables returned by the query and the downstream tables in the lineage relationship graph based on the graph entry module 240. That is, the lineage relationships between all permanent tables in the upstream lineage relationships of the queried temporary table and the downstream tables of the temporary table are added to the lineage relationship graph.

[0066] Figure 4 This is a schematic diagram illustrating the operation of the blood relationship management method provided in the embodiments of this application.

[0067] like Figure 4 As shown, operation 1 opens session A; operation 2 processes data from permanent tables a and b to generate temporary table c; operation 3 processes data from temporary table c and permanent table e to generate temporary table d; operation 4 processes data from temporary table d to generate permanent table f; operation 5 closes session A (the corresponding temporary tables c and d will also be automatically deleted). This differs from... Figure 1The known method for managing the lineage of temporary tables shown in the illustration, and the lineage management method provided in this embodiment, after performing operation 3, can record not only the lineage relationships between temporary table d and temporary table c and permanent table e, but also the lineage relationships between temporary table d and permanent tables a and b. Thus, even after the lineage relationship of temporary table c is deleted, the lineage relationship between temporary table d and permanent tables a and b remains traceable. After performing operation 4, not only the lineage relationship between permanent table f and temporary table d, but also the lineage relationships between permanent table f and permanent tables e, a, and b remain traceable. Thus, even after the lineage relationship of temporary table d is deleted, the lineage relationship between permanent table f and permanent tables e, a, and b remains traceable.

[0068] Based on the above technical solution, by tracing back to the permanent table in the upstream lineage of the temporary table, a lineage relationship is also established between the permanent table in the upstream lineage relationship and the downstream table of the temporary table. Even if the temporary table is deleted from the lineage relationship, the lineage relationship between the downstream table of the temporary table and the permanent table in the upstream lineage relationship of the temporary table is still traceable, thereby ensuring the availability of the data system.

[0069] In one possible implementation, the node identifier of the node corresponding to the temporary table includes: the table name of the temporary table and the session identifier of the session in which the second SQL statement is located, wherein the second SQL statement indicates that the temporary table was generated.

[0070] Understandably, to avoid confusion about the lineage of temporary tables with the same name created in different sessions, temporary tables can be bound to the session identifier of the session in which they are created. In this way, even temporary tables with the same name can be distinguished by the session identifier they are bound to. If the bound session identifiers are different, they are not the same temporary table.

[0071] For example, such as Figure 4 As shown, in session A, operation 2 processes data from permanent tables a and b to generate a temporary table c. In the recorded lineage, the node corresponding to temporary table c is identified by its table name c and the session identifier A of the session in which it was generated; that is, node "Ac". In session B, operation 7 processes data from permanent tables g and h to generate a temporary table c. In the recorded lineage, the node corresponding to temporary table c is identified by its table name c and the session identifier B of the session in which it was generated; that is, node "Bc". This effectively distinguishes the temporary table c in session A from the temporary table c in session B, avoiding the problem of confused lineage caused by creating temporary tables with the same name in different sessions.

[0072] In one possible implementation, the method 300 further includes: periodically searching for a target node in the lineage graph, the target node corresponding to a temporary table, and the identifier of the target node containing a session identifier of a closed session; and deleting the target node and the edge connected to the target node from the lineage graph.

[0073] For example, the lineage management device can periodically search for target nodes in the lineage graph based on the temporary table lineage cleaning module 250, thereby deleting these target nodes and the edges connected to these target nodes in the lineage graph.

[0074] As mentioned above, a large number of temporary tables are generated daily in actual data production, and these temporary tables are automatically deleted when the session is closed. However, storing the lineage relationships of all generated temporary tables in the graph database consumes a significant amount of storage resources. This not only affects the efficiency of database computation and querying but also generates a lot of outdated lineage relationship data for temporary tables that no longer exist. Therefore, periodically deleting the lineage relationships of target nodes helps free up storage resources and improve the efficiency of database computation and querying.

[0075] In one possible implementation, method 300 further includes: periodically determining closed sessions based on the node identifier of the target node corresponding to each temporary table in the lineage graph and the session identifier of the unclosed sessions stored under the specified path.

[0076] It is understandable that the session identifiers of closed sessions included in the target node's identifier can include those of normally closed sessions as well as those of abnormally closed sessions. As mentioned above, the data system stores information such as the session IDs and session creation times of sessions that have not yet been closed in a fixed path. For example, in Hive, the session IDs of all unclosed sessions are stored in a file at the path " / tmp / Hive" in HDFS. The session ID of a normally closed session can be understood as a session ID that only exists in the graph database or Redis, and not in the " / tmp / Hive" path; the session ID of an abnormally closed session can include the session IDs of sessions that have not yet been closed within a preset time period, scanned by the path scanning submodule.

[0077] It is also understandable that the cycle can be preset, such as 12 hours, 24 hours, 48 ​​hours, 5 days, 10 days, etc., and this application does not impose any restrictions on it.

[0078] For example, the lineage management device can periodically search for target nodes in the lineage graph based on the temporary table lineage cleanup module 250. That is, it can periodically filter out the session identifiers of normally closed sessions and / or abnormally closed sessions by monitoring the status of active sessions, thereby further deleting the lineage relationships of temporary tables generated in these sessions, without mistakenly deleting the lineage relationships of temporary tables in sessions that are not actually closed, to ensure the availability of the data system. Figure 4 As shown, after periodically triggering the batch deletion task of the lineage relationship of the temporary table, if session A and session B, as well as the session identifier of the session where the temporary table d was generated, are selected, and the session identifier of the normally closed session and / or the session identifier of the abnormally closed session are selected, then nodes "Ac", "Bc", and d can be determined as target nodes, and these target nodes and the edges connected to these target nodes are deleted from the lineage relationship graph.

[0079] In one possible implementation, method 300 further includes: based on each of the plurality of SQL statements, obtaining at least one of the following: operation-related information corresponding to the SQL statement, and information related to the data table involved in the SQL statement. The operation-related information includes one or more of the following: operation type, operation identifier, session, Internet Protocol IP address of the machine performing the operation, creation time or user submitting the operation request. The information related to the data table includes one or more of the following: table name, type, database, cluster, person in charge of the data table, fields included in the data table, field types, partition where the data table is located, creation time or update time.

[0080] The operation type can include at least one of the following: creating a data table, creating a view table, modifying a table name, downloading (e.g., Load), exporting (e.g., Export), importing (e.g., Import), deleting a table (TruncateTable), or querying.

[0081] For example, the lineage management device can collect the raw data lineage information corresponding to each SQL statement based on the information collection module 210. The raw data lineage information may include operation-related information corresponding to the SQL statement, and relevant information of the data tables (including input tables and / or output tables) involved in the SQL statement. For a detailed description, please refer to the relevant description above, which will not be repeated here for the sake of brevity.

[0082] In one possible implementation, each operation type corresponds to a relation template, and the operation-related information corresponding to each operation type is recorded through the corresponding relation template.

[0083] The operation-related information corresponding to each operation type can be recorded through the corresponding relationship template. In other words, the lineage relationship management method provided in this application can not only manage the lineage relationship between tables, but also manage the relationship between tables and other entities, and between other entities and other entities.

[0084] Figure 5 This is a schematic diagram of the relationship template provided in the embodiments of this application.

[0085] like Figure 5 As shown, Figure 5 a) is the relation template corresponding to the data table creation operation; Figure 5 b) is the relation template corresponding to the operation of creating a view table; Figure 5 c) is the relation template corresponding to the table name modification operation; Figure 5 d) is the relation template corresponding to the download operation; Figure 5 e) is the relation template corresponding to the export operation; Figure 5 f) is the relation template corresponding to the import operation; Figure 5 g) is the relation template corresponding to the table deletion operation; Figure 5 h) is the relation template corresponding to the query operation. The record template can include not only the lineage relationship between tables, but also the relationship between tables and other entities, and between other entities and other entities, providing richer relational data and facilitating the analysis of other issues in the future. This application does not impose any limitations on this.

[0086] As mentioned above, the lineage relationships between tables, and also the relationships between tables and other entities, as well as between other entities, can all be encapsulated in the form of nodes and edges and stored in graph data. In one possible implementation, nodes and edges also contain their own attribute information.

[0087] As an example and not a limitation, the attribute information of a temporary table node may include, but is not limited to: table name, type (internal or external table), session identifier of the bound session, creation time, update time, test or production type, responsible person, whether it is a view, and whether it has been deleted. Due to operational habits, there may be a large number of temporary tables with the same name in actual production. In the data system, since temporary tables exist in different sessions, there will be no conflict. However, if the temporary tables with the same name are not distinguished when recording the lineage, the lineage will be confused. Therefore, this application adds the session identifier to the node identifier and attributes of the temporary table node to facilitate subsequent querying and analysis.

[0088] As an example and not a limitation, the attribute information of a database node may include, but is not limited to: database name, description statement, storage location, parameters, and whether it has been deleted.

[0089] As an example and not a limitation, the attribute information of an HDFS file node may include, but is not limited to, storage location, file name, and other attribute information.

[0090] To facilitate a better understanding of the blood relation management method provided in this application, the following is combined with... Figure 6 The method for managing blood relations provided in this application will be further explained.

[0091] Figure 6 This is another illustrative flowchart of the blood relationship management method provided in the embodiments of this application.

[0092] Figure 6 The steps shown can be performed by a bloodline management device, or by a component (such as a chip, chip system, etc.) configured in the bloodline management device, or by a logic module or software capable of implementing all or part of the functions of the bloodline management device. This application embodiment does not limit this. The bloodline management device may have, for example... Figure 2 The structure shown is not limited to the embodiments described in this application. Figure 6 As shown, the blood relationship management method provided in this application embodiment may include steps involved in real-time tasks (e.g., steps 601 to 608) and steps involved in timed tasks (or periodic tasks) (e.g., steps 609 to 611). The following describes... Figure 6 Each step in the process will be explained in detail.

[0093] The steps involved in a real-time task:

[0094] In step 601, the SQL statement is executed.

[0095] For example, the lineage management device can execute an SQL statement in response to a user's operation request corresponding to an SQL statement. The SQL statement includes, but is not limited to, SQL statements corresponding to operations such as creating a data table, creating a view table, modifying a table name, downloading, exporting, importing, deleting a table, or querying.

[0096] In step 602, the original data lineage information corresponding to the SQL statement is obtained.

[0097] For example, a blood relationship management device can be based on Figure 2 The information acquisition module 210 shown obtains the raw data lineage information corresponding to the SQL statement. A description of the raw data lineage information can be found in the relevant content above; for brevity, it will not be repeated here.

[0098] In step 603, it is determined whether the data in the original lineage information involves a temporary table.

[0099] For example, the lineage management device can determine, based on the relationship resolution module 220, whether the data in the original lineage information involves a temporary table; that is, it can determine whether the type of the input table and / or output table involved in the SQL statement is a temporary table. If the type of the input table or output table involved in the SQL statement is a temporary table, step 604 can be executed; if the type of the input table and output table involved in the SQL statement is not a temporary table, the lineage relationship of the permanent table is recorded based on known methods, and this application does not impose any limitations on this.

[0100] In step 604, based on the operation type corresponding to the SQL statement, a target relation template is determined from a set of preset relation templates, and relation parsing is performed based on the target relation template.

[0101] For example, the bloodline management device can, based on the relationship parsing module 220, determine the target relationship template from a set of preset relationship templates according to the operation type corresponding to the SQL statement, and perform relationship parsing based on the target relationship template. The preset relationship templates may include, but are not limited to, those shown below. Figure 5 The relationship template shown is as follows. For example, when the SQL statement is a statement that creates a data table, and the corresponding operation type is create data table, the target relationship template can be as follows: Figure 5 The relation template corresponding to the data table creation operation shown in a).

[0102] In step 605, the parsed lineage relationships and / or other relationships are encapsulated into a format acceptable to the graph database, stored in the graph database, and the session identifier of the current session is recorded in Redis.

[0103] For example, the lineage management device can, based on the graph module 240, encapsulate the parsed lineage relationships and / or other relationships into a format acceptable to the graph database and store them in the graph database. Furthermore, it can also record the session identifier of the current session in Redis to facilitate subsequent filtering of closed sessions by their session identifiers. Understandably, querying data in Redis is more convenient, faster, and more efficient than querying data directly in the graph database.

[0104] In step 606, it is determined whether the temporary table appears as input to the operation, and another table is generated based on the temporary table.

[0105] For example, the bloodline management device can parse a temporary table as input to an operation based on the relationship parsing module 220, and generate (or output) another table (i.e., a downstream table of the temporary table) based on the temporary table. If the temporary table is used as input to the operation and another table is generated based on the temporary table, step 607 can be executed; if no other table is generated based on the temporary table, no step can be executed.

[0106] In step 607, the graph database is searched layer by layer upwards from the node identified by the temporary table to find the permanent table in the upstream lineage of the temporary table as the logical upstream lineage of the downstream table of the temporary table.

[0107] For example, the lineage management device can, based on the logical lineage reasoning module 230, query upwards layer by layer in the lineage relationships of the graph database, starting from the node identified by the temporary table, to find the permanent table in the upstream lineage relationship of the temporary table as the logical upstream lineage of the downstream table of the temporary table. A detailed description can be found in the relevant content above; for brevity, it will not be repeated here.

[0108] In step 608, the lineage relationships between these upstream permanent tables and the downstream tables of the temporary table are recorded in the graph database.

[0109] For example, the lineage management device can record the lineage relationships between these upstream permanent tables and the downstream tables of the temporary table in the graph database based on the graph module 240. A detailed description can be found in the relevant content of step 340 in method 300, and for the sake of brevity, it will not be repeated here.

[0110] The steps involved in a scheduled task:

[0111] In step 609, the session identifiers of normally closed sessions and abnormally closed sessions are periodically filtered.

[0112] For example, the lineage management device can periodically filter the session identifiers of normally closed sessions and abnormally closed sessions based on the temporary lineage cleanup module 250. A detailed description of normally closed sessions and abnormally closed sessions can be found in the relevant content above, and will not be repeated here for the sake of brevity.

[0113] In step 610, the target node is determined based on the session identifiers of these normally closed sessions and the session identifiers of abnormally closed sessions.

[0114] For example, the lineage management device can determine the target node based on the temporary lineage cleanup module 250, using the session identifiers of normally closed sessions and abnormally closed sessions. A detailed description of the target node can be found in the relevant content above, and for the sake of brevity, it will not be repeated here.

[0115] In step 611, these target nodes and the edges connected to these target nodes are deleted from the graph database, and the session identifiers associated with these target nodes are deleted from Redis.

[0116] For example, the lineage management device can delete these target nodes and the edges connected to them from the graph database based on the temporary table lineage cleanup module 250. It can also delete the session identifiers associated with these target nodes from Redis. Detailed descriptions can be found in the relevant content above; for brevity, they will not be repeated here.

[0117] Figure 7 This is another schematic block diagram of the blood relationship management device provided in the embodiments of this application. For example... Figure 7 As shown, the blood relationship management device 700 may include: an execution module 710, an acquisition module 720, a query module 730, and a recording module 740. The execution module 710 can be used to execute a first Structured Query Language (SQL) statement, which instructs the generation of downstream tables based on a temporary table. The acquisition module 720 can be used to acquire a lineage graph between multiple data tables, which describes the lineage relationships between the multiple data tables generated during the execution of multiple SQL statements. The multiple SQL statements include the first SQL statement. The lineage graph includes multiple nodes corresponding to the multiple data tables, and edges connecting parent nodes and child nodes among the multiple nodes. Each edge points from a parent node to a child node, indicating that the data table corresponding to each child node is generated based on the connected parent node. The query module 730 can be used to query upwards layer by layer in the lineage graph starting from the node identified by the temporary table, until all data tables in the queried layer are permanent tables, at which point the query stops. The recording module 740 can be used to record the lineage relationships between all permanent tables returned by the query and the downstream tables in the lineage graph.

[0118] Optionally, the node identifier of the node corresponding to the temporary table includes: the table name of the temporary table and the session identifier of the session in which the second SQL statement is located, wherein the second SQL statement indicates the generation of the temporary table.

[0119] Optionally, the lineage management device may further include a temporary table lineage cleaning module, which can be used to periodically search for target nodes in the lineage graph, the target nodes corresponding to the temporary table, and the identifier of the target node containing the session identifier of a closed session; and delete the target node and the edges connected to the target node from the lineage graph.

[0120] Optionally, the temporary table lineage cleanup module is also used to periodically determine the closed session based on the node identifier of the target node corresponding to each temporary table in the lineage graph and the session identifier of the unclosed session stored under the specified path.

[0121] Optionally, the acquisition module 720 can also be used to acquire at least one of the following based on each of the plurality of SQL statements: operation-related information corresponding to the SQL statement, and data table-related information involved in the SQL statement. The operation-related information includes one or more of the following: operation type, operation identifier, session, Internet Protocol IP address of the machine performing the operation, creation time or user who submitted the operation request. The data table-related information includes one or more of the following: table name, type, database, cluster, person in charge of the data table, fields included in the data table, field types, partition where the data table is located, creation time or update time.

[0122] Optionally, each operation type corresponds to a relation template, and the operation-related information corresponding to each operation type is recorded through the corresponding relation template.

[0123] Optionally, the operation type includes at least one of the following: creating a data table, creating a view table, modifying a table name, downloading, exporting, importing, deleting a table, or querying.

[0124] It should be understood that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. For example, as an example and not a limitation, the acquisition module 720 can be equivalent to... Figure 2 The information collection module 210 and query module 730 shown can be equivalent to Figure 2 The logical bloodline reasoning module 230 and the recording module 740 shown can be equivalent to Figure 2 The diagram shows module 240. Furthermore, the functional modules in the various embodiments of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0125] Figure 8This is another schematic block diagram of the bloodline management device provided in the embodiments of this application. This device can be used to implement the bloodline management device in the above-described method, or components (such as chips, chip systems, etc.) in the bloodline management device, or the functions of a logic module or software capable of implementing all or part of the functions of the bloodline management device. The device can be a chip system. In the embodiments of this application, the chip system can be composed of chips, or it can include chips and other discrete devices.

[0126] like Figure 8 As shown, the blood relationship management device 800 may include at least one processor 810 for implementing the embodiments of this application. Figure 3 or Figure 6 The steps are as follows. For example, processor 810 can be used to execute a first Structured Query Language (SQL) statement, which instructs the generation of downstream tables based on a temporary table; obtain a lineage graph between multiple data tables, the lineage graph describing the lineage relationships between the multiple data tables generated during the execution of multiple SQL statements, the multiple SQL statements including the first SQL statement, the lineage graph including: multiple nodes corresponding to the multiple data tables, and edges connecting parent nodes and child nodes among the multiple nodes, each edge pointing from a parent node to a child node, indicating that the data table corresponding to each child node is generated based on the connected parent node; query upwards layer by layer in the lineage graph starting from the node identified by the temporary table, until all data tables in the queried layer are permanent tables, at which point the query stops; record the lineage relationships between all permanent tables returned by the query and the downstream tables in the lineage graph. See the detailed description in the method example for specifics; it will not be repeated here.

[0127] The kinship management device 800 may further include at least one memory 820 for storing program instructions and / or data. The memory 820 is coupled to the processor 810. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, which may be electrical, mechanical, or other forms, for information exchange between devices, units, or modules. The processor 810 may operate in conjunction with the memory 820. The processor 810 may execute program instructions stored in the memory 820. At least one of the at least one memory may be included in the processor.

[0128] The kinship management device 800 may further include a communication interface 830 for communicating with other devices via a transmission medium, thereby enabling the kinship management device 800 to communicate with other devices. The communication interface 830 may be, for example, a transceiver, interface, bus, circuit, or a device capable of transmitting and receiving functions. The processor 810 may utilize the communication interface 830 to transmit and receive data and / or information.

[0129] This application embodiment does not limit the specific connection medium between the processor 810, memory 820, and communication interface 830. This application embodiment... Figure 8 The processor 810, memory 820, and communication interface 830 are connected via bus 840. Bus 840 is in Figure 8 The connections between other components are shown in bold and are for illustrative purposes only, not as limiting information. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0130] This application also provides a computer program product, the computer program product comprising: a computer program (also referred to as code or instructions), which, when executed, causes a kinship management device to perform... Figure 3 or Figure 6 The steps in any of the embodiments shown.

[0131] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is executed, it causes the kinship management device to perform... Figure 3 or Figure 6 The steps in any of the embodiments shown.

[0132] It should be understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0133] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0134] The terms “unit”, “module”, etc., used in this specification may be used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution.

[0135] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. In the several embodiments provided in this application, it should be understood that the disclosed apparatus, devices, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0136] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0137] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0138] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs, DVDs), or semiconductor media (e.g., solid-state disks, SSDs), etc.

[0139] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0140] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for managing blood relations, characterized in that, include: Execute the first SQL statement, which instructs the generation of a downstream table based on a temporary table, wherein the SQL statement is a Structured Query Language statement; Obtain a lineage graph between multiple data tables. The lineage graph is used to describe the lineage relationship between the multiple data tables generated during the execution of multiple SQL statements. The multiple SQL statements include the first SQL statement. The lineage graph includes: multiple nodes corresponding to the multiple data tables, and edges connecting parent nodes and child nodes among the multiple nodes. Each edge points from the parent node to the child node, indicating that the data table corresponding to each child node is generated based on the connected parent node. The query proceeds upwards from the node identified by the temporary table in the bloodline graph, layer by layer, until all data tables in the queried layer are permanent tables, at which point the query stops. Establish a lineage relationship between the permanent table of upstream lineage relationships and the downstream table of the temporary table; The lineage graph records the lineage relationships between all permanent tables returned by the query and the downstream tables, so that even after the lineage relationship of the temporary table is deleted, the lineage link from the downstream table to the permanent table can still be traced through the lineage graph. The node identifier of the node corresponding to the temporary table includes: The temporary table name and the session identifier of the session in which the second SQL statement is located are used to distinguish temporary tables with the same name in a multi-session environment. The method further includes: The target node is periodically searched in the bloodline graph. The target node corresponds to a temporary table, and the identifier of the target node includes the session identifier of the closed session. The session identifier of the closed session includes the session identifier of the normally closed session and the session identifier of the abnormally closed session. The session identifier of the abnormally closed session includes the session identifier of the session that was not closed within a preset time period scanned by the path scanning submodule. Remove the target node and the edges connected to the target node from the lineage graph; The method further includes: The closed session is determined periodically based on the node identifier of the target node corresponding to each temporary table in the lineage graph and the session identifier of the unclosed session stored under the specified path.

2. The method as described in claim 1, characterized in that, The method further includes: Based on each of the multiple SQL statements, obtain at least one of the following: operation-related information corresponding to the SQL statement, and information related to the data table involved in the SQL statement. The operation-related information includes one or more of the following: operation type, operation identifier, session, Internet Protocol IP address of the machine executing the operation, creation time or user submitting the operation request. The data table-related information includes one or more of the following: table name, type, database, cluster, person in charge of the data table, fields included in the data table, field types, partition where the data table is located, creation time or update time.

3. The method as described in claim 2, characterized in that, Each operation type corresponds to a relation template, and the operation-related information for each operation type is recorded through the corresponding relation template.

4. The method as described in claim 3, characterized in that, The operation types include at least one of the following: creating a data table, creating a view table, modifying a table name, downloading, exporting, importing, deleting a table, or querying.

5. A blood relationship management device, characterized in that, Includes modules for implementing the method as described in any one of claims 1 to 4.

6. A blood relationship management device, characterized in that, Including processor and memory, among which, The memory is used to store computer programs; The processor is used to invoke the computer program so that the kinship management device performs the method of any one of claims 1 to 4.

7. A computer-readable storage medium comprising instructions which, when executed on a computer, cause the computer to perform the method of any one of claims 1 to 4.

Images