Transaction tracking method and device based on transaction relation graph

Abstract

The embodiment of the invention provides a transaction tracking method based on a transaction relation graph, and the method comprises the steps: carrying out the target traversal of the transaction relation graph, and obtaining a plurality of unit transactions; the target traversal comprises that for any first directed edge, a corresponding propagation message is transmitted to a target outgoing edge of a first pointing node according to a first transaction constraint, and the propagation message comprises first identification information of the first directed edge; and the target outgoing edge and the corresponding transaction information are constructed into a unit transaction, the transaction information comprises a transaction amount corresponding to the target outgoing edge and path information obtained according to the propagation message, and the path information comprises the first identification information as a parent path identifier. Based on the plurality of unit transactions, performing path construction operation to obtain a transaction tracking record containing a plurality of transaction chains; the path construction operation comprises the step of sequentially connecting a plurality of unit transactions according to the path information of each unit transaction.

Description

Technical Field

[0001] One or more embodiments of the present specification relate to the field of graph computing, and in particular, to a method and device for tracking transactions based on a transaction relationship graph. Background Art

[0002] With the development of computer technology and the rapid popularization of e-commerce, online transactions have become an indispensable part of people's daily lives. As the base system supporting online transactions, the payment system generates massive amounts of capital transactions every day. These capital transactions link users, merchants, financial institutions and other transaction objects, reflecting the complex transaction relationships between massive transaction objects.

[0003] By abstractly modeling a large number of fund transactions, a transaction relationship graph can be constructed. Traversing, calculating, and analyzing the transaction relationship graph and tracing the fund transaction chain can play an important reference role in resolving business risks, combating black and gray production activities, analyzing the intentions of transaction objects, and controlling fund risks, and has great mining and analysis value.

[0004] Therefore, we hope to have a solution that can efficiently analyze the transaction relationship graph and track the transaction chain through technical means. Summary of the invention

[0005] One or more embodiments of this specification describe a method and device for transaction tracking based on a transaction relationship graph. For a transaction relationship graph containing massive fund transaction information, in the process of traversing it, the unit transaction is taken as the processing object, and the directed edge identification information of the upstream unit transaction is transmitted to it as the parent path identification; then, based on the parent path identification, the association between each unit transaction is analyzed, the unit transactions are connected, the complete transaction path is restored, and the transaction tracking record containing the transaction chain information is obtained. In this way, not only the accuracy of transaction path restoration is ensured, but also the amount of information transmitted during the graph traversal process can be significantly reduced, the IO throughput can be reduced, and the computing performance and resource overhead can be effectively balanced, thereby improving the analysis efficiency of the transaction relationship graph.

[0006] According to a first aspect, a method for tracing a transaction based on a transaction relationship graph is provided, wherein the transaction relationship graph includes nodes representing transaction objects and directed edges representing transactions, and the method includes:

[0007] Performing a target traversal on the transaction relationship graph to obtain a number of unit transactions; the target traversal includes, for any first directed edge, transmitting the corresponding propagation message to the first target out-edge pointing to the node according to the first transaction constraint, the propagation message includes the first identification information of the first directed edge, the first transaction constraint includes that the first transaction time corresponding to the first directed edge is earlier than the second transaction time corresponding to the target out-edge; constructing the target out-edge and its corresponding transaction information as the unit transaction, the transaction information includes the transaction amount corresponding to the target out-edge and the path information obtained according to the propagation message, and the path information includes the first identification information as the parent path identifier.

[0008] Based on the plurality of unit transactions, a path construction operation is performed to obtain a transaction tracking record including a plurality of transaction chains; the path construction operation includes sequentially connecting the plurality of unit transactions according to the path information of each unit transaction.

[0009] According to an implementation, the propagation message further includes second identification information of a root transaction to which the first directed edge belongs; the path information further includes the second identification information as a root path identifier; and the path construction operation includes:

[0010] The unit transactions are grouped according to the root path identifier of each unit transaction.

[0011] For any group, several unit transactions are connected based on the parent path identifiers of the unit transactions therein.

[0012] In one scenario of the above implementation, the root transaction is determined in the following manner:

[0013] For any first node, if there is no incoming edge on which the target traversal has not been performed, and there is a first outgoing edge on which the target traversal has not been performed, the first outgoing edge is determined as a root transaction.

[0014] In one scenario of the above implementation, the root transaction is determined in the following manner:

[0015] For any second node, if there is a second outgoing edge on it, and the transaction time corresponding to the second outgoing edge is earlier than all incoming edges on the second node that have not yet performed the target traversal, then the second outgoing edge is determined as a root transaction.

[0016] According to an implementation, the first transaction constraint further includes: a time difference between the first transaction time and the second transaction time is less than a first time threshold.

[0017] According to one implementation, the target out-edge is determined by the following steps:

[0018] For the first directed node, a number of third outgoing edges on the first directed node that have not yet been traversed by a target are sorted according to the targets and offset with the first directed edge based on the transaction amount in sequence.

[0019] If there is a fourth outbound edge that can be fully offset, it will be included in the target outbound edge.

[0020] If there is a fifth outgoing edge that cannot be fully offset, split it into a first sub-edge containing the amount that can be fully offset and a second sub-edge containing the remaining amount. The first sub-edge is included in the target outgoing edge, and the second sub-edge remains in a state where the target traversal is not performed.

[0021] In one scenario of the above implementation, the third outgoing edge is a directed edge having a first association with the first directed edge; the first association includes one or more of the following: transaction order association, transaction commodity association.

[0022] In one scenario of the above implementation, the target sorting includes one of the following: sorting based on transaction time and sorting based on transaction amount.

[0023] According to one implementation, the path building operation is performed by a map-reduce framework, which includes a mapping module, a shuffling module and a plurality of reduction task modules; the path building operation includes:

[0024] The plurality of unit transactions are randomly read into a plurality of shards through the mapping module.

