Cloud edge collaborative streaming analysis method, system and device for business big data

Abstract

The invention relates to a cloud edge collaborative streaming analysis method, system and device for business big data, and the method comprises the steps: receiving streaming data packets from a plurality of edge nodes, extracting business entity identifiers of the streaming data packets, carrying out the fusion calculation of the business entity identifiers and feature vectors, and generating a global state view; performing traversal matching on the global state view and rule conditions in a preset first business rule set, identifying abnormal state features, triggering a rule updating process, extracting a historical state view from a historical database and performing business iteration on the historical state view and the abnormal state features, and generating a candidate replacement rule set; and packaging the replacement service rule into a rule updating instruction according to the sorting issuing queue, and distributing the rule updating instruction to the corresponding edge node to complete rule updating. According to the invention, the real-time accurate updating of the business rule can be realized, so that the response speed and decision accuracy of the dynamic business environment are obviously improved.

Description

Technical Field

[0001] This invention relates to the technical field of business big data, and in particular to a cloud-edge collaborative streaming analysis method, system, and device for business big data. Background Technology

[0002] As enterprises deepen their digital transformation, the data generated during business operations exhibits massive, real-time, and multi-source streaming characteristics. Cloud-edge collaborative computing has become a key paradigm for processing such business big data and achieving intelligent decision-making. Within this paradigm, the core challenge lies in how to perform real-time analysis of business flows dispersed at the edge from a global perspective and dynamically optimize the processing logic of edge nodes. Existing analysis methods typically employ static rules or periodic batch update strategies, which struggle to adapt to rapid changes in business dynamics and lack precise perception and targeted optimization mechanisms for abnormal states. This results in delayed business rule updates, impacting both global analysis results and real-time edge processing effectiveness. Summary of the Invention

[0003] The main objective of this invention is to provide a cloud-edge collaborative streaming analysis method, system, and device for business big data, which can realize real-time and accurate updates of business rules, thereby significantly improving the system's response speed and decision-making accuracy in the face of dynamic business environments.

[0004] To achieve the above objectives, this invention provides a cloud-edge collaborative streaming analysis method for business big data, comprising: Receive streaming data packets from multiple edge nodes, extract the business entity identifier and feature vector of the streaming data packets, perform fusion calculation, and generate a global state view; The global state view is traversed and matched with the rule conditions in the preset first business rule set to identify abnormal state characteristics and trigger the rule update process. The historical state view is extracted from the historical database and the abnormal state characteristics are used for business iteration to generate a set of candidate replacement rules. Calculate the content difference between the candidate replacement rule set and the first business rule set. When the content difference exceeds a preset difference threshold, extract the replacement business rule from the candidate replacement rule set and insert it into a preset sorting and distribution queue. The replacement business rule is encapsulated into a rule update instruction according to the sorted distribution queue, and then distributed to the corresponding edge node to complete the rule update.

[0005] Preferably, the step of receiving streaming data packets from multiple edge nodes, extracting the service entity identifiers and feature vectors of the streaming data packets, fusing them together, and generating a global state view includes: Each of the streaming data packets is parsed and separated to obtain the business entity identifier and the feature vector; Using the business entity identifier as the index key, feature vectors from different edge nodes but with the same business entity identifier are merged into the same business entity group, and the timestamp and edge node information of each feature vector are recorded. Each business entity group is sorted by timestamp and associated with the business entity identifier for aggregation and situational analysis to generate the global state view.

[0006] Preferably, the step of traversing and matching the global state view with the rule conditions in the preset first business rule set to identify abnormal state characteristics and trigger the rule update process, extracting the historical state view from the historical database and performing business iteration with the abnormal state characteristics to generate a candidate replacement rule set, includes: Iterate through each rule condition in the first business rule set and match it item by item with the business entity state features in the global state view; When it is detected that the state feature of the business entity does not meet the rule conditions, the abnormal state feature that triggers the abnormality in the state feature of the business entity is extracted and recorded as a matching abnormal event. Based on the similarity of the abnormal state features in the matched abnormal events, the matched abnormal events are grouped into abnormal groups to obtain abnormal feature patterns; Based on the abnormal feature pattern, retrieve the historical state view containing similar patterns from the historical database; Based on the historical state view, historical rule change records associated with the abnormal feature pattern are extracted, and the candidate replacement rule set is generated through rule adjustment and business iteration.

[0007] Preferably, based on the historical state view, historical rule change records associated with the abnormal feature pattern are extracted, and through rule adjustment and business iteration, the candidate replacement rule set is generated, including: Traverse the historical rule change records associated with the abnormal feature pattern in the historical state view, and extract the handling effect data from each historical rule change record; Each historical rule change record is compared and analyzed with the first business rule set to identify the corresponding differences, and the validity weight of the differences is marked according to the processing effect data. Based on the differences and the validity weights, the historical rule conditions in the historical rule change records are extracted, and the parameters of the historical rule conditions are adjusted and the logic is optimized to generate candidate rule information. Verify whether the candidate rule information generates false alarms in the historical state view and can correctly identify the abnormal feature pattern. Integrate the verified candidate rule information to obtain the candidate replacement rule set.

[0008] Preferably, the step of calculating the content difference between the candidate replacement rule set and the first business rule set, and extracting replacement business rules from the candidate replacement rule set and inserting them into a preset sorting and distribution queue when the content difference exceeds a preset difference threshold, includes: The conditional expressions, parameter values, and logical operators of the candidate replacement rule set and the first business rule set are compared one by one. The difference values ​​of each part are calculated and integrated to generate the content difference degree. Each content difference is compared with the preset difference threshold, and the rule conditions that exceed the preset difference threshold are marked as mismatch rules, and the total number of mismatch rules in the current period is counted. When the total number of mismatched rules exceeds a preset threshold, the corresponding replacement business rule is extracted from the candidate replacement rule set based on the mismatched rules. The replacement business rules are sorted in descending order according to their content differences and then inserted into the distribution queue in sequence.

[0009] Preferably, the step of comparing the conditional expressions, parameter values, and logical operators of the candidate replacement rule set with the first business rule set, calculating the difference values ​​of each part respectively, and integrating them to generate a content difference score includes: The conditional expressions of the corresponding rule pairs in the first business rule set and the candidate replacement rule set are parsed, each conditional expression is decomposed into an operand sequence and an operator sequence, and the difference between the two sequences is calculated to obtain a structural difference metric. Extract the parameter values ​​from the rule pair, calculate and integrate the relative change percentage of the numerical parameters and the enumeration similarity of the non-numerical parameters to obtain the parameter difference metric. Analyze the operator types and logical relationships of the logical operators in the rule pairs, and integrate them to generate logical difference metrics; The structural difference metric, the parameter difference metric, and the logical difference metric are weighted and fused according to a preset weight ratio to obtain the content difference degree.

[0010] Preferably, the step of encapsulating the replacement business rule into a rule update instruction according to the sorted distribution queue and distributing it to the corresponding edge node to complete the rule update includes: According to the sorted distribution queue, the rule identifier, version number and update content of each replacement business rule are extracted sequentially, and serialized and encapsulated according to the preset instruction format to generate the rule update instruction; According to each of the replacement business rules, find the target edge node that needs to be updated, and query the current status information of the target edge node; Based on the current status information and the distribution urgency level of the sorted distribution queue, an instruction distribution strategy is formulated; According to the distribution strategy, the rule update instruction is sent to the target edge node, and the instruction transmission status is monitored. If a transmission failure or target node response timeout is detected, a retransmission mechanism is initiated until the update is confirmed.

[0011] Preferably, the step of formulating an instruction distribution strategy based on the current status information and the distribution urgency level of the sorted distribution queue includes: The network connection quality level, computing load rate, and available storage space parameters of the current status information are extracted to construct the state profile of the node. The distribution emergency level is matched with the node status profile to obtain the instruction matching result; Based on the matching results, the distribution channels of each rule update instruction are identified as the corresponding real-time push channel, batch transmission channel, and timed synchronization channel; Each of the distribution channels is configured with a transmission mode, and the transmission modes are integrated to form the instruction distribution strategy, wherein the real-time push channel is in immediate send mode, the batch channel is in batch transmission mode, and the timed synchronization channel is in timed synchronization mode.

[0012] Preferably, the present invention also provides a cloud-edge collaborative streaming analysis system for business big data, applied to any one of the cloud-edge collaborative streaming analysis methods for business big data described above, comprising: The acquisition module is used to receive streaming data packets from multiple edge nodes, extract the business entity identifier and feature vector of the streaming data packets, perform fusion calculation, and generate a global status view. The analysis module is used to traverse and match the global state view with the rule conditions in the preset first business rule set, identify abnormal state characteristics, and trigger the rule update process. It extracts the historical state view from the historical database and performs business iteration with the abnormal state characteristics to generate a set of candidate replacement rules. The association module is used to calculate the content difference between the candidate replacement rule set and the first business rule set. When the content difference exceeds a preset difference threshold, the replacement business rule is extracted from the candidate replacement rule set and inserted into a preset sorting and distribution queue. The processing module is used to encapsulate the replacement business rule into a rule update instruction according to the sorted distribution queue, and distribute it to the corresponding edge node to complete the rule update.

[0013] This invention also provides a cloud-edge collaborative streaming analytics device for business big data, comprising: Memory, used to store programs; A processor is used to execute the program to implement the various steps of the cloud-edge collaborative streaming analysis method for business big data described in any of the above-mentioned embodiments.

