Data processing method, electronic device, and computer program product

Abstract

The present disclosure provides a data processing method, an electronic device and a computer program product. The method of the present disclosure first determines simulation configuration information of a to-be-simulated task, wherein the to-be-simulated task is used to simulate a processed task request, the simulation configuration information represents a task configuration, and the configuration content of at least one configuration item is different between the task configuration and a task configuration applied when the processed task request is processed, the task configuration contains a plurality of configuration items used to provide parameters required for processing the task, then the to-be-simulated task is simulated according to the simulation configuration information to obtain a simulation processing result, and finally, based on the simulation processing result, the change of a task index under different task configurations is determined.

Description

Technical Field

[0001] This disclosure specifically relates to data processing methods, electronic devices, readable storage media, and computer program products. Background Technology

[0002] Simulation testing is a common method of simulating the operation of a system in a virtual simulation environment. When a system processes tasks such as data computation or other types of tasks, by replaying and simulating the data flow of the task, the task processing results under different operating conditions can be obtained. The task processing effect can then be evaluated by comparing the results.

[0003] Current traffic replay methods primarily involve algorithm-level comparisons, using traffic simulations to examine the task processing effects of different algorithms. This limits the simulation conditions that the system can select, making it impossible to obtain the effects of factors other than the algorithm on task processing. Summary of the Invention

[0004] This disclosure provides data processing methods, electronic devices, readable storage media, and computer program products.

[0005] The first aspect of this disclosure proposes a data processing method, comprising: determining simulation configuration information of a task to be simulated, wherein the task to be simulated is used to simulate a processed task request, and the task configuration represented by the simulation configuration information and the task configuration applied when the processed task request is processed have at least one configuration item with different configuration content, and the task configuration includes multiple configuration items used to provide parameters required for the task to be processed; performing simulation processing on the task to be simulated according to the simulation configuration information to obtain a simulation processing result; and determining the changes in task indicators under different task configurations based on the simulation processing result.

[0006] According to some embodiments of this disclosure, multiple configuration items in the task configuration correspond to multiple levels divided according to the processing order. In two levels adjacent in the processing order, the configuration items included in the later level are used to provide the parameters required to process the data determined by the configuration items included in the earlier level.

[0007] According to some embodiments of this disclosure, the method of processing the task request includes determining the data receiver corresponding to the data to be allocated, and the multiple levels corresponding to the multiple configuration items in the task configuration include an allocation level; performing simulation processing on the task to be simulated according to the simulation configuration information includes: determining the data receiver corresponding to the data to be allocated in the task to be simulated according to the parameters provided by the configuration items of the allocation level included in the simulation configuration information, and the processed task request indicates that the data receiver corresponding to the data to be allocated has been determined.

[0008] According to some embodiments of this disclosure, the data to be allocated corresponds to customer demand, which represents a requirement for a demand object, and the data recipient is used to provide services related to processing the customer demand.

[0009] According to some embodiments of this disclosure, determining the data receiver corresponding to the data to be allocated in the simulation task according to the parameters provided by the configuration items of the allocation level included in the simulation configuration information includes: for multiple task requests included in the simulation task, if the request time of the task request is reached, then the task request that has reached the request time is taken as the target request; and determining the data receiver corresponding to the data to be allocated in the target request according to the parameters provided by the configuration items of the allocation level included in the simulation configuration information.

[0010] According to some embodiments of this disclosure, determining the data receiver corresponding to the data to be allocated in the target request based on the parameters provided by the configuration items of the allocation level included in the simulation configuration information includes: determining candidate objects from the requirement objects provided by the task to be simulated based on the parameters provided by the configuration items of the first level in the allocation level included in the simulation configuration information; determining candidate receivers from the data receivers associated with the candidate objects based on the parameters provided by the configuration items of the second level in the allocation level; and determining the data receiver corresponding to the data to be allocated in the target request from the candidate receivers based on the parameters provided by the configuration items of the third level in the allocation level.

[0011] According to some embodiments of this disclosure, determining the simulation configuration information of the task to be simulated includes: in response to receiving a configuration change request, generating simulation configuration information of the task to be simulated based on the configuration change request.

[0012] According to some embodiments of this disclosure, generating simulation configuration information for a task to be simulated based on the configuration change request includes: generating a modified task configuration containing modified configuration items and unchanged configuration items based on the configuration change request; and generating simulation configuration information representing the modified task configuration and the original task configuration respectively, thereby obtaining multiple simulation configuration information for the task to be simulated.

[0013] According to some embodiments of this disclosure, the configuration change request includes a first identifier, a second identifier, and the changed configuration content of the changed configuration item. The first identifier represents the version number of the changed configuration item itself, and the second identifier is used to represent the version number of the previous version from which the configuration content change originates.

[0014] According to some embodiments of this disclosure, after determining the changes in task indicators under different task configurations based on the simulation processing results, the method further includes: generating and outputting evaluation information of the changes, wherein the evaluation information is used to represent the correlation between the changed task indicators and the configuration items that caused the changes in the task indicators.

[0015] According to some embodiments of this disclosure, the evaluation information is generated through a mapping relationship between indicators and configuration items.

[0016] According to some embodiments of this disclosure, before simulating the task to be simulated according to the simulation configuration information, the method further includes: comparing stored task data and corresponding stored synchronization data, wherein the task data is related to the processed task request, the task data is synchronized to a data provider to form the synchronization data, and the data provider provides the synchronization data as the synchronization data required for simulation; and if it is determined that the task data and the synchronization data being compared are different, then a data synchronization anomaly is determined.

[0017] According to some embodiments of this disclosure, the task data corresponding to the task to be simulated is determined by the processed task indicated in the simulation request.

[0018] According to some embodiments of this disclosure, the task data used for comparison includes one or more of the following: request data in the task request, description data describing the initiator of the task request, and description data describing the task receiver that matches the task request.

[0019] According to some embodiments of this disclosure, at least a portion of the task data associated with the processed task request is streaming data, which is stored sequentially in the order of generation to the data source, and the data provider provides the synchronization data required for simulation through its own retrieval function.

[0020] According to some embodiments of this disclosure, comparing stored task data and corresponding stored synchronization data includes comparing the data fingerprint of the stored task data and the data fingerprint of the corresponding stored synchronization data, wherein different data fingerprints indicate that the data being compared is different.

[0021] A second aspect of this disclosure provides an electronic device, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, causing the processor to perform the data processing method described in any of the above embodiments.