[0025] The unit transactions with the same root path identifier in the plurality of shards are grouped into the same reduction task module through the shuffling module.

[0026] Any reduction task module executes the reduction task for path construction on the assigned target unit transaction to obtain the corresponding transaction chain.

[0027] According to one implementation, obtaining a transaction tracking record including a plurality of transaction chains includes:

[0028] For the first path obtained by the path construction operation, starting from its tail node, the path is traversed along any incoming edge to the source node, and the transaction information on the visited directed edges is recorded in sequence to obtain the transaction tracking record of the first transaction chain.

[0029] According to a second aspect, a device for tracking transactions based on a transaction relationship graph is provided, wherein the transaction relationship graph includes nodes representing transaction objects and directed edges representing transactions, and the device includes:

[0030] The traversal module is configured to perform a target traversal on the transaction relationship graph to obtain a plurality of unit transactions; the target traversal includes, for any first directed edge, transmitting the corresponding propagation message to the first target out-edge pointing to the node in accordance with the first transaction constraint, the propagation message includes the first identification information of the first directed edge, the first transaction constraint includes that the first transaction time corresponding to the first directed edge is earlier than the second transaction time corresponding to the target out-edge; the target out-edge and its corresponding transaction information are constructed as the unit transaction, the transaction information includes the transaction amount corresponding to the target out-edge and the path information obtained according to the propagation message, and the path information includes the first identification information as the parent path identifier.

[0031] The path construction module is configured to perform a path construction operation based on the plurality of unit transactions to obtain a transaction tracking record including a plurality of transaction chains; the path construction operation includes sequentially connecting the plurality of unit transactions according to the path information of each unit transaction.

[0032] According to a third aspect, a computer program product is provided, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method described in the first aspect.

[0033] According to a fourth aspect, a computing device is provided, comprising a memory and a processor, wherein an executable code is stored in the memory, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0034] By implementing the method and device provided in the embodiments of this specification, in the process of traversing and calculating the transaction relationship graph, only by propagating small-volume messages containing path information, each unit transaction with upstream and downstream associations can be connected to each other, a complete transaction path can be constructed, and a transaction tracking record can be formed. The problem of high IO throughput occupancy in the process of traversing and calculating the transaction relationship graph can be solved, while ensuring the accuracy of the calculation, the balance between computing performance and resource overhead can be achieved, the efficiency of the transaction relationship graph calculation can be improved, and its application field can be further broadened. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present invention, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0036] Figure 1 This is an example of a transaction relationship graph structure disclosed in the embodiments of this specification;

[0037] Figure 2An example of a transaction relationship diagram is provided for the embodiments of this specification;

[0038] Figure 3 A technical framework diagram for transaction tracking based on a transaction relationship graph disclosed in an embodiment of this specification;

[0039] Figure 4 A flowchart of a method for tracking transactions based on a transaction relationship graph provided according to an embodiment of this specification;

[0040] Figure 5A A scenario diagram of determining a target out-edge according to an embodiment of this specification;

[0041] Figure 5B A scenario diagram of determining a target out-edge according to an embodiment of this specification;

[0042] Figure 5C A schematic diagram of a directed edge cancellation scenario provided according to an embodiment of this specification;

[0043] Figure 5D A schematic diagram of a directed edge cancellation scenario provided according to an embodiment of this specification;

[0044] Figure 6 Several root transaction determination examples provided according to the embodiments of this specification;

[0045] Fig. 7A This is a schematic diagram of a path construction scenario according to an embodiment of this specification;

[0046] Figure 7B This is a schematic diagram of a path construction scenario according to an embodiment of this specification;

[0047] Figure 8 A schematic diagram of a technical framework for applying Map-Reduce according to an embodiment of this specification;

[0048] Fig. 9 A schematic diagram of a path traversal operation provided according to an embodiment of this specification;

[0049] Fig.10 A schematic diagram of a device for tracking transactions based on a transaction relationship graph according to an embodiment of this specification. DETAILED DESCRIPTION

[0050] The solution provided by the embodiments of this specification is described below in conjunction with the accompanying drawings.

[0051] As mentioned above, the transaction relationship graph is a directed graph obtained by abstractly modeling a large number of fund transactions. In it, nodes can represent transaction objects, which can be users, merchants, financial institutions, etc. These transaction objects can be identified by some form of account (for example, ID in electronic payment system, bank card number, etc.), and directed edges can represent fund transactions between nodes. In other words, the transaction objects can be abstracted as nodes in the directed graph, and the fund transactions can be abstracted as directed edges in the directed graph. The corresponding transaction information (for example, transaction amount, transaction time, transaction scene, etc.) is loaded on the corresponding directed edges as edge attribute information, thereby constructing a transaction relationship graph.

[0052] In real business scenarios, as capital transactions occur, funds flow between multiple transaction objects. In order to identify business risks in massive capital transactions, graph traversal calculations can be performed on the transaction relationship graph to track capital transactions.

[0053] Figure 1 A sample transaction relationship graph architecture is provided, where nodes A, B, C, and D represent the transaction objects in the transaction. A directed edge represents a capital transaction, and the source node it connects to is the initiator of the transaction, and the node it points to is the counterparty or receiver of the transaction. The directed edge carries the transaction information of the corresponding capital transaction, for example, transaction scenario: transfer, transaction amount: ￥100, transaction time: 2024.01.0115:00. In addition, the transaction relationship graph can also be interpreted from the perspective of capital relations. Taking transaction object B as an example, B's downstream capital transactions include "spending ￥50 to transaction object C" and "sending a red envelope of ￥50 to transaction object D", and the corresponding upstream capital transaction is "transferring ￥100 from A to B". Based on the transaction relationship graph, by traversing along the directed edges, a capital turnover path containing multiple transaction chains can be obtained, and the transaction tracking of the transaction chain can be realized. Transaction characteristics extracted from the capital turnover path, such as transaction chain length, capital residence time, and capital source, can assist in analysis in downstream tasks and provide important references in resolving business risks, combating black and gray market activities, analyzing the intentions of transaction parties, and managing capital risks.