[0014] The present invention provides a cloud-edge collaborative streaming analysis method, system, and device for business big data, which has the following beneficial effects: By generating a global state view through real-time fusion of streaming data from multiple edge nodes and dynamically iterating replacement rules based on anomaly characteristics, real-time and accurate updates of business rules can be achieved, significantly improving the system's response speed and decision-making accuracy in dynamic business environments. By matching global analysis results with rule conditions and calculating the degree of difference, rule issuance is ensured only when there is substantial optimization, enabling on-demand allocation of cloud-edge collaborative resources and avoiding unnecessary communication and computational overhead. Through a priority queue-based rule distribution mechanism, priority updates of critical business logic are guaranteed, maintaining overall system processing performance and stability in complex and ever-changing business scenarios. Attached Figure Description

[0015] Figure 1 This is a flowchart of a cloud-edge collaborative streaming analysis method for business big data provided by the present invention; Figure 2 This is a structural diagram of a cloud-edge collaborative streaming analysis system for business big data provided by the present invention; Figure 3 This is a structural diagram of a cloud-edge collaborative streaming analysis device for business big data provided by the present invention.

[0016] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0018] The present invention will now be further described in conjunction with the accompanying drawings and specific embodiments.

[0019] Reference Figure 1The present invention provides a cloud-edge collaborative streaming analysis method for business big data, comprising: Step S1: Receive streaming data packets from multiple edge nodes, extract the business entity identifier and feature vector of the streaming data packets, perform fusion calculation, and generate a global status view; Step S2: Iterate and match the global state view with the rule conditions in the preset first business rule set, identify abnormal state characteristics, and trigger the rule update process. Extract the historical state view and abnormal state characteristics from the historical database for business iteration and generate a set of candidate replacement rules. Step S3: Calculate the content difference between the candidate replacement rule set and the first business rule set. When the content difference exceeds the preset difference threshold, extract the replacement business rule from the candidate replacement rule set and insert it into the preset sorting and distribution queue. Step S4: The replacement business rules are encapsulated into rule update instructions by sorting the distribution queue and distributed to the corresponding edge nodes to complete the rule update.

[0020] Based on the steps described above, the detailed process is as follows: Step S1: The cloud-based analytics hub continuously monitors and receives streaming data packets asynchronously transmitted from distributed edge nodes via message middleware. Each streaming data packet contains structured data that has undergone preliminary processing at the edge, and its encapsulation format follows a unified protocol specification. Upon arrival, the data packets undergo integrity verification and decryption to ensure the reliability and security of data transmission. The data packets are parsed to separate the header and payload. Key business entity identifiers are extracted from the header; these identifiers uniquely represent a business instance, such as a transaction session ID in a securities trading scenario or a device physical code in an IoT scenario.

[0021] The system extracts feature vectors calculated from edge nodes from the payload. These vectors are multi-dimensional numerical feature sets used to describe the operational state of business entities within a specific time window. The extraction process involves deserializing serialized data and transforming data objects based on a predefined field mapping table. After extraction, the system enters the fusion computation stage. Fusion computation uses the business entity identifier as the core index key to merge feature vectors from different edge nodes that point to the same business entity. The system maintains a memory-based global state cache table, which uses the business entity identifier as the key and a list of time-series feature vectors as values.

[0022] When a new feature vector arrives, the system queries the cache table. If a record for the corresponding business entity exists, the new vector is inserted into the list in timestamp order; otherwise, a new record is created. This process ensures continuous tracking of the overall state of the same business entity. Fusion computation is not simply a data stacking process, but includes state deduction.

[0023] Based on the latest feature vector sequence, built-in state calculation functions are invoked, such as calculating the moving average of indicators, detecting data distribution drift, or performing state inference based on predefined business logic. A global state view is generated for each tracked business entity. This view is a composite data structure that aggregates multi-dimensional and multi-time point state information, reflecting the latest and most complete operational status of the business entity on a global scale.

[0024] Step S2: The system loads a pre-configured first set of business rules, which is stored in a database accessible to the rule engine. Each rule contains one or more conditional expressions used to determine whether a state is normal. The rule engine iterates through each rule in the first set of business rules and applies the conditional expressions of each rule to the currently generated global state view.

[0025] The matching process is a step-by-step comparison. The rule engine extracts the state feature values ​​referenced by the rule conditions from the global state view and logically compares them with the thresholds or patterns defined in the rule conditions. When the rule engine detects that the state feature of a business entity does not meet the conditions of a rule, it determines that a rule matching exception has occurred. The engine then captures the key state feature that triggered this exception, marks it as an exception state feature, and generates a matching exception event containing the exception state feature, the associated business entity identifier, the triggered rule ID, and a timestamp.

[0026] This event not only triggers real-time alerts, but more importantly, it serves as a signal to initiate the rule update process. Once the rule update process is triggered, the system uses this abnormal state characteristic as a query condition to retrieve historical state views with similar abnormal patterns from the historical database. The retrieval process may involve pattern similarity calculations to find similar abnormal scenarios that have occurred in the past.

[0027] The system analyzes the retrieved historical state views and their corresponding handling records, focusing on the rule adjustment measures taken historically for such anomalies and their final effects. By analyzing these historical experiences, the system iterates its business logic: based on successful historical rule change patterns and combined with the specific parameters of the current anomaly state, it adaptively adjusts, optimizes, or restructures the conditional expressions of the original rules, thereby generating a series of candidate replacement rules that may be more suitable for the current business environment. These candidate replacement rules constitute a set, representing potential solutions proposed by the system for newly emerging anomaly patterns.

[0028] Step S3: The newly generated set of candidate replacement rules is compared with the currently effective set of first business rules in a refined manner. This comparison is not a simple overall consistency check, but rather delves into the internal structure of each rule's conditional expression. The conditional expression of each rule is parsed and broken down into basic elements such as operands, operators, and parameter values.

[0029] For each pair of corresponding old and new rules, the system calculates the differences in three dimensions: syntax structure, parameter values, and logical operators. For example, at the structural level, it analyzes the changes in the tree structure of the conditional expression; at the parameter level, it calculates the deviation of numerical parameters or the addition of enumeration parameters; and at the logical level, it determines changes in operator types or adjustments to combinational logic.

[0030] The system weights and merges the differences across the three dimensions according to preset weight ratios, ultimately obtaining a quantified content difference score. This score comprehensively represents the magnitude of change of a single candidate rule relative to the original rule. After calculating the content difference score for each candidate rule, the system compares it with a preset difference threshold. This threshold is a configurable parameter designed to filter out minor and non-substantial rule adjustment suggestions arising from normal business fluctuations, ensuring that only rules with significant changes trigger the update process.

[0031] When the content difference of a candidate rule exceeds a certain threshold, the rule is marked as a rule to be updated and enters the sorting and distribution queue. Rules entering the queue are not simply piled up, but are sorted in descending order based on their content difference. Rules with greater difference usually indicate a more urgent abnormal scenario or a more severe inadequacy of the original rule, and are therefore given a higher update priority. This difference-based sorting mechanism ensures that limited network and computing resources are prioritized for processing the most critical rule updates, thereby optimizing the efficiency and timeliness of the overall update process.

[0032] Step S4: Following the order in the sorted distribution queue, each high-priority replacement business rule is processed sequentially. For each rule to be distributed, the system serializes and encapsulates its rule content, unique rule identifier, new version number, and target edge node identifier according to a predefined instruction data format, generating a complete, machine-readable rule update instruction package.

[0033] This encapsulation process ensures the structural integrity and reliable parsing of the instruction during transmission. After the instruction is generated, the system determines one or more target edge nodes that need to receive the update based on the applicable business scope of the rules. Before distribution, the system queries the current status profile of these target edge nodes, including information such as their network connection quality, CPU load, and storage space.

[0034] Based on the status profile and the priority of rule update instructions, the system dynamically formulates a distribution strategy. For high-priority instructions and nodes in good condition, a real-time push channel is used to strive for instant delivery; for scenarios with moderate priority or high node load, batch transmission or timed synchronization channels may be selected to balance update timeliness and system stability.

[0035] After the command is issued, the cloud continuously monitors the distribution status and establishes a confirmation mechanism. If no successful response is received from the edge node within the timeout period, the cloud will initiate a retransmission mechanism until a confirmation is received or the maximum number of retries is reached. Once the edge node successfully receives and applies the new rule, it will send an update completion confirmation to the cloud. The cloud will then update the version status of the rule in the rule management center, marking the completion of the closed loop for this cloud-edge collaborative rule optimization for a specific business scenario.

[0036] This invention provides a cloud-edge collaborative streaming analytics method for business big data. It generates a global state view by real-time fusion of streaming data from multiple edge nodes and dynamically iterates to generate replacement rules based on anomaly features. This enables real-time and accurate updates of business rules, significantly improving the system's response speed and decision-making accuracy in dynamic business environments. By matching global analysis results with rule conditions and calculating the degree of difference, it ensures that rules are only triggered when there is substantial optimization, achieving on-demand allocation of cloud-edge collaborative resources and avoiding unnecessary communication and computational overhead. Through a priority queue-based rule distribution mechanism, it ensures priority updates of critical business logic, thereby maintaining the overall system processing performance and stability in complex and ever-changing business scenarios.

