Business data processing method and device and storage medium

Abstract

The application relates to a business data processing method and device and a storage medium, and relates to the technical field of data processing. The method comprises the following steps: acquiring a business event stream; performing abnormality identification on the business event stream based on a monitoring rule to obtain an abnormal event, wherein the monitoring rule comprises a trigger parameter; in response to the identification of the abnormal event, performing processing on the abnormal event based on a dynamically configured processing node sequence; and dynamically updating the trigger parameter of the monitoring rule based on a processing result.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a business data processing method, apparatus, and storage medium. Background Technology

[0002] Currently, in the field of business system monitoring, pre-defined fixed rules are typically used to detect anomalies in business data, and predefined alarms or handling scripts are executed when anomalies are detected. However, the monitoring rules and anomaly handling logic in the above approach are often statically bound and hard-coded. When business scenarios change or anomaly patterns evolve, manual code modification and service restart are required to update the monitoring strategy. Furthermore, the above approach lacks an effective feedback mechanism for anomaly handling results, and cannot automatically adjust the sensitivity of monitoring rules based on actual handling effectiveness. This leads to problems such as false positives, false negatives, or delayed handling when facing complex and ever-changing business traffic, making it difficult to achieve adaptive closed-loop optimization of the monitoring system. Summary of the Invention

[0003] This invention provides a business data processing method, apparatus, and storage medium to at least solve the problem in related technologies where monitoring strategies cannot adaptively optimize based on processing results. The technical solution of this invention is as follows: According to a first aspect of the present invention, a business data processing method is provided, the method comprising: acquiring a business event stream; identifying anomalies in the business event stream based on monitoring rules to obtain anomalies, wherein the monitoring rules include trigger parameters; processing the anomalies based on a dynamically configured sequence of processing nodes in response to the identification of the anomalies; and dynamically updating the trigger parameters of the monitoring rules based on the processing results.

[0004] The above solution decouples anomaly identification from anomaly handling and establishes a feedback path from the handling result to the monitoring rule parameters, enabling the system to automatically calibrate the monitoring benchmark based on the actual handling effect during operation. This solves the problem of poor adaptability caused by the static and fixed nature of traditional monitoring strategies and realizes closed-loop adaptive optimization of the monitoring system.

[0005] As a technical solution, abnormal events are handled based on a dynamically configured sequence of processing nodes, including: selecting a target action component from a pre-defined atomic action component library based on the attribute characteristics of the abnormal event; orchestrating and generating a sequence of processing nodes based on the dependencies between the target action components; and calling the target action component according to the sequence of processing nodes to handle the abnormal event.

[0006] This solution encapsulates exception handling actions into independent atomic components and supports dynamic orchestration based on dependencies. This allows the processing logic to no longer rely on hard-coded scripts, but instead to build differentiated handling chains in real time based on the specific attributes of exception events, thereby improving the flexibility and scalability of exception handling.

[0007] As a technical solution, the target action component is invoked according to the processing node sequence to handle abnormal events, including: executing the target action component on the abnormal event according to the execution topology of the processing node sequence; wherein, the execution topology includes at least one of serial execution, parallel execution or conditional branch execution; the action type of the target action component includes at least one of service blocking, alarm push, service degradation or log recording.

[0008] This solution supports advanced processing requirements such as multi-threaded concurrent handling and conditional judgment diversion in complex business scenarios by defining diverse execution topologies and standardized action types, ensuring the efficiency and determinism of exception handling processes at the execution level.

[0009] As a technical solution, the trigger parameters of the monitoring rules are dynamically updated based on the processing results, including: based on a preset sliding time window, the trigger frequency of abnormal events and the success rate of abnormal handling actions are counted; based on the trigger frequency, the success rate of handling, and a preset feedback algorithm, the parameter adjustment amount of the trigger parameters is calculated; and the trigger parameters are updated based on the parameter adjustment amount.

[0010] Among them, the sliding time window refers to the time range used for statistical data, the length of which can be set according to the business fluctuation cycle to smooth out instantaneous noise; the trigger frequency refers to the number of times abnormal events are identified within the sliding time window, representing the density of abnormalities; the processing success rate refers to the proportion of the number of successful abnormal handling actions to the total number of actions executed within the sliding time window, representing the effectiveness of the current handling strategy; the parameter adjustment amount is the trigger parameter correction value calculated based on the feedback algorithm, used to quantify the magnitude of rule optimization.

[0011] This scheme transforms discrete processing results into continuous rule optimization signals by introducing time-dimensional statistical indicators and quantitative feedback algorithms, thus avoiding false disturbances to the monitoring strategy caused by single, occasional events and ensuring the stability and convergence of the rule adaptation process.

[0012] As a technical solution, based on the trigger frequency, processing success rate, and preset feedback algorithm, the parameter adjustment amount of the trigger parameters is calculated, including: when the trigger frequency exceeds the first preset threshold, the numerical threshold in the trigger parameters is lowered according to the preset gradient; when the processing success rate is lower than the second preset threshold, a verification action insertion instruction is generated, which is used to dynamically insert verification action nodes in the processing node sequence.

[0013] The first preset threshold is a critical value for determining whether anomalies are too frequent, used to trigger negative feedback adjustment of sensitivity; the preset gradient is a step size factor for triggering parameter adjustment, controlling the rate of rule change to prevent oscillation; the second preset threshold is a critical value for determining whether the current treatment method has failed, used to trigger structured enhancement of the treatment strategy.

[0014] This solution employs a dual feedback mechanism. On the one hand, it automatically relaxes or tightens thresholds to balance load and risk when anomalies occur frequently. On the other hand, it automatically supplements the verification process to improve the accuracy of handling when the failure rate is high. This achieves dual adaptive evolution of the monitoring strategy at both the parameter and structural levels.

[0015] As a technical solution, before performing anomaly identification on business event streams based on monitoring rules, the method also includes: obtaining rule configuration instructions; parsing the rule configuration instructions into executable scripts; and hot-loading the executable scripts into the rule execution container to update the monitoring rules.

[0016] This solution utilizes runtime parsing and hot-loading mechanisms to enable changes to monitoring rules without interrupting business services or restarting the system, achieving monitoring policies taking effect within seconds and significantly shortening the feedback cycle from policy adjustment to online verification.

[0017] As a technical solution, parsing rule configuration instructions into executable scripts includes: identifying the data format of the rule configuration instructions, where the data format includes a domain-specific language or a structured data format; and compiling the rule configuration instructions into executable scripts in the target programming language based on the compilation rules corresponding to the data format.

[0018] This solution supports compilation and conversion of various configuration formats to target languages, shielding the technical details of the underlying execution engine. This allows upper-level business personnel to define monitoring logic in a declarative manner, reducing the technical threshold and maintenance cost of monitoring rule configuration.

[0019] As a technical solution, anomaly identification is performed on the business event stream based on monitoring rules to obtain abnormal events, including: matching the attribute features of a single business event in the business event stream based on the single event judgment conditions in the monitoring rules to obtain a first identification result; and / or calculating and matching the aggregation features of multiple business events within a preset time window based on the window aggregation judgment conditions in the monitoring rules to obtain a second identification result; and determining the abnormal event based on the first identification result and / or the second identification result.