[0054] In one scenario, the transaction graph can be distributed and stored in different computing devices through graph segmentation technology (e.g., point segmentation, edge segmentation, etc.). With the continuous growth of transaction data, the transaction graph can also be horizontally expanded, for example, by adding computing nodes and computing devices to meet the expansion requirements of the transaction graph in the topology structure. Figure 1, the dotted line indicates the device where the node is located. Nodes A and B in the figure are stored in device DA, and nodes C and D are stored in device DB. When performing graph traversal calculations, device DA and device DB can communicate with each other and use distributed computing technology (for example, BSP model, Pregel framework, etc.) to complete the traversal calculation of the transaction relationship graph. In practice, according to specific business needs and combined with the characteristics of the transaction relationship graph, different nodes / directed edges can be stored in one computing device or in multiple storage devices. Figure 1 Just an example.

[0055] It should be understood that in the following text and in the description of the embodiments, for the sake of simplicity, for the transaction information in the transaction relationship diagram, the transaction time is expressed in natural days in the form of D+n, where D represents the base transaction date of the transaction relationship diagram, and n represents the nth natural day after the base transaction date. For example, assuming that D is January 1, 2024, then D+1 represents January 2, 2024, D+2 represents January 3, 2024, and so on. The transaction amount is simplified to an integer. The simplified expression does not represent a limitation on the embodiments. In actual applications, according to business requirements and computing power, the transaction time in the payment system can usually be accurate to milliseconds or even microseconds; the transaction amount can usually be processed by a carry algorithm to retain two decimal places.

[0056] Due to the massive amount of fund transactions in the payment system, the transaction relationship graph constructed based on the abstract modeling of these transactions often also includes a massive amount of directed edges and nodes. Obviously, transaction tracking on a transaction relationship graph of such a scale will inevitably lead to the inability to focus the graph traversal calculation, waste computing resources, and reduce computing efficiency. Therefore, the transaction relationship graph that includes fund transactions within a period of time can be used as the target for transaction tracking. The transaction relationship graph can be a subgraph extracted from the total transaction relationship graph that includes all fund transactions. For example, it can be an incremental transaction relationship graph composed of fund transactions that occurred within nearly 6 months based on transaction time; it can also be a transaction relationship graph obtained by composing a graph centered on a certain node to be analyzed, or some fund transactions to be analyzed. See Figure 2 , the accompanying figure provides an example transaction relationship diagram, which is extracted from the total transaction relationship diagram and includes capital transactions between 12 transaction objects in the past 5 natural days (D+0 to D+4).

[0057] Based on the transaction relationship graph introduced above, in order to realize transaction tracking, in a related technology, the transaction relationship graph can be traversed and calculated along the directed edges according to the upstream and downstream fund dependencies of the fund transaction. Specifically, starting from the starting node, each node in the transaction relationship graph is traversed and accessed. In the access to any node, the transaction tracking information received by the upstream node (i.e., the initiator of the transaction) is superimposed on the transaction information of this transaction, and then propagated along the directed edge of this transaction to the pointed node (i.e., the visited node). In other words, in the process of traversal, as the traversal calculation progresses, the propagated transaction tracking information will also be gradually expanded, which includes the complete transaction tracking information corresponding to the transaction link. When traversing to the transaction end node (the end of the transaction link), the transaction tracking information it receives covers the complete tracking information of the entire transaction path from the starting node to the end node. The following example illustrates the transaction tracking involved in this related technology. In the following examples and embodiments, <source node, pointing node> is used to represent a directed edge between two nodes representing a transaction, with the direction pointing from the source node to the pointing node representing the counterparty; in some special cases, <source node, pointing node, amount> is used to distinguish and represent multiple directed edges between two nodes. This representation method briefly and clearly describes the fund transaction between nodes, which helps to better understand and apply the methods and devices disclosed in the embodiments of this specification.

[0058] based on Figure 2 The transaction relationship diagram shown is traversed by applying the calculation ideas of the above-mentioned related technologies. Taking one of the transaction links as an example, the information propagation shown in Table 1 below will be generated.

[0059] Table 1 Example of information propagation in traversal transaction relationship graph

[0060] Traversal sequence number Directed edges traversed Points to the transaction tracking information received by the node 1 <A,B> A→B 2 <B,D> A→B→D 3 <D,G> A→B→D→G 4 <G,I> A→B→D→G→I 5 <I,J> A→B→D→G→I→J

[0061] In the above examples, for the sake of simplicity, only the transaction node is used as the main content of the transaction tracking information. In actual practice, the transmitted transaction tracking information will also include other business information related to the transaction, such as transaction time, transaction voucher, transaction amount, etc. This will not be expanded in detail here.

[0062] It is not difficult to see that in the above transaction tracking method, relying on the incremental superposition of propagation information, the complete tracking information of the transaction link can be propagated on each node in the transaction relationship graph. Therefore, as an end node, the complete transaction chain can be directly read from the received transaction tracking information.

[0063] However, the inventors found that in the transaction tracking methods of these related technologies, as the scale of the transaction relationship graph increases, or the depth of the transaction flow increases, the information transmitted between nodes will become more and more bloated. For example, in the above example, the transaction object No. 5 J in the transaction link will receive transaction tracking information containing 5 transactions, and this message will gradually expand as the graph traversal calculation progresses. Obviously, this transaction tracking method will generate a propagation message with an increasing volume, trigger a large amount of data reading and writing, and reduce the efficiency of graph calculation, so that transaction tracking based on the transaction relationship graph cannot be applied to large-scale capital transaction calculations.