[0037] In one embodiment, streaming data packets from multiple edge nodes are received, and the business entity identifiers and feature vectors of the streaming data packets are extracted and fused to generate a global state view, including: Streaming data packets from edge nodes arrive at the cloud access layer via message middleware, and their transmission follows specific application layer protocols to ensure reliability. Each data packet consists of a header and a payload, and the encapsulation format uses a platform-defined binary structure or a general serialization protocol.

[0038] The parsing process begins with integrity verification of the data packets. A checksum is calculated and compared with the corresponding field in the packet header. Data packets that fail verification are discarded to ensure data quality in subsequent processing. Passing data packets proceed to the decryption stage, where a symmetric key algorithm negotiated with edge nodes is used to decrypt the payload, restoring the plaintext business data. After decryption, the data packets are structured and parsed according to predefined format specifications.

[0039] The packet header typically includes metadata fields such as packet sequence number, timestamp, source edge node identifier, and business entity identifier. The parser extracts these fields precisely by byte offset, with the business entity identifier being the core index and prioritized for extraction. This identifier is usually a globally unique string or encoding used to unambiguously refer to a business object instance in a distributed environment. The payload contains feature data preprocessed by the edge nodes, structured as a set of key-value pairs or a multi-dimensional vector.

[0040] The parsing process deserializes the payload into a standardized feature vector object based on pre-registered feature pattern descriptions. This object encapsulates multiple dimensions of numerical or categorical feature values. Ultimately, the parsing and separation operation outputs two distinct data objects: a business entity identifier representing the unique identity of the business, and a feature vector describing its instantaneous state.

[0041] In this stage, the business entity identifier acts as the natural key for data aggregation. The system maintains a global hash map table, which uses the hash value of the business entity identifier as the key and the corresponding business entity group object as the value. This hash map structure allows for lookup operations with near-constant time complexity, ensuring efficient merge performance even in high-throughput data stream environments.

[0042] A business entity group is a carefully designed dynamic data structure that typically contains a thread-safe, ordered collection container to store all feature vector instances of the same business entity at different points in time, possibly originating from different edge nodes. This container maintains these instances in strict chronological order of feature vector timestamps, naturally forming a time-ordered sequence of states. When each feature vector is stored, in addition to its own feature data, its timestamp information and the source edge node identifier are also recorded, forming a complete traceability information chain.

[0043] The timestamp recording precision reaches the millisecond level, ensuring accurate sorting even for data from different edge nodes. Edge node identifiers are recorded using globally unique node codes, which are bound to node identity credentials assigned during system deployment. When a new feature vector is extracted, the system calculates the hash value of its business entity identifier and looks it up in the global hash map table. The choice of hash function is carefully considered to minimize collisions while maintaining high computational efficiency.

[0044] If a corresponding business entity group already exists in the mapping table, the following operations are performed: acquire the write lock for the business entity group, insert this feature vector into the correct position in the ordered set container according to its timestamp order, update the container's size and other metadata information, and finally release the write lock. This process ensures data consistency in a multi-threaded concurrent environment. If a corresponding business entity group does not exist, create a new business entity group instance, initialize its internal ordered set container, add this feature vector as an initial member, and register the business entity group instance in the global hash mapping table.

[0045] Newly created business entity groups are also initialized with a set of metadata, including the original string identifying the business entity, creation time, last update time, etc. This merging process ensures that all state information related to the same business entity is aggregated in one place, regardless of which edge node this information originates from. Recording timestamps allows all feature vectors within the group to be arranged in chronological order, providing a foundation for subsequent time-series analysis; while recording edge node information preserves the spatial attributes of the data, helping to trace back to the specific data source node when state anomalies occur.

[0046] The formation of business entity groups integrates previously scattered and isolated point-like observation data into a continuous data sequence depicting the state evolution of business entities over a period of time, providing structured input for the generation of a global state view. Each business entity group actually constitutes an independent data management unit, preparing a complete and orderly data foundation for subsequent timestamp-sorting and situational simulation operations.

[0047] After the business entity group completes data merging, although the feature vectors within the group are stored in timestamp order, strict sorting verification is still required to ensure the absolute accuracy of the time sequence. The system uses an efficient merge sort algorithm to perform the final sorting of all feature vectors within the group. This algorithm is particularly suitable for processing already basically ordered linked list structures, and can complete the sorting in linear logarithmic time, accurately handling possible cases of identical timestamps or minor disorder.

[0048] The sorting process is based on the high-precision timestamp carried by each feature vector. The sorted sequence of feature vectors constitutes the complete state trajectory of the business entity in the time dimension. After the time-series sorting is completed, the system performs an association aggregation operation. This operation uses the business entity identifier as the aggregation anchor point, deeply binding the ordered sequence of feature vectors with the identifier. The association process is not simply adding metadata, but rather constructing a composite data structure called a global state view.

[0049] This structure uses business entity identifiers as its core key and comprises the following main components: a rigorously ordered sequence of feature vectors, a set of trend indicators statistically derived from the sequence, and a current state label generated based on business rules. The set of trend indicators is calculated by analyzing the changing patterns of feature values ​​in the sequence, such as calculating the slope, variance, or periodicity of numerical features within a specific time window. Situational deduction is a crucial step in generating a global state view.

[0050] The deduction process is based on a sorted sequence of historical states, using a predefined state transition model to predict or assess the current and potential operational states of business entities. The system traverses the ordered sequence of feature vectors, identifies key state inflection points, and combines domain knowledge to determine the causal relationships of state changes. For example, if a pattern of continuously rising memory usage and increasing log error frequency is detected in multiple consecutive feature vectors, a potential memory leak situation may be deduced.

[0051] The inference algorithm calculates the confidence level for each identified situational pattern and associates it with the corresponding feature vector interval. The resulting global state view is a dynamically updated data entity that not only records the instantaneous state of the business entity at various points in time, but more importantly, reveals the evolution logic and potential trends between states through correlation aggregation and situational inference, providing upper-level decision-making with a panoramic state perception that includes history, current status, and prediction.

[0052] This embodiment merges multi-source feature vectors using business entity identifiers as index keys to construct a state set centered on the business entity. This effectively solves the problem of fragmented state data for the same entity in a distributed environment, laying a data foundation for accurate panoramic state perception. By strictly sorting the feature vectors within each business entity group by timestamp and performing correlation aggregation and situational inference, it is possible to reconstruct a continuous and complete state evolution trajectory of the business entity from discrete time-series data, significantly improving the depth of understanding and accuracy of judgment regarding the operational state of complex systems. By generating a global state view that integrates historical data, current status, and trend predictions, it provides unprecedented data support for upper-level decision-making, enabling anomaly detection, root cause analysis, and strategy optimization to be based on comprehensive and dynamic state cognition, ultimately improving the intelligent operation and maintenance level and business continuity assurance capabilities of the entire system.

[0053] In one embodiment, the global state view is iterated and matched against the rule conditions in a pre-set first business rule set to identify abnormal state characteristics and trigger a rule update process. This involves retrieving historical state views and abnormal state characteristics from the historical database for business iteration, generating a candidate replacement rule set, including: The rules engine loads a pre-configured first set of business rules from persistent storage. This set exists in the form of executable code snippets or declarative expressions. The traversal process employs a depth-first strategy, processing each rule condition sequentially according to its priority. Each rule condition is essentially a logical assertion regarding the state characteristics of a business entity, and the feature fields referenced in its condition expression must completely correspond to the feature dimensions defined in the global state view.

[0054] Before the matching operation begins, the rule engine parses the business entity to be detected and its complete set of state features from the global state view. The matching process is essentially the evaluation process of the conditional expression. The rule engine substitutes the specific feature values ​​of the current business entity into the variable positions of the rule condition and performs step-by-step calculations according to the logical and comparison operators defined in the expression. For example, for the rule condition "CPU utilization is greater than the threshold and the number of memory errors continues to increase", the engine first obtains the CPU utilization value from the state features and compares it with the preset threshold, and then checks the trend of the number of memory errors in the most recent sampling points.

[0055] This process is performed independently for each business entity in the global state view, ensuring the comprehensiveness of rule evaluation. Matching calculations produce Boolean results: true indicates the state meets the rule's expectations, while false indicates an abnormal state. The entire traversal matching process is completed in memory, leveraging the rule engine's just-in-time compilation optimization technology to ensure evaluation efficiency and achieve rapid parallel verification of massive amounts of state data.

[0056] When the rule engine determines that the state of a business entity does not meet the rule conditions, it immediately triggers the anomaly extraction process. This extraction process does not simply record the entire state feature vector; instead, it performs root cause analysis, precisely locating the specific feature dimensions or combinations that cause the rule conditions to evaluate to false. The rule engine traces back the evaluation process of the conditional expression, identifying the key sub-conditions that make the final result false. The state features upon which these sub-conditions depend are marked as anomalous state features. The extraction of anomalous state features includes two parts: feature identifiers and feature values.

[0057] The feature identifier explicitly points to a specific monitoring metric or business dimension, while the feature value records the specific value or state of that metric at the time the anomaly occurred. Simultaneously, the anomaly context information is fully captured, including the rule identifier that triggered the anomaly, the timestamp of the anomaly occurrence, the associated business entity identifier, and the anomaly severity level. These elements together constitute a complete matching anomaly event record. This event record is encapsulated using a standardized data format, typically including an event header and an event body.

