Service decision-making method and device

Abstract

The invention provides a service decision-making method and device, and the method comprises the steps: responding to an execution cycle of a batch decision-making task, loading to-be-decided service data associated with the batch decision-making task, and loading a service decision-making logic bound with the batch decision-making task; partitioning a plurality of first data records based on service identifiers of the plurality of first data records in the to-be-decided service data to obtain a plurality of data partitions; the first data records in the multiple data partitions are subjected to service decision making in parallel through service decision making logic, so that service decision making results of the first data records are generated, and therefore the processing throughput and response efficiency of large-batch service data can be improved, and decision making delay of the large-batch service data can be greatly shortened; and meanwhile, the data of the same service entity or the associated context is aggregated in the same data partition for processing, so that the problem of service decision logic conflict is effectively avoided, and the logic correctness and service compliance of a decision result are guaranteed.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to a business decision-making method and apparatus. Background Technology

[0002] In the financial sector, business decisions are widely applied in core scenarios such as credit approval, risk control, investment management, customer service, and anti-fraud, profoundly impacting an institution's asset security, operational efficiency, and compliance capabilities. Faced with an increasingly complex market environment, constantly evolving customer needs, and continuously evolving risk factors, financial institutions urgently need to make rapid and accurate assessments of the feasibility or risk level of their business operations. Therefore, the ability to make efficient business decisions is of paramount importance. Summary of the Invention

[0003] This disclosure provides a business decision-making method and apparatus to at least partially solve one of the technical problems in the related art. The technical solution of this disclosure is as follows: According to a first aspect of the present disclosure, a business decision-making method is provided, comprising: in response to the arrival of an execution cycle of a batch decision-making task, loading business data to be decided associated with the batch decision-making task, and loading business decision logic bound to the batch decision-making task; partitioning the plurality of first data records in the business data to be decided based on business identifiers of the plurality of first data records to obtain a plurality of data partitions; and using the business decision logic to perform business decisions on the first data records in the plurality of data partitions in parallel to generate business decision results for each of the first data records.

[0004] According to a second aspect of the present disclosure, a business decision-making apparatus is provided, comprising: a loading module, configured to load business data to be decided associated with the batch decision-making task and load business decision logic bound to the batch decision-making task in response to the arrival of the execution cycle of the batch decision-making task; The partitioning module is used to partition the multiple first data records in the business data to be decided based on the business identifiers of the multiple first data records to obtain multiple data partitions; the decision module is used to use the business decision logic to perform business decisions on the first data records in the multiple data partitions in parallel to generate business decision results for each of the first data records.

[0005] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement a business decision-making method as described in the first aspect of the present disclosure.

[0006] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform a business decision-making method as described in the first aspect of the present disclosure.

[0007] According to a fifth aspect of the present disclosure, a computer program product is provided, comprising: a computer program that, when executed by a processor, implements the business decision-making method as described in the first aspect of the present disclosure.

[0008] The technical solutions provided by the embodiments of this disclosure have at least the following beneficial effects: In this technical solution, when a batch decision-making task reaches its execution cycle, the associated business data to be decided and the bound business decision logic are automatically loaded. The data is then partitioned based on the business identifier of each first data record, forming multiple independent data partitions. The business decision logic is then used to execute decision processing on each partition in parallel, which improves the processing throughput and response efficiency of large-scale business data and significantly reduces the decision latency. Simultaneously, data from the same business entity or related context is aggregated within the same data partition for processing, effectively avoiding business decision logic conflicts and ensuring the logical correctness and business compliance of the decision results. Specifically, when making business decisions on the first data records in multiple data partitions in parallel, the business tags associated with each data partition are used to select the appropriate data from multiple business data partitions. The system determines the matching target logic within the business decision-making logic and processes data records in each partition in parallel based on this target logic, reducing business decision-making time and improving the accuracy and compliance of decisions. Furthermore, when multiple business tags are associated with data records in any data partition, the system selects the highest-priority tag from the multiple business tags associated with any data partition as the target business tag according to a preset tag priority order, and determines the matching target business decision-making logic accordingly. Alternatively, the multiple business tags associated with any data partition can be combined into a composite tag, and the mapping table can be queried based on this composite tag to determine the matching target business decision-making logic. This effectively avoids business tag conflicts or semantic loss and significantly improves the system's adaptability and intelligence level to business scenarios.

