A large-scale association relationship real-time analysis method based on incremental graph computation

Abstract

The present application relates to the technical field of data analysis, and more particularly to a large-scale correlation real-time analysis method based on incremental graph calculation, comprising: obtaining correlation data of accounts, personnel and transaction entities and modeling as attribute graph data; dividing nodes into hub type and regular type according to node attributes, obtaining partition attribution information and recording version changes; obtaining incremental events, determining processing partitions according to partition attribution information or partition strategies; determining initial affected nodes according to incremental events and expanding to obtain affected subgraphs, adopting candidate rollback strategy to determine alternative candidate sources for deletion events and performing migration verification; updating affected nodes and correlations, performing local iterative calculation in the affected subgraphs to obtain updated attribute graph data; and adopting distributed graph analysis strategy to analyze correlations in parallel. The present application avoids re-computing the entire attribute graph when incremental data arrives, and takes into account real-time performance and computing resource consumption.

Description

Technical Field

[0001] This invention relates to the field of data analysis technology, and in particular to a method for real-time analysis of large-scale relationships based on incremental graph computation. Background Technology

[0002] In large-scale attribute graph scenarios composed of account, personnel, and transaction relationships, it is necessary to support analysis requirements such as multi-hop association queries, shortest path tracing, and community clustering. Moreover, the graph data is in a state of continuous incremental writing, including positive events such as new accounts, new transactions, and new personnel associations, as well as deletion events such as transaction revocation, account cancellation, and termination of guarantee relationships. Therefore, an incremental graph computing method is required to recalculate only the affected scope after data changes, and to reasonably distribute the newly added and changed data to each partition computing node to support subsequent distributed parallel computing.

[0003] In real-world business scenarios, the associated data between accounts, individuals, and transactions often arrives in large batches with high concurrency within a short time window, and the connection density varies significantly across different nodes. A few accounts or individuals may become associated with a large number of other entities in a short period, while most nodes are only involved in a few associations. At the same time, deletion events such as transaction cancellations and relationship terminations can render calculations based on previous evidence of a particular association unreliable. This high concurrency of data arrival, uneven node connection density, and the invalidation of evidence due to relationship changes are common challenges faced by large-scale attribute graphs in incremental computation.

[0004] Patent publication number CN115658978A discloses a method for importing multi-source data into a graph database system. This method reads and transforms heterogeneous multi-source data according to a preset configuration file, then partitions the transformed data according to the preset number of partitions in the configuration file. During the writing process, it uses a round-robin strategy to route available graph database services and a random strategy to distribute write requests to different service nodes, thereby balancing the connection and write load of each service node. However, the number of partitions disclosed in this technical solution is a pre-configured fixed value, and the distribution of write requests is determined by round-robin and random strategies. When continuous data writing leads to a continuous increase in the graph size and increasingly dense and uneven connections between different nodes, the fixed number of partitions and the routing method unrelated to connection relationships can easily cause some partitions to accumulate a large amount of densely related data, resulting in a gradual imbalance in the load of each partition over time. Summary of the Invention

[0005] In view of this, the present invention provides a real-time analysis method for large-scale association relationships based on incremental graph computation, in order to solve the problems in the prior art that lack a partition load balancing mechanism for high concurrency arrival of incremental data and uneven node connection density, and that the state rollback after edge deletion lacks a means to verify the validity of cross-partition evidence.

[0006] The technical solution of this invention is implemented as follows:

[0007] This invention provides a method for real-time analysis of large-scale relationships based on incremental graph computation, comprising the following steps:

[0008] S1. Obtain the relationship data between accounts, personnel and transaction entities, unify the entities and deduplicate the relationships in the relationship data, and model it as attribute graph data. The attribute graph data includes nodes, node attributes, relationships and relationship attributes.

[0009] S2. Based on node attributes, divide the nodes in the attribute graph data into nodes belonging to the hub channel and nodes belonging to the regular channel. Different partitioning strategies are used for nodes belonging to the hub channel and nodes belonging to the regular channel to determine their respective target partitions, obtain the partitioning information of nodes and their relationships, and record the version changes of the partitioning information. Among them, the partitioning strategy for regular type nodes is combined with the node degree and the conflict relationship between nodes in the batch for load balancing.

[0010] S3. Obtain incremental events of addition, attribute change and deletion for attribute graph data. For incremental events with existing partition ownership information, determine the processing partition according to the corresponding partition ownership information. For new nodes or associations, determine the processing partition using the partitioning strategy to obtain incremental events with processing partition identifiers.

[0011] S4. Determine the initial affected nodes based on incremental events, and use the affected scope definition strategy to calculate the state and expand the scope of the initial affected nodes to obtain the affected subgraph; for the deletion type incremental events, use the candidate rollback strategy to determine the alternative candidate source, and use the version change of the partition ownership information to migrate and verify the candidate source across partitions to obtain the update status and candidate source record of each node in the affected subgraph.

[0012] S5. Based on the affected subgraph, the state to be updated, and the candidate source record, update the affected nodes and relationships in the attribute graph data, and use message passing to perform local iterative calculations in the affected subgraph to obtain the updated attribute graph data.

[0013] S6. Based on the updated attribute graph data, a distributed graph analysis strategy is used to perform parallel analysis of the relationships between accounts, personnel and transaction entities to obtain the relationship analysis results.

[0014] Based on the above technical solutions, preferably, step S2 specifically includes:

[0015] S21. Determine whether a node belongs to a regular channel or a hub channel based on the node attributes, and maintain a degree counter for regular channel nodes and a load counter for each partition.

[0016] S22. For the edges in the regular channel, determine the candidate partition set based on the conflict group affiliation relationship dynamically maintained within the batch, and score the candidate partitions based on the node's adaptability and load balancing degree, and assign the edges to the candidate partitions with the highest scores to obtain the partition affiliation information of the regular channel.

[0017] S23. Update the load counter of the corresponding partition according to the partition ownership information of the conventional channel, and re-score the allocated edges according to the evolution of node degree. If there is a partition in the candidate partition set with a higher score than the original allocated partition, migrate the edge to the candidate partition with the highest score, and update the corresponding partition ownership information and its version record.

[0018] S24. For nodes in the hub channel, determine the primary partition based on the distribution of their neighbors in each partition of the regular channel, and establish read-only copies in the partitions that have associated edges with the node to obtain the partition ownership information of the hub channel.

