Risk control factor blood relationship visualization method, device, equipment and storage medium

Abstract

The application discloses a risk control factor blood relationship visualization method and device, equipment and storage medium, relates to the technical field of data processing, and comprises the following steps: in response to a blood tracing request of a target business factor, performing reverse tracing with the target business factor as a starting node, and tracing to a data source node of the target business factor; based on the target business factor, the data source node and the reverse tracing path, a blood relationship link of the target business factor is constructed; and based on the blood relationship link, a blood relationship graph of the target business factor is generated. By generating a blood relationship link through reverse tracing, the problem of invisible and difficult to trace of the blood relationship link of the risk control factor in the prior art is solved, and the readability and tracing efficiency of the data link are improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to methods, apparatus, equipment and storage media for visualizing the lineage of risk control factors. Background Technology

[0002] Risk control factors are the core basis for financial risk control decisions. Current mainstream methods for visualizing the data lineage of risk control factors use tree structures or basic flowcharts as the display medium. They present the data flow path by connecting data sources, processing nodes, and business factors as nodes, thus achieving a macro-level representation of lineage relationships. However, the core limitation of existing technologies lies in the coarse granularity of lineage display. They can only present the macro-level link of "data source tracing to the final business factor," failing to cover the various intermediate stages in the factor development process, and making it even more difficult to locate fine-grained lineage relationships at the field level. This deficiency directly leads to a situation where, when anomalies occur in the source data or intermediate stages, technical personnel need to invest significant manpower to trace the data flow step by step, making it impossible to quickly pinpoint the problem node and its impact scope, significantly prolonging the risk handling time.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a method, device, equipment and storage medium for visualizing the lineage of risk control factors, aiming to solve the technical problem of the difficulty in tracing the lineage of risk control factors.

[0005] To achieve the above objectives, this application proposes a method for visualizing the lineage of risk control factors, the method comprising: In response to a lineage tracing request for a target business factor, reverse tracing is performed starting from the target business factor and tracing back to the data source node of the target business factor. Based on the target business factor, the data source node, and the tracing path of reverse tracing, the lineage relationship link of the target business factor is constructed; Based on the aforementioned bloodline relationship links, a bloodline relationship map of the target business factor is generated.

[0006] In one embodiment, the step of responding to a lineage tracing request for a target business factor and performing reverse tracing from the target business factor as the starting node to the data source node of the target business factor includes: Based on the factor identifier information of the target business factor, obtain the summary factor and calculation dimension configured and bound to the target business factor; The calculation logic of the summary factor is analyzed to determine the meta-factors corresponding to the summary factor and the calculation dimension; Based on the preset mapping relationship between the meta-factor and the target message, the target message on which the meta-factor depends is determined; The target message is traced and located until the data source node corresponding to the target message is determined.

[0007] In one embodiment, the step of parsing the calculation logic of the summary factor to determine the meta-factors corresponding to the summary factor and the calculation dimension includes: Obtain the calculation logic definition text and factor parameters of the summary factor; Perform syntax parsing on the computational logic definition text to extract the data processing function identifiers and meta-factor identifiers referenced in the computational logic definition text; Based on the data processing function identifier, the meta-factor identifier, the factor parameters, and the calculation dimension, the meta-factor associated with the summary factor is determined by querying.

[0008] In one embodiment, the step of determining the target message on which the meta-factor depends based on a preset mapping relationship between the meta-factor and the target message includes: Query the preset mapping relationship between the meta-factor and the candidate message to obtain the set of candidate messages associated with the meta-factor; The calculation logic of the aggregation factor is analyzed, and the message reference range defined by the meta-factor is determined based on the calculation logic; Based on the message reference range, the candidate message set is filtered to determine the target message that matches the message reference range.

[0009] In one embodiment, the step of tracing and locating based on the target message until the data source node corresponding to the target message is determined includes: Query the distribution file identifier associated with the target message, and determine the corresponding distribution file node based on the distribution file identifier; Based on the generation relationship between the distributed file node and the data model, the data model node corresponding to the distributed file node is traced back; Based on the mapping relationship between the data model nodes and the data source, the data source node corresponding to the data model node can be traced back.

[0010] In one embodiment, the step of constructing the lineage relationship link of the target business factor based on the target business factor, the data source node, and the reverse tracing path includes: Based on the target business factors, the data source nodes, and the reverse tracing path, determine the dependency type and association direction of the nodes in the tracing path; Based on the dependency type and the association direction, an initial relationship link for the target business factor is generated; The initial relationship links are detected and associated to construct the lineage relationship links of the target business factors.

[0011] In one embodiment, the method further includes: Receive node abnormality trigger signal, and identify the corresponding abnormal node from the kinship map based on the node abnormality trigger signal; The upstream and downstream full-link related nodes of the abnormal node are highlighted to obtain the abnormal relationship link where the abnormal node is located.

[0012] Furthermore, to achieve the above objectives, this application also proposes a visualization device for the lineage of risk control factors, the visualization device comprising: The node tracing module is used to respond to a lineage tracing request for a target business factor, and to perform reverse tracing starting from the target business factor to the data source node of the target business factor. The link generation module is used to construct the lineage relationship link of the target business factor based on the target business factor, the data source node, and the tracing path of reverse tracing. The genealogy generation module is used to generate a genealogy graph of the target business factor based on the genealogy link.

[0013] In addition, to achieve the above objectives, this application also proposes a visualization device for the lineage of risk control factors, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the visualization method for the lineage of risk control factors as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the visualization method for the pedigree relationship of risk control factors as described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the visualization method for the pedigree of risk control factors as described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: This application proposes a method, apparatus, device, and storage medium for visualizing the lineage relationships of risk control factors. In response to a lineage tracing request for a target business factor, reverse tracing is performed starting from the target business factor and tracing back to its data source node. Based on the target business factor, the data source node, and the reverse tracing path, a lineage relationship link for the target business factor is constructed. Based on this lineage relationship link, a lineage relationship graph of the target business factor is generated. By generating the lineage relationship link through reverse tracing, the problem of invisible and difficult-to-trace risk control factor lineage links in existing technologies is solved, improving the readability and tracing efficiency of the data link. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating the first embodiment of the visualization method for the bloodline relationship of risk control factors in this application; Figure 2 An example diagram of the generation of bloodline links provided in the embodiment of the visualization method for the bloodline relationship of risk control factors in this application; Figure 3 A simplified flowchart illustrating the visualization method for the lineage of risk control factors provided in this application embodiment; Figure 4 This is a schematic diagram of the module structure of the visualization device for the bloodline relationship of risk control factors in an embodiment of this application; Figure 5 This is a schematic diagram of the hardware operating environment involved in the visualization method of the bloodline relationship of risk control factors in the embodiments of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution of this application embodiment is: in response to a lineage tracing request for a target business factor, reverse tracing is performed with the target business factor as the starting node, tracing back to the data source node of the target business factor; based on the target business factor, the data source node, and the reverse tracing path, a lineage relationship link of the target business factor is constructed; based on the lineage relationship link, a lineage relationship graph of the target business factor is generated.

