Data query method and related equipment

Abstract

The invention discloses a data query method and related equipment, which are used for solving the problem of low recursive query efficiency in business object relation topology analysis. The method comprises the following steps: responding to a data query request, and obtaining a plurality of business object identifiers carried in the data query request; generating a data query task of the current level based on the plurality of business object identifiers, and submitting the data query task of the current level to a distributed computing service so as to execute the data query task in parallel in at least one database matched with the business object identifiers; obtaining an execution result of the data query task of the current level, and determining the data query task of the next level based on the sub-business object identifier in the execution result; wherein the data query task of the next level is executed in parallel through the distributed computing service until a preset stop condition is met, the generation of the data query task of the next level is stopped, and the business object topological data is generated and output according to the execution result of the data query task of each level.

Description

Technical Field

[0001] This application relates to the field of data processing, and more particularly to data query methods and related equipment. Background Technology

[0002] As enterprises become increasingly digitalized, more and more business objects are managed and operated through enterprise data systems, leading to increasingly complex relationships between different business objects. To extract valuable information from these complex and diverse relationships, it is typically necessary to calculate the hierarchical or dependency relationships between business objects and construct complete business object topology data.

[0003] In existing technologies, the retrieval and analysis of relationships between business objects mainly employ recursive queries or graph database queries. Recursive queries typically use a relational database to iterate layer by layer, starting from the source object to find its directly related objects, and then continuing to find the next level of related objects, thereby obtaining a multi-level dependency structure; another approach uses a graph database to obtain multi-level relationship data at once.

[0004] However, in scenarios with large-scale business relationship networks or involving multiple types of data sources, the recursive query performance of relational databases deteriorates sharply as the hierarchy deepens or the data volume surges, making it difficult to meet real-time requirements. Graph databases use declarative query syntax, meaning the query process is a closed, one-time operation. When processing large-scale datasets, it is often necessary to load multi-level business object-related data into memory all at once, which can easily lead to excessive memory and CPU pressure, resulting in I / O blocking or loss of intermediate calculation results. Therefore, existing technologies are insufficient to meet the needs of large-scale business object topology analysis. Summary of the Invention

[0005] Based on the above problems, this application provides a data query method and related equipment, aiming to solve the computational performance bottleneck problem in the existing technology when processing large-scale, multi-level business object relationships, and improve the topology relationship analysis capability and data query processing efficiency in a multi-source heterogeneous data environment.

[0006] Firstly, embodiments of this application provide a data query method, including:

[0007] In response to a data query request, obtain multiple business object identifiers carried in the data query request;

[0008] A data query task for the current level is generated based on the multiple business object identifiers, and the data query task for the current level is submitted to the distributed computing service to execute the data query task in parallel in at least one database that matches the business object identifier;

[0009] The execution result of the current level data query task is obtained, and the next level data query task is determined based on the sub-business object identifier contained in the execution result. The next level data query task is executed in parallel by the distributed computing service until a preset stopping condition is met. Then, the generation of the next level data query task is stopped, and business object topology data is generated and output according to the execution results of the data query tasks at each level.

[0010] Secondly, embodiments of this application also provide a data query device, including:

[0011] The request parsing unit is used to respond to data query requests and obtain multiple business object identifiers carried in the data query request.

[0012] The task generation and distribution unit is used to generate a data query task at the current level based on the multiple business object identifiers, and submit the data query task at the current level to the distributed computing service to execute the data query task in parallel in at least one database that matches the business object identifier.

[0013] The iterative processing unit is used to obtain the execution result of the data query task at the current level, and determine the data query task at the next level based on the sub-business object identifier contained in the execution result; wherein, the data query task at the next level is executed in parallel by the distributed computing service until a preset stopping condition is met, then the generation of the data query task at the next level is stopped, and business object topology data is generated and output according to the execution results of the data query tasks at each level.

[0014] Thirdly, embodiments of this application also provide a computer device, including:

[0015] Processor, memory, input / output interfaces;

[0016] The memory is either a short-term storage memory or a persistent storage memory;

[0017] The processor is configured to communicate with the memory and execute instructions in the memory to perform the data query method described in the first aspect of the embodiments of this application or any specific implementation thereof.

[0018] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is used to implement the data query method described in the first aspect or any specific implementation of the first aspect of the embodiments of this application.

[0019] Fifthly, embodiments of this application also provide a computer program product having a computer program / instruction stored thereon. When the computer program / instruction is executed by a processor, it is used to implement the data query method described in the first aspect or any specific implementation of the first aspect of the embodiments of this application.

[0020] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0021] This application embodiment transforms multiple business object identifiers into data query tasks that can be scheduled in parallel at the current level. This allows data query operations for different business objects to be executed synchronously on multiple computing nodes. Compared to the single-chain recursive query method of relational databases in the prior art, this significantly reduces the query pressure on a single node. Furthermore, this application embodiment utilizes distributed computing services to execute data query tasks in at least one database that matches the business object identifier. This allows for automatic selection of suitable data sources based on different business objects, achieving task distribution across database types and improving resource utilization in multi-source heterogeneous data environments. By obtaining the execution results of the current level's data query tasks and generating the next level's data query tasks based on the sub-business object identifiers in the execution results, the task composition of the next level can be adjusted in real time during the computation process based on the query results. This results in higher accuracy and completeness of the final constructed business object topology data. Compared to the closed-loop query method of graph databases that expands all levels of data downwards at once, this application embodiment effectively avoids problems such as excessive memory consumption and CPU peak overload caused by loading a large amount of data at once. By using a layered and batch query approach, the resource consumption of a single computation is reduced, thereby improving the stability of business object topology analysis. Attached Figure Description

[0022] Figure 1 A schematic diagram of a system architecture provided for an embodiment of this application;

[0023] Figure 2 This is a schematic flowchart of a data query method provided in an embodiment of this application;

[0024] Figure 3 A schematic diagram of a data query method based on the state of a business object provided in this application embodiment;

[0025] Figure 4 This application provides a schematic diagram of a distributed computing service task distribution and scheduling process in accordance with an embodiment of the present application.

[0026] Figure 5 A schematic diagram of the business processing flow of a layer recursive is provided for an embodiment of this application;

[0027] Figure 6This is a schematic diagram of another data query method provided in an embodiment of this application;

[0028] Figure 7 This is a schematic diagram of a data query device provided in an embodiment of this application;

[0029] Figure 8 This is a schematic diagram of a computer device structure provided in an embodiment of this application. Detailed Implementation

[0030] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0031] The method provided in this application embodiment can be applied to, for example, Figure 1 In the system architecture shown, terminal 102 communicates with server 101 via a network, and data storage system 100 stores data that server 101 needs to process or requires. Data storage system 100 can be integrated onto server 101 or located in the cloud or on other network servers. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices, such as smartwatches, smart bracelets, and head-mounted devices. Server 101 can be implemented using a standalone server or a server cluster composed of multiple servers. In this embodiment, data storage system 100 can be a standalone physical storage server, a distributed storage system composed of multiple storage nodes, or a cloud storage system providing services such as object storage, relational databases, cache databases, cloud databases, and cloud storage. For example, data storage system 100 can be implemented using a combination of relational databases (such as PostgreSQL), graph databases (such as Neo4j), or key-value cache databases (such as Redis). The specific type of data storage system 100 can be flexibly configured according to the actual deployment environment and business needs, but is not limited to the examples described above.