[0009] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0010] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0011] Figure 1This is a flowchart illustrating the business decision-making method shown in the first embodiment of this disclosure; Figure 2 This is a flowchart illustrating the business decision-making method shown in the second embodiment of this disclosure; Figure 3 This is a flowchart illustrating the business decision-making method shown in the third embodiment of this disclosure; Figure 4 This is a schematic diagram illustrating the principle of the business decision-making method shown in the embodiments of this disclosure; Figure 5 This is a schematic diagram of the business decision-making device shown in the fourth embodiment of this disclosure; Figure 6 This is a schematic diagram of the structure of an electronic device shown in an exemplary embodiment of the present disclosure. Detailed Implementation

[0012] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0013] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0014] It should be noted that the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in the technical solution disclosed herein are all carried out with the consent of the user, and all comply with the provisions of relevant laws and regulations, and do not violate public order and good morals.

[0015] In current decision engine systems, batch decision-making typically refers to the centralized execution of predefined rules or strategies on large amounts of data (such as users, orders, and transactions) to achieve automated judgment or scoring. This is commonly seen in risk control, marketing, and credit scenarios. The main technical implementation methods include: (1) Batch execution based on rule engines: Use rule engines such as Drools, FICO Blaze, and IBM ODM to perform centralized inference on the dataset through Stateless Session or batch command (Command-based Execution). For example, perform abnormal behavior detection on 1 million users in batches every morning to determine whether they meet the preset trust conditions and output the risk level.

[0016] (2) Integration with big data platforms: embed decision-making logic into big data processing frameworks such as Apache Spark, Flink, and Hive, and utilize distributed computing capabilities to execute rules in parallel. Example: Spark reads user behavior logs and calls user-defined functions (UDFs) to execute rule judgments.

[0017] (3) Scheduled task scheduling + decision pipeline: Use scheduling tools (such as Airflow, Quartz, KubernetesCronJob) to trigger batch decision tasks, forming a pipeline of "data loading → feature extraction → rule execution → result output".

[0018] (4) Micro-batching: In the integrated stream and batch architecture, data is processed in batches according to time windows (e.g., every 5 minutes), taking into account both real-time performance and throughput.

[0019] (5) Batch call to the decision service API: The decision engine exposes a REST / gRPC interface, which is called by external systems in a loop (e.g., 1000 messages per batch) to achieve batch decision-making.

[0020] However, the above technologies still have the following problems and bottlenecks: (1) Performance bottleneck: The performance of the rule engine drops significantly when processing large-scale data, especially for complex rules (such as the Rete algorithm which has high memory usage), making it difficult to support throughput of millions per second.

[0021] (2) Poor scalability: Traditional rule engines (such as Drools) are mostly single-machine or limited cluster modes, which are difficult to scale horizontally and cannot make full use of distributed computing resources.

[0022] (3) Delay in rule compilation and deployment: after rule changes, they need to be recompiled and deployed. Batch tasks cannot dynamically load the latest rules, resulting in delayed decision-making.

[0023] (4) Lack of unified batch scheduling and monitoring. Batch tasks are scattered across different scripts or scheduling systems, lacking unified execution status tracking, failure retry, and log auditing capabilities.

[0024] (5) The consistency and idempotency of the results are difficult to guarantee. If a failure and restart occur during batch execution, it is easy to cause duplicate or missed decisions and lack transactional guarantees.

[0025] (6) The rules and data are highly coupled. The rule logic often depends on a specific data structure. When the input data format changes, a lot of rules need to be modified, resulting in high maintenance costs.

[0026] (7) Insufficient observability: Batch decision-making lacks fine-grained execution path tracking, making it difficult to pinpoint why a record is rejected or scored abnormally.

[0027] (8) It is difficult to integrate with machine learning models. The rule engine and ML model (such as Python model) have different operating environments. When performing batch inference, cross-system calls are required, resulting in low efficiency and high latency.

[0028] To address any of the above-mentioned problems, this disclosure proposes a business decision-making method and apparatus.

[0029] The business decision-making method of embodiments of this disclosure is described below with reference to the accompanying drawings.