[0024] In this embodiment, for ease of description, the following description will focus on the visualization system of the bloodline relationship of risk control factors.

[0025] Risk control factors are the core basis for financial risk control decisions. Currently, mainstream methods for visualizing the data lineage of risk control factors in the industry use tree structures or basic flowcharts as the display medium. They present the data flow path by connecting data sources, processing nodes, and business factors as nodes, thus achieving a macro-level representation of lineage relationships. However, the core limitation of existing technologies lies in the coarse granularity of lineage display. They can only present the macro-level link of "data source → final business factor," failing to cover the various intermediate stages in the factor development process, and making it even more difficult to locate fine-grained lineage relationships at the field level. This deficiency directly leads to a situation where, when anomalies occur in the source data or intermediate stages, technical personnel need to invest significant manpower to trace the data flow step by step, making it impossible to quickly pinpoint the problem node and its impact scope, significantly prolonging the risk handling time.

[0026] This application provides a solution that generates a lineage relationship chain through reverse tracing, which solves the problem that the lineage chain of risk control factors is invisible and difficult to trace in the prior art, and improves the readability and tracing efficiency of the data chain.

[0027] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, a visualization system for the lineage of risk control factors, etc. The following description uses a visualization system for the lineage of risk control factors as an example to illustrate this embodiment and the subsequent embodiments.

[0028] Based on this, embodiments of this application provide a method for visualizing the lineage of risk control factors, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the visualization method for the bloodline relationship of risk control factors in this application.

[0029] In this embodiment, the visualization method for the bloodline relationship of the risk control factor includes steps S11 to S13: Step S11: In response to the lineage tracing request of the target business factor, reverse tracing is performed with the target business factor as the starting node, tracing back to the data source node of the target business factor.

[0030] It should be noted that the target business factor is a terminal factor directly applied to risk control rules and indicators by business personnel. It is the core basis for risk control decisions, and different summary factors will be used at different points in time. In this step, it serves as the starting point for lineage tracing, clearly defining the target object for tracing. The lineage tracing request is a request initiated by a user (such as business, development, or risk control team members) to query the data source and flow of the target business factor, and it is the triggering condition for executing this step.

[0031] Additionally, it should be noted that reverse tracing refers to a method of tracing back from the target business factors at the terminal to the original data source. The core technology used is "recursive query + node association matching," which is used to reconstruct the data flow path layer by layer. The data source node is the source system providing the original data, along with its corresponding database, files, etc., containing the source data model. It is the endpoint of reverse tracing, marking the completion of the entire tracing process.

[0032] Understandably, the purpose of this step is to obtain the complete data flow trajectory of the target business factor from the terminal to the source. The principle is to use reverse tracing to break the limitation of existing technologies that "can only show the macro link". By tracing backward from the target business factor, it ensures that no intermediate flow link is missed. Its role is to provide basic data support for the subsequent construction of a complete lineage link and avoid the problem of link breakage or omission caused by the forward tracing direction.

[0033] Specifically, in one embodiment of this application, a traceability request initiated by a user through the system interface using the name or identifier of a target business factor triggers a reverse tracing process. Alternatively, it receives traceability instructions and target business factor identifiers transmitted from other system interfaces to initiate tracing. Batch traceability requests are supported, allowing reverse tracing to be performed on multiple target business factors simultaneously. Single tracing satisfies immediate query needs, while batch tracing improves the efficiency of multi-factor management. Combinations of various methods can cover the interaction needs of different users and systems.

[0034] For example, when a user enters the target business factor "1001 - spot position quantity" in the risk control factor lineage management system and initiates a traceability request, the system takes the business factor as the starting node, first queries its associated summary factor, then traces back to the meta factor, message, and issued file through the summary factor, and finally traces back to the data model corresponding to the data source.

[0035] Step S12: Based on the target business factor, the data source node, and the tracing path of reverse tracing, construct the lineage relationship link of the target business factor.

[0036] It should be noted that the traceability path is a sequence of node associations formed during the reverse tracing process, including intermediate nodes (such as summary factors, meta-factors, messages, etc.) and the connections between nodes, which is the core data foundation for building the link. The lineage relationship link is a structured link that reflects the complete data flow of the target business factor from the data source to the terminal factor, containing node-level and field-level association information. Its function is to integrate the scattered traceability nodes and relationships into an ordered and complete link structure.

[0037] Understandably, the purpose of this step is to transform the discrete nodes and relationships obtained through reverse tracing into a standardized link structure. The principle is to sort out the dependencies and order between nodes according to the data flow logic based on the target business factor (end point), data source node (start point), and intermediate nodes in the tracing path. Its role is to provide structured data for the subsequent generation of visualization maps, and to solve the problem of poor visualization effect caused by messy links and lack of a unified structure in the existing technology.

[0038] Specifically, in one embodiment of this application, the nodes are logically ordered according to the sequence of "data source node → data model → file distribution → message → meta-factor → summary factor → target business factor" to construct the link. First, the dependency types between nodes (such as direct dependency and indirect dependency) are clarified, and then the link is constructed by sorting according to dependency strength. Then, the link is categorized by node type (such as data storage type and data processing type) to ensure clear link classification. This approach ensures the integrity and readability of the link from different dimensions: logical order ensures the rationality of link flow, dependency type ensures the accuracy of link associations, and node type classification ensures a clear link structure. Combining these methods achieves optimal construction of a structured link.

[0039] For example, based on the traceability path of "1001 - spot position quantity", the system sorts out the relationship between the data source node (11-032 database) → data model node (DWD_AST_HLDP_INFO product position information table) → file distribution node → message node (21 - product position information) → meta factor node (16 - circulation type) → summary factor node (1001001 - spot position quantity (pre-instruction)) → target business factor node, and constructs a complete lineage relationship link according to the forward logic.

[0040] Step S13: Based on the bloodline relationship link, generate the bloodline relationship map of the target business factor.

[0041] It should be noted that the kinship graph is the result of presenting the kinship chain in a visual graphical form. The hierarchical layout technology is used to determine the display position of each node, and the node association drawing technology is used to present the connection relationship between nodes. Its function is to transform the structured chain into an intuitive and interactive graphic, so that users can quickly understand the data flow chain.