[0020] This solution combines real-time single-point detection and time window aggregation analysis, enabling it to quickly respond to sudden single-point anomalies and effectively capture cumulative risks hidden in time-series patterns, thus improving the comprehensiveness and accuracy of anomaly identification.

[0021] According to a second aspect of the present invention, a business data processing apparatus is provided, the apparatus comprising: an acquisition module configured to acquire a business event stream; an anomaly detection module configured to identify anomalies in the business event stream based on monitoring rules to obtain anomaly events, the monitoring rules including trigger parameters; an anomaly processing module configured to process the anomaly events based on a dynamically configured sequence of processing nodes in response to the identification of the anomaly events; and a parameter update module configured to dynamically update the trigger parameters of the monitoring rules based on the processing results.

[0022] According to a third aspect of the present invention, a business data processing system is provided, wherein the business data processing system stores instructions that, when executed by a processor, enable a controller to execute a business data processing method as described in the first aspect and any possible technical solution thereof.

[0023] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, on which instructions are stored, such that when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform a business data processing method as described in the first aspect and any possible implementation thereof.

[0024] According to a fifth aspect of the present disclosure, a computer program product is provided, the computer program product including computer instructions, which, when executed on an electronic device, cause the electronic device to perform the business data processing method of the first aspect and any possible implementation thereof.

[0025] The technical solutions provided by the embodiments of the present invention bring at least the following beneficial effects: This application constructs a closed-loop adaptive mechanism for monitoring and identification, dynamic processing, and feedback optimization. First, by atomizing anomaly handling actions and supporting dynamic orchestration, it breaks the limitation of hard-coded processing logic in traditional monitoring systems, enabling the system to flexibly assemble handling links according to the real-time attributes of abnormal events, significantly improving the agility in dealing with complex and ever-changing business scenarios. Second, by collecting processing result data and statistically analyzing trigger frequency and processing success rate based on sliding time windows, a quantitative feedback path from handling effect to monitoring rule parameters is established, enabling the monitoring strategy to automatically calibrate thresholds or supplement verification links according to the actual operating status, effectively solving the problems of false alarms and missed alarms caused by the lag of manual optimization and the static solidification of rules. Finally, by combining rule hot loading and multi-dimensional anomaly identification technology, the real-time nature of monitoring strategy adjustment and the comprehensiveness of anomaly capture are ensured, achieving continuous improvement in the intelligence level of the monitoring system while ensuring business continuity.

[0026] 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

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

[0028] Figure 1 This is a flowchart illustrating a business data processing method according to an exemplary embodiment; Figure 2 This is a block diagram illustrating a business data processing apparatus according to an exemplary embodiment; Figure 3 This is a schematic diagram of an electronic device according to an exemplary embodiment. Detailed Implementation

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

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

[0031] Before providing a detailed description of the business data processing method provided in the embodiments of this application, a brief introduction to the implementation environment involved in the embodiments of this application is given.

[0032] For ease of understanding, the business data processing method provided in this application will be described in detail below with reference to the accompanying drawings.

[0033] Figure 1 This is a flowchart illustrating a business data processing method according to an exemplary embodiment, such as... Figure 1 As shown, the business data processing method includes the following steps.

[0034] Step S100: Obtain the business event stream.

[0035] Business event streams refer to time-series data sets that reflect the operational status of a business system.

[0036] In some implementation architectures, the data collector collects raw data from the business server in real time through a standard interface and converts it into an event stream of a unified format, which is then injected into a message queue.

[0037] It should be understood that business event streams are not limited to financial transaction records, but can also include sensor readings from IoT devices, access logs of internet services, call chain tracing data between microservices, or system resource monitoring indicators.

[0038] This embodiment achieves broad adaptability of the technical solution to different business scenarios by standardizing and cleaning and encapsulating multi-source heterogeneous data, enabling subsequent processing logic to run on a unified data model.

[0039] Step S200: Based on monitoring rules, perform anomaly identification on the business event stream to obtain abnormal events. The monitoring rules include trigger parameters.

[0040] In some implementations, the rule execution container consumes business event streams from the message queue and loads currently active monitoring rules for matching calculations.

[0041] The monitoring rules define the logical conditions for determining whether a business status is abnormal, while the trigger parameters are the dynamically adjustable numerical boundaries or weighting factors within these logical conditions.

[0042] For example, a monitoring rule can be defined as the number of failed requests exceeding N within a unit of time, where N is the trigger parameter. This design, which separates the judgment logic skeleton from the specific trigger parameter, allows the system to change the sensitivity of anomaly detection simply by adjusting the trigger parameter without modifying the rule code itself, providing a structured foundation for subsequent adaptive optimization.

[0043] In step S300, in response to the identification of an abnormal event, the abnormal event is processed based on the dynamically configured sequence of processing nodes.

[0044] When the rule execution container determines that an exception event has occurred, the exception handling engine does not execute a pre-coded fixed script, but instead loads or generates a dynamically configured sequence of processing nodes based on the current exception context.

[0045] It should be noted that the processing node sequence and the aforementioned monitoring rules are independent of each other in terms of data structure: the monitoring rules belong to the detection layer logic, which focuses on what constitutes an anomaly; while the processing node sequence belongs to the execution layer logic, which focuses on what to do after an anomaly is detected.

[0046] There is no static binding relationship between the two at compile time; instead, they are dynamically associated through runtime exception event attributes. This decoupled design allows the same set of monitoring rules to be applied to multiple different handling strategies, or the same handling strategy to be reused in different types of exception scenarios, greatly improving the system's flexibility and scalability. Dynamic configuration means that during system operation, the sequence of processing nodes can be assembled, adjusted, or replaced in real time according to configuration instructions, rather than being fixed at system startup.

[0047] Step S400: Based on the processing results, dynamically update the trigger parameters of the monitoring rules.

[0048] The data write-back component collects execution result data from the exception handling engine (such as success / failure status, time consumption, resource consumption, etc.) and sends this feedback data to the rule parsing engine. The rule parsing engine analyzes the validity of the processing results based on a preset feedback algorithm, calculates the adjustment amount of the trigger parameters, and hot-loads the updated parameters into the rule execution container. This step constitutes the core closed-loop mechanism of the technical solution in this application.

[0049] By establishing a feedback path from execution results to detection parameters, the system can automatically calibrate monitoring benchmarks based on actual handling effectiveness. For example, when the success rate of handling a certain type of anomaly remains low, the system can automatically tighten trigger parameters to raise the identification threshold and reduce ineffective handling caused by false alarms; conversely, if the false negative rate increases, the system can automatically relax parameters to improve detection capabilities. This mechanism transforms the monitoring system from a static rule executor into an adaptive system with self-evolution capabilities, effectively addressing the challenges posed by business traffic fluctuations and anomaly pattern drift.

[0050] This solution implements a data-driven closed-loop business data processing mechanism. By logically decoupling anomaly detection and anomaly handling, and dynamically adjusting detection parameters using feedback signals from processing results, it solves the technical problems of static, fixed rules and the inability to automatically optimize based on actual operational performance in traditional monitoring solutions, significantly improving the accuracy and environmental adaptability of business monitoring.

[0051] In this embodiment, the dynamic configuration mechanism mentioned in step S300 of the above embodiment is further refined.