[0019] Based on the above technical solution, preferably, in step S22, the candidate partition set is determined according to the local footprints of the two endpoints of the edges that have generated associated edges in each partition, and a partition in which at least one of the two endpoints has generated an associated edge is selected as a candidate partition; edges within the same conflict group are scored in the order of arrival number within the batch, different conflict groups are processed in parallel, and conflict groups are merged into merged conflict groups due to newly arrived edges generating associations during the processing. After merging, the load balancing state accumulated by each conflict group before merging is used to continue processing the unprocessed edges within the group; the candidate partition set... Each partition in , targeting the edge By scoring function:

[0020] ;

[0021] Scoring was conducted, among which For node pair partitioning Locality of fit For partitioning The load counter, To handle the conflict within the group to the border Previously accumulated placeholder load, For load balancing weighting coefficients, The target load balancing is determined based on the load of each partition at the start time of the batch and the total number of edges in this batch.

[0022] Based on the above technical solution, preferably, in step S23, the edges of the allocated partitions are... The rate of change of degree is calculated based on the degree values ​​of the two endpoints recorded at the partition allocation time and the degree values ​​of the two endpoints at the current time. In the rate of change of degree Exceeding the preset threshold At that time, the edges are adjusted according to the current load counter of each partition. Re-scoring, where there exists a score higher than the edge. When partitioning the original allocated partition, the edges will be... Migrate to the partition with the highest score and update the edges. Version records of the degree of the two endpoints and the corresponding partition ownership information.

[0023] Based on the above technical solutions, preferably, in step S24, the primary partition of a node is the partition with the highest coverage ratio of the node's neighbors among the partitions of the regular channel. The node's attributes and status values ​​are uniformly maintained by the primary partition, and the read-only copies established on the other partitions are only for local reading. After the primary partition completes the status update, it synchronizes the latest status value to the partition where the read-only copy is located. For nodes in the regular channel and the hub channel, it is determined whether the node meets the preset channel migration conditions based on the evolution of the node degree or the distribution of its neighbors. When the preset channel migration conditions are met, the nodes that meet the conditions are migrated between the regular channel and the hub channel, and the partition ownership information and version records corresponding to the migrated nodes are updated synchronously.

[0024] Based on the above technical solutions, preferably, in step S1, the associated relationship data includes the transfer relationship between accounts, the holding or operation relationship between personnel and accounts, and the participation relationship between personnel and transactions; the entity unification refers to merging records from different sources but pointing to the same entity based on a unified entity identifier; in the modeled attribute graph data, nodes record the type identifier and business attributes of accounts, personnel or transactions, and the associated relationship records the corresponding direction and occurrence time, wherein the transfer relationship and participation relationship also record the transaction amount, and the corresponding relationship between the node and its associated relationship is stored using an adjacency structure.

[0025] Based on the above technical solutions, preferably, step S4 specifically includes:

[0026] S41. Divide the aggregation method of node status values ​​into monotonically additive and non-monotonic elimination categories. For monotonically additive nodes, maintain a record of all candidate sources of contribution. For non-monotonic elimination nodes, maintain a two-level candidate source record of the current candidate source and the backup candidate source.

[0027] S42. Based on the incremental event type corresponding to the initially affected node, the scope is expanded. For nodes activated by new or attribute change type incremental events, the corresponding neighbor node is included in the affected subgraph and expanded further based on whether the aggregated state value has changed compared with the state value recorded before activation. For nodes activated by deletion type incremental events, the state value is recalculated based on the update result of the candidate source record, and then the expansion is determined based on whether the recalculated state value has changed compared with the state value recorded before activation.

[0028] S43. For nodes involved in deletion-type incremental events, verify whether the deleted association constitutes a valid candidate source based on its candidate source record. If it constitutes a valid candidate source, remove the monotonically additive node from the candidate source record and re-aggregate it according to the remaining candidate sources. For non-monotonic elimination nodes, promote the backup candidate source to the current candidate source. After the promotion or removal is completed, perform migration verification on the partition ownership in the updated candidate source record according to the version change of the partition ownership information, and determine the recalculated state value based on the verification result.

[0029] Based on the above technical solutions, preferably, in step S41, the candidate source records maintained for monotonically additive nodes are a set of quadruples, with each element recording contributing neighbors, the association relationship of the connection, the neighbor's state value, and the partition where the neighbor is located; the candidate source records maintained for non-monotonic elimination nodes are candidate chains of length 2, with the current candidate source record in the candidate chain being the contributing source that plays a decisive role in the node's state value, and the backup candidate source record being the second source in the candidate sequence.

[0030] Based on the above technical solution, preferably, in step S43, for monotonically additive nodes, the existence of the quadruple corresponding to the deleted association is verified in the candidate source record. If it exists, it is removed, and the remaining quadruples are re-aggregated.

[0031] ;

[0032] in, For nodes that undergo state re-aggregation. For nodes The re-aggregated state value, for The remaining contributing neighbors, For the neighbors With nodes The relationship between them For the neighbors The status value to be updated for The corresponding partition version, For nodes The set of candidate source records, For association Carrying business attributes, It is a combinatorial function. It is an aggregation operator.

[0033] For nodes that are not subject to monotonic elimination, after promoting a backup candidate source to a new current candidate source, the partition ownership version of the promoted current candidate source record is first compared with the corresponding version recorded in the partition ownership information. If the versions are inconsistent, the partition ownership of the promoted current candidate source record is corrected according to the partition ownership information. If the partition where the promoted current candidate source is located is different from the partition where the node is located after correction, a verification message is sent to the partition where the promoted current candidate source is located, and the recalculated state value is determined based on the returned actual state value. If both the promoted current candidate source and the backup candidate source are empty, all neighbors of the node are rescanned, the node state value is recalculated, and the candidate source record is reconstructed.

[0034] Based on the above technical solutions, preferably, in step S6, the state values ​​of the nodes in the graph are maintained, with the value range determined by the type of analysis being performed, and are updated according to the combined results of neighbor contributions; the distributed graph analysis strategy includes:

[0035] Multi-hop association query takes the state value domain as a binary set, the combination method is the neighbor state value itself, and the aggregation method is a logical OR operation, which is used to determine whether there is a reachable path between nodes;

[0036] The shortest path calculation takes the state value range as the union of non-negative real numbers and infinity, the combination method is the sum of the neighbor state values ​​and the edge attributes, and the aggregation method is the minimum value operation.

[0037] Community tags are defined by taking the state value domain as the community tag set, combining them by reading the current tags of neighbors, and aggregating them by taking the tags that appear most frequently among the neighbors.

[0038] The present invention has the following advantages over the prior art:

[0039] This invention avoids recalculating the entire attribute graph when incremental data arrives by defining the affected subgraph and updating iteratively through incremental event-driven methods. This enables the analysis of large-scale account, personnel, and transaction relationships to be updated in a timely manner as the data changes, balancing real-time performance with computational resource consumption.