[0042] Understandably, the purpose of this step is to provide users with an intuitive and easy-to-understand display of blood relations. The principle is based on a structured blood relation chain, using visualization technology to arrange nodes and draw connection lines according to certain rules. Its function is to solve the problem that the blood relation display is not intuitive and the user's understanding cost is high in the existing technology, and to improve the user's perception efficiency of the data chain.

[0043] Specifically, nodes are arranged horizontally according to the hierarchy of "Business Factors (Top Level) → Summary Factors → Meta Factors → Messages → Distributed Files → Data Models → Data Sources (Bottom Level)" and vertically distributed within the same level. Different colors or icons are used to identify nodes by type (e.g., business factor class, data source class) to improve distinguishability. The system supports graph zooming and panning operations to adapt to viewing needs of different link lengths. The hierarchical layout ensures clear link logic, node classification labels facilitate quick identification of node types, and zooming and panning operations enhance the user viewing experience. Combined, these features achieve optimal visualization results.

[0044] For example, based on the lineage relationship link of "1001 - spot position quantity", the system arranges each node horizontally in a hierarchical manner. The top layer displays the business factor of "1001 - spot position quantity", the next layer displays the associated summary factors, and so on down to the bottom data source node. Each node is marked with a different color according to its type, generating a scalable and pannable lineage relationship map, which allows users to intuitively view the entire link relationship.

[0045] This embodiment, through the above-described scheme, obtains all nodes in the entire chain by reverse tracing, constructs a structured lineage chain, and then generates a visual graph. It realizes the full-chain tracing and visualization of the target business factors to the data source, solving the problem of the invisible and difficult-to-trace lineage chain of risk control factors in the prior art. It extends the data lineage from the macro link to the full process coverage, improves the readability and tracing efficiency of the data chain, and provides basic support for anomaly location, change impact assessment, and cross-team collaboration.

[0046] Based on the above implementation scheme, in one feasible implementation, the step of responding to a lineage tracing request for a target business factor, and performing reverse tracing starting from the target business factor to trace back to the data source node of the target business factor, includes S21~S24: Step S21: Based on the factor identification information of the target business factor, obtain the summary factor and calculation dimension bound to the target business factor configuration.

[0047] It should be noted that factor identification information, such as factor number and factor name, is used to uniquely identify target business factors. In this step, it is used to accurately locate the configuration data corresponding to the target business factor, and the identification is matched with the business factor configuration information stored in the database. The summary factor consists of four parts: calculation dimension, monitoring scope, factor parameters, and calculation formula. The calculation formula is derived from the four arithmetic operations of several meta-factors and serves as the intermediate link connecting business factors and meta-factors. The calculation dimension is the grouping basis during business factor calculation and is an inherent attribute of the business factor. In this step, it serves as the first intermediate node in the reverse tracing of business factors, and its role is to build a traceability bridge from the business factor to subsequent data nodes.

[0048] Specifically, the system queries the target business factor identifier's corresponding action point record from the factor management database, then matches the summary factors bound to that action point, and reads the bound calculation dimensions from the target business factor's basic information table. If the target business factor has multiple action points, the system queries the summary factors corresponding to each action point separately, and finally merges and removes duplicates to obtain a complete set of summary factors.

[0049] For example, the identification information of the target business factor "1001 - spot position quantity" is "1001". The system queries the factor management database to find the corresponding action time points of the factor, including "before - instruction", "during", and "after". It then matches and obtains the summary factors "1001001 - spot position quantity (before - instruction)", "1001002 - spot position quantity (during)", and "1001002 - spot position quantity (after)" bound to each action time point. After merging, the summary factor set corresponding to the business factor is obtained, and the bound calculation dimension is read from the business factor basic information table.

[0050] Step S22: Analyze the calculation logic of the summary factor to determine the meta-factors corresponding to the summary factor and the calculation dimension.

[0051] It should be noted that the calculation logic is the core component of the summary factor. It defines the combination method and operation rules of the meta-factors and stores it in DSL (Domain-Specific Language) code (a self-developed standardized factor development language). In this step, it is used to extract the relationship between the summary factor and the meta-factors. The parser performs syntactic analysis on the DSL code. The meta-factor is a combination or arithmetic operation of several fields from a single message. It is the smallest data granularity in factor processing. In this step, it serves as the next-level traceability node of the summary factor, and its role is to further extend the lineage tracing link and get closer to the data source.

[0052] Specifically, the DSL code parser is invoked to perform lexical and syntactic analysis on the DSL codes of the aggregated factors, extracting meta-factor identifiers. If the calculation logic references a DSL function, the calculation logic of the DSL function is parsed first, and then the associated meta-factors are extracted. The parsed meta-factors are then deduplicated to avoid repeated tracing.

[0053] For example, for the summary factor "1001001-Spot open interest (pre-instruction)", the system calls the DSL code parser to parse its DSL code. The code defines "11-Initial open interest participates in four arithmetic operations", and the referenced DSL function is associated with "1-Product identifier meta-factor (identifier 1)". After parsing and deduplication, the meta-factor set corresponding to the summary factor is {11-Initial open interest, 1-Product identifier}.

[0054] Step S23: Determine the target message on which the meta-factor depends based on the preset mapping relationship between the meta-factor and the target message.

[0055] It should be noted that the preset mapping relationship is a combination mapping relationship of "meta-factors - target messages" pre-stored in the database. It is established based on the value logic of meta-factors and the data attributes of messages, and the corresponding message records are queried through meta-factor identifiers. Target messages are the static and real-time data (such as basic securities information, initial holdings information, etc.) on which risk control calculations rely. They are the data source of meta-factors and serve as the next-level traceability node of meta-factors in this step. Their role is to continue extending the lineage link and connect to the intermediate data carriers in the data flow.

[0056] Specifically, the system queries the full set of messages corresponding to the meta-factor identifier from the "meta-factor-target message" mapping table. If multiple meta-factors are associated with the same message, they are merged and deduplicated to obtain the target message set. This ensures the accuracy and efficiency of target message identification, enables basic matching queries, improves the adaptability of messages to business scenarios, avoids redundant processing, and can optimize the filtering effect of target messages when used in combination.

[0057] Step S24: Based on the target message, perform tracing and positioning until the data source node corresponding to the target message is determined.

[0058] It should be noted that tracing and locating refers to the process of reversing the data source from the target message, tracing back layer by layer through the pre-defined associations between the message and downstream nodes. The data source node is the original data source of the target message, containing information such as the source system, database, and source table. In this step, it serves as the tracing endpoint, and its role is to complete the closed-loop tracing from the target business factor to the original data source.