[0064] In order to solve the above problems, a method for tracking transactions based on a transaction relationship graph is proposed in an embodiment of this specification. Figure 3 The technical framework is shown in the figure. In the process of traversing the transaction relationship graph, each directed edge can only pass its own propagation message to the associated downstream transaction directed edge; the propagation message contains the path information containing its own directed edge identifier. That is to say, each unit transaction (such as unit transaction<B,C> ) may only include the directed edge identification information of its upstream transaction (parent transaction) as the parent path identification (for example, as shown in curly brackets, the parent path:<A,B> ). This can standardize the data format of message propagation, greatly reduce the volume of message propagation during the transaction relationship graph traversal, and reduce IO occupancy. After traversal, several unit transactions with corresponding parent path identifiers can be obtained (as shown in the middle dotted box in the attached figure), and then these unit transactions are connected according to the path information containing the parent path identifier, and the transaction paths in the transaction relationship graph are restored (as shown in the dotted box on the right side of the attached figure), so as to achieve the purpose of transaction tracking.

[0065] Following the above technical ideas. Figure 4 In FIG. 1 , a flow chart of a method for tracking transactions based on a transaction relationship graph according to an embodiment of the present specification is shown. It can be understood that the method can be executed by any device, equipment, platform, or device cluster with computing and processing capabilities. Figure 4In this embodiment, the transaction relationship graph includes nodes representing transaction objects and directed edges representing transactions, and the method includes at least the following steps. Step S401: Perform a target traversal on the transaction relationship graph to obtain a number of unit transactions; the target traversal includes, for any first directed edge, transmitting the corresponding propagation message to the first target out-edge pointing to the node according to the first transaction constraint, the propagation message includes the first identification information of the first directed edge, the first transaction constraint includes that the first transaction time corresponding to the first directed edge is earlier than the second transaction time corresponding to the target out-edge; construct the target out-edge and its corresponding transaction information as the unit transaction, the transaction information includes the transaction amount corresponding to the target out-edge and the path information obtained according to the propagation message, and the path information includes the first identification information as the parent path identifier. Step S403: Based on the several unit transactions, perform a path construction operation to obtain a transaction tracking record containing several transaction chains; the path construction operation includes, according to the path information of each unit transaction, sequentially connecting several unit transactions.

[0066] The specific implementation methods of the above steps will be described in detail below with reference to the accompanying drawings.

[0067] Step S401: traverse the transaction relationship graph to obtain a number of unit transactions.

[0068] The goal of this step is to extract unit transactions by traversing the transaction relationship graph. Each fund flow is a unit transaction. In order to record the upstream and downstream relationships between unit transactions, the identification information of the upstream unit transaction (parent transaction) is passed to its corresponding downstream unit transaction during the traversal process.

[0069] The target traversal corresponding to achieving the above-mentioned goal includes: for any first directed edge, the corresponding propagation message is transmitted to the first target out-edge pointing to the node in accordance with the first transaction constraint, and the propagation message includes the first identification information of the first directed edge, and the first transaction constraint includes that the first transaction time corresponding to the first directed edge is earlier than the second transaction time corresponding to the target out-edge; the target out-edge and its corresponding transaction information are constructed as the unit transaction, and the transaction information includes the transaction amount corresponding to the target out-edge and the path information obtained according to the propagation message, and the path information includes the first identification information as the parent path identifier.

[0070] The transaction information refers to the business information related to the transaction, including but not limited to the transaction amount, transaction time, and transaction scenario. The identification information refers to the unique identifier that can refer to the corresponding directed edge, including but not limited to ID and UUID (Universally Unique Identifier).

[0071] by Figure 2 Taking the transaction relationship diagram shown in the figure as an example, the execution of the target traversal is illustrated.<A,B> As the first directed edge, node B is the first pointing node. Execute the target traversal and convert the edge<A,B> The first identification information of is used as the parent path identifier, encapsulated in the propagation message, and passed to the target outgoing edge of node B:<B,C> ,<B,D> ,<B,E> , corresponding to three unit transactions, each unit transaction holds its corresponding upstream transaction (<A,B> ). By traversing the transaction relationship graph in this way, several unit transactions containing the parent transaction path identifier can be extracted. In this example, the several unit transactions are shown in Table 2 below.

[0072] Table 2 Unit transaction example

[0073] Unit Trading Parent path identifier (the first identifier information) <A,B> -- <B,D> <A,B> <D,G> <B,D> <G,I> <D,G> <I,J> <G,I> <B,C> <A,B> <B,E> <A,B> <C,F> <B,C> <C,H> <B,C> <E,M> <B,E> <E,N> <B,E>

[0074] The above is a brief introduction to target traversal. It can be seen that the transaction message propagates along the first directed edge, through the first pointing node, to the target outgoing edge. Therefore, before message propagation, the first thing to determine is the target outgoing edge that receives the message. In specific applications, in order to meet the business needs of transaction tracking, the target outgoing edge can be limited and screened from multiple dimensions, including but not limited to: the range of transaction time, the size of transaction amount, and the association of transaction attributes.

[0075] In one example, message propagation can follow the objective time law of fund transactions, that is, the fund transaction represented by the target outgoing edge should have a transaction time later than the transaction time of the parent transaction it depends on. Therefore, the transaction sequence based on the transaction time can be considered, and the outgoing edges that meet the increasing transaction sequence can be selected from the outgoing edges pointing to the first node as the target outgoing edges. That is, the first transaction constraint includes: the first transaction time corresponding to the first directed edge is earlier than the second transaction time corresponding to the target outgoing edge. Figure 5A As shown, the first directed edge<A,B> The corresponding first transaction time is D+2. Among the outgoing edges pointing to node B, the outgoing edges that satisfy the increasing transaction timing are<B,D> and<B,E> , so the target out-edge can include the edge<B,D> and edge<B,E> .