[0040] This invention avoids load contention between high-connectivity nodes and ordinary nodes under the same set of partitioning rules by pre-splitting the node type and scoring the regular channel edges using batch conflict groups, and by processing the hub channel nodes separately using a primary partition plus read-only replica method. This improves the partition load balancing in incremental write scenarios.

[0041] This invention distinguishes between monotonically additive and non-monotonic elimination aggregation methods and maintains corresponding candidate source records for each. This allows the replacement candidate source to be directly located based on the records when an association deletion event occurs, without needing to retain all historical evidence or rescan neighbors to complete the state rollback. Attached Figure Description

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

[0043] Figure 1 This is a flowchart of the real-time analysis method for large-scale correlations of the present invention;

[0044] Figure 2 This is a flowchart of the node partitioning strategy of the present invention;

[0045] Figure 3 This is a flowchart illustrating the affected subgraph definition and candidate rollback process of the present invention. Detailed Implementation

[0046] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0047] like Figure 1 As shown, this invention provides a real-time analysis method for large-scale association relationships based on incremental graph computation, comprising the following steps:

[0048] S1. Obtain the relationship data between accounts, personnel and transaction entities, unify the entities and deduplicate the relationships in the relationship data, and model it as attribute graph data. The attribute graph data includes nodes, node attributes, relationships and relationship attributes.

[0049] S2. Based on node attributes, divide the nodes in the attribute graph data into nodes belonging to the hub channel and nodes belonging to the regular channel. Different partitioning strategies are used for nodes belonging to the hub channel and nodes belonging to the regular channel to determine their respective target partitions, obtain the partitioning information of nodes and their relationships, and record the version changes of the partitioning information. Among them, the partitioning strategy for regular type nodes is combined with the node degree and the conflict relationship between nodes in the batch for load balancing.

[0050] S3. Obtain incremental events of addition, attribute change and deletion for attribute graph data. For incremental events with existing partition ownership information, determine the processing partition according to the corresponding partition ownership information. For new nodes or associations, determine the processing partition using the partitioning strategy to obtain incremental events with processing partition identifiers.

[0051] S4. Determine the initial affected nodes based on incremental events, and use the affected scope definition strategy to calculate the state and expand the scope of the initial affected nodes to obtain the affected subgraph; for the deletion type incremental events, use the candidate rollback strategy to determine the alternative candidate source, and use the version change of the partition ownership information to migrate and verify the candidate source across partitions to obtain the update status and candidate source record of each node in the affected subgraph.

[0052] S5. Based on the affected subgraph, the state to be updated, and the candidate source record, update the affected nodes and relationships in the attribute graph data, and use message passing to perform local iterative calculations in the affected subgraph to obtain the updated attribute graph data.

[0053] S6. Based on the updated attribute graph data, a distributed graph analysis strategy is used to perform parallel analysis of the relationships between accounts, personnel and transaction entities to obtain the relationship analysis results.

[0054] In one embodiment of the present invention, step S1 includes: connecting to structured data sources such as account information database, personnel information database, and transaction record database through the data access layer, reading the original records using database change capture or batch extraction interfaces, and converting them into a unified attribute graph data model according to preset field mapping rules.

[0055] Specifically, the transfer relationships between accounts, the holding or operational relationships between personnel and accounts, and the participation relationships between personnel and transactions are parsed as graph relationships. Account, personnel, and transaction entity records are parsed as graph nodes, and each node is assigned a unique node identifier and a set of node attributes. Node attributes include fields such as account type, registration time, and personnel identity identifier. The account type field serves as the node type identifier, with values ​​including personal accounts, merchant accounts, clearing accounts, and gateway accounts. This field is determined during the account opening and qualification review process and is integrated along with the node record, eliminating the need for subsequent runtime statistics. Relationships are assigned a set of relationship attributes, including fields such as direction and occurrence time. Transfer relationships and participation relationships also record transaction amounts. Records of the same entity appearing repeatedly in different data sources are merged based on the entity's primary key or a unique entity identifier generated according to preset rules, i.e., unified entity processing to avoid redundant nodes for the same entity in the graph. Records of the same relationship repeatedly collected from different data sources are deduplicated to avoid duplicate relationships in the graph. The attribute graph data after modeling is completed is stored in an adjacency structure. The node table stores the node identifier, node attributes, and node type identifier, while the association table stores the identifiers of the two endpoints of the association and the association attributes. This adjacency structure supports quickly locating all the associations associated with a node based on its identifier.

[0056] In one embodiment of the present invention, such as Figure 2 As shown, step S2 specifically includes the following steps:

[0057] S21. Determine whether a node belongs to a regular channel or a hub channel based on the node attributes, and maintain a degree counter for regular channel nodes and a load counter for each partition.

[0058] A pre-defined set of hub types is established, including merchant accounts, clearing accounts, gateway accounts, and other account types explicitly designated for high-concurrency transactions. When a node joins the graph, its node type identifier determines whether it belongs to the hub type set. If it does, it is assigned to a hub channel; otherwise, it is assigned to a regular channel. This determination is completed before the node participates in any partition scoring, and the result serves as the routing label that travels with the node. For each node in the regular channel... Maintain a real-time updated degree counter Whenever the side When the partition ownership is determined, update synchronously. , Assume the cluster has a total of There are partitions, and the set of partitions is denoted as . For each partition Maintain the real load counter This indicates the number of edges that have been written to disk for the current partition. This counter is only updated after batch processing is completed and the data is written to disk. During batch processing, this real load counter is not read or written directly to avoid frequent cross-thread synchronization overhead.

[0059] S22. For edges in the regular channel, determine the candidate partition set based on the conflict group affiliation relationship dynamically maintained within the batch, and score the candidate partitions based on the node's adaptability and load balancing degree, and assign the edge to the candidate partition with the highest score to obtain the partition affiliation information of the regular channel.

[0060] Edges continuously written to the attribute graph are organized into batches according to a preset fixed time window or fixed number of rows window. When a batch is formed, each edge within the batch is assigned a fixed arrival sequence number. For each edge within the batch (Both endpoints belong to the regular channel), before participating in the scoring, a candidate partition set is determined: based on the local footprints of the two endpoints of the edge in each partition, at least one partition in which an associated edge has been generated is selected as a candidate partition, denoted as . If edges within a batch have data competition due to overlapping endpoints, they are grouped into the same conflict group. Edges within the conflict group are scored and partitioned strictly sequentially according to their arrival sequence number within the batch. Different conflict groups are processed in parallel by different worker threads. If a conflict group is merged into a larger conflict group during batch processing due to later-arriving edges becoming associated with other groups, the merged group retains one of its original shared counting structures and incorporates the accumulated placeholder load values ​​from the other group into that structure. This merging operation is completed at the same moment the merge decision occurs. Afterward, the placeholder updates of the merged group are uniformly read and written to the merged structure. Edges processed before the merge are not recalculated due to the merge. Thus, the sequential constraint is limited to the subset of edges where load competition truly exists and this competition is dynamically confirmed with the decision execution. Completely parallel processing is achieved between edge subsets in the candidate partition sets that never overlap within the batch. (Regarding the candidate partition set...) Each partition in The score is calculated using the following scoring function:

[0061] ;

[0062] in ( ) represents the locality of fitness of a node. Represents a node Currently assigned to a partition The number of associated edges, For nodes The current value of the degree counter, Let t be the edge reached by. , For the edge The two endpoints of the node, this definition makes the node In partition The more associated edges that have been gathered in the middle, the better. The higher the value, the more the scoring function can guide the clustering of node-related edges in the same partition and reduce cross-partition communication. For candidate partition set The i-th partition in For partitioning The actual load counter; For the conflict group to which this edge belongs, the conflict is handled to the edge. Previously accumulated placeholder load; This is the load balancing weighting coefficient, used to adjust the relative weights of locality fit and load balancing degree in the scoring; The target load balancing is determined by dividing the sum of the loads of each partition at the start of the batch by the sum of the total number of edges in this batch, and then dividing by the total number of partitions. The edges... Assign the edge to the partition with the highest score in the candidate partition set, and obtain the partition affiliation information for that edge. Complete. After making the partitioning decision, immediately update the placeholder load within its corresponding conflict group:

[0063] ;

[0064] in For the edge The final partition is assigned, where t is the batch arrival sequence number of the edges within the conflict group.

[0065] The initial values ​​within a conflict group are taken from the zero values ​​at the start of the batch. Within the same conflict group, before a worker thread scores the t-th edge, it must confirm that all edges with indices less than t in that group have completed their placeholder updates. Subsequent reads... Only then are they included in the scoring calculation; different conflict groups do not share any placeholder load storage units, and their scoring and update processes are independent of each other, requiring no waiting or synchronization. After all conflict groups within a batch have been processed, the accumulated placeholder increments of each conflict group are merged into the actual load counter, that is, all i are executed. , This is the final cumulative value when the conflict group is processed. Then, the node, edge data and partition ownership of this batch are written into the distributed graph storage structure, and the placeholder load of each conflict group is reset to zero for use by the next batch.

[0066] S23. Update the load counter of the corresponding partition according to the partition ownership information of the regular channel, and re-score the allocated edges according to the evolution of node degree. If there is a partition in the candidate partition set with a higher score than the original allocated partition, migrate the edge to the candidate partition with the highest score, and update the corresponding partition ownership information and its version record.

[0067] Historical edges of allocated partitions Record the degrees of the two endpoints at the time of assignment. , As incremental writes continue, the rate of change in degree is calculated periodically:

[0068] ;

[0069] when Exceeding the preset correction trigger threshold When the degree state of the two endpoints of an edge has significantly evolved compared to the allocation time, the score of the edge relative to all k partitions is recalculated based on the current actual load counter (excluding placeholder load, as this correction occurs between batches rather than within batches). The candidate set includes all partitions, without being limited by the intra-batch footprint. If there is a partition with a score significantly higher than the originally allocated partition, the edge is migrated to the partition with the highest score, and the degree of its two endpoints is updated to the current degree value; otherwise, the original allocation remains unchanged. If any endpoint of the edge is recorded as a candidate source, its migration operation must synchronously update the version number of that endpoint in the partition ownership version table.

[0070] S24. For nodes in the hub channel, determine the primary partition based on the distribution of their neighbors in each partition of the regular channel, and establish read-only copies in the partitions that have associated edges with the node to obtain the partition ownership information of the hub channel.

[0071] In this system, the primary partition of a node is the partition with the highest coverage ratio of the node's neighbors among the partitions of the regular channel. The node's attributes and status values ​​are maintained uniformly by the primary partition. The read-only copies established on the other partitions are only for local reading. After the primary partition completes the status update, it synchronizes the latest status value to the partition where the read-only copy is located. For nodes in the regular channel and the hub channel, it is determined whether the node meets the preset channel migration conditions based on the evolution of the node degree or the distribution of its neighbors. When the preset channel migration conditions are met, the nodes that meet the conditions are migrated between the regular channel and the hub channel, and the partition ownership information and version records corresponding to the migrated nodes are updated synchronously.

[0072] Specifically, nodes belonging to the hub channel In a certain partition of its regular channel When the first associated edge is formed between them, it is a node in that partition. Create a read-only copy, and denote the set of host partitions of this copy as . The copy content is nodes. The current state value is a mirror image of the attribute. Let... For nodes The set of neighbors, nodes Relative candidate host partition Neighbor coverage is defined as:

[0073] ;

[0074] Designate the partition with the highest neighbor coverage as the node. The primary partition, i.e. .node The attributes and status values ​​are maintained and updated uniformly by the primary partition, involving nodes. The edges can be read locally on the partition where the read-only replica resides, without cross-partition communication; after each round of updates, the primary partition broadcasts its latest state value to all partitions in the host partition set except the primary partition through the replica synchronization channel, and each partition updates its local read-only replica accordingly. Let... For the current time node The number of sides, for Previous nodes of each batch The number of edges, defining the edge growth rate. Every Each batch is verified once: if the nodes in the regular channel satisfy Migrate it to the hub channel, create a read-only copy for it according to the above rules, and revoke its historical partition affiliation in the regular channel; if the node in the hub channel satisfy Its read-only copy is revoked and re-incorporated into the regular channel partition according to the rules described in S21 to S23, whereby... , Based on the preset migration trigger threshold, this migration process is executed only once in batches at the end of each observation window, without affecting the normal partitioning and calculation process during the observation period. If a node is recorded as a candidate source, its channel switching must synchronously update the partition ownership version table, with the triggering method consistent with historical edge migration under degree evolution. In addition, a global partition ownership version table is maintained, indexed by node identifier, recording the current partition ownership and corresponding version number of each node; whenever a node experiences a partition ownership change due to historical edge migration or channel migration, within the same batch of migration operations, the corresponding version number in the version table is incremented once and written to the new partition ownership. This action is completed in the same batch as a necessary component of the migration operation and is not an independent fault tolerance module for candidate source migration verification.