[0059] Specifically, the process first queries the distribution files associated with the target message, then traces the data model through the distribution files, and finally traces the data source through the data model. If the target message is associated with multiple distribution files, the data source corresponding to each distribution file is traced separately, and then merged to obtain a complete set of data sources. During the tracing process, the associated fields of each node are recorded to support field-level tracing.

[0060] This embodiment, through the above-described scheme, concretizes the reverse tracing process by outlining the steps of "obtaining the summary factor bound to the business factor → parsing the summary factor to obtain the meta-factor → matching the target message corresponding to the meta-factor → tracing the message back to the data source." It clarifies the association and matching logic of each level of nodes, solves the problems of ambiguous reverse tracing paths and unclear node associations in existing technologies, makes full-link tracing more operable, further improves the accuracy and coherence of lineage tracing, and provides more detailed node association data support for the subsequent construction of structured links and visualization maps.

[0061] Based on the above implementation scheme, in one feasible implementation, the step of parsing the calculation logic of the summary factor and determining the meta-factors corresponding to the summary factor and the calculation dimension includes S31~S33: Step S31: Obtain the calculation logic definition text and factor parameters of the summary factor.

[0062] It should be noted that the calculation logic definition text is text data that records the summary factor calculation rules. Written in a self-developed DSL language, it includes information such as meta-factor references, calculation rules, and function calls. In this step, it serves as the raw data for parsing, and the definition text stored in the factor configuration database is read. Its purpose is to provide raw material for subsequent syntax parsing and is the foundation for extracting meta-factor relationships. Factor parameters include conditional parameters and calculation parameters, used to filter messages or adjust the calculation logic.

[0063] Specifically, the calculation logic text field in the factor configuration database is queried based on the summary factor identifier, and the text content is read directly. If the calculation logic text is stored in encryption, it is decrypted before reading. After reading the text, the text format is validated to ensure it conforms to the DSL syntax specification and to avoid invalid parsing.

[0064] For example, the identifier of the summary factor "1001001 - spot position quantity (pre-instruction)" is "1001001". The system queries the factor configuration database based on this identifier and reads the corresponding calculation logic definition text as "summary factor = initial position quantity meta-factor (ID:11) + DSL function (ID:18) - sell transaction quantity meta-factor (ID:13)". After the text format is validated, it proceeds to the subsequent parsing steps.

[0065] Step S32: Perform syntax parsing on the computational logic definition text to extract the data processing function identifiers and meta-factor identifiers referenced in the computational logic definition text.

[0066] It should be noted that syntax parsing refers to the process of disassembling and analyzing the definition text according to the grammatical rules of the DSL language, including sub-steps such as lexical analysis and syntax tree construction. The data processing function identifier is a unique identifier (e.g., function ID) used to identify DSL functions. DSL functions are reusable functions formed by standardizing and encapsulating the calculation logic of general summary factors. The meta-factor identifier is a unique identifier (e.g., meta-factor ID) used to identify meta-factors.

[0067] Specifically, the DSL parser is invoked to first perform lexical analysis on the text, breaking it down into lexical units such as keywords, identifiers, and operators. Then, a syntax tree is constructed to identify the object type (metafactor, function) corresponding to the identifier and extract the identifier. If nested calls exist in the text (such as a function referencing a metafactor), the nested parts are recursively parsed to extract identifiers at all levels. The extracted identifiers are categorized and stored separately as metafactor identifiers, function identifiers, and parameter identifiers for easy retrieval later.

[0068] For example, the text defining the computational logic "summary factor = initial position quantity meta-factor (ID:11) + DSL function (ID:18) - sell transaction quantity meta-factor (ID:13)" is parsed and lexically analyzed into lexical units such as "summary factor", "=", "initial position quantity meta-factor", "(ID:11)", "+", "DSL function", "(ID:18)", "-", "sell transaction quantity meta-factor", and "(ID:13)". After constructing the syntax tree, the meta-factor identifiers "11" and "13", the data processing function identifier "18", and the absence of factor parameters are identified and stored as three categories of identifier sets.

[0069] Step S33: Based on the data processing function identifier, the meta-factor identifier, the factor parameters, and the calculation dimension, query and determine the meta-factor associated with the summary factor.

[0070] It should be noted that query determination refers to the process of retrieving related objects and relationships from the corresponding management database based on the extracted identifiers, combining meta-factor identifiers, function identifiers, and parameter identifiers for joint queries. Related meta-factors include directly referenced meta-factors and indirectly referenced meta-factors (such as meta-factors referenced in DSL functions). Their function is to integrate all meta-factors related to the summary factor, forming a complete set of meta-factors, providing comprehensive evidence for subsequent tracing of message nodes.

[0071] Specifically, the process first queries the metafactor management database for directly related metafactors using metafactor identifiers; then, it queries the metafactors related to DSL functions using data processing function identifiers and adds them to the metafactor set; finally, it queries the metafactors related to factor parameters using factor parameters and adds them to the set. The retrieved metafactors are deduplicated to avoid duplicate records. The association type of the metafactors (direct association, function association, parameter association) is recorded to provide association type information for subsequent lineage link construction.

[0072] This embodiment, through the above-described scheme, further refines the process of parsing and summarizing factor calculation logic to obtain meta-factors by breaking down the steps of "obtaining the calculation logic definition text → parsing and extracting three types of identifiers → joint querying meta-factors with multiple identifiers". It clarifies the transformation logic from text to identifiers and then to meta-factors, solving the problems of insufficient parsing of calculation logic and incomplete extraction of meta-factors in the prior art. It achieves comprehensive coverage of directly and indirectly related meta-factors, improves the accuracy and completeness of meta-factor extraction, and provides more comprehensive intermediate node data for subsequent target message matching and full-link tracing.

[0073] Based on the above implementation scheme, in one feasible implementation, the step of determining the target message on which the meta-factor depends according to the preset mapping relationship between the meta-factor and the target message includes S41~S43: Step S41: Query the preset mapping relationship between the meta-factor and the candidate message to obtain the set of candidate messages associated with the meta-factor.

[0074] It should be noted that the candidate message set is a collection of all messages that the meta-factor may be associated with. It is determined based on a pre-defined "meta-factor-target message" mapping relationship, which is stored in the message association database and established by matching the meta-factor's value fields with the message's field attributes. This pre-defined mapping relationship is constructed during initialization based on a data dictionary and business rules. In this step, the candidate message set serves to provide a foundational dataset for subsequent target message filtering, ensuring sufficient data source support for the filtering process.