[0022] A third aspect of this disclosure provides a readable storage medium storing a computer program, which, when executed by a processor, is used to implement the data processing method described in any of the above embodiments.

[0023] This disclosure provides a fourth aspect of a computer program product, the computer program product comprising a computer program, which, when executed by a processor, is used to implement the data processing method described in any of the above embodiments. Attached Figure Description

[0024] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0025] Figure 1 The diagram illustrates an application scenario of the data processing method according to some embodiments of this disclosure.

[0026] Figures 2-9 A schematic diagram of the overall flow of the data processing method M10 according to some embodiments of the present disclosure is shown.

[0027] Figure 10 This is a schematic block diagram of the structure of a data processing apparatus according to one embodiment of the present disclosure.

[0028] Figure 11 This is a schematic block diagram of an electronic device according to one embodiment of the present disclosure. Detailed Implementation

[0029] The present disclosure will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0030] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0031] Unless otherwise stated, the exemplary implementations / embodiments shown are to be understood as providing exemplary features of various details that provide ways in which the technical concepts of this disclosure can be implemented in practice. Therefore, unless otherwise stated, the features of various implementations / embodiments may be additionally combined, separated, interchanged and / or rearranged without departing from the technical concepts of this disclosure.

[0032] The terminology used herein is for the purpose of describing particular embodiments and is not restrictive. As used herein, unless the context clearly indicates otherwise, the singular forms “a” and “the” are intended to include the plural forms as well. Furthermore, when the terms “comprising” and / or “including” and variations thereof are used in this specification, it indicates the presence of the stated features, integrals, steps, operations, parts, components, and / or groups thereof, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, parts, components, and / or groups thereof. It should also be noted that, as used herein, the terms “substantially,” “about,” and other similar terms are used as approximate terms rather than as terms of degree, thus explaining the inherent biases in measurements, calculated values, and / or provided values ​​that would be recognized by one of ordinary skill in the art.

[0033] When service providers deliver services to customers through applications (APPs), they typically need to continuously optimize the application to improve service quality and effectiveness. Simulating actual traffic is one way to achieve this.