[0076] Furthermore, in a specific implementation of the above example, the first transaction constraint also includes: the time difference between the first transaction time and the second transaction time is less than a first time threshold. The first time threshold may be a maximum value of the time difference of associated transactions set according to the business scenario characteristics supported by the payment platform / transaction platform. For example, for financial services, the fund settlement cycle in the payment system may be 2 natural days, that is, for transactions with a time difference within 2 natural days, it can be determined to have the correlation between upstream and downstream transactions. Corresponding to this example, refer to Figure 5A , can be determined as the target out-edge, only the edge<B,D> .

[0077] In another specific implementation of the above example, the first transaction constraint may also include: the time difference between the first transaction time and the second transaction time is greater than a second time threshold. For example, for commodity trading business, the logistics cycle of the commodity is at least 2 natural days, that is, for commodity resale transactions with a time difference of more than 2 natural days, it can be determined to have a correlation with the upstream and downstream transactions of the same commodity. Corresponding to this example, in Figure 5A In the example, only the edge<B,E> .

[0078] In another example of determining the target outgoing edge, several third outgoing edges on the first directed node that have not been traversed to the target can be offset with the first directed edge based on the transaction amount in sequence to determine which outgoing edges represent transactions derived from the first directed edge. Figure 5B The example shows a scenario of determining the target outgoing edge, where the directed edge<A,B> is the first directed edge, and node B is the first pointing node.

[0079] First, determine the third outgoing edge: exclude the directed edges that have been visited by the target traversal, for example, the directed edge<B,F> (shown by dotted arrows in the figure), the remaining directed edges that have not been traversed by the target can be used as the third outgoing edges, for example, the directed edges<B,D> ,<B,C> and<B,E> (Indicated by double horizontal arrow lines in the accompanying drawings), these directed edges are offset with the first directed edge in sequence to screen out the corresponding target out-edges.

[0080] In one implementation, the third outgoing edge can be delineated by the association relationship between directed edges. That is, the third outgoing edge is a directed edge that has a first association with the first directed edge; the first association includes one or more of the following: transaction order association, transaction commodity association. Taking a scenario as an example, in a transaction system, the funds paid by a buyer for an order usually have to go through the fund settlement of multiple financial institutions (transaction objects) before finally flowing into the seller's account. In this process, each fund flow carries the information of the order. Therefore, the upstream and downstream transactions can be associated through the transaction order to determine the third outgoing edge associated with the first directed edge. Taking another scenario as an example, in an e-commerce system, the goods purchased by the buyer may be circulated through the channels of multiple intermediaries before being delivered to the buyer. During the channel circulation process, each transaction flow carries the identification information of the transaction commodity. Therefore, the upstream and downstream transactions can be associated through the transaction commodity to determine the third outgoing edge associated with the first directed edge.

[0081] Next, the third outgoing edge can be regarded as the target outgoing edge, and the propagation message on the first directed edge (including the identification information of the first directed edge) is passed to the third outgoing edge. In specific practice, the third outgoing edge selected from the first pointing node usually includes multiple directed edges (for example, generating capital diversion, structured transactions, etc.). At this time, the third outgoing edge can be offset with the first directed edge based on the transaction amount in turn, so that several target outgoing edges associated with the parent transaction represented by the first directed edge can be determined in the third outgoing edge.

[0082] In business practice, transaction operations such as fund pooling, fund dispersion, and mixed transaction chains often occur, which lead to fund mixing. As a result, one or more directed edges contained in the third out-edge cannot be directly offset in full with a single parent transaction. Therefore, in the process of executing the offset operation with the first directed edge, it is determined which third out-edges can constitute the target out-edges based on the offset results.

[0083] According to a practical scenario, in the third outbound side, if there is a fourth outbound side that can be fully offset, it will be included in the target outbound side. Figure 5B Taking the transaction relationship subgraph shown in the figure as an example, the third outgoing edge of the first directed node B is connected to the first directed edge<A,B,￥150> The third outgoing side<B,D,￥80> First, the offset can be performed in full, and the directed edge can be determined as the target outgoing edge. At this time, the amount of the parent transaction represented by the first directed edge that can be offset is ￥150-￥80=￥70; then the third outgoing edge<B,C,￥50> The directed edge can also be determined as the target outgoing edge. At this time, the amount of the parent transaction available for offset is ￥20; the remaining third outgoing edge<B,E,￥50> It is no longer possible to offset the parent transaction in full.

[0084] According to another practical scenario, in the third outgoing edge, if there is a fifth outgoing edge that cannot be fully offset, it is split into a first sub-edge containing an amount that can be fully offset and a second sub-edge containing the remaining amount, and the first sub-edge is included in the target outgoing edge, while the second sub-edge remains in a state where the target traversal is not performed. Figure 5B For example, when the third outgoing edge<B,E,￥50> When full offset is not possible, the directed edge can be split into a first sub-edge with a transaction amount of ￥20 (equal to the amount available for offset on the first directed edge) and a second sub-edge with a transaction amount of ￥30 (equal to the remaining amount). Since the first sub-edge can be fully offset, the first sub-edge can be determined as the target outgoing edge, while the second sub-edge remains in a state of not performing target traversal.

[0085] The above is an explanation of how to determine the target outgoing edge. It is not difficult to see that in the process of offsetting the third outgoing edge with the first directed edge in sequence, the offsetting order of the third outgoing edge will affect the offsetting result. Applying different offsetting orders will produce different target outgoing edges and / or the first sub-edge and the second sub-edge obtained by splitting. In a specific practice, the third outgoing edge can be offset with the first directed edge in sequence based on the transaction amount according to the target sorting; the target sorting can be a preset sorting rule.