[0075] In this invention, a node type-based pre-processing method separates the minority of hub-type nodes with extremely high connection density from the majority of regular-type nodes, avoiding competition between them under the same scoring mechanism. For regular channel edges, a serial decision-making and placeholder load mechanism for intra-batch conflict groups is introduced, enabling edges arriving at high concurrency to perceive allocation decisions already made within the same batch without waiting for all historical load states to be updated, thus balancing decision accuracy and intra-batch processing efficiency. For hub-type nodes, a point replication method using primary partitions and read-only replicas is adopted to prevent local overheating due to edge-segmented scoring. Simultaneously, a dynamic migration mechanism between channels and a global partition ownership version table enable the partitioning strategy to adapt to changes in node connection characteristics over time, providing a basis for cross-partition data verification in subsequent steps.

[0076] In one embodiment of the present invention, step S3 includes: accessing newly generated or changed entity-related data in real time through a streaming data processing framework, with event types including adding nodes, adding relationships, changing attributes, and deleting.

[0077] Specifically, continuously accessing incremental events reuse the batch arrival sequence number organization method established in S2, dividing batches according to the same fixed time window or fixed number of entries window to ensure that batch boundaries remain consistent in the partitioning decision and subsequent affected scope definition stages. For newly added incremental events within a batch, their processing partitions are determined according to the partitioning strategy described in S2: if it is a newly added relationship and both endpoints belong to the regular channel, the processing partition is determined according to the candidate partition determination, conflict group scoring, and degree evolution migration rules described in S22 to S23; if the endpoints of the relationship belong to the hub channel, the corresponding read-only replica relationship is established or reused according to the rules described in S24. For attribute change and deletion incremental events, since their corresponding nodes or relationships already have partitioning information, their processing partitions are directly determined based on the existing partitioning information and read-only replica distribution, without the need to re-execute partitioning scoring. After the processing partitions are determined, the incremental events are assigned processing partition identifiers and delivered to the computing nodes of the corresponding partitions.

[0078] In one embodiment of the present invention, such as Figure 3 As shown, step S4 specifically includes:

[0079] S41. Divide the aggregation method of node state values ​​into monotonically additive and non-monotonic elimination categories. For monotonically additive nodes, maintain a record of all candidate sources of contribution. For non-monotonic elimination nodes, maintain a two-level candidate source record of the current candidate source and the backup candidate source.

[0080] For each node in the graph Maintenance status value The value range, combination method, and aggregation method are pre-configured before acquiring incremental events, based on the specific business analysis objectives served by this real-time analysis. For example, the value range can be set to a binary set, the combination method can be the neighbor's state value itself, and the aggregation method can be set to a logical OR operation, used to determine reachability; or the value range can be set to the union of non-negative real numbers and infinity, the combination method can be the sum of the neighbor's state value and the associated attribute, and the aggregation method can be set to the minimum value operation, used to measure distance; or the value range can be set to a set of labels, the combination method can be set to read the current label of the neighbor, and the aggregation method can be set to the label with the highest frequency among the neighbors, used to divide communities. Based on the nature of the aggregation method, it is divided into two categories: under aggregation methods such as logical OR and counting summation, the removal of any contribution source does not change the validity of the remaining contribution sources, and is classified as monotonically additive; under aggregation methods such as minimum value and mode, the elimination of a contribution source will make the previously unadopted contribution source a valid candidate again, and is classified as non-monotonic elimination.

[0081] For monotonically additive nodes, maintain candidate source records. It is a set of quadruplets, with elements being Record the contributing neighbors separately Connection relationships The neighbor's state value at that time Maintenance partition of current status values ​​of neighbors If If it belongs to the hub channel, then ,otherwise for The corresponding regular partition; all contributing neighbors that meet the aggregation criteria are recorded. The set is naturally complete and does not lose its completeness due to the removal of individual contributors.

[0082] For nodes that are not monotonically eliminated, maintain the candidate source record as a candidate chain of fixed length 2. The elements in the chain are expanded into quintuples. ,in For the neighbors The version number of the current partition ownership record; Record the current status The source of contribution where the value plays a decisive role. The candidate chain records the second-ranking source in the candidate sequence. The length of the candidate chain does not increase with the node degree, thus keeping the storage overhead of candidate source records within a bounded range. The insertion and maintenance of the candidate chain follow a uniform rule: when a node... When a new candidate value is generated due to the addition of a new edge or the update of the state of an existing neighbor, the candidate value is compared with... , The relative merits of the current recorded value determine its insertion position or rejection. This rule applies uniformly to all scenarios, including state updates for new events, fallback reconstruction for deleted events, and candidate chain refreshes triggered by subsequent message passing, ensuring that the candidate chain truly reflects the current best and second-best candidate sources at any given time.

[0083] S42. Based on the incremental event type corresponding to the initially affected node, the scope is expanded. For nodes activated by incremental events of the type of addition or attribute change, it is determined whether to include the corresponding neighbor node in the affected subgraph and continue to expand based on whether the aggregated state value has changed compared with the state value recorded before activation. For nodes activated by incremental events of the type of deletion, the state value is recalculated based on the update result of the candidate source record, and then it is determined whether to continue to expand based on whether the recalculated state value has changed compared with the state value recorded before activation.

[0084] After an incremental event is processed, the initial affected nodes are determined. These are the nodes directly involved in the incremental event and are added to the initial activation set, maintaining a queue of nodes to be processed. In each round, nodes are retrieved from the queue and their status is determined based on the type of their triggering event: for nodes activated by incremental events of the addition or attribute change type, their neighbor contributions are re-aggregated according to their aggregation method to obtain a new state value. Compared with the historical state values ​​recorded before activation The equivalence comparison is performed, and the propagation criterion is... Update when the criterion is true. The node's neighboring nodes are then added to the next round's activation queue; if the criterion is false, the propagation branch at that node immediately terminates. For nodes activated by deletion-type incremental events, the impact of the deleted associations on the state value is first determined based on their candidate source records. Then, the corresponding contribution sources are removed or promoted from the node's candidate source records, and the nodes are re-aggregated to obtain a new state value. The criteria for transmission are When the criterion is true, update. The neighboring nodes are then added to the next round's activation queue, and propagation continues in the deletion direction. If the criterion is false, the propagation branch at that node immediately terminates. When the same node is activated simultaneously by both addition and deletion events in the same round, the events are processed sequentially according to their original arrival order in the batch to avoid duplicate overwriting of state values. The above expansion process is performed round by round. After each round, only nodes with newly generated state changes in that round continue to expand outwards. The queue will be emptied within a finite number of rounds, allowing the propagation range to adaptively converge as the node's state changes.

[0085] S43. For nodes involved in deletion-type incremental events, verify whether the deleted association constitutes a valid candidate source based on its candidate source record. If it constitutes a valid candidate source, remove the monotonically additive node from the candidate source record and re-aggregate it according to the remaining candidate sources. For non-monotonic elimination nodes, promote the backup candidate source to the current candidate source. After the promotion or removal is completed, perform migration verification on the partition ownership in the updated candidate source record according to the version change of the partition ownership information, and determine the recalculated state value based on the verification result.