[0058] The event header contains metadata such as the event ID and generation time, while the event body stores specific anomaly characteristics, rule information, and business entity context. The encapsulated matching anomaly event is published to the internal event bus for consumption by subsequent processing modules that subscribe to the event. This event-driven architecture ensures decoupling between anomaly detection and subsequent processing, improving system scalability while guaranteeing real-time and reliable transmission of anomaly information. Each matching anomaly event becomes a crucial data point for system self-optimization and decision-making.

[0059] The anomaly grouping operation is based on feature similarity measurement. First, the captured multiple matching anomaly events need to be vectorized. The anomaly state features extracted from each anomaly event are converted into a standardized feature vector. The vector dimensions include multiple dimensions such as anomaly type encoding, numerical deviation, occurrence time context, and associated resource type.

[0060] Similarity calculation employs a multi-dimensional weighted cosine similarity algorithm. This algorithm simultaneously considers the direction and magnitude of feature vectors, accurately reflecting the essential similarity between anomalous events by assigning appropriate weights to different dimensions. The grouping process utilizes a density-based clustering algorithm, which automatically identifies groups of anomalous events with similar characteristics without requiring pre-specified group numbers. The algorithm first calculates the density distribution of each anomalous event in the feature space, groups density-connected anomalous events into the same group, and filters out isolated points in sparse regions.

[0061] Each resulting anomaly group represents a recurring failure mode or business anomaly scenario, known as an anomaly feature pattern. Each anomaly feature pattern is defined by the common characteristics of its member anomaly events, generating a feature profile for that pattern, including metadata such as core feature sets, typical numerical ranges, and temporal distribution patterns. The establishment of anomaly feature patterns allows for the systematic organization of scattered anomaly events, elevating point-like anomalies to common pattern knowledge, providing accurate query conditions and processing targets for subsequent rule optimization based on historical experience.

[0062] The retrieval process uses anomalous feature patterns as query conditions and performs multi-dimensional similarity matching in the historical database. The historical database uses a time-series data engine to store historical state views, each view containing a complete sequence of state features and related anomaly handling records. The retrieval conditions construct feature profiles based on anomalous feature patterns, generating a composite query condition that includes multiple sub-conditions such as feature dimension matching, numerical range filtering, and time window limitation.

[0063] The retrieval operation employs a two-stage query strategy. The first stage uses an index to quickly filter candidate historical state views, which have a potential correlation with the current anomalous feature pattern in terms of basic features. The second stage performs fine-grained matching on the candidate set, calculating the similarity score between the anomalous patterns contained in each historical state view and the current anomalous feature pattern.

[0064] Similarity calculation comprehensively considers multiple factors such as feature overlap, numerical deviation trends, and temporal evolution patterns, employing a weighted scoring mechanism to generate the final similarity estimate. The system sorts the search results based on the similarity scores, selecting the top few historical state views with the highest similarity as a valid reference set. Each retrieved historical state view carries a complete processing context, including the occurrence time, duration, scope of impact, and final handling measures and effectiveness evaluation of the historical anomaly. This historical experience provides valuable reference for handling current anomalies, enabling the system to make decisions based on historical data, rather than starting from scratch each time.

[0065] The extraction process analyzes the accompanying rule change logs for each relevant historical state view retrieved. These historical rule change records detail the adjustments made to business rules in response to similar anomalies, including modifications to rule conditions, parameter adjustments, changes to logical operators, and the resulting validation results.

[0066] The extraction process focuses on rule change instances that have ultimately proven effective, summarizing successful handling patterns for this type of anomaly. The rule adjustment process employs a strategy combining parameter optimization and logic restructuring. For parameter-based rules, a parameter optimization model is established based on parameter adjustment patterns from historical successful cases, automatically calculating the optimal parameter values ​​suitable for the current anomaly characteristics. For logically complex rules, the logical adjustment paths in historical rule changes are analyzed to identify the most effective combination of conditions and judgment logic for this type of anomaly.

[0067] The business iteration process incorporates a multi-dimensional evaluation mechanism to predict the effectiveness of each adjusted rule candidate. The evaluation dimensions include key indicators such as rule coverage, false positive rate, and execution efficiency. The iteration process generates multiple rule candidate versions, each representing a different optimization focus and trade-off.

[0068] The final set of candidate replacement rules is a preliminary set of rule optimization solutions. Each candidate rule comes with detailed generation rationale and expected effect analysis, including validation results based on historical data and a suitability score for the current anomaly. The formation of the candidate replacement rule set provides ample choice for subsequent rule update decisions, ensuring that the system can select the rule version most suitable for the current business environment from multiple optimization directions. The entire rule generation process embodies a knowledge-driven methodology, transforming valuable experience from historical data into executable business rule optimization solutions.

[0069] This embodiment achieves automated detection and accurate identification of abnormal business states by traversing and matching the global state view with pre-defined business rules, effectively improving the timeliness and accuracy of anomaly detection. Grouping and summarizing matched abnormal events based on the similarity of abnormal state characteristics allows for the extraction of common feature patterns from discrete anomalies, providing an effective means for systematically analyzing recurring business problems. By retrieving state views and related rule change records containing similar patterns from the historical database, the system can optimize rules based on historical successes, significantly improving the targeting and effectiveness of rule adjustments.

[0070] In one embodiment, historical rule change records associated with abnormal feature patterns are extracted based on the historical state view, and a set of candidate replacement rules is generated through rule adjustment and business iteration, including: For each relevant historical state view retrieved earlier, the traversal operation accesses its associated rule change log database. This log database records the complete context of each rule adjustment in a time-series structure. Each historical rule change record includes the specific content of the rule change, the time of the change, the reason for the change, the implementer of the change, and important data on the effects of the action.

[0071] The traversal process proceeds in reverse chronological order, prioritizing the most recent rule change instances, as they typically better reflect the characteristics of the current system environment. Extracting the effectiveness data is the core operation of this step. This effectiveness data is a set of quantitative indicators that objectively record the system's actual response after the rule change. The extracted data items include key performance indicators such as the reduction rate of corresponding abnormal events after the rule change, the trend of rule triggering frequency changes, the number of false alarms generated by rule execution, and changes in rule matching accuracy.

[0072] These data are calculated comprehensively from system monitoring logs and business indicator databases. The extraction process also considers the time window in which the rules take effect, eliminating interference from other factors to ensure that the extracted data truly originates from the current rule change. Each historical rule change record and its corresponding effect data are encapsulated into a complete analytical unit, providing a complete data sample with causal relationships for subsequent comparative analysis. This process transforms raw operation logs into structured analytical data, making historical experience measurable and comparable quantitative evidence.

[0073] The comparative analysis takes each historical rule change record extracted in the early stage as an object and performs a fine-grained comparison between the rule change content contained therein and the corresponding rule in the currently effective first business rule set. The comparison operation is carried out at the level of rule syntax tree, parsing the conditional expressions of the old and new rules into an abstract syntax tree, and using a tree structure comparison algorithm to compare the similarities and differences between the two node by node.

[0074] The discrepancies were precisely identified as specific operations such as the addition or removal of operands in the rule conditions, changes in comparison operators, alterations in logical connectors, and adjustments to threshold parameters. After identifying the discrepancies, each discrepancy was assigned a validity weight based on the treatment effect data. The weighting process was based on a comprehensive analysis of the treatment effect data after the rule changes, establishing a correlation assessment between the discrepancies and the effect improvement. Discrepancies significantly correlated with positive effects such as increased anomaly reduction rate and decreased false alarm rate were assigned higher validity weights; discrepancies unrelated to effect improvement or even showing a negative correlation were assigned lower weights.

[0075] The weight calculation employs a multi-factor weighted evaluation model, comprehensively considering factors such as the magnitude, duration, and stability of the improvement indicators. Each difference point ultimately receives a quantified weight value, which characterizes the effectiveness of this type of rule adjustment in historical experience, providing an important reference for subsequent rule optimization. Determining the difference points and their effectiveness weights allows the rule optimization process to focus on historically proven effective adjustment strategies, improving the targeting and success rate of rule iteration.

[0076] Based on the discrepancies and their validity weights obtained from the preliminary analysis, the system performs targeted rule condition extraction. The extraction process does not simply copy historical rule conditions, but rather adapts them to the specific characteristics of the current anomaly pattern. The system prioritizes historical rule conditions corresponding to discrepancies with high validity weights as base templates; these templates represent historically validated rule adjustment patterns. The parameter adjustment phase primarily optimizes quantifiable parameters in the rule conditions, such as numerical thresholds and time window sizes.

[0077] The algorithm adjustment process references parameter modification trajectories in historical rule change records and combines them with the numerical distribution characteristics of various indicators in the current anomaly feature pattern. New parameter values ​​suitable for the current scenario are calculated using methods such as interpolation or extrapolation. The logic optimization phase focuses on improving the structure of rule condition expressions. The system analyzes the combination of logical operators, the order of condition clauses, and the nesting level in historical rule conditions to identify logical structure changes that significantly improve detection performance. The optimization process may include simplifying redundant conditions, merging similar clauses, and adjusting judgment priorities.

[0078] For complex logical expressions, the system employs syntax tree reconstruction technology to optimize execution efficiency while maintaining semantic equivalence. The rule conditions, after parameter adjustment and logical optimization, are encapsulated as candidate rule information. This information includes not only the rule condition expression itself but also metadata such as the historical rule change record ID, the validity weight of the adjustment basis, and the expected scope of application. Each candidate rule represents a potential solution for the current abnormal feature pattern, and its generation process reflects knowledge reuse and adaptive innovation based on historical experience.