[0052] Specifically, based on a dynamically configured sequence of processing nodes, abnormal events are processed, including: selecting a target action component from a pre-defined library of atomic action components based on the attribute characteristics of the abnormal event; orchestrating and generating a sequence of processing nodes based on the dependencies between the target action components; and calling the target action component according to the sequence of processing nodes to process the abnormal event.

[0053] This implementation concretizes the abstract dynamic configuration into a three-stage automated process of selection, orchestration, and execution at runtime. Its core technical effect is that it proves that the processing chain is not a pre-hard-coded static script, but a computational instance dynamically generated by the system based on the real-time context, thereby significantly enhancing the visibility and certainty of the technical solution during infringement comparison.

[0054] During the selection phase, the exception handling engine first parses the attribute characteristics carried by the exception event. These attribute characteristics are not limited to the risk level mentioned in the above embodiments, but can also include multi-dimensional information such as business type (e.g., payment, login, query), data source identifier, time sensitivity tag, or user VIP level. The atomic action component library stores multiple standardized functional units, each with pre-set applicable condition tags or matching rules. The exception handling engine matches and calculates the attribute characteristics of the exception event with the applicable conditions of each component to filter out the target action component required for the current scenario.

[0055] For example, when attribute characteristics indicate that the anomaly is a high-risk payment transaction, the system may simultaneously select the transaction blocking component, SMS alert component, and manual review work order creation component as the target set; while when the attribute characteristic is low-risk missing logs, only the log supplementation component and internal notification component are selected. This attribute-based dynamic selection mechanism allows the same system to automatically adapt differentiated handling strategies for different business scenarios without the need to develop separate processing code for each scenario.

[0056] During the orchestration phase, the system does not simply stack the selected target action components in a disordered manner. Instead, it automatically generates a sequence of processing nodes with defined execution logic based on the dependencies between the target action components. In this application, the dependency relationship refers to the sequential relationship between data input and output of components or the order of business logic, which is expressed and stored at the underlying level through specific data structures.

[0057] As a preferred implementation, this dependency relationship is described using a Directed Acyclic Graph (DAG) data structure. In the DAG model, each target action component is mapped to a node, and the dependencies between components are mapped to directed edges.

[0058] For example, if the execution of the SMS alert component depends on the blocking result ID returned by the transaction blocking component, then there exists a directed edge in the graph pointing from the transaction blocking node to the SMS alert node. The advantages of using a DAG structure are twofold: firstly, it can automatically derive a valid linear or parallel execution sequence through topological sorting algorithms, ensuring the logical correctness of the processing flow; secondly, it can mathematically eliminate the risk of deadlock caused by circular dependencies, guaranteeing the stability of the system during runtime.

[0059] It should be understood that, in addition to DAG, in other embodiments, dependencies can also be implemented using other graph-theoretic data structures that can express temporal and causal relationships, such as adjacency lists, adjacency matrices, or Petri nets, as long as they can support the automated generation of processing sequences.

[0060] During the execution phase, the exception handling engine sequentially or concurrently calls the target action components to handle exception events according to the orchestrated sequence of processing nodes. Since the sequence of processing nodes is calculated in real time based on dependencies, its execution order strictly follows the inherent constraints of the business logic.

[0061] For example, in the DAG example above, the system first schedules and executes the transaction blocking component. After it successfully returns a result, the system passes that result as an input parameter to the SMS alarm component for triggering. If a preceding node fails, the system can decide whether to skip subsequent dependent nodes, execute a compensation node, or terminate the entire sequence based on a preset fault tolerance strategy. This dynamic orchestration and execution mechanism based on dependencies completely decouples the anomaly detection logic from the anomaly handling logic. This means that when adding or modifying a handling action, only the metadata definition and dependency graph in the component library need to be updated, without refactoring the entire processing flow code, greatly improving the maintainability and scalability of the system.

[0062] In this embodiment, the specific execution method of the processing node sequence generated in the above embodiments is further defined. Specifically, according to the processing node sequence, the target action component is invoked to handle the abnormal event, including: executing the target action component on the abnormal event according to the execution topology of the processing node sequence; wherein, the execution topology includes at least one of serial execution, parallel execution, or conditional branch execution; the action type of the target action component includes at least one of service blocking, alarm push, service degradation, or log recording.

[0063] This embodiment provides a specific runtime carrier for the dynamic orchestration mechanism in the above embodiments by defining diverse execution topologies and standardized action types, so that the abstract dependency graph can be transformed into deterministic machine execution instructions.

[0064] It should be understood that although this embodiment lists three typical topologies and four action types, these are merely preferred examples provided to explain the technical solution and are not intended to limit the scope of protection.

[0065] In other implementations, the execution topology may include more complex control flow structures such as loop execution and nested subprocesses; the action type may also be extended to any atomic operation that can be executed by a computer program, such as data cleaning, cache refresh, and external API callback.

[0066] In some implementations, serial execution topology is suitable for scenarios where there are strict temporal dependencies or data transmission relationships between target action components. For example, when dealing with high-risk transaction anomalies, the system must first call the business blocking component to cut off the transaction link. Only after receiving a successful blocking return code should the alarm push component be called to send a notification containing blocking details to the operations and maintenance personnel. If the order is reversed or the execution is parallel, it may result in missing key handling results in the alarm information, or even trigger downstream misoperations before the blocking takes effect. With serial topology, the anomaly handling engine strictly schedules components sequentially according to the direction of the directed edges, ensuring the causal correctness of the business logic.

[0067] Parallel execution topology is suitable for scenarios where the target action components are independent and have no data coupling. For example, when an abnormal event of excessive system load is detected, the processing node sequence may simultaneously include SMS notification components, email notification components, and dashboard refresh components. Since these three only consume the same abnormal event data and do not interact, the exception handling engine can utilize multi-threading or asynchronous I / O mechanisms to concurrently call these three components. Compared to serial execution, parallel topology can reduce the total processing time from the sum of the times of each component to the maximum value of the times of each component, significantly improving the timeliness of exception response in high-concurrency scenarios.

[0068] Conditional branching execution topology is used to implement differentiated routing based on anomaly attributes or intermediate states. For example, a conditional judgment node can be set in the processing node sequence. When the risk level field of an anomaly event is high, the process flows to the branch where the manual review component is located; when the risk level is low, the process flows to the branch where the automatic degradation component is located. This topology allows the same set of monitoring rules to adaptively select the optimal handling path based on the real-time context, avoiding the maintenance redundancy caused by configuring a complete processing chain separately for each risk level. At the underlying implementation level, conditional branching is usually implemented by introducing a gateway node in the DAG graph. This gateway node determines which subsequent edge to activate based on the result of a preset expression calculation.

[0069] Regarding the action types of target action components, business interruption refers to a mandatory operation that interrupts the current business process or rejects a request; alarm push refers to an information transmission operation that sends notifications to relevant personnel through channels such as instant messaging, email, and SMS; service degradation refers to a protective operation that shuts down non-core functions to ensure the availability of the main process when the system is overloaded or malfunctioning; and logging refers to the data retention operation that persistently stores abnormal situation data for post-event auditing. These four types cover the four core dimensions of loss prevention, notification, preservation, and traceability in anomaly handling.