[0086] When the relationship When a node is marked for deletion due to events such as transaction reversal, account cancellation, or relationship termination, the node is first determined. The aggregation type it depends on: For monotonically additive aggregations, in the candidate source record The system checks if the quadruple corresponding to the deleted association exists; if it does not exist, the node... Remain silent; if it exists, remove it and re-aggregate by remaining sources:

[0087] ;

[0088] in, For nodes that undergo state re-aggregation. for The remaining contributing neighbors, For the neighbors With nodes The relationship between them For the neighbors The status value to be updated for The corresponding partition version, For nodes The set of candidate source records, For association Carrying business attributes, It is a combinatorial function. It is an aggregation operator.

[0089] For non-monotonic elimination aggregations, first verify whether the deleted edge corresponds to a candidate chain. If the deleted edge does not correspond It doesn't correspond either ,node Remain silent; if in response , directly Leave blank, Remain unchanged and do not trigger propagation; if corresponding Then Upgraded to new , Set to empty. At the moment the promotion occurs, first check the value after the promotion. Perform migration-aware failure verification on the candidate sources recorded in the record: [The record contains...] With partition version table The current version number is compared. If they match, it means that the partition ownership of this candidate source has not changed since its establishment, and the record in the current version number is directly used. If the two are inconsistent, it indicates that the candidate source has undergone a partition ownership change due to historical edge migration in S23 or channel migration in S24 after the candidate chain was established. In this case, first correct the candidate chain record according to the latest value in the version table. , Then with the corrected As the target partition for subsequent verification, this correction process does not trigger a recalculation of the candidate source state values ​​themselves; it only corrects the partition attribution flag. After completing the attribution verification, if the partition is upgraded... Recorded With nodes The current partition is different, so it is determined to be a cross-partition rollback, node The partition is located towards Send verification message ,in For records in the candidate chain The state value at the moment the candidate relationship is established; Return after receiving Current actual state value .like The candidate value for rollback is adopted directly based on the recorded value, that is... If they are not equal, then... Replace and recalculate and nodes Rejoin the queue for the next round of activation to verify further propagation to its neighbors. If With nodes If the current partition is the same, read directly from the local machine. After completing the above calculations, no cross-partition messages will be initiated. If promoted... , All are empty, triggering a node A rescan of all current neighbors is performed, and the aggregation method of S41 is recalculated. The candidate chain is reconstructed based on the rescan results (during reconstruction, the candidate source of the new record is written to the version number snapshot in the current version table). This rescan is triggered only when both levels of candidates in the candidate chain are exhausted, and is a fallback branch of the bounded fallback mechanism, rather than the default processing path for deletion events. When the active node transmits state changes to neighbors belonging to other partitions, if the two already have a cross-partition read-only replica relationship due to the allocation decision in step S2, the transmission is carried out along the established replica synchronization channel; otherwise, it is directly delivered to the target partition based on the current partition ownership record. The cross-partition verification message reuses this propagation channel and no separate communication link is established.

[0090] In this invention, by classifying the aggregation methods of node state values ​​into monotonically additive and non-monotonic elimination classes, and designing two candidate source record structures—a complete source set and a bounded candidate chain—for each class, the state rollback of deletion events can accurately locate the alternative candidate source without retaining all historical evidence. The expansion of the affected subgraph is determined round by round based on whether the state value has actually changed, avoiding computational redundancy or omissions caused by the fixed hop count definition method. Combined with the cross-partition verification mechanism for changes in partition ownership information version, the partition ownership information involved in the candidate source record can still be detected and corrected in a timely manner even if it changes due to edge migration or channel migration, avoiding rollback calculations based on expired partition ownership data.

[0091] In one embodiment of the present invention, step S5 includes: for the affected subgraph and its corresponding updated state value and candidate source record output in step S4, each partition computing node locates the nodes and related relationship data belonging to its own partition within the affected subgraph range in its local memory, and performs structure update and state update: structure update refers to writing the newly added and deleted nodes and related relationships into the adjacency structure of the partition, and synchronously updating the attribute fields of the affected nodes and related relationships; state update refers to writing the updated state value and candidate source record content (including the partition affiliation and version number recorded therein) into the state storage field of the node, replacing its historical state value and the original candidate source record.