[0030] Figure 1 This is a flowchart illustrating the business decision-making method shown in the first embodiment of this disclosure.

[0031] like Figure 1 As shown, this business decision-making method includes the following steps: Step 110: In response to the arrival of the execution cycle of the batch decision task, load the business data to be decided associated with the batch decision task, and load the business decision logic bound to the batch decision task.

[0032] To automate the triggering and context preparation of batch decision-making tasks, one possible approach is to automatically load the business data to be decided associated with the batch decision-making task when the execution cycle of the batch decision-making task is reached (e.g., 2:00 AM every day), and simultaneously load the business decision logic bound to the task.

[0033] The business data to be decided includes, for example, a batch of loan application records awaiting approval or transaction records awaiting verification. The business decision logic may include a set of business decision rules and / or at least one business decision model. The set of business decision rules may include multiple business decision rules, such as: "If the customer's number of overdue payments is ≥ 3 and the debt ratio is > 80%, then the application will be rejected." The business decision model may be a machine learning model, such as logistic regression, gradient boosting tree, neural network, etc., which can be used to quantitatively evaluate complex nonlinear features, such as outputting default probability, risk score, or recommendation level.

[0034] In some embodiments, such as Figure 2As shown, loading the business decision logic bound to the batch decision task may include the following steps: Step 1101: In response to the arrival of the execution cycle of the batch decision task, the latest version of the business decision rule set associated with the batch decision task is retrieved from the database through the decision engine.

[0035] In this embodiment of the disclosure, the business decision logic includes at least one of the following: a business decision rule set and at least one business decision model. When the business decision logic includes a decision rule set, in order to avoid decision deviations caused by the lag in the version of the decision rules, as a possible implementation, when the preset execution cycle of a certain batch of decision tasks is detected to arrive, the decision engine actively initiates a query to the rule storage database to obtain the latest version of the business decision rule set bound to the batch of decision tasks.

[0036] Step 1102: Using the decision engine, read at least one latest version of the business decision model associated with the batch decision task from the model repository.

[0037] To avoid decision-making biases caused by outdated business decision-making model versions, in this embodiment of the disclosure, the decision engine also accesses a model repository, such as a model registry, object storage, or dedicated model service, to read the latest version of the business decision-making model associated with the batch task, such as a logistic regression model, gradient boosting tree (GBDT), deep neural network, or scoring card.

[0038] Step 1103: Cache the business decision rule set and / or at least one business decision model to the local memory of the decision engine.

[0039] To improve the processing efficiency and resource utilization of the batch decision-making process, in this embodiment of the disclosure, the business decision rule set and / or at least one business decision model are preloaded into memory before the task is executed, avoiding frequent access to external storage when processing each data record, and significantly reducing related overhead and latency.

[0040] In summary, by having the decision engine proactively retrieve the latest version of the business decision rule set associated with the task from the database when the batch decision task reaches its execution cycle, and simultaneously read the corresponding latest version of the business decision model from the model repository, and then cache the obtained rule set and / or model in the decision engine's local memory, it is ensured that each batch decision is based on the latest business decision logic, effectively avoiding misjudgments caused by version lag or inconsistency. In addition, by storing the latest version of the business decision logic in the decision engine's local memory before the batch decision task is executed, repeated access to external storage during task execution can be reduced, significantly reducing resource overhead and network latency.

[0041] Step 120: Based on the business identifiers of multiple first data records in the business data to be decided, partition the multiple first data records to obtain multiple data partitions.

[0042] To achieve ordered processing of business data in high-concurrency scenarios, one possible approach is to perform logical partitioning on the batch of data records to be processed (i.e., the first data records) after data loading is complete, thereby generating multiple independent data partitions. For example, multiple first data records can be partitioned based on the business identifier contained in each first data record to obtain multiple data partitions. The business identifier may include, but is not limited to, fields that can uniquely or collectively identify business entities, such as customer ID, order number, organization code, and contract number.

[0043] As one possible implementation, the business type of the business identifier of multiple first data records in the business data to be decided is determined according to the business type mapping rule; the multiple first data records are partitioned according to the business type corresponding to the multiple first data records to obtain multiple data partitions.