[0070] To ensure that components of different action types can be uniformly scheduled and orchestrated in the same processing node sequence, this application defines a standardized interaction interface for each component in the atomic action component library.

[0071] Specifically, each target action component implements a unified input-output contract, including standardized input parameter data structures, output parameter data structures, and exception throwing specifications. Regardless of whether the component internally performs HTTP calls, database writes, or local calculations, its external calling method remains consistent. This standardized interface design is the technical foundation for achieving pluggable characteristics. It allows the exception handling engine to inject parameters and retrieve results without needing to be aware of the component's internal implementation details, simply by following the interface definition. When a new action type (such as automatic refund) needs to be added, developers only need to encapsulate the new component according to the standard interface and register it in the component library. It can then be immediately referenced by existing orchestration logic without modifying the engine's core code or restarting the service. This mechanism fundamentally guarantees the feasibility and scalability of dynamically configuring the processing node sequence.

[0072] In one implementation, the dynamic update mechanism mentioned in step S400 of the above embodiments is further specified. Specifically, based on the processing results, the trigger parameters of the monitoring rules are dynamically updated, including: based on a preset sliding time window, the trigger frequency of abnormal events and the processing success rate of abnormal handling actions are statistically analyzed; based on the trigger frequency, processing success rate, and a preset feedback algorithm, the parameter adjustment amount of the trigger parameters is calculated; and the trigger parameters are updated based on the parameter adjustment amount.

[0073] This implementation transforms the abstract dynamic update into a quantifiable mathematical logic model. By introducing statistical indicators with a time dimension and a defined feedback algorithm, the adaptive adjustment of monitoring rules is no longer a random or purely experience-based human setting, but an automated calculation process based on objective operational data. This effectively avoids the risks of purely human rules and strengthens the technical sophistication of the solution.

[0074] During the statistical phase, the data write-back component maintains a preset sliding time window for collecting runtime data. The sliding time window refers to a continuous time period that slides forward on the time axis with a fixed step size, and it includes two key attributes: window length and sliding step size.

[0075] The window length defines the time span of the statistical data, such as 60 seconds, 5 minutes, or 1 hour. A longer window length can smooth out noise interference caused by instantaneous traffic fluctuations and reflect more stable business trends. The sliding step size defines the frequency of window updates, such as 1 second or 10 seconds. A smaller step size can improve the system's responsiveness to environmental changes. It should be understood that, in addition to fixed-length sliding windows, other embodiments can also use counting windows based on the number of events or dynamic windows based on session periods, as long as they can provide continuous and ordered time-series samples.

[0076] Within this sliding time window, the system calculates two core metrics in real time. The first is the trigger frequency, calculated using the following formula: ,in This indicates the total number of abnormal events identified within the current window. The first term represents the window length. The trigger frequency characterizes the density of anomalies occurring in the current business scenario and is a direct physical quantity measuring system load pressure and risk exposure level. The second term is the processing success rate, calculated using the following formula: ,in This indicates the number of times the exception handling action within the window was successfully executed. This represents the total number of executions. The success rate characterizes the effectiveness of the current handling strategy. If this value remains consistently low, it indicates that the existing sequence of processing nodes may not be able to effectively handle the current abnormal pattern, or that the monitoring rules themselves contain false alarms leading to too many invalid actions. These two metrics together constitute the input vector of the feedback algorithm, characterizing the operational status of the monitoring system from both quantitative and qualitative dimensions.

[0077] Furthermore, during the calculation phase, the system calculates the parameter adjustment amount of the triggering parameters based on the triggering frequency, processing success rate, and a preset feedback algorithm. As a preferred implementation, the preset feedback algorithm adopts a weighted linear combination model, and its calculation formula is as follows.

[0078]

[0079] in, This indicates the amount of parameter adjustment required to trigger the action. This represents the actual trigger frequency within the current sliding time window; The baseline trigger frequency represents the expected level of anomalies in the system under normal steady state, and its value ranges from 80% to 120% of the historical statistical average. This represents the current actual processing success rate; The target success rate represents the standard for the expected handling effect of the business, and is usually set in a high confidence range between 0.9 and 0.99. This is the frequency sensitivity coefficient, used to adjust the weight of the impact of trigger frequency deviation on parameter adjustment. The value range is generally 0.1 to 0.5, and a larger value is taken when the business is more sensitive to traffic fluctuations. This is the effect compensation coefficient, used to adjust the weight of the impact of the treatment success rate deviation on parameter adjustment. The value range is generally from 0.5 to 1.0 to ensure that the treatment effect plays a dominant role in the feedback mechanism.

[0080] The above formula shows that when the actual trigger frequency Higher than the benchmark value When the first term is positive, it tends to increase the trigger parameter (such as raising the threshold) to suppress excessive sensitivity; when the actual processing success rate... Below the target value When the second factor is positive, it also tends to adjust parameters to optimize the handling effect. This two-factor feedback mechanism avoids the one-sidedness of adjustment caused by a single indicator. For example, if the triggering frequency is high but the processing success rate is also high, it means that the current strategy is effective even though it is busy, and the system only needs to fine-tune the parameters to adapt to the load; conversely, if the triggering frequency is low but the success rate is extremely low, it means that there may be serious missed reports or errors in the handling logic, and the system will generate a large positive adjustment to quickly correct the rules.

[0081] It should be understood that the above weighted linear combination model is only one example. In other embodiments, the feedback algorithm may also employ a PID control algorithm, a gradient descent variant, or a nonlinear mapping function based on reinforcement learning, as long as it can establish a deterministic mapping relationship from the state index to the parameter adjustment amount.

[0082] Finally, during the update phase, the system adjusts the parameters based on the calculated values. Update the trigger parameters. The specific update logic is as follows: ,in The trigger parameter value before the update. The updated trigger parameter value is used. To prevent parameter oscillations or out-of-bounds errors, the system also sets parameter boundary constraints and change rate limits. For example, the minimum value of the trigger parameter is set to 0, the maximum value to 200% of the initial value, and the adjustment range in a single instance cannot exceed 10% of the current value. This constraint mechanism ensures the convergence and stability of the adaptive process and prevents monitoring rules from failing due to occasional extreme data. Through the above complete quantitative feedback loop, this embodiment realizes the transformation of the monitoring strategy from passive configuration to active evolution, enabling the system to automatically find the optimal balance point of operating parameters without human intervention.

[0083] In this embodiment, the feedback algorithm mentioned in the above embodiments is further elaborated, providing two differentiated adaptive adjustment strategies for different anomaly modes. Specifically, based on the trigger frequency, processing success rate, and a preset feedback algorithm, the parameter adjustment amount of the trigger parameters is calculated, including: when the trigger frequency exceeds a first preset threshold, the numerical threshold in the trigger parameters is lowered according to a preset gradient; when the processing success rate is lower than a second preset threshold, a verification action insertion instruction is generated, which is used to dynamically insert verification action nodes into the processing node sequence.

[0084] This implementation demonstrates two dimensions of system self-evolution: parameter-level fine-tuning and structural-level refactoring. The former adapts to fluctuations in business traffic through numerical changes, while the latter compensates for deficiencies in the handling logic through topology changes. Together, they constitute a three-dimensional adaptive defense system.