[0086] In one example, the target ranking may be a ranking based on transaction time. Figure 5B Taking the transaction relationship subgraph shown as an example, the transaction time on the third outgoing edge is reversed with the first directed edge in the order from early to late. In this reverse order, the third outgoing edges to be reversed are:<B,D> ,<B,C> ,<B,E> , the results can be obtained as Figure 5C As shown, the target outgoing edge is:<B,D,￥80> ,<B,C,￥50> ,<B,E,￥20> (first sub-edge), the second sub-edge is:<B,E,￥30> .

[0087] In another example, the target ranking may be based on the transaction amount. Figure 5B Taking the transaction relationship subgraph shown as an example, the transaction amount on the third outgoing edge is in the order from low to high, and the first directed edge is offset. In this offset order, the third outgoing edges to be offset are:<B,C> ,<B,E> ,<B,D> , the results can be obtained as Figure 5D As shown, the target outgoing edge is:<B,C,￥50> ,<B,E,￥50> ,<B,D,￥50> (first sub-edge), the second sub-edge is:<B,D,￥30> .

[0088] The above specifically describes the method for determining the target out-edge during the target traversal process. In addition, the selection of the root transaction as the starting point of the target traversal will also have an important impact on the result of the target traversal. The root transaction refers to the first transaction that triggers a series of related transactions. In other words, it is the initial transaction activity in a transaction chain. The root transaction can be any directed edge specified in the transaction relationship graph based on business query requirements, or it can be a directed edge in the transaction relationship graph that can be used as a root transaction through certain query rules. In specific practice, the query rule can be to find a specific out-edge on any node. If the transaction represented by the specific out-edge does not depend on any upstream transaction, then the specific out-edge can be determined as a root transaction.

[0089] According to one implementation, an outbound edge on a node without any inbound edge may be determined as a root transaction. Figure 6Several root transaction determination examples are provided. Referring to example 1 in the figure, node A has two outgoing edges, neither of which has been processed by the target traversal, and it has no incoming edges. In other words, the two fund transactions corresponding to the two outgoing edges of node A do not have any upstream fund transaction dependencies, so the outgoing edges of node A<A,B> and<A,C> All of them can be identified as root transactions.

[0090] According to one implementation, for any first node, if there is no incoming edge on which the target traversal has not been performed, and there is a first outgoing edge on which the target traversal has not been performed, the first outgoing edge can be determined as a root transaction. Figure 6 Example 2, outgoing edge of node A<A,B> The target traversal has been completed, and there is one outgoing edge that has not yet been traversed.<A,C> At the same time, since all the incoming edges of node A have been traversed to the target, it can be inferred that there is no edge in the transaction relationship graph.<A,C> The upstream fund transaction that it depends on.<A,C> Identify as a root transaction.

[0091] According to one implementation, for any second node, if there is a second outgoing edge on it, and the transaction time corresponding to the second outgoing edge is earlier than all incoming edges on the second node that have not yet performed the target traversal, then the second outgoing edge can be determined as a root transaction. Figure 6 In example 3, unlike example 2, there is an incoming edge on node A that has not yet been traversed to the target. However, the transaction time of this incoming edge is D+3, which is later than the remaining outgoing edges on node A that have not been traversed to the target.<A,C> Based on the common sense of transaction timing, the incoming edge that is later than the outgoing transaction will not become an edge<A,C> That is to say, in this scenario, although node A has an incoming edge that has not been traversed to the target, the transaction time of all the incoming edges that have not been traversed to the target is later than the transaction time of the outgoing edges on node A that have not been traversed to the target. At this time, it can be inferred that there is no upstream fund transaction dependency corresponding to the outgoing edge in the transaction relationship graph. Therefore, the outgoing edge of node A can be<A,C> Identify as a root transaction.

[0092] After the target traversal of the transaction relationship graph as described above, several unit transactions can be obtained, each of which holds the first identification information (parent path identification) of its parent transaction. Through the first identification information, each unit transaction can be connected in series and displayed as a transaction path to form a transaction tracking record containing several transaction chains.

[0093] In step S403, a path construction operation is performed based on the plurality of unit transactions to obtain a transaction tracking record containing a plurality of transaction chains. The path construction operation includes sequentially connecting a plurality of unit transactions according to the path information of each unit transaction. Fig. 7AA schematic diagram of a path construction scenario is shown. Through target traversal, several unit transactions as shown on the left side of the attached figure are obtained, wherein ID represents the first identifier of the directed edge of the unit transaction; Parent_ID represents the first identification information of the parent transaction obtained through information propagation in the target traversal. According to the correspondence between Parent_ID and ID, these unit transactions can be connected one by one. As shown in the right box in the attached figure, by executing the path construction operation, a transaction path containing the several unit transactions can be obtained, including a tail node without downstream transactions (nodes D and E in this example) and a head node without upstream transactions (node ​​A in this example). It can be known that in the case where the target traversal starts from multiple root transactions, multiple transaction paths with different root transaction source nodes as head nodes can also be obtained through the path construction operation.

[0094] In a specific implementation, the propagation message transmitted during the target traversal process also includes the second identification information of the root transaction to which the first directed edge belongs (as the root path identifier). Figure 7B The path construction scenario provided by the implementation method is shown. Referring to the attached figure, in addition to the first identification of each directed edge and the parent path identification, the several unit transactions shown on the left side of the figure also hold the second identification information of the root transaction to which they belong (shown as Root_ID in the figure). For the root transaction itself, its Root_ID is its own first identification information. When performing the path construction operation, the several unit transactions can be grouped according to the root path identification held by each unit transaction. Figure 7B The grouping result is shown in the middle box of the attached figure. According to the root path identifier (Root_ID), the unit transactions are divided into two groups, one of which is the root transaction of<A,B> , the root transaction of the other group is<F,G> Then, for any group, several unit transactions are connected based on the parent path identifier of the unit transaction. As shown in the right box of the figure, two transaction paths with different root transaction source nodes as the first nodes can be obtained, one of which starts with node A and the other starts with node F.