[0075] Specifically, the "meta-factor-target message" mapping table is retrieved from the message association database. By inputting the meta-factor identifier, all corresponding message records are retrieved, forming a candidate message set. During the query, the association fields between the meta-factor and each candidate message are recorded, providing field-level basis for subsequent filtering.

[0076] Step S42: Analyze the calculation logic of the summary factor, and determine the message reference range limited by the meta-factor based on the calculation logic.

[0077] It should be noted that the message reference range is a filtering condition restriction on messages in the summary factor calculation logic, such as message type, business scenario, time range, etc. In this step, it is used to filter the candidate message set and extract the filtering conditions from the calculation logic in the form of DSL code; its role is to clarify the effective range of meta-factor associated messages and provide a judgment standard for the filtering of candidate messages.

[0078] Specifically, the conditional parameters in the summary factor calculation logic are parsed to extract filtering conditions such as message type and business scenario, thus determining the message reference range. If the calculation logic references DSL functions, the message filtering rules in the DSL functions are parsed and added to the message reference range. The filtering conditions are categorized into "must be met" and "optional to be met" to clarify the filtering priority.

[0079] Step S43: Based on the message reference range, filter from the candidate message set to determine the target message that matches the message reference range.

[0080] It should be noted that the target message is the message in the candidate message set that meets all the filtering conditions. Its purpose is to accurately locate the message that the meta-factor actually depends on, providing an accurate intermediate node for subsequent tracing of the data source.

[0081] Specifically, the filtering criteria are prioritized, with "must-be-met" conditions matched first, followed by "optional-be-met" conditions, thus progressively filtering out the target messages. If multiple messages in the candidate message set meet the criteria, all of them are retained to form the target message set.

[0082] This embodiment, through the above-described scheme, further refines the process of matching meta-factors and target messages by dividing the steps of "querying the candidate message set → determining the message reference range → filtering to obtain the target message". It clarifies the filtering logic from candidate messages to target messages, solves the problems of ambiguous message matching and interference from irrelevant messages in the prior art, realizes the accurate association between meta-factors and target messages, improves the accuracy and targeting of message matching, and provides more accurate intermediate node support for subsequent data source tracing and full-link lineage construction.

[0083] Based on the above implementation scheme, in one feasible implementation, the step of tracing and locating based on the target message until the data source node corresponding to the target message is determined includes S51~S53: Step S51: Query the distribution file identifier associated with the target message, and determine the corresponding distribution file node based on the distribution file identifier.

[0084] It should be noted that the distributed file identifier is information used to uniquely identify the distributed file, such as file number and file name, and is stored in the message management database, where it has an associated record with the target message. The distributed file is a structured data file generated based on the internal target data model, used to connect the flow of messages and the data model. In this step, it serves as the upper-level traceability node of the target message. The associated distributed file identifier is queried through the target message identifier, and then the distributed file is matched using the identifier; its role is to build a traceability bridge between the target message and the data model, extending the lineage.

[0085] Specifically, the system queries the "Delivered File Identifier" field corresponding to the target message from the message management database, and then queries the corresponding delivered file node from the delivered file management database based on this identifier. If the target message is associated with multiple delivered file identifiers, multiple delivered file nodes are matched to form a set of delivered files. During the query, the association fields between the target message and the delivered files are recorded to support field-level traceability.

[0086] Step S52: Based on the generation relationship between the distributed file node and the data model, trace back to obtain the data model node corresponding to the distributed file node.

[0087] It should be noted that the generation relationship refers to the pre-defined relationship generated by the data model from the distributed documents. In other words, the data model is the data source for the distributed documents and is stored in the distributed document association table. The data model is an internal standardized model formed after the source data is cleaned, aggregated, and transformed. It serves as the unified data foundation for factor development and acts as the next-level traceability node above the distributed documents in this step. The associated data model is queried through the distributed document identifier; its role is to further extend the lineage and get closer to the original data source.

[0088] Specifically, the system queries the target data model identifier corresponding to the distributed file identifier from the distributed file association table, and then queries the corresponding data model node from the data model management database based on this identifier. If the distributed file is generated jointly by multiple data models, each data model node is traced separately to form a data model set. The field mapping relationship between the distributed file and the data model is recorded, clarifying the data model fields corresponding to the fields in the distributed file.

[0089] Step S53: Based on the mapping relationship between the data model node and the data source, trace back to obtain the data source node corresponding to the data model node.

[0090] It should be noted that the mapping relationship between data model nodes and data sources refers to the association between the data model and the data source. That is, the data model is generated by the data source and stored in the data model management table, containing data job identifiers, source system information, etc. The data source node is the source system that provides the original data, along with its corresponding database, files, etc. It is the endpoint of the end-to-end traceability. The associated data source information is queried through the data model identifier. Its function is to complete the traceability from the data model to the original data source, achieving a closed-loop end-to-end traceability system.

[0091] Specifically, the data model is queried from the data model management table to identify the corresponding data job. Then, based on this identifier, the source system identifier, database identifier, and source table field information of the data source are extracted from the data job table and combined to obtain the data source node. If the data model is associated with multiple data jobs, the data source corresponding to each data job is traced separately, and the nodes are merged and deduplicated to obtain a complete set of data source nodes. The processing rules information for the data model and data source are recorded to provide a basis for change impact assessment.

[0092] This embodiment, through the above-described scheme, further refines the process of tracing the data source based on the target message by breaking it down into steps: "querying the issued file identifier to determine the issued file node → tracing the data model node based on the generation relationship → tracing the data source node based on the mapping relationship." This clarifies the hierarchical relationship logic between the message, the issued file, the data model, and the data source, solving the problem of unclear traceability in the intermediate links of data flow in the prior art. It achieves accurate tracing layer by layer from the message to the data source, improves the intermediate links of the whole-link tracing, and provides more solid node association data for building a complete and fine-grained lineage relationship link.

[0093] Based on the above implementation scheme, in one feasible implementation, the step of constructing the lineage relationship link of the target business factor based on the target business factor, the data source node, and the reverse tracing path includes S61~S63: Step S61: Based on the target business factor, the data source node, and the reverse tracing path, determine the dependency type and association direction of the nodes in the tracing path.

[0094] It should be noted that dependency type refers to the nature of the relationship between nodes in the tracing path, including direct dependency (such as the relationship between business factors and summary factors), indirect dependency (such as the relationship between business factors and meta-factors), and functional dependency (such as the relationship between summary factors and DSL functions), etc., determined based on node type and association rules. Association direction refers to the direction of data flow between nodes, such as from data source to data model as the forward direction, and from business factors to summary factors as the reverse direction, determined based on data flow logic; the role of both is to clarify the essential attributes and flow order of the relationship between nodes, providing a foundation for subsequently constructing an orderly lineage chain.