[0085] First, regarding parameter-level adaptive adjustment, when the trigger frequency exceeds a first preset threshold, the system determines that the current monitoring rule is too sensitive or that there is an abnormal surge in business traffic, causing a large influx of events into the processing chain, which may lead to system overload or generate too many invalid alarms. At this point, the data write-back component triggers a negative feedback adjustment mechanism, lowering the numerical threshold in the trigger parameters according to a preset gradient. The first preset threshold is a critical value representing the system's upper limit tolerance for abnormal event density. Its setting is typically based on the statistical distribution of historical baseline data, such as taking the position three standard deviations of the average trigger frequency during the same period over the past 30 days, or deduced from the maximum throughput capacity of downstream processing components. The preset gradient defines the rate and direction of parameter adjustment; in this embodiment, it is represented by a negative step size factor used to control the magnitude of each adjustment to prevent parameter oscillation.

[0086] To illustrate this mechanism more clearly, a specific transaction risk control scenario is used as an example. Assume the monitoring rule is that a high-risk warning is triggered when a single transaction amount exceeds a threshold T, and the current threshold T in the trigger parameters is 100,000 yuan. During a certain promotional activity, the system detects that the trigger frequency F within the sliding time window reaches 50 times per second, while the first preset threshold F_max is set at 30 times per second. Since F > F_max, the system determines that the current threshold is too strict, leading to a flood of false alarms. At this point, the rule parsing engine 420 calculates a new threshold based on the preset gradient descent formula. As a preferred calculation method, the parameter adjustment amount... It can be determined using the following formula.

[0087]

[0088] in, This is a sensitivity coefficient, ranging from 0.1 to 0.5, used to adjust the aggressiveness of the system's response to frequency exceeding limits; This is the current threshold. Substituting the above value, if we take... ,but Yuan. The system updates the threshold to [value]. In practical engineering implementation, to avoid frequent decimal point calculations and parameter jitter, a minimum adjustment step size (e.g., 1000 yuan) can be set and the result rounded down, ultimately adjusting the threshold to 86,000 yuan or 80,000 yuan. Through this gradient adjustment mechanism, the system can automatically relax the identification threshold when traffic peaks arrive, effectively smoothing out peaks and valleys while ensuring that core risks are controllable, and protecting backend processing resources from being exhausted.

[0089] It should be understood that although this example uses the reduction of the amount threshold as an example, in other scenarios, if the triggering parameter is a positive indicator such as the number of allowed failures, the reduction operation may also be manifested as a decrease in value to increase sensitivity. The specific adjustment direction depends on the monotonic relationship between the triggering parameter and the degree of risk.

[0090] Secondly, regarding the adaptive adjustment at the structural level, when the processing success rate falls below the second preset threshold, it indicates that although the current processing node sequence is correctly triggered, it cannot effectively achieve the expected handling goals, such as blocking interface call failures, intercepting alarm messages, or automatic repair script execution errors. This usually means that the complexity of the abnormal event exceeds the capability boundary of the existing automated process, or that an unforeseen change has occurred in the external environment. At this point, simply adjusting numerical parameters cannot solve the problem; the system must enhance the processing logic itself. The data write-back component generates a verification action insertion instruction, which is used to dynamically insert verification action nodes into the processing node sequence.

[0091] The second preset threshold is the baseline for determining whether the current handling strategy has failed, typically set at a confidence level between 0.8 and 0.95. The specific value can be dynamically configured based on the business's accuracy requirements. Verification action nodes are atomic components specifically designed to verify data authenticity, supplement contextual information, or request manual intervention. They differ from conventional business handling components and primarily serve a diagnostic and fallback function.

[0092] Regarding the insertion position of verification action nodes, the system supports two modes: pre-verification and post-verification. Pre-verification mode is suitable for scenarios where poor input data quality leads to frequent processing failures. The system inserts the verification node at the beginning of the processing sequence or before critical dependent nodes. For example, before freezing an account, a secondary account status query node is inserted to confirm that the account has not been cancelled before freezing, thus avoiding invalid calls. Post-verification mode is suitable for scenarios with high uncertainty in processing results. The system inserts the verification node after the action, such as inserting a fund flow verification node after sending a successful refund notification. If the verification is inconsistent, a reversal process is automatically triggered. After receiving the verification action insertion instruction, the rule parsing engine recompiles the DAG graph of the processing node sequence, injects the new verification node and its dependent edges into the graph, and uses a hot-loading mechanism to make the updated sequence take effect immediately.

[0093] As can be seen from the comparison, the two strategies address drastically different anomaly modes: the gradient downsampling mechanism primarily addresses quantitative issues, namely systemic overload caused by flow fluctuations or inappropriate thresholds. Its adjustment methods are continuous and numerical, aiming to restore the system's steady-state equilibrium. In contrast, the check node insertion mechanism primarily addresses qualitative issues, namely handling failures caused by logical defects or environmental variations. Its adjustment methods are discrete and structured, aiming to improve the system's robustness and accuracy. This dual adaptive strategy enables the technical solution of this application not only to smoothly adjust parameters like a traditional PID controller but also to automatically generate new antibodies (check logic) when encountering novel threats, much like a biological immune system. This significantly enhances the non-obviousness and practical application value of the technical solution.

[0094] In this embodiment, the dynamic update mechanism of monitoring rules in the above embodiments is further specified at the underlying implementation level. Specifically, before performing anomaly identification on the business event flow based on monitoring rules, the method further includes: obtaining rule configuration instructions; parsing the rule configuration instructions into an executable script; and hot-loading the executable script into the rule execution container to update the monitoring rules.

[0095] This implementation transforms the rule configuration behavior of upper-layer business into the underlying code compilation and runtime loading technology process. Its core defense purpose is to prove that changes in monitoring rules are not simply modifications of data parameters or adjustments to management rules, but involve substantial reconstruction and dynamic deployment of computer program execution logic, thereby establishing the technical attributes of the technical solution at the computer system level.

[0096] Specifically, it will be implemented in the following manner.

[0097] First, the system obtains rule configuration instructions.

[0098] The rule configuration instructions here refer to declarative descriptive data used to define or modify anomaly identification logic. They are in a configuration state, separate from directly executed machine instructions. Operations personnel can orchestrate the logic through the rule configuration canvas on the operations terminal 500, or submit configuration requests through an external API interface. Regardless of the input source, the rule configuration instructions ultimately received by the system are a structured intermediate representation, such as a JSON object, XML document, or domain-specific language (DSL) text. This design decouples the configuration entry point from the execution engine, allowing non-technical personnel to generate standardized configuration instructions through a graphical interface without directly writing underlying code. It should be understood that rule configuration instructions only express the business intent of what to do and do not yet have the ability to be directly executed by the processor; they must undergo subsequent conversion processing.

[0099] Secondly, the rule parsing engine parses the rule configuration instructions into an executable script. This step is essentially a complete compilation or interpretation process.