[0095] According to one implementation, the Map-Reduce computing framework can be used to implement the above path construction operation. Map-Reduce is a programming model suitable for parallel distributed computing that processes massive amounts of data, and is widely used in big data processing and generation scenarios. In the Map-Reduce computing framework, the Map operation is responsible for splitting the input data into multiple fragments for reading, and these fragments can be processed in parallel on multiple computing nodes at the same time, thereby increasing the speed of data processing. The Reduce operation processes the intermediate result data output by the Map phase by executing a specific reduce function, and finally generates the result output. There can also be a shuffle operation between the Map and Reduce operations, which can group and aggregate data according to a specific key value, and data with the same key is assigned to the same Reduce task, so that different Reduce tasks can process their respective data sets in parallel, thereby further improving computing efficiency.

[0096] According to the implementation, based on the map-reduce framework, a mapping module, a shuffle module and a plurality of reduction task modules are implemented. Through the mapping module, a plurality of unit transactions are randomly read into a plurality of shards. Through the shuffle module, unit transactions with the same root path identifier in the plurality of shards are grouped into the same reduction task module. Any reduction task module executes a reduction task for path construction (through a reduction function) on the assigned target unit transaction to obtain a corresponding transaction chain. Figure 8 The technical framework provided according to the implementation manner is shown.

[0097] Referring to the attached figure, the unit transaction box on the left shows several unit transactions obtained from the transaction relationship graph through target traversal. These unit transactions are randomly read into several shards (shown as shard A, shard B, ..., shard X in the attached figure) through the mapping module. In a specific implementation, the mapping module can also process the unit transactions read into the shards to generate key-value pairs. After processing by the mapping module, the data read into the shards is shuffled, and the root path identifier held by each unit transaction is used as the key to group the unit transactions with the same root path identifier (these unit transactions are derived from the same root transaction) into the same reduction task module. In any reduction task module, the reduction task is executed, and the unit transactions grouped therein are connected into a transaction path through a path construction operation, which contains several transaction chains starting from the same root transaction. It can be seen that multiple reduction task modules can be calculated in parallel to improve computing efficiency.

[0098] In some embodiments, the obtained transaction path can also be traversed to obtain a transaction tracking record containing a specific transaction chain. The path traversal can be performed in the corresponding reduction task module, or it can be performed independently according to specific business needs after the path construction operation is completed (outside the corresponding mapping-reduction framework), and the embodiments of this specification do not limit this. The path traversal can be implemented by a variety of algorithms, including but not limited to depth-first search (DFS), breadth-first search (BFS), and Dijkstra algorithm (Dijkstra).

[0099] Specifically, for the first path obtained through the path construction operation, starting from its tail node, the path is traversed along any incoming edge to the source node, and the transaction information on the visited directed edges is recorded in sequence to obtain the transaction tracking record of the first transaction chain. Fig. 9 The diagram shows a schematic diagram of the path traversal operation provided by the embodiment. In the example transaction path provided in the figure, the tail node (node ​​D, node E) is used as the starting point of the path traversal, and the path traversal is performed and recorded along the incoming edges to the source node in sequence. For example, starting from node D, along the incoming edges on it<C,D> , traverse to the source node C, and record the transaction information held on the directed edge (including transaction amount, path information, etc.), and so on, until traversing to the root transaction, and obtaining the transaction tracking records of the transaction chain corresponding to each tail node.

[0100] It should be understood that the above path traversal can be executed repeatedly to extract several transaction chains from the transaction path, and corresponding tracking records of fund transactions are generated to provide analysis references for downstream tasks.

[0101] According to one or more embodiments, a method for transaction tracking based on a transaction relationship graph is described in detail above. By adopting the above method provided in the embodiments of this specification, in the process of traversing and calculating the transaction relationship graph, by standardizing the data format of message propagation, the layer-by-layer transmission of duplicate data content can be basically eliminated, so that in the graph traversal calculation, the amount of data transmitted by the message becomes stable and consistent, and the amount of calculation and IO throughput are greatly optimized. Furthermore, the transaction relationship graph traversal is combined with the map-reduce computing framework, and the transaction tracking records are generated by parallel computing, so as to give full play to the distributed computing performance and improve the efficiency of the transaction relationship graph calculation, so as to meet the demand for achieving a balance between the horizontal expansion of the transaction relationship graph data scale and the computing performance.

[0102] In this specification, the word "first" in terms such as the first transaction and the first outbound edge, as well as the corresponding "second" and "third" (if any) in the text, are merely for the convenience of distinction and description and do not have any limiting meaning.

[0103] The foregoing describes certain embodiments of the present specification, and other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in an order different from that in the embodiments, and the desired results may still be achieved. In addition, the processes depicted in the accompanying drawings do not necessarily have to be performed in the specific order or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0104] Fig.10 1 is a schematic diagram of a device for tracking transactions based on a transaction relationship graph according to an embodiment of this specification. The device 1000 is deployed in a computing device, and the computing device can be implemented by any device, equipment, platform, device cluster, etc. with computing and processing capabilities. Figure 4 The transaction relationship graph includes nodes representing transaction objects and directed edges representing transactions, and the device 1000 includes:

[0105] The traversal module 1001 is configured to perform a target traversal on the transaction relationship graph to obtain a number of unit transactions; the target traversal includes, for any first directed edge, transmitting the corresponding propagation message to the first target out-edge pointing to the node in accordance with the first transaction constraint, the propagation message includes the first identification information of the first directed edge, the first transaction constraint includes that the first transaction time corresponding to the first directed edge is earlier than the second transaction time corresponding to the target out-edge; the target out-edge and its corresponding transaction information are constructed as the unit transaction, the transaction information includes the transaction amount corresponding to the target out-edge and the path information obtained according to the propagation message, and the path information includes the first identification information as the parent path identifier.

