Service decision-making method and device

Abstract

The invention provides a business decision-making method and device. The method comprises the following steps: acquiring an offline feature of a target object for handling a target business from a specified database; wherein the offline feature is used for indicating a statistical result of historical business data of businesses handled by the target object, and the offline feature is data source information and feature calculation logic defined by a visual configuration interface; performing batch processing calculation on historical business data from a feature data source corresponding to the data source information to obtain and store the historical business data in a specified database; according to the offline features, business decision making is carried out on the target business, so that the offline features are calculated in real time without compiling codes, the technical difficulty of non-technical personnel participating in feature engineering is remarkably reduced, meanwhile, delay and resource consumption caused by real-time calculation are avoided, and the stability and response efficiency of a decision making system are improved.

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, directly impacting an institution's asset security, operational efficiency, and compliance capabilities. Faced with a complex market environment, diverse customer needs, and dynamically changing risk factors, financial institutions need to quickly and accurately assess the feasibility and risk level of their operations. Every decision can affect the flow of funds, customer experience, and institutional reputation; therefore, how to make 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: obtaining offline features of a target object handling a target business from a specified database; wherein the offline features are used to indicate statistical results of historical business data of the target object's completed business, and the offline features are obtained by batch processing and calculating historical business data from the feature data source corresponding to the data source information through a visual configuration interface and feature calculation logic, and stored in the specified database; and making a business decision on the target business based on the offline features.

[0004] According to a second aspect of the present disclosure, a business decision-making apparatus is provided, comprising: an acquisition module, configured to acquire offline features of a target object handling a target business from a specified database; wherein the offline features are used to indicate statistical results of historical business data of the target object's completed business, and the offline features are obtained by batch processing and calculating historical business data from the feature data source corresponding to the data source information through a visual configuration interface and feature calculation logic, and stored in the specified database; and a decision-making module, configured to make a business decision on the target business based on the offline features.