[0044] In other words, to accurately determine the business type corresponding to each record, the business identifiers contained in multiple first data records in the business data to be decided are parsed and matched according to preset business type mapping rules, thereby determining the business type corresponding to each first data record. These business identifiers may include, but are not limited to, product codes, transaction categories, customer types, or document numbers, and business types may include "personal consumer loans" or "cross-border payments." Furthermore, based on the business type determined for each first data record, records with the same business type are grouped together, thus dividing all data into multiple data partitions, such as "corporate loan partition" and "credit card approval partition."

[0045] As another possible implementation, the value range of the business identifiers of multiple first data records in the business data to be decided is obtained; the value range is divided according to the set number of partitions to obtain multiple sub-intervals; and the first data records whose business identifiers are located in any sub-interval are assigned to the same data partition.

[0046] In other words, in order to achieve efficient partitioning of the business data to be decided, the value range of the business identifiers of multiple first data records in the business data to be decided is obtained; then, according to the preset number of partitions, the value range is evenly or strategically divided into multiple consecutive sub-intervals, for example, the ID range [1, 1000000] is divided into 10 sub-intervals, each containing 100,000 IDs; finally, all first data records whose business identifiers fall within the same sub-interval are grouped into the same data partition.

[0047] Step 130: Using business decision logic, business decisions are made in parallel on the first data record in multiple data partitions to generate business decision results for each first data record.

[0048] To achieve efficient execution and optimized resource utilization for large-scale business decisions, one possible approach is to invoke the loaded business decision logic and perform decision calculations in parallel on the data records in each data partition. After each first data record is processed by the decision logic, the corresponding business decision result is output, such as "pass / reject", "risk level A / B / C", or "requires manual review".

[0049] To achieve idempotent writing and incremental updates of batch decision results, one possible approach is to first obtain the sub-identifier (such as partition ID) under the batch ID of the batch decision task to which the data partition belongs after completing the business decision for each data partition. Then, for any first data record in any data partition, while obtaining its business decision result, a query is performed in the database to check whether a second data record already exists, associated with both the sub-identifier and the record identifier (such as primary key ID, business serial number, etc.), based on the sub-identifier corresponding to the partition and the record identifier itself. This second data record is used to persistently store the business decision result corresponding to the first data record. If the query result is not found, the currently generated business decision result is written to the database and stored as a new second data record. This effectively avoids duplicate writing or overwriting of results due to task retries, repeated partition processing, or system anomaly recovery, ensuring that each decision result is persisted only once within the same batch and record context.

[0050] Furthermore, to achieve traceability and real-time monitoring of the batch business decision-making process, after generating the business decision result for any first data record in any data partition, a structured decision record can be generated by combining the decision result of that first data record with its corresponding decision context. The decision context explicitly indicates the key decision elements relied upon in generating the decision result, including but not limited to the business rule version used, decision model identifier, input feature fields, threshold parameters, business tags, timestamps, execution time, and rule hit status. Subsequently, the system uniformly reports the decision records corresponding to each first data record to the monitoring system, enabling operations and maintenance personnel to track and verify the logical basis, execution path, and compliance of each decision result.

[0051] To achieve efficient delivery of batch decision results, one possible approach is to standardize the message encapsulation of the business decision results of each first data record, generating decision messages with clear structure and complete semantics. Then, through a pre-defined message queue, such as Kafka, RabbitMQ, or RocketMQ, these decision messages are sent asynchronously to downstream business systems. This allows downstream systems to consume decision messages on demand without blocking the main decision-making process and execute corresponding subsequent business operations based on the decision results contained within. Downstream systems may include, but are not limited to, approval engines, notification services, accounting modules, or manual review platforms.

[0052] In some implementations, such as Figure 3 As shown, step 130 may include the following steps: Step 1301: For any data partition, based on the business tag associated with the first data record in any data partition, determine the target business decision logic that matches any data partition from multiple business decision logics.

[0053] To achieve a precise match between business decision logic and data partitioning, one possible approach is to determine the business tags associated with the first data record in any data partition after data partitioning is completed, such as "corporate loans" or "cross-border transactions". These business tags reflect the business attributes or processing context of the data. Then, based on these business tags, the target business decision logic that best matches the semantics and business characteristics of the current partition is selected from multiple business decision logics.