[0032] Terminal 102 can act as a requesting end, receiving topology data query results, task execution status and related feedback information returned by server 101.

[0033] Server 101 is equipped with a corresponding distributed computing service module, which is used to execute the data query method provided in this application. Specifically, it responds to data query requests, parses business object identifiers, generates hierarchical data query tasks, calls the distributed computing service to execute queries in parallel across different databases, and constructs business object topology data based on the query results at each level. The server can return the generated business object topology structure, query details at each level, or visualized business object topology data to terminal 102, enabling the presentation of query results, business analysis, or subsequent application calls.

[0034] It should be noted that the method provided in this application can be executed independently on the server side, independently on the terminal device side, or jointly by the terminal device and the server. For example, the terminal can perform partial parsing and preprocessing of business object identifiers locally, while the server performs distributed queries and topology construction across databases. Figure 1 The system architecture shown in the embodiments is intended to more clearly illustrate the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0035] The method of this application will be further described in detail below, and some specific possible implementation examples will be provided. Embodiments of this application provide a data query method, such as... Figure 2 As shown, the method includes steps S201-S203.

[0036] S201: Respond to the data query request and obtain the identifiers of multiple business objects carried in the data query request;

[0037] In this embodiment, the data query request can be triggered by a terminal device, an upstream business system, or a scheduled task. The data query request contains at least one business object identifier, and these multiple business object identifiers can correspond to different business dimensions (such as materials, components, equipment, personnel, orders, tasks, etc.). Each business object identifier can take the form of a Universally Unique Identifier (UUID), a code generated based on preset rules, or a composite identifier formed by combining business fields. For example, the business object identifier for a material object can be an identifier generated by combining the material code and the specification code, and the business object identifier for an equipment object can be the equipment asset number or an identifier calculated using a hash algorithm.

[0038] S202: Generate a data query task for the current level based on multiple business object identifiers, and submit the data query task for the current level to the distributed computing service to execute the data query task in parallel in at least one database that matches the business object identifier;

[0039] Since data from different business objects can be stored in relational databases and / or graph databases, and these two types of databases are suitable for handling real-time transaction data and archived relational data, respectively, it is necessary to determine the corresponding data query method based on the data storage mode to which the business object identifier belongs. For example, real-time master data queries can be performed using a structured query language, or archived relational queries can be performed using graph query statements. Therefore, this application embodiment determines the corresponding data storage mode based on each business object identifier, and constructs a data query task for the current level that includes the target database type and query statement parameters. Then, all data query tasks constructed at this level are uniformly submitted to the distributed computing service.

[0040] After receiving a data query task, the distributed computing service splits multiple data query tasks at that level into multiple task streams according to its internally configured multi-task distribution strategy, and pushes them to their respective database access channels. This allows each task to independently initiate a query on its corresponding database type. In this way, multiple business objects within the same level can simultaneously trigger multiple database queries without blocking each other. This enables enterprise data systems to leverage the multi-task scheduling capabilities within the distributed computing service to achieve parallel execution of data query tasks at the current level, thereby significantly improving the processing capacity for deep-level queries on large-scale business objects.

[0041] S203: Obtain the execution result of the data query task at the current level, and determine the data query task at the next level based on the sub-business object identifier contained in the execution result; wherein, the data query task at the next level is executed in parallel through the distributed computing service until the preset stopping condition is met, then stop generating the data query task at the next level, and generate and output business object topology data according to the execution results of the data query tasks at each level.

[0042] Here, the sub-business object identifier refers to the identifier of the downstream or derived business object entity that the current-level business object identifier points to in the data query results. For example, in an asset management system, a sub-business object of a device object may be its project, procurement contract, or maintenance record. After the current-level data query task is completed, sub-business object identifiers that have a relationship with the previous-level business object identifier are extracted from the execution results of each task. These sub-business object identifiers are regarded as candidate starting points for the next level, thereby determining the target sub-business object identifier for generating data query tasks at the next level. Based on this, following a similar approach to step S202, a new set of data query tasks is generated for the target sub-business object identifiers at the next level, and submitted to the distributed computing service for parallel execution. This process is repeated cyclically to realize the business object topology data query process that recursively expands from multiple business object identifiers in the initial data query request to deeper levels.

[0043] Furthermore, to manage the results of task processing at each level, this embodiment of the application includes two functional modules within the system: a graph data collector and a graph data assembler. The graph data collector works in conjunction with the distributed computing service. After each level of data query task is completed, the distributed computing service uniformly feeds back the task processing results of the current level (including sub-business object identifier sets, relationship categories, weight parameters, loop detection results, etc.) to the graph data collector. The graph data collector records and stores the received data according to hierarchical order and relationships.

[0044] After all data query tasks at all levels have been completed, or after any preset stopping condition is met (such as the query depth reaching the upper limit, no new sub-business objects being added, the query volume reaching the threshold, or the utilization rate of resources such as CPU or memory reaching the safety line), the graph data assembler begins to pull the business object topology data that has been stored hierarchically from the graph data collector, and merges, links, and structurally assembles the nodes and their relationships at different levels. The graph data assembler can employ various assembly algorithms as needed, such as hierarchical node merging algorithms (which deduplicate, merge, and hierarchically organize business object nodes returned by different tasks at the same level), node expansion algorithms (which start from a node and expand its associated nodes to the upper or lower levels, thereby completing the parent-child relationships between nodes), or parallel assembly algorithms (which distribute the topology data generated by different levels or tasks to multiple computing threads or nodes to perform assembly operations in parallel). In some scenarios, to improve processing performance, the graph data assembler can also simultaneously advance the assembly in two directions—upward (N-1 layers) or downward (N+1 layers)—based on randomly selected N layers of nodes, to accelerate the construction of the overall business object topology network. Finally, the graph data assembler submits the complete or partially assembled topology network structure to the graph output structure unit, which retrieves the constructed relationship graph or subgraph from the graph data assembler and outputs it to the display interface synchronously or asynchronously. For example, it can output a complete business object topology diagram, a local dependency subgraph of a specified object, a loop structure diagram, or a hierarchical relationship unfolding diagram, so that users can perform visual analysis, risk insight audit, or business tracing.

[0045] Considering that business objects are stored in different types of databases as their lifecycle progresses, business objects that are active or frequently changing and updated are typically stored in relational databases to support high-frequency transaction processing. After business objects are historically documented or archived, their relationship structures can be migrated or synchronized to a graph database for subsequent traversal and analysis of relationships. In large-scale business scenarios, if queries on multiple business objects are still uniformly executed from the same type of database without differentiation, it will result in centralized queries on all business objects using the same database, leading to excessive database connection pressure. This will affect the normal access to transactional and archived data, and may even cause resource contention and query timeouts, thus posing risks to the stability and data consistency of the enterprise data system. Therefore, in one embodiment, step S202 of this application embodiment generates a data query task at the current level based on multiple business object identifiers, and submits the data query task at the current level to a distributed computing service to execute the data query task in parallel in at least one database matching the business object identifier. This includes: obtaining status information of multiple business object identifiers; grouping multiple business object identifiers according to the status information; determining the database type and data query method applicable to each business object identifier based on each group to construct a data query task for each business object identifier at the current level; if the status information of the business object identifier indicates a non-archived state, then configuring the data query task of the business object identifier to be executed in a relational database; if the status information of the business object identifier indicates an archived state, then configuring the data query task of the business object identifier to be executed in a graph database.