[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, offline features of the target object handling the target business are obtained from a specified database to make business decisions. This avoids the latency and resource consumption caused by real-time calculation of offline features, improving the stability and response efficiency of the decision-making system. Furthermore, the offline features are obtained by batch processing historical business data based on data source information and feature calculation logic defined in a visual configuration interface and stored in a specified database. This allows the feature engineering process to be completed without writing code, significantly lowering the collaboration threshold between business and technical personnel. Specifically, the offline features of the target object are obtained by loading a scheduled task generated based on the data source information and feature calculation logic defined in the visual interface. Based on the pre-set task scheduling strategy and execution script in the scheduled task, historical business data of the target object is obtained from the feature data source, and then processed according to the feature calculation logic. The system batch processes historical business data to generate offline features, which are then stored in a designated database configured for scheduled tasks. This automates the generation of offline features, improves development efficiency, reduces reliance on manual coding, supports non-technical personnel in feature construction, and enhances system maintainability and scalability. Specifically, it automatically generates data processing query statements based on task-related configuration information. These queries are then encapsulated with the configuration information to construct scheduled tasks. This allows users to define complex feature logic without manually writing SQL or scripts, lowering the technical barrier and improving the efficiency and consistency of task construction. It avoids syntax errors and logical deviations introduced by manual coding and supports non-technical personnel in participating in the feature development process through visual configuration, further enhancing system maintainability.

[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 1 This 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 flowchart illustrating the business decision-making method shown in the fourth embodiment of this disclosure; Figure 5 This is a schematic diagram illustrating the principle of the business decision-making method shown in the embodiments of this disclosure; Figure 6 This is a schematic diagram of the business decision-making device shown in the fifth embodiment of this disclosure; Figure 7 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 related technologies, the offline feature development model used for business decision-making relies heavily on manual coding, which has problems such as low efficiency, high threshold, difficulty in maintenance, non-standardization, difficulty in expansion, and lack of versioning. It is no longer able to meet the urgent needs of enterprises for rapid iteration, unified management, and efficient reuse of feature assets.

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

[0017] The business decision-making method and apparatus of embodiments of this disclosure are described below with reference to the accompanying drawings.

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

[0019] like Figure 1 As shown, this business decision-making method includes: Step 110: Obtain the offline characteristics of the target object handling the target business from the specified database.

[0020] Among them, offline features are used to indicate the statistical results of historical business data of the target object. Offline features are obtained by batch processing and calculating historical business data from the feature data source corresponding to the data source information through the visual configuration interface, and stored in the specified database.

[0021] To achieve efficient business decision-making, one possible approach is to retrieve offline characteristics of the target object handling the target business from a designated database. These offline characteristics are the result of statistical analysis of data generated during the target object's historical business transactions, such as indicators like "number of loan applications in the past year," "average historical repayment period," or "cumulative consumption amount." These offline characteristics are not calculated in real-time during decision-making; instead, they are generated in advance through a visual configuration interface using pre-defined data source information and feature calculation logic. This data is then periodically batch-processed from historical business data from the feature data source and persistently stored in the designated database. The data source information includes data source type, connection address, database name, and table name; the feature calculation logic includes at least one of the following: aggregate function, measure field, data grouping dimension, and data filtering conditions.

[0022] In some embodiments, such as Figure 2 As shown, the offline features of the target object are generated using the following steps: Step 010: Load the tasks to be scheduled; the tasks to be scheduled are generated based on the data source information and feature calculation logic defined in the visual interface.

[0023] To decouple task configuration from task execution and improve the efficiency of offline feature generation, one possible approach is to retrieve generated, pending feature computation task instances from the task configuration storage center. These pending tasks are task description files or task metadata automatically generated based on data source information and feature computation logic defined by the user through a visual configuration interface. After configuration, the task is persistently stored in the task configuration storage center. Then, when triggered during a scheduling cycle or manually executed, the complete execution context of the pending task is loaded from this storage center, including data access methods, computation logic, and target output location.

[0024] In some embodiments, such as Figure 3 As shown, the tasks to be scheduled can be generated using the following steps: Step 0010: Obtain task-related configuration information and data processing query statements generated based on the configuration information.

[0025] To avoid the risk of errors from manually writing SQL or scripts, one possible approach is to read task-related configuration information from the configuration store, including data source information, feature calculation logic, task scheduling strategy, and target output configuration. Then, based on this configuration information, executable data processing query statements are automatically generated, such as SELECT statements conforming to FlinkSQL syntax. This statement defines the complete data processing flow from source data extraction and transformation calculation to result writing.

[0026] It should be noted that the configuration information was generated using the following steps: (1) In response to the first configuration operation on the visualization interface, configure the data source information of historical business data on the visualization interface; To avoid the problem of relying on technicians to manually code and access data in traditional development models, one possible approach is to respond to the user's first configuration operation on the visual interface and guide the user to complete the configuration of data source information, such as selecting the data source type, filling in the connection address, authentication credentials, source data table name, and required fields; among which, the data source types include: relational databases, data warehouses, and non-relational databases.

[0027] (2) In response to the second configuration operation on the visualization interface, configure the feature calculation logic in the visualization interface, wherein the feature calculation logic includes at least one of the following: aggregation function, measure field, data grouping dimension and data filtering condition; To achieve flexible and customizable feature generation capabilities, as a possible approach, in response to the user's second configuration operation, a configuration entry point for feature calculation logic is provided in the visual interface. This allows users to construct complete statistical calculation rules by selecting aggregation functions, specifying metric fields, setting grouping dimensions, and defining data filtering conditions. Among these, aggregation functions may include COUNT, SUM, MAX, etc., specified metric fields may include transaction amount, grouping dimensions may include customer ID, region, etc., and data filtering conditions may include time range, status marker, etc.

[0028] (3) In response to the third configuration operation on the visualization interface, configure the task scheduling strategy and the library information of the specified database used to store offline features in the visualization interface; To ensure the secure and accurate storage and use of the generated results data, as a possible implementation, in response to the user's third configuration operation, the task scheduling strategy and the library information for the specified database used to store offline features can be configured in the visual interface. The library information may include the type of specified database, IP address, port, username, password, and result table name, etc. Thus, this configuration can ensure that the task can run periodically as planned and write the generated feature data to the preset persistent storage for subsequent query or decision-making calls.

[0029] (4) Generate configuration information based on data source information, feature calculation logic, task scheduling strategy and library information.

[0030] To achieve centralized management and standardized output of multi-dimensional configurations and avoid execution deviations caused by information dispersion, one possible approach is to integrate the data source information, feature calculation logic, scheduling strategy, and target library information obtained during the configuration process into a structured task configuration information. It should be noted that this configuration information exists in JSON, YAML, or object format, serving as input data for subsequent data processing queries and scheduled tasks.

[0031] The data processing query statement is generated using the following steps: (1) Generate source table declaration statements that conform to the set syntax specifications based on the data source information and the field mapping relationship associated with the feature calculation logic; wherein, the source table declaration statements are used to define the logical structure and physical connection method of the task input data from the feature data source; To avoid the tediousness and error risks of manually writing source table creation statements, one possible approach is to automatically generate source table declaration statements that conform to the target execution environment's syntax (such as Flink SQL) based on the user-configured data source information and the field mapping relationships defined in the feature calculation logic. It's important to note that the field mapping relationships defined in the feature calculation logic can include mappings from source fields to target fields, alias settings, etc. The source table declaration statement not only describes the logical structure of the task's input data, such as field names and data types, but can also include physical connection parameters such as connector type, access credentials, and read mode, thus fully defining how the task reads data from the feature data source.

[0032] As an example, the access method of the feature data source is determined based on the data source information, and the data connection configuration parameters of the feature data source are generated; the field structure of the task input data is parsed based on the field mapping relationship, and the source data type of the task input data is converted into the running data type supported by the task execution environment; if there is a unique identifier field in the field structure, a primary key semantic identifier is added to the field structure, where the primary key semantic identifier is used to indicate that the unique identifier field is the logical primary key in the task; the data connection configuration parameters are combined with the field structure containing the primary key semantic identifier to generate the source table declaration statement.

[0033] In other words, to ensure accurate access to task input data, the access method for the feature data source is first determined based on the feature data source information, and corresponding data connection configuration parameters, such as username, password, and read parallelism, are generated. Then, the field structure of the task input data is parsed according to the field mapping relationship, and the data type of the task input data is converted to the runtime data type supported by the task execution environment (such as Flink). If a unique identifier field (such as user ID) exists in the field structure, a primary key semantic identifier is added to identify the uniqueness of events in the stream processing task and avoid duplicate calculations. Finally, the connection parameters are combined with the field structure containing primary key semantics to generate a source table declaration statement that conforms to the syntax specifications. The data type of the task input data can include Oracle's NUMBER, MySQL's DATETIME, etc., the runtime data type can include BIGINT, TIMESTAMP, etc., and the primary key semantic identifier can include PRIMARY KEY or KEY annotation, etc.

[0034] (2) Based on the first field structure of the configuration output field of the library information and feature calculation logic, generate a result table declaration statement that conforms to the set syntax specification; wherein, the result table declaration statement is used to define the second field structure of the task output field and the external storage access parameters; To achieve effective storage of offline features, one possible approach is to generate a result table declaration statement that conforms to a set syntax specification, based on the target database's library information and the output field structure defined in the feature calculation logic (i.e., the first field structure, which may include field names, types, and whether it is a primary key, etc.). This result table declaration statement defines the field structure of the task's output data (i.e., the second field structure) and external storage access parameters required for writing to the target storage, such as connection parameters, write mode (e.g., append, overwrite), and partitioning strategy, ensuring that offline features can be correctly written to the specified database.

[0035] (3) Generate task execution statements based on the configuration information; To avoid syntax errors and logical deviations introduced by manual coding, one possible approach is to automatically generate task execution statements that describe the data processing flow based on the data source, feature calculation rules, grouping dimensions, and filtering conditions in the configuration information. For example, an SQL query statement such as SELECT ... GROUP BY ... WHERE ....

[0036] (4) Generate data processing query statements based on source table declaration statements, result table declaration statements and task execution statements.

[0037] To generate data processing query statements with clear structure and complete semantics, one possible implementation is to combine the generated source table declaration statement, result table declaration statement, and task execution statement to obtain a data processing query statement. This data processing query statement conforms to the set syntax specifications and can include all the logic for data reading, transformation, and writing.

[0038] Step 0020: Encapsulate the data processing query statement and configuration information to generate a task to be scheduled.

[0039] To improve task portability and manageability, one possible approach is to integrate and encapsulate the data processing query statement and task-related configuration information into a structured task unit, i.e., the task to be scheduled, after obtaining them. This encapsulation process includes packaging the data query statement and task-related configuration information into a unified task description format, such as JSON, YAML, or a custom task object, and generating a unique task ID.

[0040] In summary, by acquiring task-related configuration information and automatically generating data processing query statements based on that information, users can define complex feature logic without manually writing SQL or scripts, thus lowering the technical threshold. Furthermore, by encapsulating the generated data processing query statements with the original configuration information to construct a structured task to be scheduled, the unified packaging of computational logic, metadata, and execution context is achieved, effectively improving the portability and manageability of the task.

[0041] Step 020: Based on the task scheduling strategy and running script in the task to be scheduled, schedule and execute the task to be scheduled to obtain historical business data of the target object from the feature data source, and perform batch processing on the historical business data based on feature calculation logic to generate offline features, and store the offline features in the specified database configured for the task to be scheduled.

[0042] To automate the generation of offline features, one possible approach is to have the scheduling engine trigger and execute the task based on a pre-defined task scheduling strategy and execution script. During task execution, historical business data of the target object is extracted from the configured feature data source. The historical business data is then processed in batches according to the feature calculation logic defined in the visual interface to generate offline features reflecting the historical business data of the target object. These offline features are then written to a pre-configured database for the task, thus achieving persistent storage of the offline features. The task scheduling strategy includes parameters such as execution frequency, trigger time, and dependency conditions, while the execution script may include data reading, transformation, aggregation, and writing operations.

[0043] It should be noted that, based on the task scheduling strategy and execution script configured in the task to be scheduled, before scheduling and executing the task to be scheduled, the execution context of the task to be scheduled must be initialized. The initialization of the execution context of the task to be scheduled includes at least one of the following: configuring the execution mode of the task to be scheduled as batch processing mode, building the task execution environment of the task to be scheduled, loading the functional extension modules that the task to be scheduled depends on, registering custom computing logic, and configuring the persistence method of the processing results of the task to be scheduled.

[0044] It should be noted that the task execution environment may include local debugging mode or cluster running mode. Registering custom computing logic may include registering temporary user-defined functions (UDFs). Furthermore, provided that syntax compatibility is ensured, statistical functions in feature computing logic may also be registered as recognizable temporary functions.

[0045] In summary, by loading the scheduled tasks generated based on the data source information and feature calculation logic defined in the visual interface, the technical threshold for task definition is lowered, and the flexibility and efficiency of task definition are improved, ensuring that tasks accurately meet actual business needs. Based on the pre-set task scheduling strategy and execution script in the scheduled tasks, tasks can be automatically and accurately scheduled and executed to obtain historical business data of the target object from the feature data source, batch process the historical business data to generate offline features according to the feature calculation logic, and store the offline features in the specified database configured in the scheduled tasks. This improves the development efficiency of offline features, reduces the reliance on manual coding, supports non-technical personnel to participate in feature construction, and enhances the maintainability and scalability of the system.

[0046] Step 120: Make business decisions for the target business based on offline characteristics.

[0047] To further improve the accuracy of business decisions, offline features reflecting the statistical performance of target objects in historical business activities, including credit records, transaction frequency, and the number of risk events, are used to make business decisions for target businesses. For example, offline features are input into a decision engine to perform preset threshold judgments or rule matching, generating decision results including approval, rejection, or manual review. Since offline features are pre-calculated and persistently stored results, there is no need for real-time data processing during decision-making, thereby reducing dependence on real-time computing resources and improving business decision-making efficiency while ensuring the accuracy and consistency of decisions.

[0048] In some embodiments, such as Figure 4 As shown, step 120 may include the following steps: Step 1201: Use the set data quality verification rules to verify the validity of offline features.

[0049] To ensure the reliability and accuracy of offline features used for business decisions, one possible approach is to establish data quality verification rules to validate the validity of the generated offline features. These data quality verification rules may include, but are not limited to: field integrity checks, numerical range checks, logical consistency checks, and data type compliance checks. Field integrity checks may include, for example, checking if key fields are not null; numerical range checks may include verifying whether the credit score is between 0 and 100; and logical consistency checks may include verifying whether the "cumulative repayment amount" is less than the "total loan amount."

[0050] Step 1202: In response to the offline feature passing the validity check, obtain the decision threshold associated with the offline feature.

[0051] To accurately determine the criteria for offline features, one possible approach is to automatically acquire a decision threshold associated with the offline feature after it passes data quality verification. This threshold is a pre-configured business judgment standard; for example, "overdue number ≤ 2" is considered low risk, and "user activity score ≥ 80" can trigger marketing recommendations. It should be noted that the decision threshold can be stored in a rule base, configuration table, or model parameters, and a mapping relationship can be established with the corresponding offline feature, supporting static configuration or dynamic adjustment.

[0052] Step 1203: In response to the mismatch between offline features and decision thresholds, a first business decision result indicating that the target business is at risk is generated.

[0053] To improve the accuracy of business decisions, as a possible approach, when the actual value of an offline characteristic does not meet a preset decision threshold, such as a user having "4 overdue payments in the past 6 months," which exceeds the decision threshold of 2, a first-class business decision result is generated, such as "credit denied," "marked as high risk," or "manual review required," to indicate that there is a potential risk in the target business.

[0054] To achieve timely identification and control of potential business risks, as a possible approach, when the offline characteristic value of the target object does not match the decision threshold, a risk response mechanism is automatically triggered based on the generated first business decision result. This mechanism generates structured risk warnings or abnormal alarm information, such as risk type, trigger characteristics, and confidence level, and pushes this information to the monitoring platform, risk control center, or operations system. At the same time, the first business handling process is initiated, which may include: automatically intercepting the current business process, transferring the task to a manual review queue, or notifying the operations team to intervene.

[0055] Step 1204: In response to the matching of offline features and decision thresholds, a second business decision result is generated indicating that the target business meets the set business conditions.

[0056] To improve the comprehensiveness of business decisions, as a possible approach, when the actual value of offline features meets a preset decision threshold, such as "credit score ≥ 70", a second type of business decision result is generated, such as "automatic approval", "granting credit limit" or "inclusion in the targeted marketing list", indicating that the target business meets the current business criteria.

[0057] To achieve efficient service for compliant customers, one possible approach is to automatically trigger a second business processing procedure when the offline characteristics of the target object meet the decision threshold. This second business processing procedure may include: lifting business restrictions, performing automatic release operations, or pushing personalized service recommendations to the user based on the user profile.

[0058] The business decision-making method of this disclosure obtains offline features of the target object handling the target business from a specified database and makes business decisions on the target business. This avoids the latency and resource consumption caused by real-time calculation, improves the stability and response efficiency of the decision-making system, and the offline features are obtained by batch processing historical business data based on data source information and feature calculation logic defined by a visual configuration interface and stored in a specified database. This allows the feature engineering process to be completed without writing code, significantly reducing the technical difficulty for non-technical personnel to participate in feature engineering.

[0059] Based on any of the above embodiments, such as Figure 5 As shown, taking Flink SQL as an example for data processing query statements, the business decision-making method of this disclosure embodiment may include the following steps: Step 501, Configure the feature data source; Through a visual configuration interface, users can select and configure the data sources required for feature calculations. The system supports various types of data source access, including but not limited to: 1. Relational databases: such as MySQL, Oracle, PostgreSQL, DaMeng, DB2, etc.; 2. NoSQL databases: such as Redis; 3. Distributed data warehouses: such as Hive; The configuration includes data source type, connection address, database name, table name or query statement, etc. After the system verifies the validity of the connection, it will persist the data source information as the basis for subsequent table structure generation. Step 502: Configure the feature calculation logic; Define the core calculation rules for features in the visual interface, including the following key elements: 1. Statistical functions: Supports a variety of aggregate functions, including ranking (ROW_NUMBER), variance (VAR_POP), deduplication count (DISTINCT_COUNT), maximum value (MAX), minimum value (MIN), average value (AVG), summation (SUM), count (COUNT), standard deviation (STDDEV_POP), kurtosis (STAT_KURTOSIS), mode (STAT_MODE), etc. 2. Statistical variables: Specify the fields that participate in the aggregation operation, such as transaction amount; 3. Statistical Dimensions: Dimensional fields used for grouped statistics, such as name, ID card number, etc. 4. Filtering conditions: Supports custom SQL-style WHERE expressions for data filtering, such as "start time >= '2025-01-01'" or "status = 1"; the above configuration information serves as the core input for dynamically generating Flink SQL. Step 503: Configure task scheduling strategy and feature storage target; Configure the execution plan and result output method for the feature calculation task: Scheduling strategy: Supports scheduling by time period, with time granularity including year, month, day, hour, minute, and second. Fixed frequency or Cron (a time-based job scheduling mechanism) expression can be set. Storage medium: Specifies the target database for storing the feature calculation results, supporting high-performance storage systems such as Redis. The system automatically matches the corresponding connector based on the selected storage medium; Step 504, Initialize information construction; The system initializes the runtime context of the tasks to be scheduled, i.e., the runtime context of the Flink job, which specifically includes: 1. Configure the execution mode of the task to be scheduled as batch processing mode, that is, set the Flink SQL running mode to batch processing mode (Batch Mode), which is suitable for offline feature calculation scenarios; 2. Build the specified job execution environment for the task to be scheduled, including local debugging mode (Local) or cluster running mode (YARN). 3. Configure the display method of query results for task debugging and preview; 4. Dynamically load necessary JAR package dependencies, including JDBC drivers, JDBC connectors, Redis Sink connectors, etc. 5. Register temporary system-level user-defined functions (UDFs) to register the advanced statistical functions (such as ranking, variance, etc.) involved in step 502 as temporary functions that Flink SQL can recognize, ensuring syntax compatibility; Step 505: Dynamically generate source table definitions; Based on the data source information configured in step 501 and the field reference relationships in step 502, a CREATE TABLE statement conforming to the Flink SQL syntax specification is dynamically generated to define the source table structure. This DDL statement includes: 1. Primary key setting: If the source table has a primary key, mark it as PRIMARY KEY NOT ENFORCED; 2. Field list and data types: Automatically map source database types to FlinkSQL types (e.g., VARCHAR to STRING, INT to INT); 3. Connector Type: Automatically fills in the connection type and parameters based on the data source type; Step 506: Dynamically generate the target table definition; Combining the output field structure from step 502 with the storage medium (such as Redis) specified in step 503, the system generates a CREATE TABLE statement for the target table, the contents of which include: 1. Primary key setting: The primary key of the target table is PRIMARY KEY(code,version) NOT ENFORCED; 2. Define the output field names and types; 3. Configure the Redis connector and connection information; 4. Redis Key Mapping Strategy: The Redis Key format is prefix:feature code:version_dimension1|dimension2, for example: olf:test:V2_zhangsan|510722; 5. Redis Field naming convention: Use a combination of "statistical variable_statistical function", such as age_AVG; 6. Redis Value storage format: Statistical results are stored as String type; Step 507: Dynamically generate execution statements; Based on the aforementioned configuration, the system automatically generates a complete FlinkSQL statement of type INSERT INTO ... SELECT ..., with the following structure: 1. SELECT clause: Contains all configured statistical functions and statistical variables, such as AVG(amount) ASamount_AVG, etc. 2. GROUP BY clause: Automatically generated based on the statistical dimension fields configured in step S102; 3. WHERE clause: Integrates user-configured filtering conditions; 4. The Redis Key construction logic is embedded in the Sink mapping and is serialized and output by the connector according to the rules; Step 508, schedule the task; The FlinkSQL statements and related configurations generated in the preceding steps are encapsulated into a complete schedulable task, mainly including: 1. Basic task information: Task name (FlinkSqlSubmit), Task type (FLINK), Program type (SQL), Deployment method (local), Execution type (BATCH); 2. Run the script: This includes initialization configuration (step 104), source table and target table DDL (steps 505-506), and INSERT statement (step 507). Finally, the system encapsulates the complete Flink SQL job into an executable job unit, which is then submitted by the scheduling task engine to the Flink runtime cluster for execution, completing the automated computation and storage of feature data.

[0060] 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.

[0061] Figure 6 This is a schematic diagram of the business decision-making device shown in the fifth embodiment of this disclosure.

[0062] like Figure 6 As shown, the business decision-making device 600 includes an acquisition module 610 and a decision-making module 620.

[0063] The acquisition module 610 is used to obtain the offline characteristics of the target object handling the target business from the specified database. The offline characteristics are used to indicate the statistical results of the historical business data of the target object. The offline characteristics are obtained by batch processing and calculating the historical business data from the feature data source corresponding to the data source information defined by the visual configuration interface and storing them in the specified database. The decision module 620 is used to make business decisions on the target business based on the offline characteristics.

[0064] As one possible implementation, the offline characteristics of the target object are determined using the following modules: a loading module and a scheduling module.

[0065] The loading module is used to load the tasks to be scheduled. The tasks to be scheduled are generated based on the data source information and feature calculation logic defined in the visual interface. The scheduling module is used to schedule and execute the tasks to be scheduled based on the task scheduling strategy and running script in the tasks to be scheduled, so as to obtain the historical business data of the target object from the feature data source, and perform batch processing on the historical business data based on the feature calculation logic to generate offline features, and store the offline features in the specified database configured in the tasks to be scheduled.

[0066] As one possible implementation, the task to be scheduled is generated using the following modules: a first generation module and an encapsulation module.

[0067] The first generation module is used to obtain task-related configuration information and data processing query statements generated based on the configuration information; the encapsulation module is used to encapsulate the data processing query statements and configuration information to generate tasks to be scheduled.

[0068] As one possible implementation, the business decision-making device 600 also includes: a first configuration module, a second configuration module, a third configuration module, and a second generation module.

[0069] The system comprises the following modules: a first configuration module, configured to configure the data source information of historical business data in response to a first configuration operation on the visualization interface; a second configuration module, configured to configure feature calculation logic in response to a second configuration operation on the visualization interface, wherein the feature calculation logic includes at least one of the following: aggregation function, metric field, data grouping dimension, and data filtering condition; a third configuration module, configured to configure the task scheduling strategy and the library information of the specified database for storing offline features in response to a third configuration operation on the visualization interface; and a second generation module, configured to generate configuration information based on the data source information, feature calculation logic, task scheduling strategy, and library information.

[0070] As one possible implementation, the business decision-making device 600 also includes a third generation module.

[0071] The third generation module is used to generate source table declaration statements that conform to the set syntax specifications based on data source information and field mapping relationships associated with feature calculation logic. These source table declaration statements define the logical structure and physical connection method of task input data from the feature data source. Based on library information and the first field structure of the configuration output fields of the feature calculation logic, a result table declaration statement conforming to the set syntax specifications is generated. This result table declaration statement defines the second field structure of the task output fields and external storage access parameters. Based on configuration information, a task execution statement is generated. Finally, based on the source table declaration statement, the result table declaration statement, and the task execution statement, a data processing query statement is generated.

[0072] As one possible implementation, the third generation module is also used to determine the access method of the feature data source based on the data source information, generate the data connection configuration parameters of the feature data source; parse the field structure of the task input data based on the field mapping relationship, and convert the source data type of the task input data into the running data type supported by the task execution environment; if there is a unique identifier field in the field structure, add a primary key semantic identifier to the field structure, where the primary key semantic identifier is used to indicate that the unique identifier field is the logical primary key in the task; combine the data connection configuration parameters with the field structure containing the primary key semantic identifier to generate the source table declaration statement.

[0073] As one possible implementation, the business decision-making device 600 also includes an initialization module.

[0074] The initialization module is used to initialize the execution context of the task to be scheduled. The initialization of the execution context of the task to be scheduled includes at least one of the following: configuring the execution mode of the task to be scheduled as batch processing mode; building the task execution environment of the task to be scheduled; loading the functional extension modules that the task to be scheduled depends on; registering the temporary functions associated with the task to be scheduled; and configuring the persistence method of the processing results of the task to be scheduled.

[0075] As one possible implementation, the decision module 620 is used to perform validity verification on offline features using set data quality verification rules; in response to the offline features passing the validity verification, it obtains the decision threshold associated with the offline features; in response to the offline features not matching the decision threshold, it generates a first business decision result indicating that the target business has risks; in response to the offline features matching the decision threshold, it generates a second business decision result indicating that the target business meets the set business conditions.

[0076] As one possible implementation, the business decision-making device 600 also includes a processing module.

[0077] The processing module is used to respond to a mismatch between offline features and decision thresholds, generate a risk warning or anomaly alarm for the target business based on the first business decision result, and trigger a first business handling process of risk interception, manual review or operational intervention; and to trigger a second business handling process of business release or service recommendation in response to a match between offline features and decision thresholds.

[0078] The business decision-making device of this disclosure obtains offline features of the target object handling the target business from a specified database and makes business decisions on the target business. This avoids the latency and resource consumption caused by real-time calculation, improves the stability and response efficiency of the decision-making system, and the offline features are obtained by batch processing historical business data based on data source information and feature calculation logic defined by a visual configuration interface and stored in a specified database. This allows the feature engineering process to be completed without writing code, significantly reducing the collaboration threshold between business personnel and technical personnel.

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

[0080] 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.

[0081] As an example, Figure 7 This is a schematic diagram of the structure of an electronic device 700 as shown in an exemplary embodiment of this disclosure, as follows: Figure 7 As shown, the aforementioned electronic device 700 may further include: The present invention includes a memory 710 and a processor 720, and a bus 730 connecting different components (including the memory 710 and the processor 720). The memory 710 stores a computer program, which, when executed by the processor 720, implements the business decision-making method described in the embodiments of the present disclosure.

[0082] Bus 730 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.

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

[0084] The memory 710 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 740 and / or cache memory 750. The electronic device 700 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 760 can be used to read and write non-removable, non-volatile magnetic media (…). Figure 7 Not shown; usually referred to as a "hard drive"). Although Figure 7 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 730 via one or more data media interfaces. Memory 710 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.

[0085] A program / utility 780 having a set (at least one) of program modules 770 may be stored in, for example, memory 710. Such program modules 770 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 770 typically perform the functions and / or methods described in the embodiments of this disclosure.

[0086] Electronic device 700 can also communicate with one or more external devices 790 (e.g., keyboard, pointing device, display 791, etc.), and with one or more devices that enable a user to interact with electronic device 700, and / or with any device that enables electronic device 700 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 792. Furthermore, electronic device 700 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 793. As shown, network adapter 793 communicates with other modules of electronic device 700 via bus 730. 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 700, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0087] The processor 720 executes various functional applications and data processing by running programs stored in the memory 710.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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: The offline features of the target object that has handled the target business are obtained from the specified database. The offline features are used to indicate the statistical results of the historical business data of the target object. The offline features are obtained by batch processing and calculating the historical business data from the feature data source corresponding to the data source information defined by the visual configuration interface and storing them in the specified database. Based on the offline characteristics, business decisions are made for the target service.