[0079] The verification process employs a historical backtesting method, applying the generated candidate rule information to the saved historical state view data for performance evaluation. The verification environment simulates actual rule execution scenarios, loading candidate rule information through the rule engine and comprehensively testing its performance on historical data.

[0080] The verification focuses on two aspects: first, testing the candidate rules' ability to identify target anomaly patterns, i.e., whether they can accurately capture historically known anomalies; and second, evaluating the false alarm rate of the rules, i.e., whether they will generate unnecessary alerts under normal business conditions. During the verification process, the system accurately records the matching results of each candidate rule on the historical state view, including the number of correctly identified anomalies, the number of missed anomalies, and the number of falsely reported normal events.

[0081] Based on this data, performance metrics such as precision, recall, and F1 score are calculated for the rules, generating a quantitative evaluation report. Only candidate rules that demonstrate good performance on historical data are validated. Specific criteria typically include a recognition rate of a pre-set threshold for target anomalous feature patterns, while keeping the false positive rate within an acceptable range. Validated candidate rule information is integrated into a candidate replacement rule set, which is organized according to rule type, applicable scenario, or performance score for easier subsequent screening and application.

[0082] The integration process also categorizes candidate rules with similar functions but different implementation methods, and marks the advantages and applicable conditions of each rule, providing a sufficient basis for rule update decisions. The final set of candidate replacement rules is a historically validated, high-quality rule optimization solution library, laying a solid foundation for the continuous improvement of the business rule system.

[0083] This embodiment, by traversing historical state views and extracting treatment effect data, enables quantitative evaluation of rule changes based on real historical effects, ensuring a sufficient and reliable basis for subsequent rule optimization. By finely comparing historical rule change records with the current rule set and marking the effectiveness weights of differences, it can accurately identify historically effective rule adjustment strategies, providing a clear direction for rule optimization. Based on the differences and effectiveness weights, the parameters and logic of historical rule conditions are optimized, achieving adaptive transformation of historical experience and generating more targeted candidate rules. Historical backtesting verifies the accuracy of candidate rule identification and the level of false alarm control, ensuring that the final generated set of candidate replacement rules has high practical value and reliability, effectively improving the quality of rule update decisions.

[0084] In one embodiment, the content difference between the candidate replacement rule set and the first business rule set is calculated. When the content difference exceeds a preset difference threshold, a replacement business rule is extracted from the candidate replacement rule set and inserted into a preset sorting and distribution queue, including: The comparison process unfolds on a rule-pair basis, establishing a mapping relationship between each new rule in the candidate replacement rule set and the corresponding original rule in the first business rule set. The comparison of conditional expressions is performed at the syntax tree level. First, the rule conditions are parsed into an abstract syntax tree structure, and then the minimum transformation cost between the two trees is calculated using a tree edit distance algorithm. This algorithm considers the costs of node insertion, deletion, and replacement operations, and the final normalized edit distance is used as the structural difference value.

[0085] The calculation of parameter value differences is handled separately for numerical and enumerated parameters in the rules. Numerical parameters are measured using relative rate of change, while enumerated parameters are calculated based on the similarity of their value sets. The evaluation of logical operator differences focuses on the impact of changes in operator type and adjustments to operator precedence.

[0086] Changes in operator type, such as from logical AND to logical OR, will result in a higher base difference score, while precedence adjustments quantify the difference by analyzing the degree of change in the order of expression evaluation. After calculating the difference values ​​across the three dimensions, a weighted fusion strategy is used for integration.

[0087] The weighting configuration reflects the degree of influence of each dimension on the semantic changes of the rule. Generally, structural changes in the conditional expression have the highest weight, followed by parameter values, while adjustments to logical operators have relatively lower weights. The comprehensive score generated by the weighted calculation is the content difference degree of the rule pair, which quantifies the overall magnitude of change between the old and new rules. The entire comparison process ensures that even complex rule conditions can be objectively and standardly evaluated for their degree of change.

[0088] The preset difference threshold is a dynamically configurable system parameter, set based on the rule change sensitivity level derived from historical data analysis. The threshold comparison operation iterates through each calculated content difference, using a numerical comparator to determine its magnitude.

[0089] When the content difference of a rule pair exceeds a preset threshold, it indicates that the rule change has reached a significant level that requires triggering an update process, and the system marks the rule pair as a mismatch rule. The marking operation not only records the mismatch status but also saves detailed mismatch information, including the rule identifier, the specific value of the content difference, the extent to which it exceeds the threshold, and an analysis of the main sources of the difference.

[0090] The statistical process is based on a time window, and the system maintains a counter for non-matching rules within a sliding time window. Whenever a new non-matching rule is added, the counter is incremented, and the timestamp information of that rule is recorded. The statistical scope is limited to the current processing cycle, typically a complete rule evaluation cycle, to ensure the timeliness and representativeness of the statistical results.

[0091] The statistical results include the total number of mismatched rules and their proportion in the total rule set. These two indicators together reflect the degree of deviation between the current business rule system and the actual situation. The total number of mismatched rules provides a collective basis for subsequent update decisions, avoiding frequent update triggers due to minor changes in individual rules. The entire comparison and statistical process establishes a rule change perception mechanism based on quantitative indicators, providing data support for system adaptive optimization.

[0092] The decision-making process is based on a comparison between the total number of mismatched rules obtained from preliminary statistics and a preset threshold. The preset threshold is determined by considering both the stability of the business environment and the cost of rule updates. Its purpose is to avoid frequent triggering of the update process due to minor changes in a small number of rules, ensuring the batching and consolidation of update operations. When the system detects that the total number of mismatched rules exceeds this threshold, it determines that the current rule system has deviated significantly and a batch update procedure needs to be initiated. The extraction operation is performed on each rule pair marked as mismatched.

[0093] Based on the rule identifiers stored in the mismatch rule record, the corresponding replacement business rule is precisely located in the candidate replacement rule set. The extraction process is not a simple copying of rule content, but includes a rule integrity verification mechanism. The verification includes basic requirements such as rule syntax correctness, parameter validity, and logical consistency.

[0094] For replacement business rules that pass verification, the system attaches update metadata, including management information such as source rule identifier, version number, and update priority flag. During the extraction process, dependencies between rules must also be considered. When multiple rules are logically related, it must be ensured that these related rules are extracted synchronously to maintain the internal consistency of the rule set. The final extracted replacement business rules constitute a subset of rules to be updated, representing the business rules that most urgently need updating. This batch extraction mechanism effectively balances the timeliness of rule updates with system overhead, ensuring that update operations are carried out in an orderly manner while maintaining controllable business impact.

[0095] The sorting operation is based on the content difference value corresponding to each replacement business rule, using a descending order algorithm to place the rule with the largest difference value at the front of the queue. This sorting strategy ensures that the rules with the largest changes and the most serious deviations receive the highest priority processing order, as they usually have the most significant impact on the business and urgently need to be improved.

[0096] The sorting algorithm needs to consider the scale of the number of rules and real-time requirements. Optimized quicksort or heapsort algorithms can be used to achieve efficient arrangement. Insertion operations are performed on the sorted sequence of replacement business rules. The distribution queue is a priority queue data structure with first-in, first-out characteristics, supporting the insertion and retrieval of rule update tasks according to priority order.

[0097] During the insertion process, the system assigns an appropriate queue position to each rule update task and records its insertion timestamp and expected processing time. The queue manager maintains the queue status in real time, including the current queue depth and task distribution across priority ranges. For newly inserted rule update tasks, the system checks if a task with the same rule identifier already exists in the queue. If so, it determines a replacement or deduplication strategy based on the version information to avoid duplicate updates.

[0098] The sequential insertion process ensures that tasks in the distribution queue always maintain the correct priority order, laying the foundation for the distribution and execution of subsequent update instructions. This content-differentiation-based priority scheduling mechanism allows limited system resources to be prioritized for the most critical rule updates, optimizing the efficiency and effectiveness of the overall update process.

[0099] This embodiment achieves a refined measurement of the degree of change between old and new rules by comparing rule condition expressions, parameter values, and logical operators one by one and calculating the content difference degree, providing an objective quantitative basis for update decisions. By setting a dual judgment mechanism of difference threshold and quantity threshold, it can effectively filter out important rules with substantial changes while avoiding over-responding to minor rule adjustments, ensuring the accuracy and stability of the rule update mechanism. The deployment queue is organized in descending order based on content difference degree, ensuring that rules with the largest changes and the most urgent needs are processed first, significantly improving the overall efficiency of the rule update process. Through a mechanism combining batch decision-making and priority scheduling, it ensures timely updates of key rules while achieving reasonable allocation of system resources and effective control of update costs.

[0100] In one embodiment, the conditional expressions, parameter values, and logical operators of the candidate replacement rule set and the first business rule set are compared one by one, the difference values ​​of each part are calculated, and the results are integrated to generate a content difference score, including: The parsing operation employs compiler-based syntax analysis techniques to transform textual conditional expressions into structured abstract syntax trees. Nodes in the abstract syntax tree represent operators, and leaf nodes represent operands; the tree structure fully preserves the computational precedence and compositional relationships of the expression.