[0034] Taking the real estate sector as an example, customers will make real estate-related requests to real estate service providers, such as buying, selling, or renting houses. These requests are called "business opportunities." After receiving the customer's request, the service provider's (real estate company's) business system will provide the customer with suitable properties and assign relevant personnel (such as real estate agents who maintain the property information) to provide the customer with corresponding services, including showing the property, introducing the property details online, and signing the purchase agreement.

[0035] Regarding the allocation of the aforementioned customer needs to brokers, the common practice is to conduct bucket comparison simulation tests. This involves randomly and evenly distributing customers into different groups, using different allocation algorithms for each group, and comparing the simulation allocation results of each group to see which allocation algorithm performs better.

[0036] The above-mentioned bucket comparison simulation test can only test the allocation effect corresponding to different allocation algorithms. It cannot test and compare other factors that can affect the allocation effect. The factors available for testing are incomplete and lack comprehensiveness, resulting in limitations in the comparison of test effects.

[0037] Therefore, this disclosure proposes a data processing method.

[0038] Figure 1A schematic diagram illustrating an application scenario of a data processing method according to some embodiments of the present disclosure is shown. In this application scenario, a business system 10, a messaging system 20, a retrieval system 30, and a simulation system 40 may be sequentially and communicatively connected. In this disclosure, each of the business system 10, messaging system 20, retrieval system 30, and simulation system 40 may each include at least one processor and at least one memory. Figure 1 The shape and structure of the business system 10, messaging system 20, retrieval system 30 and simulation system 40 shown should not be construed as a limitation on the scope of protection of this disclosure.

[0039] For example, business system 10 is a service provider system that provides services to customers, capable of interacting with customers and actually handling customer needs. Business system 10 is communicatively connected to messaging system 20, used to push event streams to messaging system 20 in real time. Messaging system 20 stores the received event data according to the time of receipt. The event stream includes information generated from interactions with customers, as well as information on business data maintenance and updates. Data is read from messaging system 20 using ETL (Extraction Transformation Loading) technology and written to retrieval system 30, which has retrieval capabilities. Retrieval system 30 is used to provide the data required by multiple service providers, such as simulation systems and monitoring systems.

[0040] When service providers' technical staff want to simulate historical traffic, they can configure the simulation settings in the application. One configuration item can be set to a new value that is different from the value used by the current business system, while the other configuration items and algorithms remain unchanged. Then, the simulation system 40 can replay and simulate the historical traffic based on the new configuration item to obtain the service results under different configuration item values. By comparing the service effects, the impact of a single configuration change on the service results can be accurately analyzed. It can flexibly adjust multiple configuration items to conduct comparative tests under various operating conditions, filling the gaps in the factors available for testing and facilitating the subsequent formulation and optimization of service strategies.

[0041] Figure 2 A schematic flowchart of the data processing method M10 according to some embodiments of this disclosure is shown. For example... Figure 2 The method shown includes steps S100, S200, and S300. This method can be executed by a server.

[0042] S100, determine the simulation configuration information of the task to be simulated. The task to be simulated is used to simulate a processed task request. The task configuration represented by the simulation configuration information differs from the task configuration applied when the processed task request is processed by at least one configuration item. The task configuration includes multiple configuration items used to provide the parameters required for the task to be processed.

[0043] Task requests can originate from the service requester (such as a customer). Processed task requests refer to requests that have already occurred, including those that the service provider has already completed or begun processing. For example, a customer submits a housing purchase request in the service provider's app, specifying their requirements for the property. The real estate platform, as the service provider, has already processed this request and provided the customer with a property that meets their requirements, along with a suitable real estate agent to handle the communication.

[0044] Processed task requests (referred to as historical requests) are historical traffic. The task to be simulated is a replay of the historical traffic and the processing of task requests in the historical traffic according to the new task configuration. The simulation configuration information includes the simulation task configuration. The configuration applied when historical requests are processed can be called the historical task configuration. These task configurations can each include multiple configuration items of the same type, but the simulation task configuration and the historical task configuration may differ in the configuration content of one or more of these configuration items.

[0045] The configuration content refers to the parameter values ​​of the configuration items. When the service provider processes real customer task requests and simulated task requests, the processing logic for each task applies at least some of the configuration items. The task request is processed through a combination of processing logic and configuration item parameters. For example, configuration items may include the maximum number of orders an agent can accept, the status items included in the property status list, the weight values ​​of the calculation algorithm, or other configuration items. Different configuration items (different task configurations) may result in different processing effects when handling the same task request or the same batch of task requests, such as differences in processing speed, completeness, and accuracy of task processing.

[0046] S200 performs simulation processing on the task to be simulated according to the simulation configuration information and obtains the simulation processing results.

[0047] By processing the configuration parameters provided by the logic and simulation configuration information, a holistic approach to handling task requests is formed, thereby enabling the processing of task requests to be simulated.

[0048] Assuming the simulation task request is to match a customer's home-buying needs with a suitable real estate agent, and the modified configuration settings limit the maximum number of orders each agent can accept, then the simulation processing results after processing these simulation task requests can include the results of batch data computation. It is understood that simulation task requests can also have other purposes and uses. For example, if the simulation task request is to perform batch data computation, and the modified configuration settings limit the maximum computational resource usage of a certain type of computing unit or process, then the subsequent processes are similar to the above and will not be elaborated upon here.

[0049] S300 determines the changes in task indicators under different task configurations based on simulation processing results.

[0050] Task metrics are used to evaluate the process, performance, and effectiveness of task request processing. Task metrics can be calculated from simulation results. For example, for simulations of customer home-buying needs, task metrics could include agent order coverage, agent utilization, and the percentage of orders received by new agents.

[0051] Because the configuration items for simulated task requests and real customer requests differ, the calculated task metric values ​​may also differ. Assuming the difference lies in the maximum number of orders a broker can accept, changing from 10 to 15, simulation results show that for the task metrics of broker order coverage and senior broker total orders, the change in the maximum number of orders increases both metrics, while other metrics remain unchanged. This demonstrates the changes in various task metrics under different task configurations.

[0052] Changes in task metrics can include the rate of change, which is Δi / baseline(i). 100%, where Δi is the difference between the task metrics, i is the task metric, and the difference Δi = test(i) - baseline(i). Here, baseline(i) is the running result before the configuration item of metric i was changed, and test(i) is the simulation result after the configuration item of metric i was changed.

[0053] For example, if a technician wants to test the impact of "adjusting the maximum allowed order volume for brokers in City A's Y1 business from 10 to 15" on broker order coverage, the technician can modify the configuration of the "maximum order volume for brokers" setting in the front-end configuration interface, changing it from 10 to 15, while keeping other configuration items unchanged. Then, multiple task requests received by the real business system within the most recent d days are selected from historical traffic, and corresponding simulation tasks are created. The simulation system performs the simulation according to the content of each configuration item (simulation configuration information), processing the multiple task requests sequentially in the order they occurred during the simulation.

[0054] If, when processing task request a1 in the simulation system, broker b1's current order volume is 10, then task request a1 can be matched with broker b1, and broker b1's current order volume becomes 11. If processed according to the configuration before the configuration item change, task request a1 will not be matched with broker b1 because broker b1's current order volume has reached the maximum allowed order volume.

[0055] Therefore, after the simulation system completes the simulation processing of the above multiple task requests, the broker order coverage rate in the business metrics (i.e., task metrics) will differ from the metric value before the configuration item change, i.e., there will be a change. Technical personnel can use this change to optimize the task configuration of real-world business system applications.

[0056] According to the data processing method proposed in the embodiments of this disclosure, when a service provider wants to simulate historical traffic including processed task requests, it can change the values ​​of some configuration items in the simulation configuration while keeping the remaining configuration items and the algorithm used unchanged. This allows for individual changes to a single configuration, rather than just changing the algorithm used to provide the service.

[0057] Furthermore, by replaying and simulating historical traffic using the modified configuration items, service results (such as service effectiveness and service capability) under various service conditions can be obtained. By comparing these service results, the impact of a single configuration change on business metrics can be accurately analyzed. This allows for flexible adjustment of various configuration items to conduct comparative tests under multiple service conditions, filling in the gaps in available testable factors and enabling the analysis of the impact of configuration changes using a controlled variable approach.

[0058] In addition, simulation can predict the impact on task metrics in advance, eliminating the need to actually deploy configuration changes online or wait for a long time. Simulation can quickly determine the changes in metrics caused by configuration changes, significantly reducing trial and error costs and risks. It also facilitates the formulation and optimization of service strategies, making it particularly suitable for scenarios with a large number of configuration items.

[0059] Multiple configuration items in a task configuration can correspond to multiple levels divided according to the processing order. In two adjacent levels in the processing order, the configuration items included in the later level can be used to provide the parameters required to process the data determined by the configuration items included in the earlier level.

[0060] In the task request processing logic, each configuration item in the task configuration can play its corresponding role according to its own hierarchy. For the task request to be simulated, the processing is carried out in hierarchical order. First, the configuration item parameters of the highest-level hierarchy are used to perform calculations based on the task request to obtain the first calculation result. Then, the configuration item parameters of the next level are used to perform calculations based on the first calculation result to obtain the second calculation result. This process continues until the final calculation result is obtained, which is the simulation result of the task request to be simulated.

[0061] In other words, task requests can be processed according to a certain logical chain, formed through the aforementioned multiple layers. Different layers can correspond to different processing functions, decoupling the overall functionality into multiple processing functions executed by different layers, thus increasing maintainability and iterability. The configuration items at these multiple layers can form a multi-level parameterized configuration model. The parameterized configuration model clearly defines the layer to which each configuration item belongs, its function, and its scope, allowing users (technical personnel) to flexibly adjust configuration items at any layer.

[0062] Processing task requests can include determining the data recipient corresponding to the data to be allocated. The task request is processed by identifying the appropriate data recipient for the data to be allocated contained in the task request. Correspondingly, the multiple levels corresponding to the multiple configuration items in the task configuration can include allocation levels. There can be one or more allocation levels, and the configuration items contained in each allocation level are all configuration items related to the allocation of the data to be allocated.

[0063] Figure 3 A schematic flowchart of the data processing method M10 according to other embodiments of this disclosure is shown. (See also...) Figure 3 In step S200, the method of simulating the task to be simulated according to the simulation configuration information may include: determining the data receiver corresponding to the data to be allocated in the task to be simulated based on the parameters provided by the configuration items of the allocation level included in the simulation configuration information. The specific allocation method for the data to be allocated is formed by combining the configuration items in the allocation level with the allocation logic, thereby completing the allocation of the data to be allocated to the data receiver based on the specific allocation method. Here, a processed task request can indicate that the data receiver corresponding to the data to be allocated has been determined. That is, when the corresponding data receiver for the data to be allocated is determined, the task request can be considered complete.

[0064] Data to be assigned can correspond to customer needs, which represent requirements for the desired property. The data recipient can then use this data to provide services related to processing those needs. For example, in the real estate sector, the desired property is a listing, and the customer's need is their requirement for that property. The data recipient is a real estate agent who provides services such as property introductions and showings. Therefore, customer needs need to be assigned as data to be distributed to suitable real estate agents to complete the processing of those needs.

[0065] Figure 4 A schematic flowchart of the data processing method M10 according to other embodiments of this disclosure is shown. (See also...) Figure 4 Step S200 (determining the data receiver corresponding to the data to be allocated in the simulation task according to the parameters provided by the configuration items of the allocation level included in the simulation configuration information) may specifically include steps S210 and S220.

[0066] S210: For multiple task requests contained in the task to be simulated, if the request time of a task request is reached, then the task request that has reached the request time shall be taken as the target request.

[0067] S220, based on the parameters provided by the configuration items of the allocation level included in the simulation configuration information, determine the data receiver corresponding to the data to be allocated in the target request.

[0068] A single simulation task can include multiple task requests. The simulation is considered complete when all these task requests are processed. In a real environment, clients initiate task requests at different times. During the simulation, these same task requests can be replayed sequentially according to their request times in the real environment.

[0069] Figure 5 A schematic flowchart of the data processing method M10 according to other embodiments of this disclosure is shown. (See also...) Figure 5 Step S220 (determining the data recipient corresponding to the data to be allocated in the target request based on the parameters provided by the configuration items of the allocation level included in the simulation configuration information) may specifically include steps S221, S222 and S223.

[0070] S221, Based on the parameters provided by the configuration items of the first level in the allocation hierarchy included in the simulation configuration information, determine the candidate objects from the requirement objects provided by the task to be simulated.

[0071] S222, determine the candidate receiver from the data receivers associated with the candidate object according to the parameters provided by the configuration items of the second level in the allocation hierarchy.

[0072] S223, determine the data receiver corresponding to the data to be allocated in the target request from the candidate receivers according to the parameters provided by the configuration item of the third level in the allocation level.

[0073] Taking the real estate sector as an example, the first level can be the material construction layer, which stores material SQL templates and their parameters, such as time range and property status filtering conditions. The configuration items contained in the first level can extract allocable business opportunity materials from the raw data, and are mainly used to process static data, such as selecting various data such as property information, agent information, user profiles, and algorithm models.

[0074] For example, only the configuration items representing the coverage of business opportunities at the first level can be adjusted. For instance, the configuration items before the change only included "Listed" as the business opportunity type, while the configuration items after the change include both "Listed" and "Pending Approval" as business opportunity types. By modifying the configuration items at the first level, business opportunities in the original data can be filtered, such as filtering the properties and agents participating in the simulation, thereby revealing the impact on various business metrics.

[0075] The second level can be a filtering and restriction layer, storing parameterized expressions for filtering rules, such as expressions for filtering cities or agents. The configuration items in the second level can perform multi-level filtering based on multiple dimensions such as city, business line, agent status, and user behavior, using the output of the first level. This is suitable for processing dynamic data; for example, agent status changes over time and with business progress, requiring the determination of whether an agent matches the current customer's needs based on their real-time status.

[0076] For example, you can adjust only the second-level configuration item representing the maximum number of orders a broker can currently accept, such as changing its value from 10 to 15, to see what impact it has on various business metrics. Through simulation and comparison, it was determined that the aforementioned numerical adjustment to this configuration item resulted in an increase in both the broker order coverage rate and the total number of orders accepted by senior brokers.

[0077] The third level can be the allocation strategy layer, storing parameters for the allocation algorithm, such as weight parameters like geographic location weight and broker ability weight. The configuration items in the third level can execute the allocation algorithm based on elements like geographic location, broker ability, and historical conversion rate, using the output of the second level to determine the target broker that matches the customer's needs.

[0078] It is understandable that any configuration item at any of the above levels can be changed individually, and in the task configurations applied to the two comparison results, only one configuration item may differ while the others remain the same. Examples of changing other configuration items are similar and will not be elaborated upon here.

[0079] If the simulation is based on historical traffic within time period t1, the simulation system can read the status information of each agent and the information of each property at the start of time period t1, as well as the customer demands (opportunities) received within time period t1 and their corresponding receiving times. After the simulation starts, whenever an opportunity is received, it can be filtered sequentially according to the three levels mentioned above.

[0080] The first level filters out listings, agent information, and agent status in the city where the business opportunity is located. It also allows filtering by business opportunity to obtain a list of matching listings. Since each listing has a corresponding agent responsible for maintaining the listing information, details, and showings, the second level filters the listings to find agents whose current status (e.g., current order volume) meets the criteria. Then, an allocation algorithm ultimately determines the agent matching the business opportunity, completing the opportunity allocation and updating the current status of the finally determined agent (e.g., current order volume incremented by 1).

[0081] Understandably, the property list can also be obtained directly from the data read at the start of time period t1. The obtained property list is a property list obtained by filtering according to the business opportunity in the real environment. At this time, the property list corresponding to each business opportunity is also the content read by the simulation system before the simulation starts, and can be used directly during the simulation.

[0082] This implementation addresses the challenges of numerous configuration items and complex upstream and downstream dependencies by proposing a parameter-driven end-to-end traffic simulation scheme. Through the aforementioned three levels, all configuration items (material SQL, filtering rules, and allocation strategies) in the broker allocation chain are abstracted into a unified multi-level parameterized configuration model. This model supports flexible replacement of any level and any configuration item (such as a threshold for a specific filtering field in a city), including adjustments to configuration items for material construction and filtering rules. It achieves accurate simulation and effect prediction using the "controlled variable method," making it particularly suitable for scenarios where even minor adjustments to any configuration item can significantly impact the final allocation result.

[0083] Figure 6 A schematic flowchart of the data processing method M10 according to other embodiments of this disclosure is shown. (See also...) Figure 6 Step S100 (determining the simulation configuration information of the task to be simulated) may specifically include: in response to receiving a configuration change request, generating simulation configuration information of the task to be simulated based on the configuration change request.

[0084] Technicians operate on the front-end interface, modifying the values ​​of configuration items that need changing, such as changing the maximum number of orders a broker can accept from 10 to 15. They then initiate a configuration change request to the simulation system by clicking a button. Upon receiving the configuration change request, the simulation system parses it to obtain the configuration content of the changed configuration items, thereby generating simulation configuration information, where the maximum number of orders a broker can accept is set to 15. When determining the changes in task metrics (step S300), the business metrics obtained from the simulation processing can be compared with the business metrics of the actual processing results of the same batch of task requests to determine the changes.

[0085] Figure 7 A schematic flowchart of the data processing method M10 according to other embodiments of this disclosure is shown. (See also...) Figure 7 Step S100 (determining the simulation configuration information of the task to be simulated) may specifically include the following steps S110 and S120.

[0086] S110, in response to receiving a configuration change request, generates a modified task configuration that includes both modified and unchanged configuration items based on the configuration change request.

[0087] S120 generates simulation configuration information representing the changed task configuration and the original task configuration, respectively, to obtain multiple simulation configuration information for the task to be simulated.

[0088] Multiple simulation configuration information sets are generated, including the simulation configuration information of the task configuration before the change. This means it includes the actual configuration information used in real-world processing of the same batch of task requests. For example, in reality, for task requests received on the most recent day d, the maximum number of orders a broker can accept is set to 10 in the configuration items applied during processing.

[0089] When simulating the same batch of task requests, two simulation configurations are used. The first configuration sets the maximum number of orders a broker can accept to 10, representing the original task configuration. The second configuration sets the maximum number of orders a broker can accept to 15 (the changed value), representing the changed task configuration. In step S200, simulations are performed on the same batch of task requests using both configurations, resulting in two processing outcomes. In step S300, the changes in business metrics (task metrics) are determined based on these two processing outcomes.

[0090] Using simulation to obtain the task request processing results corresponding to the task configuration before the change, compared with the processing results obtained in reality, can eliminate the impact of static data changes that occur during the execution of each task (such as changes in the basic information of housing and agents or the occurrence of unforeseen events) on the processing results, thereby ensuring that business indicators are not affected by static data changes and other situations, making the calculated indicator changes more accurate.

[0091] Understandably, in step S200, during the simulation of the task to be simulated, the execution status of the task can be monitored, and an alarm can be issued if an abnormality is detected. For example, the task execution status (such as running, success, failure, timeout, etc.) can be monitored in real time. If the task execution exceeds a preset time threshold (such as 2 hours), an alarm will be automatically triggered and the simulation will be paused. Technicians can manually terminate the simulation process and release the corresponding computing resources by triggering the button provided on the front-end interface.

[0092] Simulation tasks and real task requests can be processed in different runtime environments. For example, simulation tasks run in the simulation system, while real tasks run in the business system, thus isolating their computing resources and ensuring simulation security. The simulation system can include an independent Spark cluster, and the resource consumption limit for the simulation can be set to avoid affecting the operation of other offline tasks.

[0093] Simulation tasks with different simulation configurations can be performed in parallel. For example, the task configuration before the change and the task configuration before the change can be processed in parallel to improve simulation efficiency, support high-concurrency simulation of hundreds of millions of data points, and meet the needs of scenarios with more than 1 billion daily traffic.

[0094] A configuration change request may include a first identifier, a second identifier, and the changed configuration content for the changed configuration item. The first identifier may represent the version number of the changed configuration item itself, and the second identifier may represent the version number of the previous version from which the configuration content change originated.

[0095] Each currently modified configuration item can include the two version identifiers mentioned above, i.e., a version number. If the configuration item has not been modified, the second identifier is empty. Both the first and second identifiers are unique. For each configuration item, a tree structure can be built in the simulation system or the service provider's configuration storage system based on the changes to the configuration item to represent the version update of the configuration item. Each version tree contains only different value versions of the same configuration item, and the version trees are independent of each other.

[0096] Assume there are 50 modifiable configuration items. For example, during the initial simulation, a technician modifies configuration item p1 (maximum number of orders a broker can accept) and initiates a configuration change request. This request includes the configuration content of configuration item p1 (value 15), a first identifier (v1_002), and a second identifier (v1_001). v1_001 and v1_002 are two nodes in the version tree of configuration item p1, with version number v1_001 being the parent node of version number v1_002, forming a tree-like dependency relationship. Version number v1_001 corresponds to the configuration of configuration item p1 used in reality (value 10), and version number v1_002 corresponds to the configuration of configuration item p1 used in this simulation (value 15).

[0097] The simulation system receives and parses configuration change requests, locates the specific configuration item node in the parameterized configuration model (multi-level structure), and creates a new version configuration L1 based on configuration item p1 as one type of simulation configuration information. The value of configuration item p1 in configuration L1 is 15. The original version configuration L0 is used as another type of simulation configuration information; configuration L0 represents the configuration used in actual task request processing, and the value of configuration item p1 in configuration L0 is 10. All configuration items in configuration L1 and configuration L0 have the same value except for configuration item p1.

[0098] The new configuration version L1 can then be serialized into JSON format and stored, for example, in a MongoDB database system that uses BinaryJSON format for data storage. Afterwards, a simulation task parameter package can be constructed. This package includes a complete snapshot of both the modified configuration version L1 and the initial configuration version L0. The simulation system uses this parameter package to obtain the task configuration and perform simulation processing. A configuration snapshot refers to a static collection of multiple configuration items at the time of its generation. Since configuration L0 represents the configuration used in real-world applications, the simulation system can directly retrieve the types and values ​​of configuration items from the stored configuration information.

[0099] The simulation system can use a separate MongoDB instance to store configuration and task states, and a separate Doris instance to store simulation results, physically isolating it from the online system in the real environment to avoid query contention. MongoDB is an open-source, document-oriented NoSQL database system. Doris is a high-performance, real-time, massively parallel processing parsing database system.

[0100] During the second simulation, the technicians continued to modify configuration item p1 and initiated a configuration change request. The request included the configuration content of configuration item p1 (value 12), the first identifier (v1_003) and the second identifier (v1_002), where version number v1_002 is the parent node of version number v1_003.

[0101] The simulation system receives and parses the configuration change request, locates the configuration item node, and creates a new version configuration L2 based on configuration item p1 as one type of simulation configuration information. The value of configuration item p1 in configuration L2 is 12. Version configuration L1 is also used as another type of simulation configuration information, with the value of configuration item p1 in configuration L1 being 15. All configuration items in configuration L2 and configuration L1, except for configuration item p1, have the same values.

[0102] The stored configuration snapshots can be provided to the front end, allowing technicians to select existing configuration snapshots as simulation configuration information. For example, during the third simulation, a technician modifies configuration item p5 and initiates a configuration change request. This request includes the configuration content of configuration item p5 (value 100), the first identifier (v5_002), the second identifier (v5_001), and the unique identifier (L1) of an existing configuration snapshot.

[0103] The simulation system receives and parses configuration change requests, locates configuration item nodes, and creates a new version configuration L3 based on configuration item p5 as one type of simulation configuration information. Furthermore, it uses the unique identifier of the configuration snapshot to determine the configuration items and content of the snapshot as another type of simulation configuration information for comparison. The values ​​of all configuration items in configuration L1 and configuration L3 are identical except for configuration item p5.

[0104] The identifier in the configuration item can determine the current version and parent version of the changed configuration item, thus indicating which version's value the changed configuration item was based on. This means that each time a change request is made, it is not necessary to send the values ​​of all configuration items to the system backend; only the value and identifier of the changed configuration item need to be sent.

[0105] Furthermore, this enables the simulation system to automatically track configuration dependencies and ensure the use of a complete and consistent configuration snapshot during simulation by using configuration versions. The configuration snapshot only needs to include the version number of the configuration item used; the specific values ​​of the configuration item can be read from the stored configuration content through the mapping relationship between the version number and the configuration content. This achieves fine-grained configuration management, supports versioned management of any level and any configuration item, and makes task configurations versionable, composable, reusable, and traceable.

[0106] Continue reading Figure 7 After step S300 (determining the changes in task indicators under different task configurations based on simulation processing results), step S400 can also be executed.

[0107] S400 generates and outputs evaluation information on the changes. This evaluation information represents the relationship between the changed task metrics and the configuration items that caused those changes.

[0108] After calculating the rate of change for each task indicator, for task indicators with a non-zero rate of change, the changed configuration items that caused these changes can be identified. If there is only one changed configuration item and two task indicators have changed, then these two task indicators are related to the changed configuration item. The rate of change and this relationship are fed back to the front end and displayed on the interface, thus completing the output of evaluation information. The reasons for the indicator changes can be provided to technical personnel in the form of a visual report, achieving automatic attribution.

[0109] Evaluation information can be generated through the mapping relationship between indicators and configuration items. That is, for each task indicator, the system establishes and stores the mapping relationship between configuration items that can cause changes in that task indicator and the task indicator itself. For example, the configuration item "maximum number of orders accepted by brokers" has mapping relationships with both the "broker resource utilization rate" and "advanced broker order volume" indicators. When task indicators differ in the simulation results, the system uses a rule engine to determine the configuration items in the mapping relationship of the differing task indicator and provides this information to the front-end interface.

[0110] It can also provide the front-end interface with information on whether the results meet user expectations. For example, if the rate of change of a certain indicator exceeds a corresponding threshold, the information provided to the front-end interface will include a prompt indicating that the indicator needs to be monitored. The visualization report can include an overall indicator comparison table, indicator comparison charts by city and business line, a configuration change attribution list, and risk warnings (such as abnormal fluctuations of a certain indicator exceeding a threshold). This allows for a clear understanding of the specific impact of adjustments to different configuration items on the business, automatically attributing differences in simulation results to specific configuration item changes, and improving decision-making efficiency.

[0111] Figure 8 A schematic flowchart of the data processing method M10 according to other embodiments of this disclosure is shown. (See also...) Figure 8 Before step S200 (perform simulation processing on the simulation task according to the simulation configuration information), steps S180 and S190 can be executed first. It is understood that steps S180 and S190 can be executed after step S100 or before step S100.

[0112] S180 compares the stored task data with the corresponding stored synchronization data. The task data is related to the processed task requests. The task data is synchronized to the data provider to form synchronization data. The data provider uses this synchronization data as the synchronization data required for simulation.

[0113] S190, if it is determined that the task data to be compared and the synchronization data are different, then it is determined that the data synchronization is abnormal.

[0114] Processed task requests can be those that have completed the allocation of data to be assigned, such as requests that have identified a suitable agent for a customer's needs. Stored task data can include data generated by the business system in the process of identifying the appropriate agent for a customer's needs in a real-world environment, such as the content of the customer's needs, a list of properties matching the customer's needs, changes in agent status, and other data such as property changes.

[0115] When new task data is generated, it can be stored directly in the business system or a designated database. Task data can be periodically synchronized to a data provider, which then provides data to all systems that may use the task data. This eliminates the need for business systems to support large-scale simulation requirements and ensures end-to-end data integrity.

[0116] Suppose we want to simulate historical traffic within time period t1. Before starting the simulation, we need to compare the task data and synchronization data within time period t1. If they are the same, it means the previous data synchronization process was normal, with no data loss or synchronization errors, and the simulation can proceed. If they are different, it means the previous data synchronization process was flawed, with possible data loss or synchronization errors. In this case, the simulation will not proceed; instead, we need to query the details of the difference data and perform data repair to avoid obtaining incorrect indicator results based on erroneous data.

[0117] The task data corresponding to the task to be simulated can be determined through the processed tasks indicated in the simulation request. The simulation request and the configuration change request mentioned above can be the same request, which includes both the content of the configuration change items and the instruction to create the simulation task. Alternatively, the simulation request and the configuration change request mentioned above can be different requests. The technician first initiates a configuration change request on the front end to make the simulation system generate simulation configuration information, and then selects a simulation period and initiates a simulation request through the front end, so that the simulation system determines the task data of the task to be simulated (such as business opportunities in period t1, agent status at the start of period t1, property information, etc.) according to the processed task requests included in the simulation period.

[0118] The task data used for comparison may include one or more of the following: request data from the task request, descriptive data describing the initiator of the task request, and descriptive data describing the task recipient that matches the task request. For example, the request data corresponds to customer needs, the initiator's descriptive data corresponds to customer profiles, and the task recipient's descriptive data corresponds to broker information.

[0119] At least a portion of the task data associated with the processed task requests can be streaming data. Streaming data can be stored sequentially in the data source in the order it is generated. The data provider can provide the synchronous data required for simulation through its own retrieval functions.

[0120] For example, the data source corresponds to Figure 1 The messaging system 20 and the business system 10 are systems that receive task requests from clients and process them in reality. The data generated by the business system 10 in processing task requests is stream data, which can be stored in the data source in the order it was generated. The data provider corresponds to... Figure 1 The retrieval system 30 in the system. Data from the data source can be incrementally updated to the data provider periodically. When the simulation system receives a simulation task, it can obtain all the data required for the simulation from the data provider, including information such as the time when the business opportunity occurs and the status of the broker at different times.

[0121] By first storing streaming data in the data source of the streaming data platform, data synchronization failures are avoided if the data provider's system is unavailable (e.g., due to cluster upgrades or network fluctuations). The streaming data platform acts as an intermediate buffer layer; business systems only need to send change events to the platform without worrying about how the data is subsequently consumed, thus completely decoupling from the data provider. The data provider then provides the simulation system with the necessary data through its retrieval functions.

[0122] Figure 9 A schematic flowchart of the data processing method M10 according to other embodiments of this disclosure is shown. (See also...) Figure 9 Step S180 (comparing the stored task data with the corresponding stored synchronization data) can specifically be: comparing the data fingerprint of the stored task data with the data fingerprint of the corresponding stored synchronization data. Different data fingerprints indicate different data being compared.

[0123] A data fingerprint can be a hash value generated by MD5 (a message digest algorithm), which can uniquely represent a piece of data. Data fingerprints can be used to determine whether the information transmission is complete and consistent.

[0124] Before comparing the data fingerprints of the stored task data with the corresponding stored synchronization data, we can first listen for write events from the data source storing the task data and the data provider storing the synchronization data. For both the data source and the data provider, we determine the data fingerprints of the data written by their respective write events within their respective time windows and store them in their respective identifier storage locations.

[0125] For example, when a business system sends data to a data source for writing through a program or service component, the write event of the data source can be identified by listening, the written data can be aggregated according to a set time window (such as 5 minutes), the data fingerprint within the window can be calculated, and the data fingerprint can be stored in the first data table.

[0126] When the data provider consumes and writes data from the data source, the write events of the data provider can be identified by listening. The written data can be aggregated according to a set time window (such as 5 minutes) and the data fingerprint within the window can be calculated. The data fingerprint is then stored in the second data table.

[0127] Before simulation, for the data within the t1 time period to be simulated, the fingerprint data in the first and second data tables can be read periodically (e.g., every 5 minutes) and compared according to time windows. If the fingerprints in the same window are different, the missing data can be located by querying the original data in the data source and data provider.

[0128] The broker allocates real-time streaming data from the message system 20 to the retrieval system 30. Through bidirectional comparison of data fingerprints, active verification is performed to accurately identify problems such as data loss, duplication, and out-of-order processing. This verifies the integrity of the real-time streaming data from the message system 20 to the retrieval system 30. Therefore, it can avoid delays or data loss in the data pipeline due to network jitter, write blockage in the retrieval system 30, etc., ensuring the accuracy of the material data required for simulation and avoiding incomplete simulation data, distorted results, and misleading product decisions.

[0129] Multiple simulation configuration settings are possible, including task priorities and available resource quantities. Available resource quantities are positively correlated with task priority. Priorities, from lowest to highest, are: Normal, High, and Urgent. Higher-priority tasks can preempt computational resources from lower-priority tasks. The execution order can be dynamically adjusted based on task creation time and data volume. When the simulation system receives a simulation task request, it can write the task to a task queue. The queue is then scanned by a timed task scheduling service, and tasks are selected for execution based on priority and available resources. For the selected task, computing resources are allocated, and the simulation begins, while the task status is monitored. If an anomaly is detected, an error log is logged and output. This ensures the stability and security of the simulation system.

[0130] Multiple simulation tasks can be processed in parallel. Each simulation task may include at least one of the following: a unique task identifier, configuration information before the configuration item was changed, configuration information after the configuration item was changed, and historical data time range for playback (such as within time period t1).

[0131] Before the simulation begins, the simulation system reads historical business opportunity data within a specified time range from the data provider. It then performs data filtering at the first level to obtain material data, followed by multi-level filtering at the second level. The filtering results are stored as intermediate snapshots in a temporary table. Finally, at the third level, an allocation algorithm is called to calculate broker scores, identifying the broker with the highest score. For the same batch of historical data, simulation tasks with different configurations can be executed simultaneously. Independent resource pools isolate the computational tasks of different configurations, enabling parallel processing of tasks across multiple cities and business lines (e.g., simultaneously simulating Beijing, Shanghai, and Shenzhen).

[0132] The simulation system can dynamically adjust the number of processes and memory configuration to execute a task based on the data volume and computational complexity of the simulation task. For example, if the task involves more than N data entries, it will automatically expand to H Executor processes, with each process allocated F memory. If the task priority is "urgent," a dedicated resource pool can be allocated to prevent it from being preempted by lower-priority tasks.

[0133] By using a distributed multi-version parallel simulation scheduling framework, a task priority queue and a dynamic resource allocation mechanism are designed to support high-concurrency simulations across multiple cities, business lines, and configuration versions, improving computational efficiency by 70% and reducing simulation time from several hours to within one hour.

[0134] The following is an example description of the overall scheme of this implementation method. Technical personnel wanted to test the impact on agent allocation coverage after adjusting the maximum order volume for long-term rental businesses in Beijing from 10 to 15. In the front-end configuration interface, the technical personnel selected "Beijing - Long-term Rental - Filtering Rules," modified the "Maximum Order Volume for Agents" parameter from 10 to 15, clicked "Create Simulation Task," and selected to replay historical data from the last 7 days. The simulation system received the simulation request, parsed the configuration change, created a new version configuration (task configuration version number 2), and generated a parameter package. The system verified the data synchronization integrity of the message system 20 → retrieval system 30 for the last 7 days, confirming data availability. The simulation task entered the scheduling queue and was allocated computing resources (100 processes). The simulations of two versions, task configuration version numbers 1 and 2, were executed in parallel, including loading historical data from the last 7 days, performing material loading, filtering, and allocation, and outputting the allocation results for both versions. Then, the changes in various indicators were calculated, revealing that the agent allocation coverage increased by z1%, because the maximum order volume for agents increased, allowing more agents to accept orders; at the same time, it was found that the order volume share of the top 10% of agents increased by z2%, indicating a risk of over-concentration. The analysis report is displayed on the front end, and the product team decides whether to implement the configuration change based on the report. The overall process takes less time and efficiency is greatly improved.

[0135] Based on any of the above embodiments, this disclosure also provides a data processing apparatus. Figure 10This is a schematic block diagram of the structure of a data processing apparatus according to one embodiment of the present disclosure. Figure 10 As shown, the data processing device includes: a configuration information determination module 100, a simulation processing module 200, and an index change determination module 300.

[0136] The configuration information determination module 100 is used to determine the simulation configuration information of the task to be simulated. The task to be simulated is used to simulate a processed task request. The task configuration represented by the simulation configuration information and the task configuration applied when the processed task request is processed have at least one configuration item that is different. The task configuration includes multiple configuration items used to provide the parameters required for the task to be processed.

[0137] The simulation processing module 200 is used to perform simulation processing on the task to be simulated according to the simulation configuration information and obtain the simulation processing results.

[0138] The indicator change determination module 300 is used to determine the changes in task indicators under different task configurations based on the simulation processing results.

[0139] The aforementioned data processing device can be in the form of computer software, and each module of the data processing device can be implemented through computer software modules. The specific implementation process of the functions and roles of each module in the aforementioned device is detailed in the corresponding steps of the aforementioned method, and will not be repeated here.

[0140] The data processing method in the specific embodiments of this disclosure can be executed by an electronic device such as a server.

[0141] Therefore, based on any of the above embodiments, this disclosure also provides an electronic device that can execute the data processing method of any of the embodiments described above.

[0142] Figure 11 This is a schematic block diagram of an electronic device 1000 according to one embodiment of the present disclosure.

[0143] The hardware architecture of the electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application of the hardware and overall design constraints. Bus 1100 connects various circuits, including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400, such as peripheral devices, voltage regulators, power management circuits, external antennas, etc.

[0144] Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, only one connection line is used in this diagram, but this does not imply that there is only one bus or only one type of bus.

[0145] The processor 1200 can be a central processing unit (CPU). The processor 1200 can also be 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, or combinations of the above types of chips.

[0146] The memory 1300 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as program instructions of the computer program in the embodiments of this disclosure. The processor 1200 implements the above-described data processing method by running the non-transitory software programs, instructions, and modules stored in the memory 1300.

[0147] The memory 1300 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created by the processor 1200. Furthermore, the memory 1300 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1300 may optionally include memory remotely located relative to the processor 1200, and these remote memories may be connected to the processor 1200 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0148] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.