[0054] It should be noted that each first data record can be associated with one or more business tags. For example, a first data record can be associated with business tags such as "corporate loan", "cross-border transaction" and "high-risk customer". The business tags associated with each first data record can be directly extracted from the preset business fields of the first data record, or the business tags of the first data record can be output by parsing the first data record using a classification model.

[0055] As an example, if there is only one business tag associated with a data record in any data partition, the tag logic mapping table is queried to obtain the target business decision logic identifier corresponding to that business tag, and the corresponding target business decision logic is loaded. The tag logic mapping table includes the mapping relationship between business tags and business decision logic.

[0056] As another example, when there are multiple business tags associated with data records in any data partition, the target business tag with the highest priority is selected from the multiple business tags associated with the first data record in any data partition according to the set tag priority order, and the target business decision logic matching any data partition is determined based on the target business tag.

[0057] In other words, when there are multiple business tags associated with the first data record in any data partition, the highest priority tag can be selected from the multiple business tags associated with any data partition as the target business tag according to a preset tag priority order. Subsequently, based on the target business tag, a preset tag decision logic mapping table is queried to determine the target business decision logic that matches any data partition.

[0058] As another example, when there are multiple business tags associated with data records in any data partition, the multiple business tags associated with the first data record in any data partition are combined to obtain a composite tag corresponding to any data partition. Based on the composite tag corresponding to any data partition, the composite tag logical mapping table is queried to obtain the target business decision logic that matches any partition. The composite tag logical mapping table includes the mapping relationship between the composite tag and the business decision logic.

[0059] In other words, multiple business tags associated with data records in any data partition can be combined, such as concatenating these business tags to generate a composite tag for that data partition. Then, based on this composite tag, a pre-built composite tag logical mapping table can be queried to obtain the target business decision logic that matches any partition. It should be noted that the composite tag logical mapping table includes the mapping relationship between the composite tag and the business decision logic.

[0060] Step 1302: Using the target business decision logic that matches each data partition, business decisions are made in parallel on the first data record in each data partition.

[0061] To reduce the delay in business decisions, one possible approach is to use target business decision logic that is matched to each data partition, and to make business decisions in parallel on the first data record in each data partition.

[0062] In summary, by dynamically determining the target business decision logic matching any data partition based on the business tag associated with the first data record within it from multiple business decision logics, and then using the target business decision logic corresponding to each data partition to process the first data record in each data partition in parallel, business decision time is reduced and the accuracy and compliance of decisions are improved.

[0063] The business decision-making method of this disclosure automatically loads the associated business data to be decided and the bound business decision logic when the batch decision-making task reaches its execution cycle, and partitions the data based on the business identifier of each first data record to form multiple independent data partitions. Then, the business decision logic is used to perform decision processing on each partition in parallel, which can improve the processing throughput and response efficiency of large batches of business data, and significantly shorten the decision latency of large batches of business data. At the same time, since the partitioning is based on the business identifier, the data of the same business entity or related context is aggregated and processed in the same partition, which effectively avoids the problem of business decision logic conflict and ensures the logical correctness and business compliance of the decision results.

[0064] Based on any of the above embodiments, such as Figure 4 As shown, the business decision-making method of this disclosure embodiment may include the following steps: Step 410, Task Scheduling and Data Preparation (Solving the "Scheduling Chaos" Problem) Principle: Use a declarative scheduling system to manage batch tasks in a unified manner, avoiding scattered scripts; Implementation logic: Define scheduled tasks through Dolphinscheduler, such as executing at 2:00 every day. After the task is triggered, load the business data to be decided from the data lake (such as Delta Lake, Hive) or the database.

[0065] Step 420: Dynamic loading of rules and models (solving the "deployment delay" problem) Principle: Business decision rules and business decision models are managed through versioning and cached push, eliminating the need to restart the service; Implementation logic: Business decision rules are stored in the database in structured data or JSON format, and business decision models are uploaded to the system in PMML or pkl format; when the decision engine pushes cached data, it pulls the latest version from the database.