[0101] The decomposition process is implemented through a depth-first traversal of the syntax tree, extracting the preorder sequence of operators and the inorder sequence of operands. The operand sequence contains entity objects such as feature fields and constant thresholds referenced in the rule conditions, while the operator sequence contains an ordered arrangement of comparison operators and logical connectors. Sequence difference calculation employs a dynamic programming algorithm to solve the longest common subsequence problem. A two-dimensional matrix is ​​constructed to record the matching state of the two sequences, and finally, the added, deleted, and modified sequence elements are identified based on the matrix backtracking path. The difference calculation of the operand sequence focuses on the degree of matching of element types and positions in the sequences, while the difference analysis of the operator sequence focuses on the consistency of operator types and their order.

[0102] The structural difference metric is calculated by comprehensively considering multiple dimensions, including sequence length differences, the proportion of common subsequences, and element position offsets. The final result, after normalization, is a value between zero and one. This value accurately reflects the similarity between two conditional expressions at the syntactic structure level; a lower value indicates a greater structural difference. The entire parsing and comparison process ensures that even if the wording of the expressions differs, as long as their underlying logical structures are similar, they can be correctly identified and assigned a lower structural difference value.

[0103] The parameter extraction operation filters out all leaf nodes containing specific values ​​from the parsed abstract syntax tree. These nodes typically contain quantifiable parameters such as threshold constants and time intervals. The extraction process needs to distinguish between numerical and non-numerical parameters. Numerical parameters include integers, floating-point numbers, and other mathematically comparable values, while non-numerical parameters include strings, enumeration values, and other symbolic data.

[0104] The difference calculation for numerical parameters uses a relative percentage change algorithm. This algorithm calculates the ratio of the absolute difference between the old and new parameter values ​​to the original parameter value, effectively eliminating the influence of the parameter's magnitude on the difference result. For range-type parameters, the percentage change of the upper and lower bounds is calculated separately and then averaged.

[0105] The difference assessment of non-numerical parameters is based on edit distance theory, calculating the minimum number of edit operations required to transform one string into another, while considering the semantic similarity of enumerated values. The integration of parameter difference measures employs a weighted averaging strategy, assigning different weight coefficients to parameters according to their importance in the rule conditions. Differences in important parameters have a greater impact on the final measure, while differences in less important parameters have a relatively smaller impact.

[0106] The resulting parameter difference metric is a standardized value between zero and one, comprehensively reflecting the overall degree of change in all parameters within the rule conditions. This fine-grained parameter difference analysis can accurately identify the specific direction and magnitude of rule adjustments, providing precise data support for subsequent rule update decisions.

[0107] The analysis process extracts all logical operator nodes from the abstract syntax tree, including basic logical operators such as AND, OR, and NOT at different levels. Operator type analysis focuses on examining the essential differences between corresponding positional operators; for example, changing from logical AND to logical OR is considered a major change, while precedence adjustments between operators of the same type are considered minor changes.

[0108] Logical relationship analysis is achieved by constructing an expression dependency graph, where nodes represent sub-conditional expressions and edges represent dependencies connecting logical operators. The dependency graph comparison algorithm can identify changes in the logical connection structure, such as merging and splitting conditional branches, and adding or removing nesting levels. The quantification of logical differences employs a multi-dimensional scoring mechanism. Each difference is assigned a base score and influence weight based on its potential impact on the semantics of the rule.

[0109] Fundamental changes to operator types receive higher weight, while precedence adjustments within the same operator receive lower weight. Changes in logical relationships are quantified by analyzing the degree of change in path connectivity in the dependency graph, considering the number and range of affected conditional branches.

[0110] The generated logical difference metric is a weighted composite value of all difference point scores. This calculation also considers the relative importance of different logical operators within the rule. For example, changes to operators at the core of the conditional judgment receive higher weight than changes at the periphery. The logical difference metric accurately reflects the essential differences in rule conditions at the logical judgment level, providing a crucial basis for assessing the significance of rule changes.

[0111] The weighted fusion process is based on a pre-defined weighting scheme, which reflects the proportion of contribution of differences in each dimension to the overall degree of rule change. Weight allocation is usually based on domain knowledge, with structural differences having the highest weight because they directly reflect the essential changes at the expression syntax layer; logical differences are next, and parameter differences have the lowest weight.

[0112] The fusion calculation employs a linear weighted model, summing the three difference metrics after multiplying them by their respective weights. The weight ratios were established through rigorous experimental verification and business analysis to ensure that the final content difference score accurately reflects the actual impact of the rule changes.

[0113] In specific scenarios, the system supports dynamically adjusting weight ratios, such as appropriately increasing the weight of parameter differences in parameter-sensitive businesses. The content difference degree generated by the weighted calculation is a standardized value between zero and one, with a larger value indicating a greater magnitude of rule change. This value serves as the core basis for rule update decisions, considering not only the explicit characteristics of the change but also incorporating the differences in business importance of changes across different dimensions through a weighting mechanism. The generated content difference degree provides a scientific and quantitative standard for prioritizing rule updates, ensuring that update resources are prioritized for the most critical rule optimization tasks with the greatest magnitude of change.

[0114] This embodiment decomposes conditional expressions into operand sequences and operator sequences for differential comparison, enabling precise identification of essential differences between rules at the syntactic structure level. This provides a fine-grained analytical basis for assessing the magnitude of rule changes. By calculating the relative changes of numerical parameters and the enumeration similarity of non-numerical parameters, a comprehensive quantification of the degree of rule parameter adjustment is achieved, avoiding evaluation biases that may arise from a single metric. By analyzing the changes in the types and relationships of logical operators, deep differences in rule conditions at the logical judgment level can be captured, ensuring accurate perception of semantic changes in rules. A weighted fusion of structural, parameter, and logical differences using preset weight ratios ensures that the final generated content difference score scientifically reflects the comprehensive impact of changes in each dimension, providing a reliable quantitative standard for determining rule update priorities.

[0115] In one embodiment, the sorted distribution queue encapsulates the replacement business rule into a rule update instruction and distributes it to the corresponding edge nodes to complete the rule update, including: The extraction operation retrieves complete information about the corresponding rule from the rule metadata database based on the rule update order determined in the sorted distribution queue. Rule identifiers employ a globally unique encoding mechanism to ensure that each rule can be unambiguously identified in a distributed environment.

[0116] Version numbers follow semantic versioning specifications, consisting of a major version number, a minor version number, and a revision number, clearly reflecting the nature and scope of rule changes. Updated content includes core elements such as specific modifications to rule condition expressions, parameter adjustments, and related conditions for effectiveness. The serialization and encapsulation process follows a predefined instruction data pattern. This pattern specifies the concrete field structure of the instruction header and payload. The header contains control information such as instruction type, timestamp, and source system identifier, while the payload carries the business data related to the rule update.

[0117] The serialization operation converts the extracted structured data, such as rule identifiers, version numbers, and update content, into a byte stream format. The conversion process uses the platform's standard serialization protocol to ensure data integrity and parsing consistency during transmission. The encapsulated rule update instruction is a self-contained data packet containing necessary metadata and complete rule update content, which can be directly parsed and executed by edge nodes. The instruction generation process also includes the calculation of a data integrity checksum for error detection during subsequent transmission.

[0118] The target edge node lookup operation is based on a rule-node mapping database, which records the range of edge nodes applicable to each business rule. The lookup process employs distributed indexing technology, quickly retrieving a list of all edge node identifiers that require the rule update based on the rule identifier. The maintenance of the mapping relationship considers factors such as business partitioning, data jurisdiction, and node capability matching to ensure that rule updates accurately cover the target business scenario. Status information queries are implemented through the status interface provided by the edge node management platform.

[0119] The query content includes real-time operational metrics such as node network connection quality, computing resource utilization, and remaining storage space. Network connection quality is comprehensively evaluated using parameters such as recent heartbeat interval, packet loss rate, and link latency. Computing resource utilization focuses on the current load of CPU and memory to avoid issuing large-scale updates during periods of high load. Storage space checks ensure that nodes have sufficient space to store new rule versions and related data. Status information collection employs lightweight telemetry technology to obtain accurate node operational status with minimal performance overhead.

[0120] All status data is timestamped and undergoes consistency checks to ensure the timeliness and accuracy of status assessments. The node status information obtained from the query provides a basis for subsequent decisions on developing differentiated distribution strategies, enabling dynamic adaptation of the update process to the actual operating status of the nodes.

[0121] Based on the sorted distribution queue, the rule identifier, version number, and update content of each replacement business rule are extracted sequentially, and serialized and encapsulated according to the preset instruction format to generate a rule update instruction; Find the target edge node that needs to be updated according to each replacement business rule, and query the current status information of the target edge node; Based on the current status information and the distribution urgency level of the sorted distribution queue, formulate an instruction distribution strategy; According to the distribution strategy, the rule update command is sent to the target edge node, and the command transmission status is monitored. If a transmission failure or a timeout is detected at the target node, a retransmission mechanism is initiated until the update is confirmed.

[0122] The distribution strategy is formulated by comprehensively considering the real-time status data of the target edge nodes and the inherent urgency of the update tasks. Node status information constitutes the basic constraints for strategy formulation, network connection quality determines the type of transmission channel that can be selected, computing load affects the node's ability to process update commands instantly, and storage space parameters constrain the size of data that can be received at one time.