[0149] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, the processes or functions of this disclosure are performed wholly or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, network equipment, user equipment, core network equipment, OAM, or other programmable device.

[0150] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.

[0151] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0152] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, systems, and computer program products according to this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0153] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0154] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0155] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., refer to specific features, structures, or characteristics described in connection with that embodiment / mode or example, which are included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.

[0156] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0157] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

Claims

1. A data processing method, characterized by, include: Determine the simulation configuration information of the task to be simulated. The task to be simulated is used to simulate the processed task request. The task configuration represented by the simulation configuration information and the task configuration applied when the processed task request is processed have at least one configuration item that is different. The task configuration includes multiple configuration items to provide the parameters required for the task to be processed. The simulation task is processed according to the simulation configuration information to obtain the simulation processing result. as well as Based on the simulation results, the changes in task indicators under different task configurations are determined.

2. The data processing method according to claim 1, characterized in that, The multiple configuration items in the task configuration correspond to multiple levels divided according to the processing order. In two levels that are adjacent in the processing order, the configuration items contained in the later level are used to provide the parameters required to process the data determined by the configuration items contained in the earlier level.

3. The data processing method according to claim 1 or 2, characterized in that, The method of processing the task request includes determining the data receiver corresponding to the data to be allocated, and the multiple levels corresponding to the multiple configuration items in the task configuration include the allocation level; The simulation process for the task to be simulated is performed according to the simulation configuration information, including: Based on the parameters provided by the configuration items of the allocation level included in the simulation configuration information, the data receiver corresponding to the data to be allocated in the simulation task is determined, and the processed task request indicates that the data receiver corresponding to the data to be allocated has been determined.