[0046] In practical applications, each business object stores a field in the master data table or related business tables to characterize its current lifecycle status, such as archived or non-archived status. This status information can be maintained by the enterprise data system when a business object is changed, migrated, or archived. When a data query request containing multiple business object identifiers is received, the status field corresponding to each business object identifier is read sequentially to obtain a set of status information corresponding one-to-one with that batch of business object identifiers.

[0047] Please refer to Figure 3The flowchart shown illustrates a data query method based on business object status. After obtaining the status information of multiple business object identifiers, these identifiers are grouped according to their status information. For example, business object identifiers with the same status information or that meet the same classification rules can be grouped into the same group. For instance, business object identifiers with a non-archived status can be grouped into the first group, and those with an archived status into the second group. Further subdivision into multiple groups is also possible as needed. This grouping operation merges business object identifiers with the same data storage mode, allowing for a unified determination of the applicable database type and data query method for each group, reducing redundant judgments and improving the efficiency of data query task generation.

[0048] After grouping, the appropriate database type and data query method for each business object identifier are determined based on each group to construct the data query task for each business object identifier at the current level. For example, it may be determined that the group should be retrieved using Structured Query Language in a relational database or using Graph Query Language in a graph database. Then, based on the database type and query method of the group, a data query task containing the target database type, query statement or query template, and other execution parameters is generated for each business object identifier within the group. These data query tasks are then encapsulated into a set of data query tasks for the current level and submitted to the distributed computing service for parallel processing.

[0049] In the process of constructing the data query task described above, if the status information of the business object identifier indicates a non-archived state, then the data query task for that business object identifier is configured to be executed in a relational database. It can be understood that a non-archived state means that the business object is still in the online transaction, frequent update, or real-time query stage, and its master data is mainly stored in a relational database to meet the requirements of transaction consistency and real-time updates. Therefore, for such business objects, it is preferable to use Structured Query Language (SCL) to retrieve data in a relational database. When generating the corresponding data query task, a target relational database instance and corresponding structured query instructions are specified for the business object identifier, enabling the distributed computing service to directly access the latest business data when executing the task.

[0050] Accordingly, if the status information of a business object identifier indicates an archived state, the data query task for that business object identifier is configured to be executed in a graph database. An archived state means that the main attributes of the business object will no longer change frequently, and therefore it will be migrated or redundantly stored in a graph database to facilitate subsequent large-scale relational analysis and topology queries. Therefore, for business objects in the archived state, when constructing the data query task, the target database type will be set to a graph database, and query statements or graph traversal strategies adapted to graph databases will be used to quickly obtain multi-level relationship information of the business object in the graph database. In this way, the complex relational calculations of archived data are transferred to a database system more suitable for graph topology analysis, thereby reducing the pressure on the online relational database.

[0051] In generating data query tasks at the current level, this embodiment of the application can achieve a reasonable division of labor between relational databases and graph databases based on the status information of business object identifiers. Data in non-archived state is queried in the relational database, while data in archived state is used for large-scale relational topology queries in the graph database. This avoids excessive reliance on a single database and improves query adaptability in multi-source data environments. Furthermore, by adopting differentiated data query methods for business objects in different states, the data query task can access the latest business data while fully utilizing the retrieval advantages of graph databases in complex relationship analysis. This ensures the integrity of query results while improving the overall performance and scalability of business object data query and topology calculation.

[0052] Please refer to Figure 4 The diagram illustrates a task distribution and scheduling process based on a distributed computing service. This embodiment of the application uses a distributed computing service to uniformly decompose, schedule, and distribute data query tasks. Upon receiving a data query task at the current level, the distributed computing service first decomposes the overall data query task according to the business object identifier, forming multiple independently executable sub-query tasks. Then, these sub-query tasks are pushed to the task scheduling module of the distributed computing service. The task scheduling module distributes each sub-query task through multiple paths based on the internal task queue status, database connection pool status, and available execution resources. The distribution method can adopt a layer-by-layer scheduling mode, that is, distributing query tasks layer by layer from top to bottom according to the topology; or a multi-level scheduling mode for a single task, that is, continuously triggering multi-level queries for a certain business object within the same execution cycle to improve overall data query efficiency. This embodiment of the application does not limit the specific scheduling method and can be set according to the available system resources and business scenario requirements.

[0053] After the task is distributed, each execution node performs a query operation in the corresponding data source according to the database type specified in the data query task. For example, it retrieves real-time business data in a relational database using SQL, or retrieves archived data in a graph database using a graph query language (such as Cypher). Figure 4 The SQL query implementation and Cypher implementation shown correspond to the query execution process for different database types. Meanwhile, the task distribution module can synchronize data from some historical or archived business objects before executing data query tasks, redundantly writing important business relationship data into the graph database to enhance its retrieval capabilities; or it can split and archive historical data before writing it into the graph database to ensure that the graph database can provide fast queries of structured relationships, thereby improving the query efficiency of multi-level business object data.

[0054] Please refer to Figure 5 The diagram illustrates a business processing flow based on a layer recursor. In this embodiment, the distributed computing service uses a layer recursor to perform progressive calculations on the topological relationships of multi-level business objects. Specifically, upon receiving the nth-level business object identifier set from the recursion controller, the layer recursor inputs the current-level business object identifier and the corresponding layer number information (such as the nth-level business object identifier set) into the distributed computing service and triggers... Figure 4 The task distribution and scheduling process based on distributed computing services shown in the figure (in) Figure 5 The process involves obtaining the identifier of the nth-level business object, acquiring the state information of the business object, and then using the business object identifier and state to call the topology computing service to complete the data query. In this way, the distributed computing service will perform topology searches on all business objects involved in the current level in parallel. After completing all data query tasks within this level, the distributed computing service will send a computation completion event notification to the layer recursor.

[0055] Upon receiving the aforementioned event notification, the layer controller transmits the task processing result set returned by the distributed computing service at the current layer (e.g., the task processing result set at layer n) to the graph data collector. The graph data collector is responsible for structuring and organizing the relationship data of all business objects at this layer, including aggregating, normalizing, and storing sub-business object identifiers, relationship categories, and topology path information to build a complete layer-by-layer topology data foundation. Simultaneously, the layer recursive controller transmits all sub-business object identifiers and their layer information collected at the current layer to the recursive controller. The recursive controller analyzes and judges the sub-business object identifiers at this layer according to the pre-configured intervention algorithm strategy, and determines whether to filter, sample, weight, or remove some sub-business object identifiers based on the quantity characteristics, relationship categories, sampling weights, loop occurrences, and other control conditions to construct the business object identifier set for the next layer (e.g., the business object identifier set at layer n+1). The recursive controller returns the processed next-level business object identifier set to the layer recursive, which then uses the next-level business object identifier set as the starting point for the next round of data query tasks, thereby realizing the continuous iteration of the multi-level business object topology relationship until the preset stopping condition is met.

[0056] like Figure 6 As shown in the flowchart of another data query method provided in this application embodiment, its implementation architecture mainly includes modules such as a layer recursor, a multi-level subquery algorithm, an SQL query implementation, a Cypher query implementation, a query task, a distributed computing service, a multi-way task distribution, a relational data collector, a graph data assembler, and a graph output structure. The layer recursor is used to receive the initial business object identifier and starting level information from external input, and then pass the business object identifier of that level to the multi-level subquery algorithm module.