[0092] After the update is complete, starting from the local nodes of each partition within the affected subgraph, the calculation proceeds along the adjacency relationships within the partition using a message-passing method: Nodes To his neighbor Send containing Messages related to the relationship attribute, neighbors Upon receiving a message, the node updates its own state using the combination function and aggregation operator, and simultaneously refreshes its candidate source records (including a snapshot of the version number of the new record's source). Cross-partition message transmission is routed to the target partition along the established replica synchronization channel or according to the partition ownership record of the edge. Cross-partition verification messages reuse the same propagation channel. The above message transmission and state update process is executed iteratively round by round. After each round, the corresponding propagation criterion is used to determine whether to continue to the next round, until no more state-changing messages are generated within the affected subgraph, at which point the iteration terminates. Nodes and relationships outside the affected subgraph do not participate in this round of update and iteration, and their stored data remains unchanged. In cases where the hub channel node has read-only replicas in multiple partitions due to partition decisions, the primary partition of the node performs the state update uniformly. After each round of iteration, the primary partition sends the latest state value to each read-only replica through the replica synchronization channel to ensure consistency between replicas. If the hub node undergoes channel migration, the partition ownership version table must be updated simultaneously with the primary partition change to ensure that the partition ownership and version number recorded when the candidate source record is from this node can be correctly verified subsequently.

[0093] In one embodiment of the present invention, step S6 includes: based on the attribute graph data after the local iterative update in S5, each partition computing node executes a distributed graph analysis strategy in parallel according to the type of the received query request.

[0094] Specifically, multi-hop association queries are implemented using distributed breadth-first traversal: the query request specifies the starting node and the maximum number of hops, the partition where the starting node is located adds it to the level 0 traversal set, and then expands outwards layer by layer. For each node in each level set, the next level node is accessed along its adjacent edges. If the target node belongs to another partition, the traversal request, along with the visited path and the remaining number of hops, is forwarded to the target partition through the inter-partition communication interface to continue execution; if the target node is a hub channel node, the local read-only copy is read directly to complete the access without forwarding; each partition maintains a local marker of visited nodes to avoid repeated traversal, until the maximum number of hops is reached or the traversal set no longer expands, and returns a set of associated entities that meet the constraints of the number of hops and business attributes.

[0095] The shortest path calculation employs a distributed single-source shortest path algorithm: starting with the initial node as the source, its distance value is initialized to 0, while the distance values ​​of all other nodes are infinite. Each partition performs relaxation operations on its local edges in parallel. If passing through an edge reduces the distance to a neighboring node, the distance value of that neighbor is updated, and the predecessor node is recorded. Simultaneously, the candidate chain of that node is updated (including recording the partition version number at the time the candidate source was entered). Cross-partition boundary nodes that generate distance updates synchronize the new distance values ​​to adjacent partitions through inter-partition communication. Relaxation operations involving hub channel nodes are directly read from the local read-only replica. Each partition continues to relax accordingly, iterating repeatedly until all partitions no longer generate distance updates. Finally, the shortest association path between specified node pairs is obtained by backtracking based on the predecessor nodes recorded by each node. If the association relationship within the subsequent query range is deleted, the candidate chain currently maintained by the node is directly reused to perform a rollback (including migration-aware failure verification), without needing to recalculate the shortest path tree in its entirety.

[0096] The community label allocation adopts a distributed label propagation algorithm: initially, each node is assigned a unique initial community label. Each partition executes iterations in parallel. Each node collects the current community labels of all its neighbors (including cross-partition neighbors, obtained through boundary node communication or local read-only replicas), counts the most frequently occurring label and updates it as its own label. At the same time, it updates the source of the highest and second highest frequency labels recorded in the candidate chain and their partition version numbers. After each round of iteration, cross-partition boundary nodes synchronize the updated labels of this round to the corresponding replicas of adjacent partitions. The label updates of hub channel nodes are broadcast to each read-only replica after completion in their primary partition. Each partition updates its locally cached neighbor label information accordingly. The iteration continues until the number of nodes with global label changes between two adjacent rounds is zero, at which point convergence is determined. Finally, the label held by each node is its community. After completing their local computations, each partition's computing nodes report their partial results to the coordinating node through a unified result aggregation interface. In multi-hop join query scenarios, each partition reports partial path fragments generated within it. The coordinating node then concatenates the cross-partition path fragments sequentially based on the predecessor node information carried in the path, and deduplicates and merges duplicate paths. In shortest path calculation scenarios, each partition reports its local predecessor node chain. The coordinating node then backtracks along the predecessor chain to construct the shortest path from the starting point to the ending point. In community discovery scenarios, each partition reports the final community label of its local nodes. The coordinating node merges the sets of nodes holding the same label across partitions to form a globally consistent community partitioning result. The aggregated results are then returned to the upper-layer business system in real time through a unified query interface.

[0097] This invention employs a partitioning strategy that combines node type-based pre-distribution with intra-batch conflict group scoring. This approach takes into account the differences in load characteristics between a few high-connectivity nodes and the majority of ordinary nodes in a large-scale relational graph, achieving partition load balancing in scenarios with high-concurrency incremental data writing. By distinguishing between monotonically additive and non-monotonic elimination aggregation methods and designing candidate source record structures for each, combined with a partition ownership version verification mechanism, the state rollback of relational deletion events can accurately locate alternative evidence and perceive changes in partition ownership across partitions, avoiding computational biases caused by relying on single evidence or expired partition information. The affected subgraph adaptively expands based on the actual changes in node state values, reducing unnecessary computational scope and improving the overall response efficiency of real-time analysis of large-scale account, personnel, and transaction relational relationships.

[0098] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for real-time analysis of large-scale relationships based on incremental graph computation, characterized in that, Includes the following steps: S1. Obtain the relationship data between accounts, personnel and transaction entities, unify the entities and deduplicate the relationships in the relationship data, and model it as attribute graph data. The attribute graph data includes nodes, node attributes, relationships and relationship attributes. S2. Based on node attributes, divide the nodes in the attribute graph data into nodes belonging to the hub channel and nodes belonging to the regular channel. Different partitioning strategies are used for nodes belonging to the hub channel and nodes belonging to the regular channel to determine their respective target partitions, obtain the partitioning information of nodes and their relationships, and record the version changes of the partitioning information. Among them, the partitioning strategy for regular type nodes is combined with the node degree and the conflict relationship between nodes in the batch for load balancing. S3. Obtain incremental events of addition, attribute change and deletion for attribute graph data. For incremental events with existing partition ownership information, determine the processing partition according to the corresponding partition ownership information. For new nodes or associations, determine the processing partition using the partitioning strategy to obtain incremental events with processing partition identifiers. S4. Determine the initial affected nodes based on incremental events, and use the affected scope definition strategy to calculate the state and expand the scope of the initial affected nodes to obtain the affected subgraph; for the deletion type incremental events, use the candidate rollback strategy to determine the alternative candidate source, and use the version change of the partition ownership information to migrate and verify the candidate source across partitions to obtain the update status and candidate source record of each node in the affected subgraph. S5. Based on the affected subgraph, the state to be updated, and the candidate source record, update the affected nodes and relationships in the attribute graph data, and use message passing to perform local iterative calculations in the affected subgraph to obtain the updated attribute graph data. S6. Based on the updated attribute graph data, a distributed graph analysis strategy is used to perform parallel analysis of the relationships between accounts, personnel and transaction entities to obtain the relationship analysis results.

2. The method for real-time analysis of large-scale relationships based on incremental graph computation as described in claim 1, characterized in that, Step S2 specifically includes: S21. Determine whether a node belongs to a regular channel or a hub channel based on the node attributes, and maintain a degree counter for regular channel nodes and a load counter for each partition. S22. For the edges in the regular channel, determine the candidate partition set based on the conflict group affiliation relationship dynamically maintained within the batch, and score the candidate partitions based on the node's adaptability and load balancing degree, and assign the edges to the candidate partitions with the highest scores to obtain the partition affiliation information of the regular channel. S23. Update the load counter of the corresponding partition according to the partition ownership information of the conventional channel, and re-score the allocated edges according to the evolution of node degree. If there is a partition in the candidate partition set with a higher score than the original allocated partition, migrate the edge to the candidate partition with the highest score, and update the corresponding partition ownership information and its version record. S24. For nodes in the hub channel, determine the primary partition based on the distribution of their neighbors in each partition of the regular channel, and establish read-only copies in the partitions that have associated edges with the node to obtain the partition ownership information of the hub channel.

3. The method for real-time analysis of large-scale relationships based on incremental graph computation as described in claim 2, characterized in that, In step S22, the candidate partition set is determined based on the local footprints of the two endpoints of the edges that have generated associated edges in each partition. A partition in which at least one endpoint has generated an associated edge is selected as a candidate partition. Edges within the same conflict group are scored according to their arrival sequence number within the batch. Different conflict groups are processed in parallel, and conflict groups are merged into merged conflict groups during processing due to newly arrived edges generating associations. After merging, the accumulated load balancing state of each conflict group before merging is used to continue processing the unprocessed edges within the group. The candidate partition set... Each partition in , targeting the edge Scoring is performed based on a scoring function, which is as follows: ； In the formula, Let t be the edge reached by. , For the edge The two ends, For candidate partition set The i-th partition in For node pair partitioning Locality of fit For partitioning The load counter, To handle the conflict within the group to the border Previously accumulated placeholder load, For load balancing weighting coefficients, The target load balancing is determined based on the load of each partition at the start time of the batch and the total number of edges in this batch.

4. The method for real-time analysis of large-scale relationships based on incremental graph computation as described in claim 3, characterized in that, In step S23, the edges of the allocated partitions are... The rate of change of degree is calculated based on the degree values ​​of the two endpoints recorded at the partition allocation time and the degree values ​​of the two endpoints at the current time. In the rate of change of degree Exceeding the preset threshold At that time, the edges are adjusted according to the current load counter of each partition. Re-scoring, where there exists a score higher than the edge. When partitioning the original allocated partition, the edges will be... Migrate to the partition with the highest score and update the edges. Version records of the degree of the two endpoints and the corresponding partition ownership information.

5. The method for real-time analysis of large-scale relationships based on incremental graph computation as described in claim 2, characterized in that, In step S24, the primary partition of a node is the partition with the highest coverage ratio of the node's neighbors among the partitions of the regular channel. The node's attributes and status values ​​are maintained uniformly by the primary partition. The read-only copies established on the other partitions are only for local reading. After the primary partition completes the status update, it synchronizes the latest status value to the partition where the read-only copy is located. For nodes in the regular channel and the hub channel, it is determined whether the node meets the preset channel migration conditions based on the evolution of the node degree or the distribution of its neighbors. When the preset channel migration conditions are met, the nodes that meet the conditions are migrated between the regular channel and the hub channel, and the partition ownership information and version records corresponding to the migrated nodes are updated synchronously.

6. The method for real-time analysis of large-scale relationships based on incremental graph computation as described in claim 1, characterized in that, In step S1, the relationship data includes transfer relationships between accounts, holding or operation relationships between personnel and accounts, and participation relationships between personnel and transactions; entity unification refers to merging records from different sources but pointing to the same entity based on a unified entity identifier; in the modeled attribute graph data, nodes record the type identifiers and business attributes of accounts, personnel, or transactions, and relationship records the corresponding direction and occurrence time. Transfer relationships and participation relationships also record transaction amounts, and an adjacency structure is used to record and store the correspondence between nodes and their associated relationships.

7. The method for real-time analysis of large-scale relationships based on incremental graph computation as described in claim 1, characterized in that, Step S4 specifically includes: S41. Divide the aggregation method of node status values ​​into monotonically additive and non-monotonic elimination categories. For monotonically additive nodes, maintain a record of all candidate sources of contribution. For non-monotonic elimination nodes, maintain a two-level candidate source record of the current candidate source and the backup candidate source. S42. Based on the incremental event type corresponding to the initially affected node, the scope is expanded. For nodes activated by new or attribute change type incremental events, the corresponding neighbor node is included in the affected subgraph and expanded further based on whether the aggregated state value has changed compared with the state value recorded before activation. For nodes activated by deletion type incremental events, the state value is recalculated based on the update result of the candidate source record, and then the expansion is determined based on whether the recalculated state value has changed compared with the state value recorded before activation. S43. For nodes involved in deletion-type incremental events, verify whether the deleted association constitutes a valid candidate source based on its candidate source record. If it constitutes a valid candidate source, remove the monotonically additive node from the candidate source record and re-aggregate it according to the remaining candidate sources. For non-monotonic elimination nodes, promote the backup candidate source to the current candidate source. After the promotion or removal is completed, perform migration verification on the partition ownership in the updated candidate source record according to the version change of the partition ownership information, and determine the recalculated state value based on the verification result.

8. The method for real-time analysis of large-scale relationships based on incremental graph computation as described in claim 7, characterized in that, In step S41, the candidate source records maintained for monotonically additive nodes are a set of four-tuples, with each element recording contributing neighbors, the association relationship of the connection, the neighbor's state value, and the partition where the neighbor is located; the candidate source records maintained for non-monotonic elimination nodes are candidate chains of length 2, with the current candidate source record in the candidate chain being the contributing source that plays a decisive role in the node's state value, and the backup candidate source record being the second source in the candidate sequence.

9. The method for real-time analysis of large-scale relationships based on incremental graph computation as described in claim 8, characterized in that, In step S43, for monotonically additive nodes, the existence of the quadruple corresponding to the deleted association is verified in the candidate source records. If it exists, it is removed, and the nodes are re-aggregated according to the remaining quadruples. ； in, For nodes that undergo state re-aggregation. For nodes The re-aggregated state value, for The remaining contributing neighbors, For the neighbors With nodes The relationship between them For the neighbors The status value to be updated for The corresponding partition version, For nodes The set of candidate source records, For association Carrying business attributes, It is a combinatorial function. For aggregation operators; For nodes that are not subject to monotonic elimination, after promoting a backup candidate source to a new current candidate source, the partition ownership version of the promoted current candidate source record is first compared with the corresponding version recorded in the partition ownership information. If the versions are inconsistent, the partition ownership of the promoted current candidate source record is corrected according to the partition ownership information. If the partition where the promoted current candidate source is located is different from the partition where the node is located after correction, a verification message is sent to the partition where the promoted current candidate source is located, and the recalculated state value is determined based on the returned actual state value. If both the promoted current candidate source and the backup candidate source are empty, all neighbors of the node are rescanned, the node state value is recalculated, and the candidate source record is reconstructed.

10. The method for real-time analysis of large-scale relationships based on incremental graph computation as described in claim 1, characterized in that, In step S6, the state values ​​of the nodes in the graph are maintained, with the value range determined by the type of analysis being performed, and updated based on the combined results of neighbor contributions; the distributed graph analysis strategy includes: Multi-hop association query takes the state value domain as a binary set, the combination method is the neighbor state value itself, and the aggregation method is a logical OR operation, which is used to determine whether there is a reachable path between nodes; The shortest path calculation takes the state value range as the union of non-negative real numbers and infinity, the combination method is the sum of the neighbor state values ​​and the edge attributes, and the aggregation method is the minimum value operation. Community tags are defined by taking the state value domain as the community tag set, combining them by reading the current tags of neighbors, and aggregating them by taking the tags that appear most frequently among the neighbors.

Images