4. The data processing method according to claim 3, characterized in that, Based on the parameters provided by the configuration items of the allocation level included in the simulation configuration information, determine the data receiver corresponding to the data to be allocated in the simulation task, including: For multiple task requests included in the task to be simulated, if the request time of a task request is reached, then the task request that has reached the request time is taken as the target request; and Based on the parameters provided by the configuration items of the allocation level included in the simulation configuration information, determine the data recipient corresponding to the data to be allocated in the target request.

5. The data processing method according to claim 4, characterized in that, Based on the parameters provided by the configuration items of the allocation level included in the simulation configuration information, the data receiver corresponding to the data to be allocated in the target request is determined, including: Based on the parameters provided by the configuration items of the first level in the allocation hierarchy included in the simulation configuration information, candidate objects are determined from the requirement objects provided by the task to be simulated; Based on the parameters provided by the configuration items in the second level of the allocation hierarchy, candidate receivers are determined from the data receivers associated with the candidate objects; and Based on the parameters provided by the configuration items of the third level in the allocation hierarchy, the data receiver corresponding to the data to be allocated in the target request is determined from the candidate receivers.

6. The data processing method according to claim 1 or 2, characterized in that, After determining the changes in task metrics under different task configurations based on the simulation results, the method further includes: The evaluation information of the changes is generated and output. The evaluation information is used to represent the correlation between the changed task indicators and the configuration items that caused the changes in the task indicators.

7. The data processing method according to claim 1, characterized in that, Before performing simulation processing on the task to be simulated according to the simulation configuration information, the method further includes: The stored task data and corresponding stored synchronization data are compared. The task data is related to the processed task request. The task data is synchronized to the data provider to form the synchronization data. The data provider provides the synchronization data as the synchronization data required for simulation. If it is determined that the task data to be compared and the synchronized data are different, then the data synchronization is considered abnormal.

8. The data processing method according to claim 7, characterized in that, The task data used for comparison includes one or more of the following: request data in the task request, descriptive data describing the initiator of the task request, and descriptive data describing the task receiver that matches the task request.

9. An electronic device, characterized in that, include: The memory stores execution instructions; as well as A processor that executes execution instructions stored in the memory, causing the processor to perform the data processing method according to any one of claims 1 to 8.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, is used to implement the data processing method according to any one of claims 1 to 8.

Images