[0095] Specifically, following the node sequence of the tracing path, the association rules between adjacent nodes are analyzed one by one to determine the dependency type (e.g., business factor and summary factor are direct dependencies) and the association direction (e.g., business factor ← summary factor is a reverse direction). Indirect dependencies between non-adjacent nodes are marked, and the intermediate nodes of indirect dependencies are identified. The dependency type and association direction are bound to the node identifier and stored to form a node association attribute table.

[0096] Step S62: Based on the dependency type and the association direction, generate the initial relationship link of the target business factor.

[0097] It should be noted that the initial relationship link is a preliminary link structure built based on dependency type and association direction. It includes node sequence, dependency type label, and association direction label, and organizes nodes according to association direction and dependency type. Its function is to integrate discrete nodes and association attributes into a preliminary ordered link, providing a basic framework for subsequent optimization and improvement.

[0098] Specifically, nodes are arranged in a forward association direction: "Data Source Node → Data Model → File Distribution → Message → Meta-Factor → Summary Factor → Target Business Factor," and the dependency types between adjacent nodes are labeled to generate a linear initial link. If there are multiple branch nodes (such as a meta-factor associating with multiple messages), a tree-like initial link is generated according to the branch structure. The node type (such as data source class, business factor class) is marked in the initial link to improve the readability of the link.

[0099] Step S63: Detect and associate the initial relationship link to construct the lineage relationship link of the target business factor.

[0100] It should be noted that correlation detection refers to the process of performing integrity, validity, and redundancy checks on the initial relationship link, including node omission detection, correlation validity verification, and redundant node removal. The lineage relationship link is a complete, valid, and non-redundant link structure formed after optimization and detection, containing node-level and field-level correlation information; its function is to improve the initial link, ensuring its integrity, accuracy, and usability.

[0101] Specifically, in one embodiment of this application, an integrity check is performed: The initial link is checked to ensure it contains all nodes obtained through reverse tracing (e.g., supplementary DSL function, factor parameter nodes), ensuring no omissions. A validity check is performed: The associations between nodes are verified to ensure actual data flow, and invalid associations are eliminated. A redundancy check is performed: Duplicate nodes in the link are eliminated, and duplicate associations are merged. Field-level association information is supplemented: Based on the field mapping relationship of node associations, field-level association details are supplemented for each node.

[0102] Please refer to [link / reference] for a better understanding. Figure 2 , Figure 2 This is an example diagram of the lineage relationship chain generated for an embodiment of this application. Starting from the target business factor "1001 - spot position quantity", the diagram unfolds the complete lineage relationship chain layer by layer according to the reverse tracing logic, intuitively presenting the association relationship of each level node in this solution. As shown in the diagram, the top-level target business factor "1001 - Spot Position Quantity" is directly linked to three types of aggregation factors: "1001001 - Spot Position Quantity (Pre-Order)", "1001002 - Spot Position Quantity (During)", and "1001003 - Spot Position Quantity (Post-Order)". It is also bound to two calculation dimensions: "1 - Product" and "2 - Securities", demonstrating the direct dependency between the business factor and the aggregation factors and calculation dimensions. The aggregation factors are further linked to factor parameters such as "10001 - Circulation Type" and DSL functions such as "19 - Remaining Valid Order Quantity". Through these parameters and functions, meta-factors such as "16 - Circulation Type", "17 - Investment Type", "18 - Restricted Type", "19 - Business Type", and "11 - Initial Position Quantity" are ultimately derived, clearly demonstrating the calculation logic of the aggregation factors. The process of meta-factor extraction involves the following steps: Meta-factors are matched with target messages such as "21-Product Holdings Information," "24-Securities Basic Information," "23-Transaction Notification Message," and "22-Order Placement Message" through a pre-defined mapping relationship, thus completing the association between meta-factors and message nodes. The target messages are then associated with two types of distributed files, "21-Product Holdings Information" and "24-Securities Basic Information," respectively, achieving the connection between messages and distributed files. The distributed files are further traced back to data model nodes such as "DWD_AST_HLDP_INFO Product Holdings Information Table" and "DWD_VAR_SCR_BASI_INFO Securities Basic Information Table," clarifying the source of the distributed files. Finally, the data model nodes are associated with two types of data source nodes, "11-O32 Database" and "12-Juyuan Database," respectively, forming a complete traceability loop from business factors to the original data source.

[0103] Meanwhile, the diagram uses different colors to distinguish various nodes such as business factors, summary factors, dimensions, factor parameters, DSL functions, meta-factors, messages, distributed files, data models, and data sources. Nodes at the same level are distributed vertically, while nodes at different levels are arranged horizontally, intuitively presenting the hierarchical relationship of each node and the direction of data flow. This not only reflects the core logic of reverse tracing in this solution—"recursive query + node association matching"—but also completely restores the forward lineage link of "business factor → summary factor → meta-factor → message → distributed file → data model → data source." This provides users with a clear and intuitive visual reference for understanding the entire data flow of risk control factors, and also intuitively verifies the feasibility and effectiveness of node association matching, link construction, and visualization in this solution.

[0104] This embodiment, through the above-described scheme, further refines the process of constructing kinship relationship links by breaking it down into subdivided steps: "determining node dependency types and association directions → generating initial relationship links → detecting and optimizing association links." It clarifies the complete logic from node attribute analysis to link framework generation and link optimization, solving the problems of unsystematic, chaotic, and incomplete kinship link construction in existing technologies. It achieves the construction of structured, complete, and fine-grained kinship links, providing core data support for the subsequent generation of high-quality visualization maps and improving the practicality and readability of kinship links.

[0105] Based on the above implementation scheme, in one feasible implementation, the method further includes steps S71-S72: Step S71: Receive a node abnormality trigger signal, and identify the corresponding abnormal node from the kinship map based on the node abnormality trigger signal.

[0106] It should be noted that the node anomaly trigger signal is a signal initiated by the system monitoring module or manually by the user, indicating that a node is abnormal. This signal includes information such as the abnormal node identifier, anomaly type, and anomaly time. The system receives the signal and extracts key information. An abnormal node refers to a node with problems such as data anomalies or computational logic anomalies (e.g., missing message node data, incorrect meta-factor calculations), and is the core object of anomaly analysis in this step. Identification refers to matching and locating the corresponding node from the lineage graph based on the abnormal node identifier. Matching the identifier with nodes in the graph is crucial for accurately locating the source node of the anomaly, providing a core object for subsequent analysis of the anomaly's impact scope.