[0100] The rule parsing engine first performs lexical and syntactic analysis on the rule configuration instructions to construct an Abstract Syntax Tree (AST), and then performs semantic verification to ensure the legality and completeness of the logic. Subsequently, the code generator traverses the AST and maps it to an executable script in the target programming language. The target programming language here refers to the runtime language supported by the rule execution container, such as Java, Python, Groovy, or Lua. For example, when the configuration instruction is defined as a JSON structure that triggers an alert when the transaction amount exceeds a threshold and the user level is VIP, the rule parsing engine 420 will compile it into a Java code snippet containing conditional statements and method calls. Through this compilation and transformation mechanism, the system transforms declarative business logic into imperative program code, enabling complex business rules to be executed with the performance of native code, avoiding the performance bottleneck caused by traditional interpreted rule engines parsing configuration files line by line.

[0101] Third, the system hot-loads executable scripts into the rule execution container to update monitoring rules. Hot-loading refers to dynamically replacing or adding rule logic instances in memory while the rule execution container remains running and the business event flow processing is not interrupted. This is a key technical means to ensure business continuity.

[0102] As a preferred implementation, this application employs a class loader isolation mechanism to achieve hot reloading. Specifically, the rule execution container creates an independent child class loader for each version of the monitoring rule. When a new executable script is received, the system creates a new child class loader to load the class file corresponding to the script, generating a new rule instance. After the new instance is initialized and passes a health check, the system atomically switches the traffic routing pointer from the old instance to the new instance. Once all tasks currently being executed on the old instance are completed, the old child class loader is unloaded and resources are released. This mechanism leverages the class loader delegation model and namespace isolation features of languages ​​such as Java to ensure the coexistence and smooth transition of old and new rules in memory, completely eliminating the business interruption window caused by service restarts.

[0103] As an alternative implementation, for lightweight rule update scenarios, dynamic proxies or reflection mechanisms can be used to achieve hot reloading. For example, the rule execution container maintains a proxy object for the rule interface. When the executable script is updated, the system recompiles the script and generates a new implementation class instance, then dynamically modifies the internal reference of the proxy object to point to the new instance through reflection. This approach is more lightweight and faster to start than class loader isolation, but it usually requires the scripting language to support dynamic typing or just-in-time compilation.

[0104] Through the above implementation steps, this embodiment constructs a complete automated chain from configuration commands to runtime logic. This technique shortens the iteration cycle of monitoring rules from a traditional development-testing-packaging-deployment-restart process that takes several days to a configuration-compilation-loading process that takes only seconds, greatly improving the monitoring system's responsiveness to business changes. Simultaneously, because the entire process is completed automatically by the system without manual intervention in the production environment, it also significantly reduces the risk of service failures due to human error, ensuring the stability of the highly available business system.

[0105] In this embodiment, the rule configuration instruction parsing process mentioned in the above embodiments is elaborated in detail. Specifically, parsing the rule configuration instruction into an executable script includes: identifying the data format of the rule configuration instruction, where the data format includes a domain-specific language or a structured data format; and compiling the rule configuration instruction into an executable script in the target programming language based on the compilation rules corresponding to the data format.

[0106] This implementation effectively decouples the diversity of upper-layer business definitions from the uniformity of the underlying execution engine by introducing multi-format adaptation and standardized compilation mechanisms. Its core defensive objective is to establish a broad interpretation of the concept of configuration instructions, preventing others from circumventing infringement simply by changing the syntax of configuration files (e.g., changing JSON to XML or custom text). It also demonstrates that the parsing process is based on deterministic technical processing implemented using compiler principles from computer science, rather than simple data reading or manual translation.