2. The method according to claim 1, characterized in that, The offline features of the target object are determined using the following steps: Load the task to be scheduled; wherein the task to be scheduled is generated based on the data source information and feature calculation logic defined in the visualization interface; Based on the task scheduling strategy and running script in the task to be scheduled, the task to be scheduled is scheduled and executed to obtain the historical business data of the target object from the feature data source, and the historical business data is batch-processed based on the feature calculation logic to generate the offline feature, and the offline feature is stored in the specified database configured in the task to be scheduled.

3. The method according to claim 2, characterized in that, The task to be scheduled is generated using the following steps: Obtain task-related configuration information and data processing query statements generated based on the configuration information; The data processing query statement and the configuration information are encapsulated to generate the task to be scheduled.

4. The method according to claim 3, characterized in that, Before obtaining the task-related configuration information, the method further includes: In response to a first configuration operation on the visualization interface, the data source information of the historical business data is configured on the visualization interface; In response to a second configuration operation on the visualization interface, feature calculation logic is configured in the visualization interface, wherein the feature calculation logic includes at least one of the following: aggregation function, metric field, data grouping dimension, and data filtering condition; In response to a third configuration operation on the visualization interface, a task scheduling strategy and library information for a specified database used to store the offline features are configured in the visualization interface. The configuration information is generated based on the data source information, the feature calculation logic, the task scheduling strategy, and the library information.