[0107] Specifically, it receives anomaly trigger signals sent by users, parses the anomaly node identifiers in the signals, and matches and locates them in the graph. It also receives anomaly marking signals manually initiated by users through the graph interface, directly identifying the user-marked nodes as anomaly nodes. Furthermore, it parses the anomaly type in the anomaly trigger signals and adds type labels (such as missing data, calculation error) to the anomaly nodes.

[0108] Step S72: Highlight the upstream and downstream full-link related nodes of the abnormal node to obtain the abnormal relationship link where the abnormal node is located.

[0109] It should be noted that upstream end-to-end related nodes refer to all related nodes in the data source direction of the abnormal node in the lineage chain (such as upstream file distribution nodes, data models, and data source nodes of the abnormal message node). Downstream end-to-end related nodes refer to all related nodes in the data flow direction of the abnormal node in the lineage chain (such as downstream meta-factors, summary factors, and business factor nodes of the abnormal message node). Highlighting refers to using special visual presentation methods (such as highlight colors, flashing effects, and bold borders) to identify related nodes, which is achieved by adjusting the node display attributes. The abnormal relationship chain refers to the complete chain including the abnormal node, upstream related nodes, and downstream related nodes. Its purpose is to intuitively present the scope of the abnormality's impact, providing visual support for users to quickly troubleshoot problems.

[0110] Specifically, different colors are used to distinguish and highlight node types, such as red for abnormal nodes, orange for upstream nodes, and yellow for downstream nodes, to visually differentiate the impact levels. The connections between nodes are also highlighted to clearly show the anomaly propagation path. An anomaly link details pop-up window is provided, displaying information such as the anomaly type, the number of associated nodes, and the impact path of the abnormal node.

[0111] This embodiment, through the above-described scheme, adds anomaly handling and visualization interaction functions by following the steps of "receiving anomaly trigger signals to identify abnormal nodes → highlighting upstream and downstream related nodes to obtain the abnormal relationship chain." This solves the core pain points of unclear impact range of abnormal nodes and difficulty in troubleshooting in existing technologies, enabling rapid location of abnormal nodes and intuitive presentation of their impact range. It significantly improves the efficiency of anomaly handling, reduces risk handling costs, enriches the interactive functions of the lineage graph, and enhances the practicality and implementation value of the technical solution.

[0112] For example, to help understand the implementation process of the visualization method for the lineage relationship of risk control factors obtained by combining this embodiment with the above embodiment one, please refer to... Figure 3 , Figure 3 A simplified flowchart illustrating a method for visualizing the lineage of risk control factors is provided, specifically: Figure 3Starting with the target business factor, the system first obtains the aggregated factor bound to its configuration. Then, it parses the calculation logic definition text of the aggregated factor, extracting key data processing function identifiers, meta-factor identifiers, and factor parameters. Based on the extracted meta-factor identifiers, the system further determines the target message it depends on and traces upstream step by step, sequentially locating associated distributed files, data models, and finally the data source. The entire process clearly demonstrates the reverse tracing process from top-level business applications to bottom-level raw data, emphasizing that during the tracing process, through the parsing of calculation logic and the matching of preset mapping relationships, it achieves the accurate restoration and construction of fine-grained lineage relationships from macro factors to micro fields. This flowchart intuitively summarizes the core steps and data flow logic of this application to achieve full-link, traceable risk control factor lineage display.

[0113] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the visualization method of the risk control factor lineage in this application. Any simple transformations based on this technical concept are within the protection scope of this application.

[0114] This application also provides a visualization device for the kinship of risk control factors, please refer to... Figure 4 The visualization device for the kinship of risk control factors includes: The node tracing module 401 is used to respond to a lineage tracing request for a target business factor, and to perform reverse tracing starting from the target business factor to trace back to the data source node of the target business factor. The link generation module 402 is used to construct the lineage relationship link of the target business factor based on the target business factor, the data source node, and the tracing path of reverse tracing. The graph generation module 403 is used to generate a kinship graph of the target business factor based on the kinship link.

[0115] The visualization device for the lineage of risk control factors provided in this application employs the visualization method for the lineage of risk control factors in the above embodiments, which can solve the technical problem of difficulty in tracing the lineage of risk control factors. Compared with the prior art, the beneficial effects of the visualization device for the lineage of risk control factors provided in this application are the same as the beneficial effects of the visualization method for the lineage of risk control factors provided in the above embodiments, and other technical features in the visualization device for the lineage of risk control factors are the same as the features disclosed in the methods of the above embodiments, and will not be repeated here.

[0116] This application provides a visualization device for the lineage of risk control factors. The visualization device for the lineage of risk control factors includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the visualization method for the lineage of risk control factors in the first embodiment described above.

[0117] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a visualization device suitable for implementing the risk control factor lineage relationship in the embodiments of this application. The visualization device for the risk control factor lineage relationship in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The visualization device for the kinship of risk control factors shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0118] like Figure 5As shown, the visualization device for risk control factor lineage relationships may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the visualization device for risk control factor lineage relationships. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the visualization device for risk factor lineage to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows visualization devices for risk factor lineage with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0119] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0120] The visualization device for the lineage of risk control factors provided in this application, employing the visualization method for the lineage of risk control factors in the above embodiments, can solve the technical problem of difficulty in tracing the lineage of risk control factors. Compared with the prior art, the beneficial effects of the visualization device for the lineage of risk control factors provided in this application are the same as the beneficial effects of the visualization method for the lineage of risk control factors provided in the above embodiments, and other technical features in the visualization device for the lineage of risk control factors are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0121] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0122] 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.

[0123] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the risk control factor lineage tracing method in the above embodiments.

[0124] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0125] The aforementioned computer-readable storage medium may be included in a visualization device for the lineage of risk control factors; or it may exist independently and not be assembled into a visualization device for the lineage of risk control factors.

[0126] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a risk control factor lineage visualization device, the risk control factor lineage visualization device: responds to a lineage tracing request for a target business factor, performs reverse tracing starting from the target business factor, tracing back to the data source node of the target business factor; constructs a lineage relationship link for the target business factor based on the target business factor, the data source node, and the reverse tracing path; and generates a lineage relationship graph for the target business factor based on the lineage relationship link.

[0127] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0128] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0129] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0130] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described visualization method for the lineage of risk control factors, thereby solving the technical problem of difficulty in tracing the lineage of risk control factors. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the visualization method for the lineage of risk control factors provided in the above embodiments, and will not be repeated here.

[0131] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method for visualizing the kinship of risk control factors.