[0057] The multi-layer subquery algorithm receives the business object identifier from the layer recursive and, based on the metadata, relationship configuration, or preset database mapping rules of each business object, selects either an SQL query implementation or a Cypher query implementation to construct the corresponding data query task for that layer. Specifically, when the business object belongs to a data source stored in a relational database, the multi-layer subquery algorithm calls the SQL query implementation to generate the corresponding SQL query task; when the business object belongs to a data source stored in a graph database, the multi-layer subquery algorithm calls the Cypher query implementation to generate the corresponding graph query task.

[0058] Subsequently, the generated query tasks are submitted to the distributed computing service via the multi-task distribution module. The distributed computing service then distributes each query task to different database instances or computing nodes for parallel execution according to its internal scheduling strategy, thereby significantly improving the efficiency of querying business object topology data across multiple data sources. During the execution of data query tasks, the multi-task distribution module continuously monitors the task completion status and sends the task execution results back to the relational data collector.

[0059] The relational data collector receives and records all sub-business object identifiers and their associated relationship information obtained by each query task at the current level. It also detects potential loops, duplicate paths, and abnormal associated data, then feeds this information back to the recursive controller. The recursive controller sets intervention rules based on loop detection results, sub-business object sampling weights, and association categories to filter, weight, or sort the business object identifiers at the next level, thereby generating a set of business object identifiers for the next level. Upon receiving the set of business object identifiers for the next level from the recursive controller, the layer recursive controller triggers a new round of data queries, thus forming a layer-by-layer recursive business object data topology query process.

[0060] Figure 6 In this process, the graph data collector organizes the topology records uploaded by the relational data collector and transmits them to the graph data assembler. The graph data assembler then progressively assembles the task execution results from different levels into a complete multi-layered relational topology network. Finally, the graph output structure module obtains the fully constructed topology graph or partial subgraph from the graph data assembler and can output it synchronously or asynchronously to the display interface, monitoring platform, or external analysis system, enabling the visualization and analysis of multi-level relationships among business objects.

[0061] pass Figure 6 The overall process shown in this application embodiment realizes an automated process from task recursion, query execution, relationship collection to topology assembly and output. It can efficiently construct a query of complete business object topology data in a real business environment with multiple data sources, deep levels, and high connectivity, and ensure the accuracy, controllability, and scalability of business object topology data.

[0062] It's important to understand that in complex business object topology analysis scenarios, the query results at the current level often yield a varying number of sub-business object identifiers. The relationships between these sub-business object identifiers and the business object identifiers at the current level are diverse, including parent-child dependencies, composition relationships, reference relationships, and collaboration relationships. Current technologies typically use all sub-business object identifiers obtained from the query as input for the next round of topology queries. However, with large-scale business operations, when the number of sub-business objects returned at a certain level is exceptionally large, without filtering and processing, the data query tasks at the next level will expand exponentially. This will cause system memory or CPU resources to be rapidly occupied by a large number of redundant tasks, leading to problems such as execution queue blocking, excessive database connection usage, and severe query latency. Secondly, in real-world business scenarios, different types of relationships often have different values ​​and priorities in terms of business meaning. For example, in manufacturing scenarios, the relationship between a product and its key components is usually far more valuable for analysis than the relationship with packaging materials or shipping documents; similarly, in asset management systems, the relationship between equipment and its core maintenance records is more important than the relationship between equipment and general inspection operations. If the existing technology continues to treat all sub-business object identifiers equally, directly incorporating all obtained sub-business object identifiers into the next level of data query tasks without distinction, the main connections of high-value business object topology data may be submerged in a large number of secondary or noisy connections, causing a shift in the topology structure and failing to accurately reflect the main link dependencies between business objects, thereby reducing the business accuracy of the topology analysis results. Based on the above problems, in a feasible embodiment, for each execution result, the logical relationship or business dependency strength between each sub-business object and the current-level business object can be analyzed based on different characteristic dimensions of the multiple sub-business object identifiers in the topology analysis, such as the quantity of sub-business object identifiers, the level value of the current level, and the type of association between each sub-business object identifier and the current-level business object identifier.

[0063] For example, based on the different feature dimensions mentioned above and according to a preset intervention strategy, it can be determined whether and how each sub-business object identifier participates in the construction of the next level data query task. The intervention methods may include, but are not limited to, the following: for sub-business object identifiers whose relationship categories are relatively unimportant, numerous, or deeply hierarchical, their weight in entering the next level can be reduced, or they can even be excluded from the subsequent query scope, in order to reduce the further diffusion of unnecessary topological relationships; for sub-business object identifiers whose relationship categories are relatively important but appear too frequently, a weight reduction strategy can be implemented; conversely, for sub-business object identifiers that appear repeatedly and stably in multiple levels, their priority or sampling weight can be increased to enhance their representativeness.

[0064] After determining the identifiers of the target sub-business objects, a data query task for the next level is generated based on this set of target sub-business object identifiers. This data query task, generated based on the target sub-business object identifiers, is also submitted to the distributed computing service for parallel execution. In this way, each target sub-business object identifier serves as a new starting point for data querying, performing data query operations in its matched data source to obtain further associated sub-business objects, thereby expanding the topology between different business objects. Compared to a closed graph query method that obtains the entire path at once, this embodiment can drive the generation of data query tasks for the next level based on the execution results of the query task at the previous level, forming a progressive and adaptively adjustable multi-level data query structure. This allows for adjustments to the data query path for data query tasks at different levels, adaptively reducing data queries for business objects with relatively unimportant relationship categories, thereby effectively addressing the diverse data structures and complex relationship categories in large-scale business object networks and improving data processing efficiency.

[0065] In one embodiment, step S203 of this application, which involves determining the next-level data query task based on the sub-business object identifiers contained in the execution result, includes: if the number of sub-business object identifiers in each execution result exceeds a preset number threshold, then randomly sampling the sub-business object identifiers in the execution result to select a portion of the sub-business object identifiers as target sub-business object identifiers; and determining the next-level data query task based on the target sub-business object identifiers.

[0066] In this embodiment, the number of sub-business object identifiers contained in the execution result of the current level data query task is obtained. The number of sub-business object identifiers in each execution result is counted to determine the degree of diffusion of the association relationship of the current business object. On this basis, the number of sub-business object identifiers obtained by statistics is further compared with a preset number threshold. If the number exceeds the preset number threshold, it indicates that the current business object has the characteristics of being highly dispersed or having a large number of derivation relationships in its downstream association structure. If the large number of sub-business object identifiers in the execution result is not processed, the number of business objects that need to be processed in the topology recursion process may surge, and the data query task will also surge, thereby affecting the overall computing performance.

[0067] Once it is determined that the number of sub-business object identifiers exceeds a preset threshold, all sub-business object identifiers contained in the current execution result are randomly sampled to select a subset as target sub-business object identifiers. The random sampling process can employ either equal-probability sampling or a modified probability sampling method based on priority weights. Regardless of the mechanism used, the goal is to select a representative subset from a large number of sub-business object identifiers, ensuring that the number of data query tasks generated in the next level remains within a controllable range. For example, if a business object generates 100 sub-business object identifiers in the execution result, and the preset threshold is 30, then 30 sub-business object identifiers can be randomly sampled to enter the next stage of the data query task execution process, thereby effectively constraining the size of the sub-business object identifiers.

[0068] After completing the above random sampling process, the sampled sub-business object identifiers are used as target sub-business object identifiers to generate the next level of data query tasks. Each target sub-business object identifier can serve as the starting point for the next level of query, thus continuing the recursive query operation at the next level.