[0106] The path construction module 1002 is configured to perform a path construction operation based on the plurality of unit transactions to obtain a transaction tracking record including a plurality of transaction chains; the path construction operation includes sequentially connecting the plurality of unit transactions according to the path information of each unit transaction.

[0107] According to another embodiment of the present specification, there is also provided a computer program product, including a computer program / instruction, which implements the aforementioned combination when executed by a processor. Figure 4 The steps of the method.

[0108] According to another embodiment, the present specification further provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the aforementioned combination is implemented. Figure 4 The steps of the method.

[0109] Those skilled in the art should be aware that in one or more of the above examples, the functions described in the embodiments of the present invention may be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions may be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.

[0110] The specific implementation methods described above further describe the purpose, technical solutions and beneficial effects of the embodiments of the present invention in detail. It should be understood that the above description is only a specific implementation method of the embodiments of the present invention and is not intended to limit the scope of protection of the present invention. Any modification, equivalent replacement, improvement, etc. made on the basis of the technical solution of the present invention shall be included in the scope of protection of the present invention.

Claims

1. A method for tracing transactions based on a transaction relationship graph, wherein the transaction relationship graph comprises nodes representing transaction objects and directed edges representing transactions, the method comprising: Performing a target traversal on the transaction relationship graph to obtain a number of unit transactions; The target traversal includes, for any first directed edge, transmitting the corresponding propagation message to the first target out-edge pointing to the node according to the first transaction constraint, the propagation message includes the first identification information of the first directed edge, the first transaction constraint includes that the first transaction time corresponding to the first directed edge is earlier than the second transaction time corresponding to the target out-edge; constructing the target out-edge and its corresponding transaction information as the unit transaction, the transaction information includes the transaction amount corresponding to the target out-edge and the path information obtained according to the propagation message, the path information includes the first identification information as the parent path identification; Based on the plurality of unit transactions, a path construction operation is performed to obtain a transaction tracking record including a plurality of transaction chains; the path construction operation includes sequentially connecting the plurality of unit transactions according to the path information of each unit transaction.

2. The method according to claim 1, wherein: The propagation message further includes second identification information of the root transaction to which the first directed edge belongs; the path information further includes the second identification information as a root path identifier; The path building operation includes: Grouping the plurality of unit transactions according to the root path identifier of each unit transaction; For any group, several unit transactions are connected based on the parent path identifiers of the unit transactions therein.

3. The method according to claim 2, wherein: The root transaction is determined in the following way: For any first node, if there is no incoming edge on which the target traversal has not been performed, and there is a first outgoing edge on which the target traversal has not been performed, the first outgoing edge is determined as a root transaction.

4. The method according to claim 2, wherein: The root transaction is determined in the following way: For any second node, if there is a second outgoing edge on it, and the transaction time corresponding to the second outgoing edge is earlier than all incoming edges on the second node that have not yet performed the target traversal, then the second outgoing edge is determined as a root transaction.

5. The method according to claim 1, wherein: The first transaction constraint also includes: a time difference between the first transaction time and the second transaction time is less than a first time threshold.

6. The method according to claim 1, wherein: The target out-edge is determined by the following steps: For the first directed node, a plurality of third outgoing edges on the first directed node that have not been traversed by the target are sorted according to the target, and are offset with the first directed edge based on the transaction amount in sequence; If there is a fourth outbound edge that can be fully offset, it will be included in the target outbound edge; If there is a fifth outgoing edge that cannot be fully offset, split it into a first sub-edge containing the amount that can be fully offset and a second sub-edge containing the remaining amount. The first sub-edge is included in the target outgoing edge, and the second sub-edge remains in a state where the target traversal is not performed.

7. The method according to claim 6, wherein: The third outgoing edge is a directed edge having a first association with the first directed edge; the first association includes one or more of the following: a transaction order association and a transaction commodity association.

8. The method according to claim 6, wherein: The target sorting includes one of the following: sorting based on transaction time and sorting based on transaction amount.

9. The method according to claim 2, wherein: The path building operation is performed by a map-reduce framework, which includes a map module, a shuffle module and a plurality of reduction task modules; The path building operation includes: Randomly reading the plurality of unit transactions into a plurality of shards through the mapping module; By means of the shuffling module, unit transactions with the same root path identifier in the plurality of shards are grouped into the same reduction task module; Any reduction task module executes the reduction task for path construction on the assigned target unit transaction to obtain the corresponding transaction chain.

10. The method according to claim 1, wherein: The transaction tracking records containing several transaction chains are obtained, including: For the first path obtained by the path construction operation, starting from its tail node, the path is traversed along any incoming edge to the source node, and the transaction information on the visited directed edges is recorded in sequence to obtain the transaction tracking record of the first transaction chain.

11. A device for tracking transactions based on a transaction relationship graph, wherein the transaction relationship graph includes nodes representing transaction objects and directed edges representing transactions, the device comprising: A traversal module is configured to perform a target traversal on the transaction relationship graph to obtain a plurality of unit transactions; The target traversal includes, for any first directed edge, transmitting the corresponding propagation message to the first target out-edge pointing to the node according to the first transaction constraint, the propagation message includes the first identification information of the first directed edge, the first transaction constraint includes that the first transaction time corresponding to the first directed edge is earlier than the second transaction time corresponding to the target out-edge; constructing the target out-edge and its corresponding transaction information as the unit transaction, the transaction information includes the transaction amount corresponding to the target out-edge and the path information obtained according to the propagation message, the path information includes the first identification information as the parent path identification; The path construction module is configured to perform a path construction operation based on the plurality of unit transactions to obtain a transaction tracking record including a plurality of transaction chains; the path construction operation includes sequentially connecting the plurality of unit transactions according to the path information of each unit transaction.

12. A computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 10.

13. A computing device comprising a memory and a processor, characterized in that: The memory stores executable codes, and when the processor executes the executable codes, the method according to any one of claims 1 to 10 is implemented.

Images