[0132] The computer program product provided in this application can solve the technical problem of difficulty in tracing the lineage of risk control factors. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the visualization method for the lineage of risk control factors provided in the above embodiments, and will not be repeated here.

[0133] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for visualizing the kinship of risk factors, characterized in that, The visualization methods for the lineage of risk control factors include: In response to a lineage tracing request for a target business factor, reverse tracing is performed starting from the target business factor and tracing back to the data source node of the target business factor. The reverse tracing refers to the tracing method of deriving from the target business factor back to the data source node. Based on the target business factor, the data source node, and the tracing path of reverse tracing, a lineage relationship link of the target business factor is constructed, wherein the tracing path refers to the node association sequence formed during the reverse tracing process; Based on the aforementioned bloodline relationship links, a bloodline relationship map of the target business factor is generated; The step of responding to a lineage tracing request for a target business factor and performing reverse tracing from the target business factor as the starting node to the data source node of the target business factor includes: Based on the factor identification information of the target business factor, obtain the summary factor and calculation dimension configured and bound to the target business factor. The summary factor consists of the calculation dimension, monitoring scope, factor parameters and calculation formula. The calculation dimension is the grouping basis when calculating the target business factor and is an inherent attribute of the target business factor. The calculation logic of the summary factor is analyzed to determine the meta-factors corresponding to the summary factor and the calculation dimension. The meta-factor is a combination or arithmetic operation of several fields of a single message and is the smallest data granule processed by the summary factor. Based on the preset mapping relationship between the meta-factor and the target message, the target message on which the meta-factor depends is determined; The target message is traced and located until the data source node corresponding to the target message is determined. The step of parsing the calculation logic of the summary factor and determining the meta-factors corresponding to the summary factor and the calculation dimension includes: Obtain the calculation logic definition text and factor parameters of the summary factor; Perform syntax parsing on the computational logic definition text to extract the data processing function identifiers and meta-factor identifiers referenced in the computational logic definition text; Based on the data processing function identifier, the meta-factor identifier, the factor parameters, and the calculation dimension, the meta-factor associated with the summary factor is determined by querying. The step of determining the target message on which the meta-factor depends based on the preset mapping relationship between the meta-factor and the target message includes: Query the preset mapping relationship between the meta-factor and the candidate message to obtain the set of candidate messages associated with the meta-factor; The calculation logic of the aggregation factor is analyzed, and the message reference range defined by the meta-factor is determined based on the calculation logic; Based on the message reference range, the candidate message set is filtered to determine the target message that matches the message reference range; The step of tracing and locating based on the target message until the data source node corresponding to the target message is determined includes: Query the distribution file identifier associated with the target message, and determine the corresponding distribution file node based on the distribution file identifier; Based on the generation relationship between the distributed file node and the data model, the data model node corresponding to the distributed file node is traced back; Based on the mapping relationship between the data model nodes and the data source, the data source node corresponding to the data model node can be traced back.

2. The method of claim 1, wherein the blood relationship of the risk control factor is visualized. The step of constructing the lineage relationship link of the target business factor based on the target business factor, the data source node, and the reverse tracing path includes: Based on the target business factors, the data source nodes, and the reverse tracing path, determine the dependency type and association direction of the nodes in the tracing path; Based on the dependency type and the association direction, an initial relationship link for the target business factor is generated; The initial relationship links are detected and associated to construct the lineage relationship links of the target business factors.

3. The visualization method for the kinship of risk control factors as described in claim 1, characterized in that, The method further includes: Receive node abnormality trigger signal, and identify the corresponding abnormal node from the kinship map based on the node abnormality trigger signal; The upstream and downstream full-link related nodes of the abnormal node are highlighted to obtain the abnormal relationship link where the abnormal node is located.

4. A visualization device for the kinship of risk control factors, characterized in that, The visualization device for the kinship of risk control factors includes: The node tracing module is used to respond to a lineage tracing request for a target business factor, and to perform reverse tracing starting from the target business factor and tracing back to the data source node of the target business factor. The reverse tracing refers to the tracing method of deriving from the target business factor back to the data source node. The link generation module is used to construct the lineage relationship link of the target business factor based on the target business factor, the data source node, and the tracing path of reverse tracing, wherein the tracing path refers to the node association sequence formed during the reverse tracing process; The genealogy generation module is used to generate a genealogy graph of the target business factor based on the genealogy link. The step of responding to a lineage tracing request for a target business factor, and performing reverse tracing starting from the target business factor to trace back to the data source node of the target business factor, includes: Based on the factor identification information of the target business factor, obtain the summary factor and calculation dimension configured and bound to the target business factor. The summary factor consists of the calculation dimension, monitoring scope, factor parameters and calculation formula. The calculation dimension is the grouping basis when calculating the target business factor and is an inherent attribute of the target business factor. The calculation logic of the summary factor is analyzed to determine the meta-factors corresponding to the summary factor and the calculation dimension. The meta-factor is a combination or arithmetic operation of several fields of a single message and is the smallest data granule processed by the summary factor. Based on the preset mapping relationship between the meta-factor and the target message, the target message on which the meta-factor depends is determined; The target message is traced and located until the data source node corresponding to the target message is determined. The step of parsing the calculation logic of the summary factor to determine the meta-factors corresponding to the summary factor and the calculation dimension includes: Obtain the calculation logic definition text and factor parameters of the summary factor; Perform syntax parsing on the computational logic definition text to extract the data processing function identifiers and meta-factor identifiers referenced in the computational logic definition text; Based on the data processing function identifier, the meta-factor identifier, the factor parameters, and the calculation dimension, the meta-factor associated with the summary factor is determined by querying. The step of determining the target message on which the meta-factor depends based on a preset mapping relationship between the meta-factor and the target message includes: Query the preset mapping relationship between the meta-factor and the candidate message to obtain the set of candidate messages associated with the meta-factor; The calculation logic of the aggregation factor is analyzed, and the message reference range defined by the meta-factor is determined based on the calculation logic; Based on the message reference range, the candidate message set is filtered to determine the target message that matches the message reference range; The step of tracing and locating based on the target message until the data source node corresponding to the target message is determined includes: Query the distribution file identifier associated with the target message, and determine the corresponding distribution file node based on the distribution file identifier; Based on the generation relationship between the distributed file node and the data model, the data model node corresponding to the distributed file node is traced back; Based on the mapping relationship between the data model nodes and the data source, the data source node corresponding to the data model node can be traced back.

5. A visualization device for the kinship of risk control factors, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the method for visualizing the kinship of risk control factors as described in any one of claims 1 to 3.

6. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the method for visualizing the kinship of risk control factors as described in any one of claims 1 to 3.

Images