[0069] This application embodiment, through random sampling, can effectively filter potentially large-scale data in the early stages of data querying, preventing the business object topology data space from expanding indefinitely, reducing the number of parallel tasks, and alleviating the overall computational pressure on the system. Compared to a completely uninterrupted processing method, this application embodiment can proactively control the scale of sub-business object identifiers, improving the utilization efficiency of distributed query resources, and making the data query and business object relationship topology construction process more controllable and stable.

[0070] It is worth noting that in existing technologies, when performing multi-level business object data queries using recursive or graph database methods, a large number of deep-level sub-business objects with decreasing relevance to the initial query object are often retrieved as the hierarchy deepens. Because the connection paths between these deep-level sub-business objects and the initial query object are long, their business value and analytical significance typically diminish with increasing hierarchy. However, traditional topology algorithms often employ an indiscriminate query strategy, including all sub-business objects at all levels in the next level's data query task. This leads to the continuous accumulation of irrelevant or weakly related sub-business objects during the data query process, resulting in meaningless data queries. Especially in high-connectivity scenarios such as product structure analysis, equipment tree expansion, supply chain correlation, and multi-level accounting dependencies, the number of nodes in later levels often grows exponentially. If indiscriminate queries are still performed as in traditional solutions, it can easily lead to data query stagnation or timeouts. Therefore, in one embodiment, step S203 of this application, which involves determining the next-level data query task based on the sub-business object identifier contained in the execution result, includes: for each execution result of the current level, determining the sampling weight of each sub-business object identifier according to the level value of the current level and a preset weight adjustment function; performing weighted sampling processing on the sub-business object identifier based on the sampling weight of each sub-business object identifier to obtain the target sub-business object identifier; and determining the next-level data query task based on the target sub-business object identifier.

[0071] For each execution result at the current level, the sampling weight of each sub-business object identifier within the current level is first determined based on the level value of the current level and a preset weight adjustment function. The weight adjustment function can be a function model related to the level value, such as a power function or an exponential function. The weight adjustment function controls the magnitude of the change in the sampling weight as the level value increases; for example, the sampling weight decreases progressively with increasing level; or it increases progressively with increasing level. For example, in one feasible implementation, if the sampling weight is calculated using a power function, the formula can be expressed as: W(n) = W0 ÷ ((1+n)) a ), where n represents the level value of the current level; W(n) represents the sampling weight when the current level is n; W0 represents the initial weight; a represents the preset weight adjustment coefficient, for example, a>0, then the weight decreases as n increases; a<0, then the weight increases as n increases; the specific value can be set according to the number of branches of the business object level expansion, the expected decrease or increase of the sampling weight of the deep-level sub-business object identifier, and this application embodiment does not limit this. In another feasible implementation, if the sampling weight is implemented according to the exponential function, the formula can be expressed as: W(n)=W0×b n; where n represents the level value of the current level; W(n) represents the sampling weight when the current level is n; W0 represents the initial weight; b represents a preset weight adjustment coefficient. For example, if 0 < b < 1, the weight decreases as n increases; if b > 1, the weight increases as n increases. The specific value can be set according to the number of branches expanded by the business object level, the decreasing or increasing amplitude of the sampling weight expectation for the deep-level sub-business object identifier. The embodiments of this application do not limit this. In actual applications, the level value n of the sub-business object identifier at the current nth level can be used as the independent variable input of the weight adjustment function, and the sampling weight of the business object identifier at this level can be calculated in combination with the function parameters.

[0072] Based on the sampling weights of each sub-business object identifier at the determined current level, weighted sampling processing can be performed on all sub-business object identifiers within the current level. Weighted sampling means that among all candidate sub-business object identifiers, the extraction probability is determined according to the relative size of their sampling weights, so as to probabilistically select representative target sub-business object identifiers, ensuring that objects with higher sampling weights have a greater probability of entering the data query task of the next level and improving the data query efficiency. Taking the automotive component map as an example, for instance, the first level is the whole vehicle, the second level is the body, power system, chassis system, etc. Suppose the current level is the power system, and its subordinate sub-objects include the engine, transmission, drive shaft, turbocharger, etc. Since the engine is a key component with high importance in business analysis, the sampling weight of the engine should be higher than that of the turbocharger, and the probability of being selected in weighted sampling should also be greater. In this way, the data scale of the data query can be controlled without losing key information.

[0073] In one embodiment, step S203 of this application for determining the data query task of the next level based on the sub-business object identifiers included in the execution result includes: obtaining the association relationship categories between the business object identifier and each sub-business object identifier at the current level; for each association relationship category, obtaining the weight adjustment coefficient corresponding to the association relationship category at the current level; based on the level value and weight adjustment coefficient of the current level, calculating the category weight of the association relationship category at the current level; based on the category weight, determining the sampling weights of each sub-business object identifier with an association relationship category at the current level; according to the sampling weights, performing weighted sampling processing on the sub-business object identifiers to respectively obtain the target sub-business object identifiers under each association relationship category; according to the target sub-business object identifiers, determining the data query task of the next level.

[0074] In this embodiment, the association categories can be divided into types such as "composed of," "dependent on," and "driven by." In actual databases, these association categories can be set through foreign keys, attribute fields, edge attributes, etc. For example, in an automotive graph, the relationship between the battery and the electric drive system is a "power supply" association category, while the relationship between the motor housing and the motor is a "composed of" association category. The business semantics between these two association categories are quite different. Therefore, for each association category, it is necessary to obtain the corresponding weight adjustment coefficient based on the current level. It can be understood that the weight adjustment coefficient in this embodiment is used to quantify the importance of different association categories at different levels. The specific value can be set based on the number of branches extended in the business object hierarchy, the expected decrease or increase in the sampling weight of the deep-level sub-business object identifier, etc. This embodiment does not limit this; for example, the weight adjustment coefficient of "composed of" this association category can be lower than that of "dependent on" this association category.

[0075] Based on the current level value and the aforementioned weight adjustment coefficient, the category weight of the relationship category at the current level can be further calculated. For example, the current level value can be denoted as n, the relationship category as c, and the category weight as W(n, c). The category weight can then be calculated using the following formula: W(n, c) = K(c) × F(n), where K(c) represents the weight adjustment coefficient corresponding to the relationship category c. The specific value of K(c) can be configured according to the importance of the relationship category in the business scenario, and this embodiment does not limit this. F(n) represents the weight adjustment function related to the level value, and the specific form of F(n) can refer to the weight adjustment function used in the aforementioned embodiment.

[0076] Continuing with the example of a car's chassis system, assuming the current level n=2, there are three types of sub-business objects: suspension, shock absorbers, and stabilizer bars. These constitute three different semantic relationships. For example, the relationship between the suspension and the chassis system is a primary component relationship, with a weight adjustment coefficient a=0.8; the relationship between the shock absorbers and the chassis system is an auxiliary support relationship, with a weight adjustment coefficient a=1.2; and the relationship between the stabilizer bars and the chassis system is an auxiliary connection relationship, with a weight adjustment coefficient a=1.5. Therefore, the category weights can be obtained by substituting these values ​​into the weight adjustment function F(n).