[0066] Step 430, Distributed Parallel Decision Execution (Solving the "Performance and Scalability" Problem) Principle: Utilize the Spark distributed computing engine to embed rules and models into RDD / DataFrame operations; Implementation logic: The data is divided into multiple partitions; each partition executes decision logic independently on the Executor; hybrid execution is supported: joint judgment based on rules and models; Step 440, Idempotent Write and Fault Tolerance Mechanism (Solving the "Consistency" Problem) Principle: Ensures each record is processed only once, and allows for recovery in case of failure; Implementation logic: Each batch subtask (one batch subtask corresponds to each data partition) generates a unique sub-identifier under the batch identifier. Before the decision result is written to the database, it is checked whether there are data records in the database associated with the sub-identifier and the record identifier corresponding to the decision result. Then, idempotency is achieved by using Kafka + transaction writing or database Upsert.

[0067] Step 450, End-to-end monitoring and tracing (addressing the "insufficient observability" problem) Principle: Generate a unique trace_id for each decision record, recording the complete execution path; Implementation logic: Generate the trace_id of the decision record; the decision record can be used to record rule hit status, model input and output, and execution time; report the decision record to the monitoring system (Prometheus + Jaeger + ELK). Step 460: Asynchronous notification of results and linkage with downstream processes. Principle: After a decision is made, downstream systems are notified via a message queue; Implementation logic: Write the results to a Kafka topic or send an email / SMS; trigger subsequent processes (such as approval workflows, marketing campaigns).

[0068] Corresponding to the business decision-making method provided in the above embodiments, this disclosure also provides a business decision-making device. Since the business decision-making device provided in this disclosure corresponds to the business decision-making method provided in the above embodiments, the implementation of the business decision-making method is also applicable to the business decision-making device provided in this disclosure, and will not be described in detail in this disclosure.

[0069] Figure 5 This is a schematic diagram of the business decision-making device shown in the fourth embodiment of this disclosure.

[0070] like Figure 5 As shown, the business decision-making device 500 includes: a loading module 510, a partitioning module 520, and a decision-making module 530.

[0071] The loading module 510 is used to load the business data to be decided associated with the batch decision task and the business decision logic bound to the batch decision task in response to the execution cycle of the batch decision task; the partitioning module 520 is used to partition the multiple first data records in the business data to be decided based on the business identifiers of the multiple first data records in the business data to be decided, so as to obtain multiple data partitions; the decision module 530 is used to use the business decision logic to make business decisions on the first data records in the multiple data partitions in parallel, so as to generate the business decision results of each first data record.

[0072] As one possible implementation, the decision module 530 is used to determine, for any data partition, a target business decision logic matching any data partition from multiple business decision logics based on the business tag associated with the first data record in any data partition; and to perform business decisions on the first data record in each data partition in parallel using the target business decision logic matching each data partition.

[0073] As one possible implementation, multiple business tags are associated with data records in any data partition. The decision module 530 is used to select the highest priority target business tag from the multiple business tags associated with the first data record in any data partition according to a set tag priority order, and determine the target business decision logic matching the any data partition based on the target business tag; or, the multiple business tags associated with the first data record in any data partition are combined to obtain a composite tag corresponding to any data partition, and a composite tag logic mapping table is queried based on the composite tag corresponding to any data partition to obtain the target business decision logic matching any partition; wherein, the tag logic mapping table includes the mapping relationship between composite tags and business decision logic.

[0074] As one possible implementation, the business decision-making device 500 also includes a storage module.

[0075] The storage module is used to obtain the sub-identifiers under the batch identifier of the batch decision task where each data partition is located; for any data partition, based on the sub-identifier corresponding to any data partition and the record identifier associated with the business decision result of any first data record in any data partition, it queries whether there is a second data record associated with the sub-identifier and record identifier corresponding to any data partition in the database; wherein the second data record is used to store the business decision result of any first data record; in response to the absence of a second data record in the database, the business decision result of any first data record is stored in the database. As one possible implementation, the business decision-making device 500 also includes a reporting module.

[0076] The reporting module is used to generate a decision record for any first data record in any data partition, based on the decision result and decision context of the first data record. The decision context is used to indicate the decision elements relied upon in the decision-making process of generating the decision result of any first data record. The decision records of each first data record are reported to the monitoring system to monitor the decision results and decision-making process of each first data record.

[0077] As one possible implementation, the business decision-making device 500 also includes a sending module.