[0107] In some examples, the rule parsing engine first identifies the data format of the rule configuration instructions. Here, data format refers to the symbol system or data structure specification that carries the monitoring logic definition. As a preferred implementation, the data format should at least cover the following two typical forms: The first is Domain Specific Language (DSL), a simplified syntax system designed specifically for business monitoring scenarios. For example, it might use a natural language style expression like WHEN event.amount>threshold AND user.level == 'VIP' THEN trigger_alert. Its advantage lies in its intuitive semantics and close alignment with business thinking, making it suitable for non-technical personnel to quickly learn. The second is structured data formats, including but not limited to JSON (JavaScript Object Notation), XML (eXtensible Markup Language), YAML (YAML Ain't Markup Language), or Protocol Buffers. These formats have strict schema definitions and hierarchical structures, making them suitable for automatic machine generation, cross-system transmission, and version management.

[0108] It should be understood that the above examples are merely illustrative. In other embodiments, the data format may also be a binary serialized stream, a database table record, or even speech-to-text, as long as it can be recognized by the parser and its logical semantics can be extracted.

[0109] The aforementioned rule parsing engine, based on compilation rules corresponding to the data format, compiles the rule configuration instructions into executable scripts in the target programming language. Here, compilation rules do not refer to a single transformation function, but rather a complete collaborative process between the compiler front-end and back-end.

[0110] To avoid the maintenance explosion caused by developing a separate code generator for each data format, this application introduces Intermediate Representation (IR) as a format-independent abstract semantic layer. The entire compilation process specifically includes the following sub-steps.

[0111] First, based on the identified data format, the corresponding parser is dynamically loaded. For example, if the data is identified as DSL format, a lexical parser based on ANTLR or JavaCC is loaded; if it is identified as JSON format, a structured parser based on Jackson or Gson is loaded. Although the input sources of each parser are different, they are all designed to output a unified Abstract Syntax Tree (AST). The AST is a tree-like abstract representation of the monitored logical structure, and its node types include condition judgment nodes, logical operation nodes, variable reference nodes, action call nodes, etc., completely stripping away the syntactic details of the original format.

[0112] Secondly, the system converts the AST (Abstract Syntax Tree) into a standardized intermediate representation (IR). IR is a standardized description situated between high-level business semantics and low-level machine instructions, typically employing three-address codes, static single assignment (SSA) format, or specific bytecode protocols. IR design adheres to the principles of high cohesion and low coupling, retaining only the minimum set of information required for logical execution. For example, regardless of whether the original configuration is written in DSL (e.g., amount greater than threshold) or in JSON (e.g., {op: 'gt', left: 'amount', right:'threshold'}), at the IR level it is uniformly represented as a standard instruction sequence such as CMP_GT VAR_amount CONST_threshold. This step is a crucial technical pivot for achieving format independence.

[0113] Finally, the code generator iterates through the IR (Instructions Representation), mapping it to executable scripts in the target programming language. The target programming language refers to the native language supported by the rule execution container 430 runtime, such as Java, Python, Groovy, or Lua. The code generator has built-in mapping templates from IR instructions to target language syntax structures. For example, when the target language is Java, the CMP_GT instruction in the IR is rendered as the code snippet `if (context.getVar("amount")>context.getParam("threshold"))`; while when the target language is Python, the same IR instruction is rendered as the code snippet `if context['amount']>context.params['threshold']:`. Through this multi-fronttend + unified IR + multi-backend compiler architecture, the system achieves complete decoupling between configuration format and execution language.

[0114] To further illustrate the above compilation and conversion mechanism more clearly, a specific cross-format compatibility scenario is used as an example. Suppose the operations personnel initially defined the monitoring rule in JSON format: {"condition": {"field": "cpu_usage", "operator": ">", "value": 90}, "action": "send_sms"}. After the rule parsing engine 420 recognizes it as JSON, it calls the JSON parser to convert it into an AST, thereby generating an IR instruction sequence [LOAD_VAR cpu_usage, PUSH_CONST 90, CMP_GT, JUMP_IF_FALSE end, CALL send_sms, LABEL end]. Subsequently, the Java code generator compiles this IR sequence into a Java class code and hot-loads it into the rule execution container. Three months later, the business team decides to migrate to the more readable DSL format, rewriting the same rule as IF cpu_usage>90 THEN send_sms. At this point, the system only needs to switch to the DSL parser. The generated AST and IR sequences are completely identical to the aforementioned JSON version, so the Java code generated on the backend is also exactly the same, requiring no additional adaptation or regression testing. Conversely, if the rule execution container 430 is migrated from a Java environment to a Python environment in the future, only the code generator module needs to be replaced, and all existing JSON and DSL configuration instructions can be seamlessly reused.

[0115] Through the above implementation steps, this embodiment not only supports the coverage requirements for multiple data formats in the claims, but more importantly, it reveals the technical means behind achieving this compatibility—a layered compilation architecture based on intermediate representation. This architecture allows the system to cope with new configuration protocols (such as GraphQL, TOML) or new execution environments (such as WebAssembly, eBPF) that may emerge in the future, requiring only the extension of the corresponding parser or generator plugins without refactoring the core engine. This endows the technical solution with strong lifecycle adaptability and defense depth.

[0116] As one embodiment, the anomaly identification mechanism mentioned in step S200 of the above embodiments is further elaborated. Specifically, anomaly identification of the business event stream based on monitoring rules to obtain anomaly events includes: matching the attribute features of a single business event in the business event stream based on the single event judgment condition in the monitoring rules to obtain a first identification result; and / or calculating and matching the aggregation features of multiple business events within a preset time window based on the window aggregation judgment condition in the monitoring rules to obtain a second identification result; and determining the anomaly event based on the first identification result and / or the second identification result.

[0117] This implementation method complements anomaly detection techniques by constructing a two-dimensional identification system that combines point and surface approaches. Single-event judgment focuses on real-time attribute verification of discrete data points, characterized by statelessness and low latency, making it suitable for capturing sudden, independent point-like anomalies. Window aggregation judgment, on the other hand, focuses on temporal pattern analysis of continuous data streams, exhibiting statefulness and context awareness, making it suitable for capturing cumulative, trend-based, or frequency-based composite anomalies. Both approaches are independent yet complementary in terms of data source, computational logic, and execution timing, jointly enhancing the comprehensiveness and accuracy of anomaly identification.

[0118] As a specific embodiment, it is implemented through the following steps.

[0119] First, the rule execution container matches the attribute features of a single business event in the business event stream based on the single event judgment conditions in the monitoring rules to obtain the first identification result.

[0120] The single-event judgment condition here refers to a logical expression that can independently complete the judgment based solely on the information carried by the current event itself, without accessing historical data or maintaining additional states. For example, in a transaction risk control scenario, the single-event judgment condition could be a transaction amount greater than 50,000 yuan or a transaction status code of FAILED. When a business event enters the rule execution container 430, the system immediately extracts its attribute fields and compares them with preset thresholds or enumerated values. If a match is successful, the first identification result with a Boolean value of true is output; otherwise, false is output. Since this process does not involve historical data retrieval or aggregation calculation in memory, its single execution time is typically in the microsecond range, ensuring real-time throughput for massive business event streams. It should be understood that while single-event judgment is efficient, its scope is limited to isolated snapshots and cannot identify risk patterns that require temporal correlation to manifest, such as frequent small-amount trials within a short period of time.

[0121] Secondly, in order to compensate for the blind spots of single-point detection, the system executes in parallel based on the window aggregation judgment conditions in the monitoring rules, calculates and matches the aggregation features of multiple business events within a preset time window, and obtains the second identification result.

[0122] The preset time window here refers to the time range defined on the timeline to delineate the set of events participating in the aggregation calculation. Physically, it represents the attention span of the system's observation of business behavior. The window length can be configured according to business characteristics; for example, it can be set to 10 to 60 seconds for high-frequency trading scenarios and 5 minutes to 1 hour for user behavior analysis scenarios. Aggregation features are derived metrics obtained after statistical calculations on the event set within the window, including but not limited to count, sum, average, maximum / minimum, distinct count, or standard deviation.

[0123] Regarding the underlying state maintenance mechanism for window aggregation judgment, as a preferred implementation, the rule execution container uses a ring buffer combined with a timestamp index to manage window data. Whenever a new event arrives, the system appends it to the end of the buffer and simultaneously scans the head of the buffer, removing expired events whose timestamps exceed the current window range. This ensures that the buffer always retains only event samples from the valid window. This in-place overwrite memory management mechanism avoids the overhead of frequent object creation and garbage collection, enabling aggregation calculations to be completed within constant-level memory space.

[0124] As an alternative implementation, in a distributed stream processing architecture, a watermark-based sliding window or session window mechanism can also be used, with the stream computing framework automatically managing the state backend and window triggering logic. Regardless of the underlying implementation, the core value of window aggregation judgment lies in transforming discrete time-series signals into continuous trend characteristics. For example, by calculating the number of failed transactions for the same user ID within the past 60 seconds, the system can accurately identify brute-force attacks or credential stuffing attacks, which are often missed as normal single failed requests in a single-event dimension.

[0125] Third, the system determines the abnormal event based on the first identification result and / or the second identification result. Here, AND / OR expresses a flexible logical combination relationship between the two identification dimensions, specifically including logical AND, logical OR, and logical NOT, and their arbitrary nested combinations.

[0126] When using OR, an event is considered an anomaly if either the single-event judgment or the window aggregation judgment is true. This mode is suitable for highly sensitive scenarios, aiming to maximize anomaly recall and prevent any risk omission. When using AND, both dimensions must be true for an event to be considered an anomaly. This mode is suitable for high-precision scenarios, aiming to filter noise and reduce false alarms through a double confirmation mechanism. For example, in a payment anti-fraud rule, a trigger condition could be set: a single transaction amount > 10,000 yuan AND >= 2 instances of logins from different locations within the past 5 minutes. Only when a large transaction and abnormal login behavior are correlated in time and space is it confirmed as a high-risk event.

[0127] Through this configurable logic combiner, the technical solution of this application enables operation and maintenance personnel to freely customize the leniency and rigor of detection strategies according to actual business pain points, realizing the leap from a single static rule to a multi-dimensional dynamic model for anomaly identification logic.

[0128] To achieve the above functions, the business data processing apparatus includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art will readily recognize that, based on the algorithmic steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0129] This disclosure also provides an embodiment such as Figure 2 The business data processing device shown includes the following modules: acquisition module 21, anomaly detection module 22, anomaly handling module 23, and parameter update module 24.

[0130] The acquisition module 21 is configured to acquire business event streams; the anomaly detection module 22 is configured to identify anomalies in the business event streams based on monitoring rules to obtain anomaly events, and the monitoring rules include trigger parameters; the anomaly handling module 23 is configured to perform anomaly handling based on a dynamically configured sequence of processing nodes in response to the identified anomaly event; and the parameter update module 4 is configured to dynamically update the trigger parameters of the monitoring rules based on the execution result data.