[0077] Alternatively, in a relationship analysis scenario, taking personnel relationship topology as an example, in this scenario, the initial input is n target personnel. In the first level, the system retrieves the set of all personnel directly associated with these n personnel, denoted as m sub-objects. In the second level, different sampling weights are assigned to each relationship category (e.g., siblings, relatives, friends) to reflect the importance of different relationship categories at the current level; for example, these weights could be set to 100%, 80%, and 50%. Upon entering the third level, the system further filters the sample size for each type of relationship based on the previous level and adjusts it according to the weight decay rules for each relationship at deeper levels. For example, the sampling weight for siblings is decayed to 95%, relatives to 60%, and friends to 45%. As the hierarchy deepens, when the number of candidates at a certain level grows to a significant scale (e.g., reaching a preset value of x), the relationship category itself may no longer be the focus of topology analysis. At this point, the system can introduce noise enhancement or random noise enhancement to assign lower and closer sampling weights to various relationships, such as 15% for cousins, 10% for relatives, and 5% for friends, to reduce the influence of non-key topology paths while retaining representative child node samples. The system then continues iterating to the next level, performing topology expansion at level N+1 until there are no more samples available for expansion or a preset stopping condition is met.

[0078] In certain specific business scenarios, sampling weights do not necessarily decrease unidirectionally with increasing hierarchy; in fact, sampling weights may increase progressively with increasing hierarchy. For example, in the multi-level structure of automotive parts, suppose the current data query task is processing the hierarchy corresponding to the body system. The body system typically contains a large number of sub-components, such as doors, windows, and side panels, and these components have highly homogeneous business attributes, all belonging to body structural parts. In this case, even performing a full analysis of all sub-components would hardly significantly improve the business understanding of the body structure. Therefore, this embodiment can use the weight adjustment coefficient corresponding to the association category between the next-level sub-business object identifier and the previous-level business object to set a lower sampling weight, sampling only a small portion of representative structural parts, thereby reducing the computational scale of the current hierarchy. However, in subsequent levels, some sub-business object identifiers from the previous level may reveal sub-objects with more significant differences in business characteristics. For example, a car door might be further broken down into sub-components such as the door frame, interior trim panels, glass guide channels, lifting mechanisms, and anti-collision beams. These sub-components differ in materials, processes, and functions. If the sampling weights from the previous level are still used to reduce the sample size, the topological data on the actual structure of the car door system may be inaccurate. Therefore, in this deeper level, the sampling weights can be increased by using the weight adjustment coefficients corresponding to the association categories between the sub-business object identifiers of the next level and the business objects of the previous level. This increases the number of samples that need to be collected, ensuring that valuable business object topological data can be fully extracted from the sub-components at this level.

[0079] Finally, based on the sampling weight of each sub-business object identifier, weighted sampling is performed to obtain the target sub-business object identifier under each relationship category, which is used to generate the next level of data query tasks. Each target sub-business object identifier can serve as the starting point for the next level of query, allowing for recursive query operations to continue at that level. This not only reasonably controls the number of sampled objects, preventing the business object topology data from becoming too large, but also retains representative sub-business objects under different relationship categories, ensuring the integrity of important relationship data and thus improving the accuracy of the overall business object topology data analysis.

[0080] In real-world business object relationship networks, due to the complex many-to-many relationships between various business entities, various explicit or implicit loops can easily form between actual business objects. For example, in the product structure tree of a manufacturing company, components may be incorrectly configured as their own ancestor nodes; in the supply chain, there may be circular transaction relationships between company A and company B; and in the equipment maintenance link, work orders may repeatedly point to duplicate records of the same source object, thus forming loops. Considering that the different loop structures mentioned above may have different business semantics and topological relationship values ​​in different scenarios, in one embodiment, the next-level data query task is determined based on the sub-business object identifiers contained in the execution result. This includes: if a loop composed of sub-business object identifiers is detected based on the execution result, then a sampling weight adjustment strategy for the sub-business object identifiers on the loop path is determined according to the frequency of occurrence of the loop in different levels and the association category between the sub-business object identifiers in the loop and the business object identifiers of the current level; the sampling weights of the sub-business object identifiers are adjusted according to the sampling weight adjustment strategy, and the sub-business object identifiers are weighted and sampled based on the adjusted sampling weights; the final target sub-business object identifier is determined based on the sub-business object identifiers processed by the selected intervention method, and the next-level data query task is determined based on the target sub-business object identifier.

[0081] After obtaining the execution results of the data query task at the current level, structural analysis can be performed on the sub-business object identifiers contained in the results to identify whether there are loops consisting of dependency paths between multiple sub-business object identifiers. Loop detection can be achieved using graph traversal algorithms, such as depth-first search or topological sorting to detect back edges. In the business structure graph, if a sub-business object identifier reappears in the current path, and its path can be traced back to itself or the same business parent node, it can be considered as forming a loop. Loops may reflect circular dependencies, duplicate references, or abnormal data configurations in the business process, and therefore require special handling to avoid subsequent queries entering infinite loops or repeatedly calculating paths.

[0082] After detecting a loop, it's necessary to further evaluate its frequency of occurrence across different levels, serving as a crucial basis for determining its query importance. The frequency of occurrence across levels can be statistically analyzed by maintaining path context records, which record the cumulative number of times a loop is referenced in a path chain involving a specific business object identifier. Simultaneously, the type of association between the sub-business object identifiers within the loop and the current-level business object identifier can be considered, such as composition, dependency, or reference relationships, to assess the loop's significant business value. Through cross-analysis of these two dimensions, a sampling weight adjustment strategy is constructed to differentiate the handling of object identifiers within loop paths.

[0083] According to this sampling weight adjustment strategy, the sampling weights of the sub-business object identifiers constituting the loop path will be dynamically adjusted. Specifically, if a loop frequently recurs and the objects within it are only weakly related, the sampling weight of the sub-objects in that path can be reduced, thereby decreasing their selection probability in the next level. Conversely, if the loop contains strongly semantically related categories, its sampling weight can be increased to ensure it is displayed as a representative data in the business object topology data. It should be noted that the importance of the related category in terms of business semantics can be assigned different weights to the same related category by different enterprise systems and different business scenarios. For example, in a product structure topology scenario, principal component relationships are usually more important, while in a supply chain risk analysis scenario, financial transaction relationships may be more important. Therefore, the strategy of strengthening or weakening the sampling weight based on the frequency of loop occurrence and the related category in this application embodiment is not limited to a fixed level division of specific relationship categories, but can be flexibly configured according to business needs. For example, the priority or importance of various related relationships can be pre-set through a rule base, weight mapping table, or adaptive weight learning model.

[0084] Next, based on the adjusted sampling weights, weighted sampling is performed on the candidate set of sub-business object identifiers to select a set of target sub-business object identifiers that meet the intervention strategy requirements. Weighted sampling can be implemented using algorithms such as roulette wheel sampling, alias sampling, or stratified sampling to control the scale of business object topology data diffusion. Taking an automotive structure map as an example, if a wheel component is found to repeatedly point back to a frame node in the chassis system path, it will be determined whether this loop path is a reasonable configuration due to design changes or an abnormal reference. Based on the composition and association categories, it can be determined that it should be assigned a lower sampling probability, thereby controlling the generation of redundant data during subsequent business object sampling. Finally, the selected target sub-business object identifiers are used as objects for the next level of data query tasks, generating and submitting subsequent parallel query tasks.