[0123] The urgency level of the distribution is derived from a preset priority flag in the sorting and distribution queue. This flag is positively correlated with the difference in rule content; the greater the difference, the higher the urgency level. The strategy formulation process is essentially a multi-objective optimization solution. The core objectives include minimizing update propagation latency, maximizing update success rate, and avoiding impact on normal node operations. The strategy output is a set of specific distribution parameters, covering operable parameters such as transmission channel selection, single packet size, concurrent connections, and retry interval.

[0124] For high-urgency commands and scenarios with nodes in good condition, the strategy tends to select low-latency transmission channels and adopt a small data packet instantaneous transmission mode. For non-urgent updates or scenarios with high node load, the strategy automatically adapts to batch transmission or timed synchronization mode, achieving smooth updates through traffic shaping and rate control. The strategy also includes a conflict resolution mechanism; when multiple update commands target overlapping nodes, the transmission sequence is dynamically adjusted according to the urgency level and node status to avoid command flooding.

[0125] The transport layer establishes a reliable, encrypted connection and transmits serialized instruction data in fragments according to the packet size and concurrency determined by the strategy. Each data packet is appended with a sequence number and checksum to ensure the order and integrity of the transmission process. The monitoring system tracks the transmission status of each instruction in real time, recording key indicators such as transmission timestamp, number of retries, and node response time.

[0126] Fault detection employs a multi-condition triggering mechanism, including transport layer connection anomalies, application layer response timeouts, and checksum errors. When a timeout threshold is triggered or a clear error response is received, the system initiates a retransmission process according to the pre-defined retry mode. The retransmission mechanism uses an exponential backoff algorithm to dynamically adjust the retry interval to avoid network congestion.

[0127] Before each retransmission, the node status is rechecked. If a node is found to be unreachable, the task is temporarily suspended and the node is marked as abnormal. Update confirmation requires a complete verification process. After receiving the instruction, the edge node must complete operations such as rule parsing, syntax verification, and sandbox testing, and finally return a confirmation message containing the rule version number to the cloud.

[0128] Once the cloud receives confirmation, it updates the rule version mapping table and marks the update task as complete. If the maximum number of retries is reached and the task still fails, the system moves the task to the exception queue and triggers an alarm, allowing management to intervene.

[0129] This embodiment extracts rule update content sequentially from the sorted distribution queue and serializes and encapsulates it according to a preset instruction format, ensuring the standardization and parsability of rule update instructions and improving the reliability of instruction processing. By finding target edge nodes based on replacement business rules and querying their current status information, it achieves precise location and status awareness of the update target, providing a basis for formulating differentiated distribution strategies. Instruction distribution strategies are formulated based on node status information and distribution urgency levels, enabling the rule update process to adapt to network conditions and node load, effectively balancing update timeliness and system stability.

[0130] In one embodiment, an instruction distribution strategy is formulated based on the current status information and the distribution urgency level of the sorted distribution queue, including: Network connectivity quality level is determined through a comprehensive evaluation of recent heartbeat interval, packet round-trip time, packet loss rate, and bandwidth utilization, mapping each network metric to a unified quality level scale. Load rate is calculated based on core metrics such as CPU utilization, memory usage, and processing queue depth reported by edge nodes, using a normalization algorithm to transform heterogeneous resource metrics into comparable load coefficients. Available storage space parameters consider not only remaining storage capacity but also storage I / O performance metrics, forming a multi-faceted evaluation of storage capacity.

[0131] The state construction process employs feature fusion technology to integrate discrete state parameters into a structured node state profile. This profile uses a vectorized representation method, with each dimension corresponding to a class of state features and assigned a timeliness marker to reflect the freshness of the data. An anomaly detection mechanism is introduced during the profile construction process to automatically identify and filter noise data caused by momentary fluctuations, ensuring the stability of the state assessment.

[0132] The completed node status profile constitutes a complete digital model of the edge node's operational status. This model accurately represents the node's current processing capacity, communication conditions, and resource reserves, providing precise input for subsequent distribution decisions. The profile data is stored in a lightweight serialized format, supporting fast read, write, and transmission, meeting the low-latency requirements of real-time decision-making.

[0133] The urgency level of distribution is derived from the priority attribute of the rule update instruction. This attribute is pre-defined based on the difference in rule content and business impact assessment, forming a multi-level classification system from urgent to routine. The matching analysis first establishes a mapping relationship between node status profiles and distribution urgency levels. This relationship is derived from the correlation analysis of historical transmission success rate data and performance indicators.

[0134] For example, high-urgency commands typically require matching with nodes that have good network quality and moderate load. The matching algorithm employs multi-objective decision theory, simultaneously considering three optimization objectives: transmission timeliness, success probability, and the degree of impact on node services. The algorithm assigns weight coefficients to each objective, which can be dynamically adjusted according to the business scenario. The matching process traverses all combinations of commands to be distributed and target nodes, calculating a matching score for each combination.

[0135] The score calculation comprehensively considers the impact of node network quality on transmission latency, the impact of computational load on instruction processing capabilities, and the degree to which storage space guarantees data reception. Matching results are output as an instruction-node pairing list, with each pairing accompanied by specific transmission parameter suggestions, including recommended transmission protocols, data fragment sizes, and operational-level parameters such as the number of concurrent threads. This result accurately reflects the compatibility between each instruction and the target node, providing data support for channel selection.

[0136] The real-time push channel is suitable for command-node combinations with the highest matching scores and the most stringent transmission latency requirements. These combinations typically correspond to pairing high-urgency commands with nodes of high-quality network status. The channel employs a connection-oriented real-time transmission protocol to establish a persistent, bidirectional communication link, ensuring that command data can be sent immediately and responses can be received instantly.

[0137] During the channel identification process, it verifies whether the node currently has the processing capacity to maintain a real-time connection, avoiding overall performance degradation due to channel overload. Batch transmission channels are designed for scenarios with moderate urgency or limited target node resources. These combinations have a moderate matching score and specific constraints on node status. Batch channels employ a discrete transmission mode, packaging multiple rule update instructions into batch data packets and sending them centrally within the timeframe allowed by node resources.

[0138] When identifying channels, it's crucial to assess the compatibility between the batch packet size and the node's processing capacity to ensure that batch transmissions do not impact normal node operations. The timed synchronization channel handles non-urgent rule updates or pairing with intermittently connected nodes; this channel performs synchronization based on a preset time strategy. The channel identification process considers node online patterns and peak / off-peak periods, setting the synchronization time within the window that minimizes business impact. Each channel identification result includes complete transmission parameter configurations, forming an end-to-end transmission solution. The real-time push channel employs an immediate send mode, which is configured with key parameters such as minimum transmission latency requirements, maximum number of retries, and timeout thresholds. The immediate send mode establishes a service quality assurance mechanism, reserving transmission bandwidth for high-priority commands and setting up fast retransmission paths to cope with transient network fluctuations. The mode configuration also includes congestion control algorithm selection to ensure that the real-time push channel maintains basic service quality even during network congestion.

[0139] The batch transmission channel is configured with a batch transmission mode, focusing on optimizing batch size, concurrent thread count, and traffic shaping parameters. The batch size is dynamically adjusted based on the node's available storage space to prevent excessive data transmission in a single batch from causing storage overflow. The concurrent thread count is configured to match the node's computational load rate, reducing concurrency during high-load periods to alleviate node pressure. The traffic shaping mechanism smooths out bandwidth usage during batch transmissions, preventing sudden traffic surges from impacting network infrastructure.

[0140] The timed synchronization channel adopts a timed synchronization mode, which configures the core synchronization time point, synchronization interval, and incremental synchronization strategy. The synchronization time point is intelligently set based on the historical patterns of node business load, avoiding peak business periods. The synchronization interval is dynamically adjusted according to the rule update frequency, ensuring the timeliness of rule updates while reducing unnecessary synchronization overhead. The final instruction distribution strategy integrates the configuration parameters of the three transmission modes, forming a complete rule update distribution solution. This strategy can dynamically optimize transmission efficiency and reliability according to the actual operating environment.

[0141] This embodiment constructs a node status profile by extracting multi-dimensional status parameters such as network connection quality, computational load rate, and storage space. This allows for a comprehensive and accurate assessment of the real-time operating status of edge nodes, providing a reliable basis for distribution decisions. By performing transmission matching analysis between the distribution urgency level and the node status profile, optimal adaptation between update instructions and node resource conditions is achieved, effectively improving the targeting and success rate of instruction distribution. Based on the matching results, distribution channels are identified into three categories: real-time, batch, and timed synchronization channels. This ensures that rule updates with different urgency levels receive differentiated transmission service guarantees, optimizing system resource utilization efficiency. By configuring corresponding transmission modes for each channel and integrating them to form a complete distribution strategy, a hierarchical instruction distribution system is constructed. This ensures timely delivery of critical updates while balancing overall system stability and resource consumption.

[0142] Reference Figure 2 As shown, the present invention also provides a cloud-edge collaborative streaming analysis system for business big data, applicable to any of the above-mentioned cloud-edge collaborative streaming analysis methods for business big data, comprising: The acquisition module is used to receive streaming data packets from multiple edge nodes, extract the business entity identifiers and feature vectors of the streaming data packets, perform fusion calculations, and generate a global status view. The analysis module is used to traverse and match the global status view with the rule conditions in the preset first business rule set, identify abnormal status characteristics, trigger the rule update process, extract historical status views and abnormal status characteristics from the historical database for business iteration, and generate a set of candidate replacement rules. The association module is used to calculate the content difference between the candidate replacement rule set and the first business rule set. When the content difference exceeds the preset difference threshold, the replacement business rule is extracted from the candidate replacement rule set and inserted into the preset sorting and distribution queue. The processing module is used to encapsulate the replacement business rules into rule update instructions according to the sorted queue and distribute them to the corresponding edge nodes to complete the rule update.