[0131] It should be understood that the above modules can be implemented in hardware, such as by constructing corresponding logic circuits through field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs); or they can be implemented in the form of software functional units, such as program code stored in memory and executed by a processor. This embodiment does not specifically limit this.

[0132] The aforementioned acquisition module 21, anomaly detection module 22, anomaly handling module 23, and parameter update module 24 are respectively configured to execute the corresponding implementation steps in the business data processing method in the above embodiments.

[0133] It should be noted that the aforementioned acquisition module 21, anomaly detection module 22, anomaly handling module 23, and parameter update module 24 do not refer to independent physical hardware circuits, but rather to functional logical divisions presented by the processor when executing specific program segments. For example, when it is necessary to upgrade the anomaly recognition algorithm or adjust the feedback strategy, only the computer program in memory needs to be updated, without replacing the processor or other hardware components. Furthermore, data interaction between the functional modules is accomplished through shared memory regions, inter-process communication (IPC) mechanisms, or internal buses, ensuring low latency and consistency of data transmission in high-concurrency scenarios.

[0134] Regarding the apparatus in the above embodiments, the specific manner in which each unit module performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0135] Figure 3 This is a schematic diagram of an electronic device provided in this application. (For example...) Figure 3 The electronic device 50 may include at least one first processor 501 and a memory 503 for storing processor-executable instructions. The first processor 501 is configured to execute the instructions in the memory 503 to implement the business data processing method described in the following embodiments.

[0136] In addition, electronic device 50 may also include communication bus 502, at least one communication interface 504, input device 506 and output device 505.

[0137] The first processor 501 may be a processor (central processing unit, CPU), a microprocessor unit, an ASIC, or one or more integrated circuits for controlling the execution of programs according to the present application.

[0138] The communication bus 502 may include a path for transmitting information between the aforementioned components.

[0139] Communication interface 504 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc.

[0140] Input device 506 is used to receive input signals and output device 505 is used to output signals.

[0141] Memory 503 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory may exist independently and be connected to the processing unit via a bus. Memory may also be integrated with the processing unit.

[0142] The memory 503 stores instructions for executing the scheme of this application, and the execution is controlled by the first processor 501. The first processor 501 executes the instructions stored in the memory 503 to realize the functions of the method of this application.

[0143] In a specific implementation, as one example, the first processor 501 may include one or more CPUs, for example... Figure 3 CPU0 and CPU1 in the CPU.

[0144] In a specific implementation, as one example, the electronic device 50 may include multiple processors, such as... Figure 3 The first processor 501 and the second processor 507 are described. Each of these processors can be a single-core processor or a multi-core processor. A processor here can refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0145] The electronic device is as follows Figure 3 The diagram includes a first processor 501 and a memory 503 for storing executable instructions of the first processor 501; wherein the first processor 501 is configured to execute executable instructions to implement a business data processing method as described in any of the possible embodiments above. Since the same technical effects can be achieved, further details are omitted here to avoid repetition.

[0146] This application also provides a computer-readable storage medium, which, when executed by a processor of a business data processing apparatus or an electronic device, enables the business data processing apparatus or electronic device to perform a business data processing method as described in any of the possible embodiments above. The same technical effects can be achieved, and to avoid repetition, further details are omitted here.

[0147] This application also provides a computer program product, including a computer program or instructions, which are executed by a processor as a business data processing method according to any of the possible implementations described above. Furthermore, it achieves the same technical effects, and to avoid repetition, it will not be described again here.

[0148] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application 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 application are indicated by the following claims.

[0149] It should be understood that this application is not limited to the precise structure 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 application is limited only by the appended claims.

Claims

1. A business data processing method, characterized in that, include: Obtain the business event stream; Anomalies are identified in the business event stream based on monitoring rules to obtain abnormal events. The monitoring rules include triggering parameters. In response to the identification of the abnormal event, the abnormal event is processed based on a dynamically configured sequence of processing nodes; Based on the processing results, the trigger parameters of the monitoring rules are dynamically updated.

2. The business data processing method according to claim 1, characterized in that, The dynamically configured processing node sequence handles the abnormal events, including: Based on the attribute characteristics of the abnormal event, a target action component is selected from a preset atomic action component library; Based on the dependencies between the target action components, the sequence of processing nodes is orchestrated and generated. According to the processing node sequence, the target action component is invoked to process the abnormal event.

3. The business data processing method according to claim 2, characterized in that, The step of invoking the target action component according to the processing node sequence to handle the abnormal event includes: Based on the execution topology of the processing node sequence, the target action component is executed for the abnormal event; The execution topology includes at least one of serial execution, parallel execution, or conditional branch execution; The action type of the target action component includes at least one of service blocking, alarm push, service degradation, or log recording.

4. The business data processing method according to claim 1, characterized in that, The step of dynamically updating the trigger parameters of the monitoring rule based on the processing result includes: Based on a preset sliding time window, the trigger frequency of the abnormal event and the success rate of the abnormal handling action are statistically analyzed. Based on the trigger frequency, the processing success rate, and the preset feedback algorithm, the parameter adjustment amount of the trigger parameter is calculated; The trigger parameters are updated based on the parameter adjustment amount.

5. The business data processing method according to claim 4, characterized in that, The step of calculating the parameter adjustment amount of the triggering parameter based on the triggering frequency, the processing success rate, and a preset feedback algorithm includes: When the triggering frequency exceeds the first preset threshold, the numerical threshold in the triggering parameter is lowered according to a preset gradient. When the processing success rate is lower than the second preset threshold, a verification action insertion instruction is generated. The verification action insertion instruction is used to dynamically insert verification action nodes into the processing node sequence.

6. The business data processing method according to claim 1, characterized in that, Before performing anomaly identification on the business event stream based on the monitoring rules, the method further includes: Get rule configuration instructions; The rule configuration instructions are parsed into an executable script; The executable script is hot-loaded into the rule execution container to update the monitoring rules.

7. The business data processing method according to claim 6, characterized in that, The step of parsing the rule configuration instructions into an executable script includes: Identify the data format of the rule configuration instructions, wherein the data format includes a domain-specific language or a structured data format; Based on the compilation rules corresponding to the data format, the rule configuration instructions are compiled into an executable script in the target programming language.

8. The business data processing method according to claim 1, characterized in that, The abnormal events obtained by identifying anomalies in the business event stream based on monitoring rules include: Based on the single-event judgment conditions in the monitoring rules, the attribute features of a single business event in the business event stream are matched to obtain a first identification result; and / or, Based on the window aggregation judgment conditions in the monitoring rules, the aggregation features of multiple business events within a preset time window are calculated and matched to obtain a second identification result; The abnormal event is determined based on the first identification result and / or the second identification result.

9. A business data processing apparatus for performing any one of claims 1 to 8, characterized in that, The device includes: The acquisition module is configured to acquire business event streams; The anomaly detection module is configured to identify anomalies in the business event stream based on monitoring rules to obtain abnormal events, wherein the monitoring rules include trigger parameters; An exception handling module is configured to process the exception event based on a dynamically configured sequence of processing nodes in response to the identification of the exception event. The parameter update module is configured to dynamically update the trigger parameters of the monitoring rule based on the processing result.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the business data processing method according to any one of claims 1 to 8.

Images