[0085] Furthermore, the above-mentioned strategy for adjusting the sampling weight of sub-service object identifiers on the loop path is determined based on the frequency of the loop's occurrence across different levels and the association category between the sub-service object identifier in the loop and the service object identifier at the current level. Specifically, this includes: if the frequency of the loop's occurrence in the preceding level reaches a preset repetition threshold, the sampling weight of the sub-service object identifier corresponding to the loop is adjusted to zero; if the frequency of the loop's occurrence in the preceding level does not reach the preset repetition threshold, the sampling weight is adjusted to a non-zero value based on the frequency of the loop's occurrence and the association category between the sub-service object identifier in the loop and the service object identifier at the current level.

[0086] Please refer to the following example for understanding: If the same loop appears consecutively in multiple preceding levels, and its frequency reaches a preset repetition threshold, it indicates that the loop may be an invalid loop caused by data quality issues, incorrect model configuration, or abnormal business data. For example, in a supply chain scenario, if part A repeatedly depends on its sub-part B, and B in turn depends on A, and this meaningless loop continues to occur in consecutive multi-level topologies, then the loop has almost no actual business value and will not constitute a true bill of materials structure. In this case, the sampling weight of the sub-business object identifier corresponding to the loop can be adjusted to zero. By interrupting the loop by adjusting the weight to 0, it will no longer enter the data query task of the next level, thereby completely blocking the propagation of invalid loops. This also eliminates the need to recalculate the already generated preceding topology, avoiding additional rollback costs.

[0087] If a loop appears in a previous level but has not yet reached the repetition threshold, then the sampling weights of the relevant sub-business object identifiers need to be adjusted to be non-zero based on the frequency of the loop's occurrence and its relationship category. This allows for dynamic control of loop strengthening or weakening. For example, in a financial risk analysis scenario, if a closed loop exists where Company A borrows from Company B, and Company B then borrows from Company A, and this loop appears only once in a previous level and again in the current level, it indicates that this loop may represent potential risky behavior, such as idle funds or hidden related-party transactions. Since lending relationships are a highly business-sensitive relationship category, when the loop reappears, the sampling weights of the relevant objects along the loop path should be increased. This allows for priority retention of such objects in the next level, strengthening the loop and facilitating further in-depth analysis of its underlying financial risk chain.

[0088] Conversely, in product structure analysis scenarios, for example, a car component X might be incorrectly recorded as referencing its upstream component Y under certain data redundancy conditions, where Y contains X. Such reverse references are typically weak associations caused by data redundancy or multi-source integration. When such loops occasionally appear in the preceding hierarchy, since their business significance is weak, the sampling weight of the sub-business object identifiers on the loop path can be reduced, making them less likely to be included in the data query task in the next level. This achieves loop reduction processing, preventing non-critical loops from having an excessively expanded impact on the business object topology data. Specific reduction strategies can be found in the aforementioned embodiments, and will not be repeated here.

[0089] Through the different weight adjustment methods described above, the embodiments of this application can not only identify and interrupt duplicate and invalid technical loops, but also strengthen and retain key loops or weaken weakly related loops according to the actual value of different business scenarios, thereby realizing a business object topology data query strategy for different business semantics and ensuring the accuracy of business object topology data.

[0090] To implement the data query method of this application embodiment, this application embodiment also provides a data query device, such as... Figure 7 As shown, the device includes:

[0091] The request parsing unit 701 is used to respond to a data query request and obtain multiple business object identifiers carried in the data query request.

[0092] The task generation and distribution unit 702 is used to generate a data query task at the current level based on the multiple business object identifiers, and submit the data query task at the current level to the distributed computing service to execute the data query task in parallel in at least one database that matches the business object identifier.

[0093] The iterative processing unit 703 is used to obtain the execution result of the data query task at the current level, and determine the data query task at the next level based on the sub-business object identifier contained in the execution result; wherein, the data query task at the next level is executed in parallel by the distributed computing service until a preset stopping condition is met, then the generation of the data query task at the next level is stopped, and business object topology data is generated and output according to the execution results of the data query tasks at each level.

[0094] In one embodiment, the task generation and distribution unit 702 is specifically configured to: obtain status information of multiple business object identifiers; group the multiple business object identifiers according to the status information; determine the database type and data query method applicable to each business object identifier based on each group, so as to construct a data query task for each business object identifier at the current level; if the status information of the business object identifier indicates a non-archived state, then configure the data query task of the business object identifier to be executed in a relational database; if the status information of the business object identifier indicates an archived state, then configure the data query task of the business object identifier to be executed in a graph database.

[0095] In one embodiment, the iterative processing unit 703 is specifically used to: if the number of sub-business object identifiers in each execution result exceeds a preset number threshold, randomly sample the sub-business object identifiers in the execution result to select a portion of the sub-business object identifiers as target sub-business object identifiers; and determine the next level of data query task based on the target sub-business object identifiers.

[0096] In one embodiment, the iterative processing unit 703 is specifically configured to: for each execution result of the current level, determine the sampling weight of each sub-business object identifier based on the level value of the current level and a preset weight adjustment function; perform weighted sampling processing on the sub-business object identifier based on the sampling weight of each sub-business object identifier to obtain a target sub-business object identifier; and determine the data query task of the next level based on the target sub-business object identifier.

[0097] In one embodiment, the iterative processing unit 703 is specifically configured to: obtain the association category between the business object identifier and each sub-business object identifier in the current level; for each association category, obtain the weight adjustment coefficient corresponding to the current level and the association category; calculate the category weight of the association category in the current level based on the level value of the current level and the weight adjustment coefficient; determine the sampling weight of each sub-business object identifier in the current level that has the association category based on the category weight; perform weighted sampling processing on the sub-business object identifier according to the sampling weight to obtain the target sub-business object identifier under each association category; and determine the data query task of the next level based on the target sub-business object identifier.

[0098] In one embodiment, the iterative processing unit 703 is specifically configured to: if a loop consisting of sub-business object identifiers is detected based on the execution result, determine a sampling weight adjustment strategy for the sub-business object identifiers on the loop path based on the frequency of occurrence of the loop at different levels and the association category between the sub-business object identifiers in the loop and the business object identifiers at the current level; adjust the sampling weight of the sub-business object identifiers according to the sampling weight adjustment strategy, and perform weighted sampling processing on the sub-business object identifiers based on the adjusted sampling weights; determine the final target sub-business object identifier based on the sub-business object identifiers processed by the selected intervention method, and determine the data query task at the next level based on the target sub-business object identifier.

[0099] In one embodiment, the iterative processing unit 703 is specifically configured to: if the frequency of occurrence of the loop in the preceding layer reaches a preset repetition threshold, adjust the sampling weight of the sub-service object identifier corresponding to the loop to zero; if the frequency of occurrence of the loop in the preceding layer does not reach the preset repetition threshold, adjust the sampling weight to a non-zero value based on the frequency of occurrence of the loop and the association category between the sub-service object identifier in the loop and the service object identifier of the current layer.

[0100] It should be noted that the data query device provided in the above embodiments is only illustrated by the division of the above program modules. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program modules to complete all or part of the processing described above. In addition, the data query device and data query method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0101] Based on the hardware implementation of the above program modules, and in order to implement the data query method provided in this application embodiment, this application embodiment also provides a computer device, such as... Figure 8 As shown, the computer device 800 includes:

[0102] Processor 801, memory 802, and input / output interface 803;

[0103] The memory 802 is a short-term storage memory or a persistent storage memory;