[0143] This invention provides a cloud-edge collaborative streaming analytics system for business big data. It generates a global state view by real-time fusion of streaming data from multiple edge nodes and dynamically iterates to generate replacement rules based on anomaly features. This enables real-time and accurate updates of business rules, significantly improving the system's response speed and decision-making accuracy in dynamic business environments. By matching global analysis results with rule conditions and calculating the degree of difference, it ensures that rules are only triggered when there is substantial optimization, achieving on-demand allocation of cloud-edge collaborative resources and avoiding unnecessary communication and computational overhead. Through a priority queue-based rule distribution mechanism, it guarantees the priority updating of critical business logic, thereby maintaining the overall processing performance and stability of the system in complex and ever-changing business scenarios.

[0144] Reference Figure 3 As shown, the present invention also provides a cloud-edge collaborative streaming analysis device for business big data, comprising: Memory, used to store programs; A processor is used to execute programs to implement the various steps of a cloud-edge collaborative streaming analytics method for business big data, as described above.

[0145] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the system and each module described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0146] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A cloud-edge collaborative streaming analysis method for business big data, characterized in that, include: Receive streaming data packets from multiple edge nodes, extract the business entity identifier and feature vector of the streaming data packets, perform fusion calculation, and generate a global state view; The global state view is traversed and matched with the rule conditions in the preset first business rule set to identify abnormal state characteristics and trigger the rule update process. The historical state view is extracted from the historical database and the abnormal state characteristics are used for business iteration to generate a set of candidate replacement rules. Calculate the content difference between the candidate replacement rule set and the first business rule set. When the content difference exceeds a preset difference threshold, extract the replacement business rule from the candidate replacement rule set and insert it into a preset sorting and distribution queue. The replacement business rule is encapsulated into a rule update instruction according to the sorted distribution queue, and then distributed to the corresponding edge node to complete the rule update.

2. The cloud-edge collaborative streaming analysis method for business big data according to claim 1, characterized in that, The process of receiving streaming data packets from multiple edge nodes, extracting the service entity identifiers and feature vectors from the streaming data packets, fusing them together, and generating a global state view includes: Each of the streaming data packets is parsed and separated to obtain the business entity identifier and the feature vector; Using the business entity identifier as the index key, feature vectors from different edge nodes but with the same business entity identifier are merged into the same business entity group, and the timestamp and edge node information of each feature vector are recorded. Each business entity group is sorted by timestamp and associated with the business entity identifier for aggregation and situational analysis to generate the global state view.

3. The cloud-edge collaborative streaming analysis method for business big data according to claim 1, characterized in that, The process involves iterating and matching the global state view with the rule conditions in a preset first business rule set to identify abnormal state characteristics and trigger a rule update process. This includes retrieving historical state views from the historical database and iterating against the abnormal state characteristics to generate a candidate replacement rule set, including: Iterate through each rule condition in the first business rule set and match it item by item with the business entity state features in the global state view; When it is detected that the state feature of the business entity does not meet the rule conditions, the abnormal state feature that triggers the abnormality in the state feature of the business entity is extracted and recorded as a matching abnormal event. Based on the similarity of the abnormal state features in the matched abnormal events, the matched abnormal events are grouped into abnormal groups to obtain abnormal feature patterns; Based on the abnormal feature pattern, retrieve the historical state view containing similar patterns from the historical database; Based on the historical state view, historical rule change records associated with the abnormal feature pattern are extracted, and the candidate replacement rule set is generated through rule adjustment and business iteration.

4. The cloud-edge collaborative streaming analysis method for business big data according to claim 3, characterized in that, Based on the historical state view, historical rule change records associated with the abnormal feature pattern are extracted, and through rule adjustment and business iteration, the candidate replacement rule set is generated, including: Traverse the historical rule change records associated with the abnormal feature pattern in the historical state view, and extract the handling effect data from each historical rule change record; Each historical rule change record is compared and analyzed with the first business rule set to identify the corresponding differences, and the validity weight of the differences is marked according to the processing effect data. Based on the differences and the validity weights, the historical rule conditions in the historical rule change records are extracted, and the parameters of the historical rule conditions are adjusted and the logic is optimized to generate candidate rule information. Verify whether the candidate rule information generates false alarms in the historical state view and can correctly identify the abnormal feature pattern. Integrate the verified candidate rule information to obtain the candidate replacement rule set.

5. The cloud-edge collaborative streaming analysis method for business big data according to claim 1, characterized in that, The step of calculating the content difference between the candidate replacement rule set and the first business rule set, and extracting replacement business rules from the candidate replacement rule set and inserting them into a preset sorting and distribution queue when the content difference exceeds a preset difference threshold, includes: The conditional expressions, parameter values, and logical operators of the candidate replacement rule set and the first business rule set are compared one by one. The difference values ​​of each part are calculated and integrated to generate the content difference degree. Each content difference is compared with the preset difference threshold, and the rule conditions that exceed the preset difference threshold are marked as mismatch rules, and the total number of mismatch rules in the current period is counted. When the total number of mismatched rules exceeds a preset threshold, the corresponding replacement business rule is extracted from the candidate replacement rule set based on the mismatched rules. The replacement business rules are sorted in descending order according to their content differences and then inserted into the distribution queue in sequence.

6. The cloud-edge collaborative streaming analysis method for business big data according to claim 5, characterized in that, The step of comparing the conditional expressions, parameter values, and logical operators of the candidate replacement rule set with the first business rule set, calculating the difference value of each part, and integrating them to generate a content difference score includes: The conditional expressions of the corresponding rule pairs in the first business rule set and the candidate replacement rule set are parsed, each conditional expression is decomposed into an operand sequence and an operator sequence, and the difference between the two sequences is calculated to obtain a structural difference metric. Extract the parameter values ​​from the rule pair, calculate and integrate the relative change percentage of the numerical parameters and the enumeration similarity of the non-numerical parameters to obtain the parameter difference metric. Analyze the operator types and logical relationships of the logical operators in the rule pairs, and integrate them to generate logical difference metrics; The structural difference metric, the parameter difference metric, and the logical difference metric are weighted and fused according to a preset weight ratio to obtain the content difference degree.

7. The cloud-edge collaborative streaming analysis method for business big data according to claim 1, characterized in that, The step of encapsulating the replacement business rule into a rule update instruction according to the sorted distribution queue and distributing it to the corresponding edge node to complete the rule update includes: According to the sorted distribution queue, the rule identifier, version number and update content of each replacement business rule are extracted sequentially, and serialized and encapsulated according to the preset instruction format to generate the rule update instruction; According to each of the replacement business rules, find the target edge node that needs to be updated, and query the current status information of the target edge node; Based on the current status information and the distribution urgency level of the sorted distribution queue, an instruction distribution strategy is formulated; According to the distribution strategy, the rule update instruction is sent to the target edge node, and the instruction transmission status is monitored. If a transmission failure or target node response timeout is detected, a retransmission mechanism is initiated until the update is confirmed.

8. The cloud-edge collaborative streaming analysis method for business big data according to claim 7, characterized in that, The step of formulating an instruction distribution strategy based on the current status information and the distribution urgency level of the sorted distribution queue includes: The network connection quality level, computing load rate, and available storage space parameters of the current status information are extracted to construct the state profile of the node. The distribution emergency level is matched with the node status profile to obtain the instruction matching result; Based on the matching results, the distribution channels of each rule update instruction are identified as the corresponding real-time push channel, batch transmission channel, and timed synchronization channel; Each of the distribution channels is configured with a transmission mode, and the transmission modes are integrated to form the instruction distribution strategy, wherein the real-time push channel is in immediate send mode, the batch channel is in batch transmission mode, and the timed synchronization channel is in timed synchronization mode.

9. A cloud-edge collaborative streaming analytics system for business big data, characterized in that, The cloud-edge collaborative streaming analysis method for business big data, applied to any one of claims 1-8, includes: The acquisition module is used to receive streaming data packets from multiple edge nodes, extract the business entity identifier and feature vector of the streaming data packets, perform fusion calculation, and generate a global status view. The analysis module is used to traverse and match the global state view with the rule conditions in the preset first business rule set, identify abnormal state characteristics, and trigger the rule update process. It extracts the historical state view from the historical database and performs business iteration with the abnormal state characteristics to generate a set of candidate replacement rules. The association module is used to calculate the content difference between the candidate replacement rule set and the first business rule set. When the content difference exceeds a preset difference threshold, the replacement business rule is extracted from the candidate replacement rule set and inserted into a preset sorting and distribution queue. The processing module is used to encapsulate the replacement business rule into a rule update instruction according to the sorted distribution queue, and distribute it to the corresponding edge node to complete the rule update.

10. A cloud-edge collaborative streaming analytics device for business big data, characterized in that, include: Memory, used to store programs; A processor is used to execute the program to implement the various steps of the cloud-edge collaborative streaming analysis method for business big data as described in any one of claims 1-8.

Images