5. The method according to claim 4, characterized in that, The data processing query statement is generated using the following steps: Based on the data source information and the field mapping relationship associated with the feature calculation logic, a source table declaration statement conforming to the set syntax specification is generated; wherein, the source table declaration statement is used to define the logical structure and physical connection method of the task input data from the feature data source; Based on the library information and the configuration output field first field structure of the feature calculation logic, a result table declaration statement conforming to the set syntax specification is generated; wherein, the result table declaration statement is used to define the second field structure of the task output field and the external storage access parameters; Based on the configuration information, generate task execution statements; The data processing query statement is generated based on the source table declaration statement, the result table declaration statement, and the task execution statement.

6. The method according to claim 5, characterized in that, The step of generating a source table declaration statement conforming to a set syntax specification based on the data source information and the field mapping relationship associated with the feature calculation logic includes: Based on the data source information, the access method of the characteristic data source is determined, and the data connection configuration parameters of the characteristic data source are generated; Based on the field mapping relationship, the field structure of the task input data is parsed, and the source data type of the task input data is converted into the running data type supported by the task execution environment; If a unique identifier field exists in the field structure, a primary key semantic identifier is added to the field structure, wherein the primary key semantic identifier is used to indicate that the unique identifier field is used as the logical primary key in the task; The data connection configuration parameters are combined with a field structure containing a primary key semantic identifier to generate the source table declaration statement.