[0078] The sending module is used to encapsulate the decision results of each first data record into a message to obtain a decision message; by setting a message queue, the decision message corresponding to each first data record is asynchronously sent to the downstream system so that the downstream system can perform subsequent business processing according to the decision results in each decision message.

[0079] As one possible implementation, the partitioning module 520 is used to determine the business type of the business identifier of multiple first data records in the business data to be decided according to the business type mapping rules; and to partition the multiple first data records according to the business types corresponding to the multiple first data records to obtain multiple data partitions.

[0080] As one possible implementation, the partitioning module 520 is used to obtain the value range of the business identifiers of multiple first data records in the business data to be decided; divide the value range according to the set number of partitions to obtain multiple sub-intervals; and assign the first data records whose business identifiers are located in any sub-interval to the same data partition.

[0081] As one possible implementation, the business decision logic includes at least one of a business decision rule set and at least one business decision model; a loading module 510 is used to, in response to the arrival of the execution cycle of the batch decision task, pull the latest version of the business decision rule set associated with the batch decision task from the database through the decision engine; read the latest version of at least one business decision model associated with the batch decision task from the model repository through the decision engine; and cache the business decision rule set and / or at least one business decision model in the local memory of the decision engine.

[0082] The business decision-making device of this disclosure automatically loads the associated business data to be decided and the bound business decision logic when the batch decision-making task reaches its execution cycle, and partitions the data based on the business identifier of each first data record to form multiple independent data partitions. Then, the business decision logic is used to perform decision processing on each partition in parallel, which can improve the processing throughput and response efficiency of large batches of business data, and significantly shorten the decision delay of large batches of business data. At the same time, since the partitioning is based on the business identifier, the data of the same business entity or related context is aggregated in the same partition for processing, which effectively avoids the problem of business decision rule conflict and ensures the logical correctness and business compliance of the decision results.

[0083] In an exemplary embodiment, an electronic device is also proposed.

[0084] The electronic devices include: processor; Memory used to store processor-executable instructions; The processor is configured to execute instructions to implement the business decision-making method as proposed in any of the foregoing embodiments.

[0085] As an example, Figure 6 This is a schematic diagram of the structure of an electronic device 600 as shown in an exemplary embodiment of this disclosure, as follows: Figure 6 As shown, the aforementioned electronic device 600 may further include: The memory 610 and processor 620 are connected by a bus 630, which connects different components (including the memory 610 and the processor 620). The memory 610 stores a computer program, which implements the business decision-making method described in the embodiments of this disclosure when the processor 620 executes the program.

[0086] Bus 630 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0087] Electronic device 600 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 600, including volatile and non-volatile media, removable and non-removable media.

[0088] Memory 610 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 640 and / or cache memory 650. Electronic device 600 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 660 can be used to read and write non-removable, non-volatile magnetic media (… Figure 6 Not shown; usually referred to as a "hard drive"). Although Figure 6 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 630 via one or more data media interfaces. Memory 610 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this disclosure.

[0089] A program / utility 680 having a set (at least one) of program modules 670 may be stored, for example, in memory 610. Such program modules 670 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 670 typically perform the functions and / or methods described in the embodiments of this disclosure.

[0090] Electronic device 600 can also communicate with one or more external devices 690 (e.g., keyboard, pointing device, display 691, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 692. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 693. As shown, network adapter 693 communicates with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0091] The processor 620 executes various functional applications and data processing by running programs stored in the memory 610.

[0092] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the business decision-making method of this disclosure embodiment, and will not be repeated here.

[0093] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory including instructions, which can be executed by a processor of an electronic device to perform the business decision-making method proposed in any of the above embodiments. Optionally, the computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0094] In an exemplary embodiment, a computer program product is also provided, including a computer program / instructions, characterized in that the computer program / instructions, when executed by a processor, implement the business decision-making method proposed in any of the above embodiments.

[0095] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0096] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A business decision-making method, characterized in that, include: In response to the arrival of the execution cycle of the batch decision task, the business data to be decided associated with the batch decision task is loaded, and the business decision logic bound to the batch decision task is loaded. Based on the business identifiers of multiple first data records in the business data to be decided, the multiple first data records are partitioned to obtain multiple data partitions; Using the aforementioned business decision logic, business decisions are made in parallel on the first data records in the multiple data partitions to generate business decision results for each of the first data records.