[0104] The processor 801 is configured to communicate with the memory 802 and execute instructions in the memory 802 to perform any of the above data query methods.

[0105] Of course, in practical applications, the various components in the computer device 800 are coupled together through a bus system 804. It is understood that the bus system 804 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 804 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 8 The general labeled all buses as Bus System 804.

[0106] The memory 802 in this embodiment is used to store various types of data to support the operation of the computer device 800. Examples of such data include any computer program used to operate on the computer device 800.

[0107] It is understood that when the processor in the computer device described above executes the computer program, it can also realize the functions of each unit in the corresponding device embodiments described above, which will not be repeated here. Exemplarily, the computer program can be divided into one or more modules / units, one or more modules / units are stored in memory and executed by the processor to complete the various embodiments of this application. One or more modules / units can be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the computer device. For example, the computer program can be divided into units in the aforementioned computer device, and each unit can implement the specific functions described in the corresponding computer device above.

[0108] Computer equipment can be desktop computers, laptops, handheld computers, and cloud servers, among other computing devices. Computer equipment may include, but is not limited to, processors and memory. Those skilled in the art will understand that processors and memory are merely examples of computer equipment and do not constitute a limitation on the computer equipment. It may include more or fewer components, or combinations of certain components, or different components. For example, computer equipment may also include input / output devices, network access devices, buses, etc.

[0109] A processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of a computer device, connecting all parts of the computer device through various interfaces and lines.

[0110] Memory can be used to store computer programs and / or modules. The processor performs various functions of the computer device by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can primarily include a program storage area and a data storage area. The program storage area can store the operating system, at least one application program required for a function, etc.; the data storage area can store data created based on terminal usage, etc. Furthermore, memory can include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital cards (SD), flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0111] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, performs any of the data query methods described above.

[0112] This application also provides a computer program product that stores a computer program / instruction thereon. When the computer program / instruction is executed by a processor, it is used to implement the data query method described in the first aspect or any specific implementation of the first aspect of this application.

[0113] Those skilled in the art will readily understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces, indirect couplings or communication connections between devices or units, and may be electrical, mechanical, or other forms.

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

[0115] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

Claims

1. A data query method, characterized in that, include: In response to a data query request, obtain multiple business object identifiers carried in the data query request; A data query task for the current level is generated based on the multiple business object identifiers, and the data query task for the current level is submitted to the distributed computing service to execute the data query task in parallel in at least one database that matches the business object identifier; The execution result of the current level data query task is obtained, and the next level data query task is determined based on the sub-business object identifier contained in the execution result. The next level data query task is executed in parallel by the distributed computing service until a preset stopping condition is met. Then, the generation of the next level data query task is stopped, and business object topology data is generated and output according to the execution results of the data query tasks at each level.

2. The method according to claim 1, characterized in that, The step of generating a data query task for the current level based on the multiple business object identifiers and submitting the data query task for the current level to a distributed computing service to execute the data query task in parallel in at least one database matching the business object identifiers includes: Obtain the status information of multiple business object identifiers; Group the multiple business object identifiers according to the status information; Based on each group, determine the applicable database type and data query method for each business object identifier, so as to construct the data query task for each business object identifier at the current level; If the status information of the business object identifier indicates a non-archived status, then the data query task of the business object identifier will be configured to be executed in a relational database; If the status information of the business object identifier indicates an archived status, then the data query task of the business object identifier will be configured to be executed in the graph database.

3. The method according to claim 1, characterized in that, The step of determining the next-level data query task based on the sub-business object identifier contained in the execution result includes: If the number of sub-business object identifiers in each execution result exceeds a preset threshold, then the sub-business object identifiers in the execution result are randomly sampled to select a portion of the sub-business object identifiers as target sub-business object identifiers. Based on the target sub-business object identifier, determine the next level of data query task.

4. The method according to claim 1, characterized in that, The step of determining the next-level data query task based on the sub-business object identifier contained in the execution result includes: For each execution result at the current level, the sampling weight of each sub-business object identifier is determined based on the level value of the current level and the preset weight adjustment function. Based on the sampling weight of each sub-service object identifier, the sub-service object identifier is subjected to weighted sampling processing to obtain the target sub-service object identifier. Based on the target sub-business object identifier, determine the next level of data query task.

5. The method according to claim 1, characterized in that, The step of determining the next-level data query task based on the sub-business object identifier contained in the execution result includes: Obtain the association category between the business object identifier and each sub-business object identifier in the current level; For each of the aforementioned relationship categories, obtain the weight adjustment coefficient corresponding to the current level and the relationship category; Based on the level value of the current level and the weight adjustment coefficient, calculate the category weight of the association category at the current level; Based on the category weights, determine the sampling weights of the identifiers of each sub-business object that has the associated category in the current level; Based on the sampling weight, the sub-business object identifier is subjected to weighted sampling processing to obtain the target sub-business object identifier under each association category; Based on the target sub-business object identifier, determine the next level of data query task.

6. The method according to claim 1, characterized in that, The step of determining the next-level data query task based on the sub-business object identifier contained in the execution result includes: If a loop consisting of sub-business object identifiers is detected based on the execution result, a sampling weight adjustment strategy for the sub-business object identifiers on the loop path is determined according to the frequency of occurrence of the loop at different levels and the association category between the sub-business object identifiers in the loop and the business object identifiers at the current level. According to the sampling weight adjustment strategy, the sampling weight of the sub-business object identifier is adjusted, and the sub-business object identifier is subjected to weighted sampling processing based on the adjusted sampling weight; Based on the sub-business object identifier processed by the selected sampling weight adjustment strategy, the final target sub-business object identifier is determined, and the next level of data query task is determined based on the target sub-business object identifier.

7. The method according to claim 6, characterized in that, The step of determining a sampling weight adjustment strategy for sub-service object identifiers on the loop path based on the frequency of occurrence of the loop across different levels and the association category between the sub-service object identifier in the loop and the service object identifier at the current level includes: If the frequency of the loop in the preceding layer reaches a preset repetition threshold, the sampling weight of the sub-service object identifier corresponding to the loop will be adjusted to zero. If the frequency of occurrence of the loop in the preceding level does not reach the preset repetition threshold, the sampling weight is adjusted to a non-zero value based on the frequency of occurrence of the loop and the association category between the sub-service object identifier in the loop and the service object identifier of the current level.

8. A data query device, characterized in that, include: The request parsing unit is used to respond to data query requests and obtain multiple business object identifiers carried in the data query request. The task generation and distribution unit is used to generate a data query task at the current level based on the multiple business object identifiers, and submit the data query task at the current level to the distributed computing service to execute the data query task in parallel in at least one database that matches the business object identifier. The iterative processing unit is used to obtain the execution result of the data query task at the current level, and determine the data query task at the next level based on the sub-business object identifier contained in the execution result; wherein, the data query task at the next level is executed in parallel by the distributed computing service until a preset stopping condition is met, then the generation of the data query task at the next level is stopped, and business object topology data is generated and output according to the execution results of the data query tasks at each level.

9. A computer device, characterized in that, include: Processor, memory, and input / output interfaces; The memory is either a short-term storage memory or a persistent storage memory; The processor is configured to communicate with the memory and execute instructions in the memory to perform the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it is used to implement the method as described in any one of claims 1 to 7.

11. A computer program product having a computer program / instructions stored thereon, characterized in that, When executed by a processor, the computer program / instructions are used to implement the method as described in any one of claims 1 to 7.

Images