7. The method according to claim 2, characterized in that, Before scheduling and executing the task based on the task scheduling policy and execution script configured in the task to be scheduled, the method further includes: Initialize the execution context of the task to be scheduled; The initialization of the runtime context of the task to be scheduled includes at least one of the following: Configure the execution mode of the task to be scheduled as batch processing mode; Construct the task execution environment for the task to be scheduled; Load the functional extension modules that the task to be scheduled depends on; Register a temporary function associated with the task to be scheduled; Configure the persistence method for the processing results of the task to be scheduled.

8. The method according to claim 1, characterized in that, The step of making business decisions for the target service based on the offline characteristics includes: The offline features are validated using predefined data quality verification rules. In response to the offline feature passing the validity check, a decision threshold associated with the offline feature is obtained; In response to a mismatch between the offline features and the decision threshold, a first business decision result indicating that the target business is at risk is generated; In response to the offline feature matching the decision threshold, a second business decision result is generated indicating that the target business meets the set business conditions.

9. The method according to claim 5, characterized in that, The method further includes: In response to the mismatch between the offline features and the decision threshold, a risk warning or anomaly alarm for the target business is generated based on the first business decision result, and a first business handling process of risk interception, manual review or operational intervention is triggered. In response to the offline features matching the decision threshold, a second business processing procedure is triggered to allow business release or recommend services.

10. A business decision-making device, characterized in that, include: The acquisition module is used to obtain offline features of the target object that has handled the target business from a specified database; wherein, the offline features are used to indicate the statistical results of the historical business data of the target object that has handled the business, and the offline features are obtained by batch processing and calculating the historical business data from the feature data source corresponding to the data source information defined by the visual configuration interface and the feature calculation logic, and stored in the specified database; The decision-making module is used to make business decisions for the target service based on the offline characteristics.

Images