2. The method according to claim 1, characterized in that, The step of employing the business decision logic to perform business decisions on the first data records in the multiple data partitions in parallel, in order to generate business decision results for each of the first data records, includes: For any data partition, based on the business tag associated with the first data record in the data partition, a target business decision logic matching the data partition is determined from the plurality of business decision logics; The target business decision logic, which is matched with each of the data partitions, is used to make business decisions on the first data record in each of the data partitions in parallel.

3. The method according to claim 2, characterized in that, The business tags associated with the data records in any of the data partitions are multiple. For any data partition, determining the target business decision logic matching the data partition from the plurality of business decision logics based on the business tag associated with the first data record in the data partition includes: According to the set tag priority order, select the target business tag with the highest priority from multiple business tags associated with the first data record in any data partition, and determine the target business decision logic that matches any data partition based on the target business tag; or, Multiple business tags associated with the first data record in any data partition are combined to obtain a composite tag corresponding to any data partition. Based on the composite tag corresponding to any data partition, the composite tag logical mapping table is queried to obtain the target business decision logic matching any partition. The tag logical mapping table includes the mapping relationship between the composite tag and the business decision logic.

4. The method according to claim 1, characterized in that, The method further includes: Obtain the sub-identifier under the batch identifier of the batch decision task for each of the data partitions; For any data partition, based on the sub-identifier corresponding to the data partition and the record identifier associated with the business decision result of any first data record in the data partition, query the database to see if there is a second data record associated with the sub-identifier and record identifier corresponding to the data partition; wherein, the second data record is used to store the business decision result of any first data record; In response to the absence of the second data record in the database, the business decision result of any first data record is stored in the database.

5. The method according to claim 1, characterized in that, The method further includes: For any first data record in any data partition, a decision record for the first data record is generated based on the decision result and decision context of the first data record; wherein, the decision context is used to indicate the decision elements relied upon in the decision-making process of generating the decision result of the first data record. The decision records of each of the first data records are reported to the monitoring system in order to monitor the decision results and decision process of each of the first data records.

6. The method according to claim 1, characterized in that, The method further includes: The decision results of each of the first data records are encapsulated into a message to obtain a decision message; By setting up a message queue, the decision messages corresponding to each of the first data records are asynchronously sent to the downstream system, so that the downstream system can perform subsequent business processing based on the decision results in each decision message.

7. The method according to claim 1, characterized in that, The step of partitioning the multiple first data records in the business data to be decided based on the business identifiers of the multiple first data records to obtain multiple data partitions includes: Based on the business type mapping rules, determine the business type of the business identifiers of multiple first data records in the business data to be decided; Based on the business type corresponding to the multiple first data records, the multiple first data records are partitioned to obtain multiple data partitions.

8. The method according to claim 1, characterized in that, The step of partitioning the multiple first data records in the business data to be decided based on the business identifiers of the multiple first data records to obtain multiple data partitions includes: Obtain the value range of the business identifier of multiple first data records in the business data to be decided; The value range is divided according to the set number of partitions to obtain multiple sub-intervals; The first data record whose business identifier is located in any sub-interval is assigned to the same data partition.

9. The method according to claim 1, characterized in that, The business decision logic includes at least one of the following: a set of business decision rules and at least one business decision model. Loading the business decision logic bound to the batch decision task includes: In response to the arrival of the execution cycle of the batch decision task, the decision engine pulls the latest version of the business decision rule set associated with the batch decision task from the database; The decision engine reads at least one latest version of a business decision model associated with the batch decision task from the model repository. The business decision rule set and / or at least one business decision model are cached in the local memory of the decision engine.

10. A business decision-making device, characterized in that, include: The loading module is used to load the business data to be decided associated with the batch decision task and the business decision logic bound to the batch decision task in response to the arrival of the execution cycle of the batch decision task. The partitioning module is used to partition the multiple first data records in the business data to be decided based on the business identifiers of the multiple first data records, so as to obtain multiple data partitions; The decision module is used to apply the business decision logic to make business decisions on the first data records in the multiple data partitions in parallel, so as to generate business decision results for each of the first data records.

Images