CN117972342A

CN117972342A - Rule analysis system, rule analysis method, and storage medium

Info

Publication number: CN117972342A
Application number: CN202410015138.2A
Authority: CN
Inventors: 吴仁华; 舒清舟; 厉佐瑞; 冯显越
Original assignee: Jialian Payment Co ltd
Current assignee: Jialian Payment Co ltd
Priority date: 2024-01-04
Filing date: 2024-01-04
Publication date: 2024-05-03

Abstract

The embodiment of the application provides a rule analysis system, a rule analysis method and a storage medium, wherein the rule analysis system comprises a data acquisition module, a rule generation module and a rule engine module; the data acquisition module is used for acquiring first event data and sending the first event data to the rule engine module through event stream data; the rule generation module is used for generating a first rule corresponding to first event data according to the object input information and sending the first rule to the rule engine module through rule flow data; the rule engine module is used for acquiring the first event data from the event stream data, acquiring the first rule from the rule stream data, triggering and identifying the first rule based on the first event data, and determining a corresponding triggering result according to the triggered first rule. Therefore, dynamic loading and execution of the rules are realized, and the instantaneity and flexibility of the rule analysis system are improved.

Description

Rule analysis system, rule analysis method, and storage medium

Technical Field

The present application relates to the field of rule analysis, and in particular, to a rule analysis system, a rule analysis method, and a storage medium.

Background

A rule system refers to a computer system based on a set of predefined rules or conditions. Rule systems are commonly used to automate tasks and decision processes by processing input data and generating corresponding outputs according to predefined rules. Rule systems are widely used in many different fields, such as for customer relationship management, to automate and optimize customer interactions and services according to predefined rules and conditions. For example, an e-commerce platform may use a rules system to automatically recommend related products based on a customer's purchase history and preferences.

In the related art, the conventional rule system is based on a predefined rule set, and it is difficult to respond to changes in market and user behavior instantaneously. Rule sets are static and require prior definition and deployment. When a rule needs to be modified or a new rule introduced, it may be necessary to out-of-service, re-develop, and re-deploy the system. Resulting in a lack of real-time and flexibility in the rule analysis system.

Disclosure of Invention

The embodiment of the application mainly aims to provide a rule analysis system, a rule analysis method and a storage medium, which can effectively improve the instantaneity and flexibility of the rule analysis system.

In order to achieve the above object, a first aspect of an embodiment of the present application provides a rule analysis system, where the rule analysis system includes a data acquisition module, a rule generation module, and a rule engine module;

The data acquisition module is used for acquiring first event data and sending the first event data to the rule engine module through event stream data;

The rule generation module is used for generating a first rule corresponding to the first event data according to the object input information and sending the first rule to the rule engine module through rule stream data;

the rule engine module is used for acquiring the first event data from the event stream data, acquiring the first rule from the rule stream data, triggering and identifying the first rule based on the first event data, and determining a corresponding triggering result according to the triggered first rule.

In some embodiments, the first event includes a user behavior event and a business operation event; the data acquisition module comprises a user event acquisition module and a service event acquisition module;

The user event acquisition module is used for acquiring user behavior event data and sending the user behavior event data to the rule engine module through the event stream data;

The business event acquisition module is used for acquiring business operation event data and sending the business operation event data to the rule engine module through the event stream data.

In some embodiments, the rule analysis system further comprises a data preprocessing module for preprocessing the first event data;

The preprocessing the first event data includes:

and adding a first event type tag to the first event data according to the source of the first event data.

In some embodiments, the rule engine module further comprises a data processing unit for data processing the first event data and the first rule; the data processing of the first event data and the first rule includes:

determining the first rule in the rule flow data according to the first event type label corresponding to the first event data;

The character strings of the first event data are inversely sequenced to obtain first event information;

Determining a first rule dimension based on the first rule and the first event information;

And packaging to obtain a first event dimension doublet based on the first event type tag, the first rule dimension and the first event information, wherein the first event dimension doublet comprises the first event type tag, the first rule dimension and the first event information.

In some embodiments, the rule engine module further includes a trigger identification unit for performing trigger identification with the first rule according to the first event dimension doublet; the triggering identification according to the first event dimension tuple and the first rule comprises the following steps:

Traversing a corresponding first rule list according to the first event dimension doublet, and determining a first executor corresponding to the first event dimension doublet;

Triggering the first executor to execute the first event and returning an execution result.

In some embodiments, the first actuator includes a first filter, a first calculator, and a first accumulator;

The first filter is used for filtering indexes of conditions corresponding to the first rule;

the first calculator is used for calculating a corresponding numerical value according to the first event;

the first accumulator is used for storing an intermediate value, when the first calculator needs to call a historical value, the historical value is called from the first accumulator for calculation, and the historical value after calculation update is restored in the first accumulator.

In some embodiments, the rule analysis system further comprises an event database;

The event database is used for storing first historical event data generated by the data acquisition module and transmitting the first historical event data to the rule generation module in response to a first historical event query request of the rule generation module.

In some embodiments, the rule analysis system further includes an object tag library, where the object tag library is configured to store the object tag information, so that the rule generating module generates the first rule according to a first object tag corresponding to the first rule;

the generating the first rule according to the first object tag corresponding to the first rule includes:

Determining a first object tag corresponding to the first rule in the object tag library;

and serializing the first object information corresponding to the first object tag and writing the first object information into the first rule.

To achieve the above object, a second aspect of the embodiments of the present application provides a rule analysis method of a rule analysis system, applied to the rule analysis system, the method including:

Acquiring first event data, and sending the first event data to a rule engine module through event stream data;

Generating a first rule corresponding to the first event data according to the object input information, and sending the first rule to the rule engine module through rule stream data;

And triggering and identifying the first rule based on the first event data, and determining a corresponding triggering result according to the triggered first rule.

To achieve the above object, a third aspect of the embodiments of the present application proposes a storage medium that is a computer-readable storage medium, the storage medium storing a computer program that when executed by a processor implements the rule analysis method of the rule analysis system according to the second aspect.

Drawings

FIG. 1 is a schematic diagram of a rule analysis system according to an embodiment of the present application;

FIG. 2 is a schematic flow chart of another embodiment of the present application;

FIG. 3 is a schematic diagram of the processing of rule flows and event flows provided by yet another embodiment of the present application;

FIG. 4 is a schematic flow chart provided by another embodiment of the present application;

FIG. 5 is a schematic diagram of calculating a circular event maximum by an accumulator according to yet another embodiment of the present application;

Fig. 6 is a schematic structural diagram of a rule analysis system according to another embodiment of the present application.

FIG. 7 is a schematic diagram of a multi-business rule in an event dimension according to another embodiment of the present application;

fig. 8 is a flowchart of a rule analysis method of the rule analysis system according to another embodiment of the present application.

Reference numerals illustrate:

The system comprises a rule analysis system 100, a data acquisition module 110, a user event acquisition module 111, a business event acquisition module 112, a rule generation module 120, a rule engine module 130, a data processing unit 131, a trigger identification unit 132, a data preprocessing module 140, an event database 150, a rule database 160 and an object tag library 170.

Detailed Description

The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the application only and is not intended to be limiting of the application.

In the related art, most of the existing rule systems are mainly non-dynamic, and mainly have the following problems:

Lack of real-time: the existing rule system is mainly static, and the predefined rules cannot respond to changes of market and user behaviors in time. This means that existing systems may not meet the requirements when rules need to be adjusted or updated based on real-time data. This lack of real-time limitation can affect the flexibility and response capability of the system.

Functional coupling: in existing rule systems, a rule engine and a specific rule code are coupled together. This means that when developing a new rule, it is necessary to influence the operation of the rule engine or to stop the service when issuing a new rule, thereby influencing the rule being operated. This functional coupling limits the flexibility and independence of rules and increases the complexity of system maintenance and updating.

Flexibility is limited: existing rule systems have limited flexibility in adjusting rules or introducing new rules. Typically, rules need to be re-developed and re-deployed, which consumes a significant amount of time and resources. Such limitations result in systems that cannot quickly respond to new business needs or adapt to changing market conditions.

Based on the above, the embodiment of the application provides a rule analysis system, a rule analysis method and a storage medium, which can effectively improve the instantaneity and flexibility of the rule analysis system. The rule analysis system comprises a data acquisition module, a rule generation module and a rule engine module; the data acquisition module is used for acquiring first event data and transmitting the first event data to the rule engine module through event stream data; the rule generation module is used for generating a first rule corresponding to the first event data according to the object input information and sending the first rule to the rule engine module through rule stream data; the rule engine module is used for acquiring first event data from the event stream data, acquiring first rules from the rule stream data, triggering and identifying the first rules based on the first event data, and determining corresponding triggering results according to the triggered first rules. The embodiment of the application supports JavaBean and rule of dynamic addition event and dynamic template of rule calculation logic. This allows maximum dynamics and flexibility. In addition, the logical computation of the rules employs parallel rolling delta computation to support low latency under high concurrency multiple rules. Therefore, the embodiment of the application provides a dynamic rule system with real-time performance, flexibility and high performance.

The embodiment of the application provides a rule analysis system and a rule analysis method of the rule analysis system, and specifically, the rule analysis system in the embodiment of the application is described first by describing the following embodiment.

In order to better describe the rule analysis system provided in the embodiment of the present application, referring to fig. 1, a schematic structural diagram of the rule analysis system is first provided. The rule analysis system 100 includes a data collection module 110, a rule generation module 120, and a rule engine module 130. The following is an explanation of the function of each module:

The function of the data collection module 110 is to obtain first event data and send the data to the rules engine module 130 via the event stream data. The data collection module is responsible for collecting first event data from various sources (e.g., sensors, log files, databases, etc.) and converting it into event stream data form for subsequent rule analysis processing.

The rule generation module 120 generates first rules corresponding to the first event data according to the object input information and transmits the rules to the rule engine module 130 through the rule stream data. The rule generation module 120 generates rules applicable to the first event data according to a predefined rule generation algorithm, input information, rule templates, and the like. These rules are sent to the rule engine module 130 in the form of rule flow data for subsequent trigger identification and processing.

In some embodiments, the development of rule logic is performed in the dynamic language Groovy, which is a Java-based dynamic programming language, has a syntax that is fully compatible with Java, and provides many additional functions and simplified syntax. Groovy supports dynamic compilation and loading, and rule logic may be dynamically loaded and executed at runtime. New rules may be loaded or existing rules modified as needed at runtime without the need to recompile and deploy the entire application. Meanwhile, the Groovy provides richer expression capability and simplified grammar, can clearly express business rules and conditions, comprises collection operation, closure iteration, regular expression processing and the like, and can help you write rule logic which is easier to read and maintain.

The rule engine module 130 obtains first event data from the event stream data and obtains first rules from the rule stream data. And then, triggering and identifying the first rule by using the first event data, determining the triggered rule, and obtaining a corresponding triggering result based on the triggered rule. The rule engine module 130 is the core of the rule analysis system 100 and is responsible for handling interactions of event data and rule data, performing rule matching and triggering operations, and producing corresponding results.

Such a system architecture allows for real-time acquisition of event data, generation of corresponding rules, and trigger recognition and result generation in the rules engine module 130. In this way, the first event data can be analyzed and processed in real-time to meet specific business needs.

In some embodiments, the first event includes a user behavior event and a business operation event.

The data collection module 110 is used in the system to collect the generated log and service data from the service system to the big data system in real time for analysis and archiving. The data collection module 110 is mainly responsible for handling the collection of various heterogeneous data, including user behavior events in the buried log collection system and business operation events in the business system data. These modules are used to collect different types of event data, including user behavior events and business operation events. Thus, the data collection module 110 includes a user event collection module 111 and a business event collection module 112, the following is an explanation of the functionality of these two modules:

User event collection module 111: the module is specifically responsible for gathering event data related to user behavior. It can monitor and capture various behaviors of the user in the system or application, such as clicking, browsing, entering, etc. Through the user event collection module 111, the system is able to collect and record user interactions with the system, providing basic data for subsequent rule analysis and processing.

The business event acquisition module 112: this module is responsible for collecting event data related to business operations. It can monitor and capture events in the system that relate to business processes and operations, such as order generation, payment operations, inventory changes, etc. Through the business event collection module 112, the system can track and record various links of business operations, providing the necessary information for subsequent rule analysis and business decisions.

The design of the data collection module 110 separates user behavior events from business operational events to better distinguish and process different types of event data. The data acquisition module 110 needs to process heterogeneous data with different sources, different formats and different structures, so as to ensure the integrity and the accuracy of the data. Such an architecture enables the system to perform customized rule analysis and real-time processing for user behavior and business operations to support more accurate business decisions and user experience optimization.

In some embodiments, the detection system 100 is further provided with a data preprocessing module 140 for preprocessing the first event.

Specifically, the process of preprocessing the first event includes adding a first event type tag for the event. For example, if the first event is a user behavior event, the preprocessing module may add a tag named "event_bean_id" to the event and set it to "UserBehaviorEvent".

Such a preprocessing step helps to identify and classify different types of first events. By adding a type tag to an event, different types of event data can be accurately distinguished and processed in subsequent processing. For example, events may be matched to corresponding processing logic or modules based on event type tags to perform particular analysis, rule matching, or other operations.

The purpose of the data preprocessing module 140 is to normalize and prepare the first event so that subsequent processing modules can better understand and process the event data. By adding type tags to events, more flexible data processing and maintenance extensibility can also be provided to accommodate changes and additions to different types of events.

In some embodiments, the jump may be invoked to perform embedded point log collection, and the collected user behavior data may be sent to the message system Kafka to form a user behavior data topic. Meanwhile, the data is collected from the service system database by using the Flink CDC (CHANGE DATA Capture) technology and is sent to the message system Kafka to form a service data theme. Thus, real-time event data collection can be realized.

In the messaging system Kafka, events in two topics are preprocessed. The main preprocessing step comprises adding event bean_id corresponding to different JavaBean to facilitate subsequent event matching and processing. In addition, processing operations such as desensitization, filtering of dirty data, etc. may be included to ensure the security and accuracy of the data.

It should be noted that "Java bean" refers to a Java class for encapsulating and processing events. In particular, there may be a plurality of different JavaBean classes for representing and processing different types of event data, depending on the event type. For example, for a user behavior event, a JavaBean class named "UserBehaviorEvent" may be defined for packaging and processing data related to the user behavior. For business operations events, a JavaBean class named "BusinessEvent" may be defined for packaging and processing data related to the business operations. Each JavaBean class will be defined and implemented according to the characteristics of the event type and the data structure. They typically include proprietary attributes, public getter (access) and setter (assignment) methods, as well as other necessary methods and logic to meet the packaging, access and processing requirements for event data.

By adding a bean_id to the event, each event can be assigned a corresponding type identification for subsequent rule matching and processing. Thus, for different event types, the corresponding JavaBean can be used for data analysis and processing. This way, the rule engine can be matched with the event type according to the event id, and the corresponding rule operation is executed.

In addition, the desensitization operation is beneficial to protecting the privacy and safety of sensitive data, and ensuring that the sensitive information cannot be revealed in the processing and transmission processes of the data. Dirty data is filtered to exclude invalid or erroneous data, so as to improve the quality and accuracy of the data.

In summary, the system can realize real-time acquisition of the buried point log and the service data by using the Flume and the Flink CDC, and perform data transmission and processing by using Kafka as a message system. Events in both topics are preprocessed in Kafka, including operations of adding event bean_id, desensitizing, and filtering dirty data for subsequent rule matching and processing. This allows for real-time event matching and rule execution.

In some embodiments, the rule engine module 130 further comprises a data processing unit 131, the data processing unit 131 being configured to perform data processing on the first event data and the first rule data.

Referring to fig. 2, the data processing unit 131 performs data processing on the first event data and the first rule data, and may include steps 210 to 240.

Step 210, determining a first rule in the rule stream data according to the first event type tag corresponding to the first event data.

In this step, a rule matching the first event data is found from the rule stream data according to the type tag of the first event data. A type tag of the first event data is first obtained, the tag being used to identify the type or class of the event. The rule stream data is then accessed, the rule stream data being a data structure containing a plurality of rules, each rule being associated with a particular event type. By traversing the rule stream data, it is checked one by one whether the event type tag of the rule matches the type tag of the first event data. A matching rule is found, i.e. the event type tag of the rule matches the type tag of the first event data, which is determined as the first rule.

By this step, the rule matching with the first event data can be accurately located in the rule stream data according to the type tag of the first event data. This provides a basis for subsequent data processing and rule matching.

In some embodiments, javaBean, groovyClassLoader, which may be written using GroovyClassLoader to dynamically load the configured Groovy code (in string form), is a class loader provided by Groovy for dynamically loading the Groovy code. The PARSECLASS method in Class GroovyClassLoader may be used to parse the Groovy code string into Class objects of the Java Class.

Thus, the Groovy code string can be dynamically loaded and converted into a Class object of Java Class using GroovyClassLoader. This Class object can be used to instantiate the JavaBean object, invoke its method, and access its properties, matching events and rules through Class object and type tags of event data.

Step 220, the character string of the first event data is deserialized to obtain the first event information.

Where de-serialization is the process of converting data from its serialized form back to the original object or data structure. Here, the first event data is in the form of a string, which needs to be restored to an operable object or data. The strings may be de-serialized into objects using an appropriate de-serialization mechanism or library, such as the ObjectMapper class or Gson library in Java. Through this step, the first event data represented by the string may be converted into an operable object or data structure for subsequent data processing and rule matching.

A first rule dimension is determined based on the first rule and the first event information, step 230.

Rule analysis and matching are performed based on the first rule and the first event information to determine a dimension of the first rule. This can provide accurate identification of rule dimensions for subsequent data processing and decision making.

In step 240, the first event dimension doublet is encapsulated based on the first event type tag, the first rule dimension, and the first event information, where the first event dimension doublet includes the first event type tag, the first rule dimension, and the first event information.

In this step, the information is packaged into a first event dimension doublet. The first event dimension tuple is a data structure for containing key information for the first event. The first event type tag, the first rule dimension, and the first event information may be combined using a suitable data structure (e.g., tuple, object, or map). Thereby ensuring that the format and type of the first event dimension doublet is suitable for subsequent processing and delivery. A first event dimension tuple is obtained that contains the first event type tag, the first rule dimension, and the first event information. The doublet may be input to a subsequent step, such as rule matching, screening, routing, or other related operations.

The first event type tag, the first rule dimension, and the first event information are packaged as a data object having an appropriate structure for use in a subsequent process flow. Thus, the integrity and consistency of the data can be maintained, and accurate data can be provided for subsequent rule matching and processing.

Where a dimension is an attribute or feature that describes and classifies data. It provides a way to observe and analyze data from different perspectives. In event processing, dimensions may be various attributes associated with an event, such as time, geographic location, user identity, product category, etc., and by associating data with dimensions, grouping, aggregation, screening, and analysis of data may be performed according to different dimensions. The dimensions may help in specific problem discovery patterns, trends, and associations, and support decision making and business analysis.

For example, for a transaction event, there may be a user dimension and a dimension of the payment card as two specific dimensions.

The user dimension is an attribute or feature of the user associated with the transaction event and may include information such as the user's ID, name, age, gender, geographic location, consumption habits, and the like. By associating transaction events with user dimensions, transaction behavior can be analyzed and understood from the perspective of the user.

The payment card dimension is an attribute or feature of the payment card associated with the transaction event and may include information on the type of payment card (credit card, debit card), card number, issuing bank, expiration date, and the like. By associating transaction events with payment card dimensions, transaction behavior can be analyzed and understood from the perspective of the payment card.

In step 240, the first event type tag, the first rule dimension (in this case, the user dimension or the payment card dimension), and the first event information may be combined to create a dimension doublet. The doublet may contain event type tags, dimension types (e.g., "user" or "payment card"), dimension values (e.g., user ID or payment card number), and other related event information.

By associating events with particular dimensions, transaction events may be better understood and analyzed in subsequent processing, and related decisions, classifications, or other operations may be made based on the different dimensions.

Referring to fig. 3, in some embodiments, rule stream data is transmitted into the rule engine module 130 by using a broadcast stream form of a link engine, and the event stream and the rule broadcast stream are connected using a connect operator of the link, sharing a broadcast state. A link Broadcast Stream (Broadcast Stream) refers to a special Stream type in link Stream processing that is used to Broadcast a set of data into all parallel tasks for task sharing and use. The broadcast stream may be processed according to regular insertion/update/deletion: when there are new rule insertions, rule updates or rule deletions, these rules need to be handled accordingly. For deleted rules, they may be disabled or removed from use to ensure that they no longer affect subsequent processing.

In some embodiments, if the broadcast stream has not arrived at the time of arrival of the event stream, the event stream may be buffered using a Flink's state operator (operator state), waiting for the broadcast stream to be processed before processing the event stream in order. The processing logic may be implemented by:

A state operator is created in the processing operators of the event stream for caching the event stream data. When the event stream arrives, it is checked whether the broadcast stream has arrived. If the broadcast stream does not arrive, the event stream data is cached in a state operator. When the broadcast stream arrives, processing logic of the broadcast stream is triggered. The associated rules or data may be updated as the broadcast stream is processed and the operator of the event stream processing notified. In the event stream processing operator, it is checked by a timing task or other means whether the broadcast stream has been processed. Once it is detected that the broadcast stream has been processed, the buffered event stream data may be retrieved from the state operator and processed in sequence. This ensures that the processing of the event stream is synchronized with the processing of the broadcast stream to avoid data inconsistencies or erroneous processing. By the above steps, it is ensured that the processing of the event stream is performed in synchronization with the processing of the broadcast stream. When the event stream arrives, if the broadcast stream does not arrive, the event stream data is buffered. Once the broadcast stream processing is completed, the event stream data is processed sequentially to maintain consistency and correctness of the data. This approach establishes a synchronization mechanism between the event stream and the broadcast stream, enabling the processing of both to be coordinated.

In some embodiments, the rule engine module 130 further includes a trigger identification unit 132, where the trigger identification unit 132 is configured to perform trigger identification according to the first event dimension doublet and the first rule.

Referring to fig. 4, the trigger recognition unit 132 performs trigger recognition according to the first event dimension doublet and the first rule, and may include steps 410 to 420.

Step 410, traversing the corresponding first rule list according to the first event dimension doublet, and determining a first actuator corresponding to the first event dimension doublet.

Step 420, triggering the first executor to execute the first event, and returning an execution result.

The trigger identifying unit 132 traverses the stored first rule list and matches the rule according to the first event dimension doublet. Typically, a list of rules is predefined, each rule being associated with a particular event dimension. Traversing a first rule list according to the value of the first event dimension binary group; for each rule, values of the event dimension doublet defined in the rule are extracted. The values of the first event dimension doublet are compared with the values of the event dimension doublets defined in the rules to determine if they match, and if a matching rule is found, the first actuator to which the rule corresponds is determined.

In some embodiments, rule executors (rule execution templates) written using GroovyClassLoader to dynamically load configured Groovy code (in string form) may be used to parse the Groovy code string into Class objects of the Java Class using the PARSECLASS method in the GroovyClassLoader Class. The Class object of the parsed Java Class is obtained and an instance of the Class can be created using a reflection mechanism. After the Groovy code string is dynamically loaded using GroovyClassLoader and converted to a Class object of the Java Class, an instance of the Class can be created by reflection, i.e., matched with the corresponding event data in the event stream. In this way, rule executor objects may be used to execute rule operations that are related to corresponding event data.

In some embodiments, the first actuator includes a first filter, a first calculator, and a first accumulator.

The first filter is used for filtering indexes of conditions corresponding to the first rule. The filter is a component in the rules engine that screens and filters the input data to select only data that meets certain conditions for subsequent processing. The filter may determine the input data according to the rule-defined condition logic and return a set of data that satisfies the condition. The main function of the filter is to screen according to the conditions defined by the rules, and the filter matches the input data according to the conditions defined by the rules. The condition may relate to a certain attribute, relationship, range, etc. of the data for determining whether the filtering condition is met.

For example, when a rule requires filtering out events that have a keyword "shampoo" greater than 3 times a user's current day search, a filter may be used for conditional screening. For a plurality of events in the event stream, when the search keyword in the configuration information corresponding to one event is checked to be 'shampoo', the event is transmitted into a calculator for one time to accumulate and count, and if not, the event information is filtered. Through this filter, events meeting the conditions, i.e. the user searching for events containing the keyword "shampoo" on the same day, can be filtered out. This screening result may be passed to a subsequent calculator or other component for further processing or analysis. The actual filter implementation may vary depending on the particular rules engine framework and business requirements.

The first calculator may perform numerical calculation, logical calculation, or other types of calculation operations on the input data according to requirements defined by the rules. It may perform various mathematical, logical, or string operations using an API or library of functions provided by the rules engine to generate the desired calculation results.

For example, assume that there is a rule that requires calculation of a discount for the amount of purchase of a user, and a discount rate is determined according to the kind and number of items purchased. The following calculation logic may be performed using the first calculator:

s1, acquiring information of the types and the quantity of purchased commodities.

S2, determining the applicable discount rate according to the conditions defined by the rules. For example, if the kind of electronic products of the commodity are purchased and the number exceeds 3, the discount rate is 10%; otherwise, the discount rate is 5%.

S3, calculating the discount amount according to the purchase amount and the discount rate.

S4, the first calculator can return the calculation result to the rule engine for subsequent rule execution or other operations.

Wherein the first accumulator may be used to hold some state or history data for use in subsequent calculations. When the first calculator needs to calculate using the history value, it may obtain the corresponding history value from the first accumulator, and update the calculated result back to the first accumulator for use in subsequent calculation or other operations.

For example, assume that there is a rule that requires counting the total amount purchased for each user and calculating the average amount purchased for each user. May be implemented using a first accumulator and a first calculator. For purchase record events for a plurality of users in an event stream, a historical purchase total for the user is obtained from a first accumulator. And accumulating the purchase amount corresponding to the current arrival purchase record event into the historical purchase total amount, updating the result and storing the result in a first accumulator, and calling the updated historical purchase total amount again in the subsequent calculation to calculate an accumulated value. In calculating the average purchase amount, the average purchase amount may be calculated using the historical value and the number of purchase events stored in the first accumulator.

Referring to fig. 5, fig. 5 is a schematic diagram showing that a maximum value of a circular event is calculated by an accumulator, the circular event is filtered by a filter first, an unconditional star event is removed, then an event with an event value of 2 is first passed through the calculator, and 2 is assigned to the accumulator, when an event with an event value of 3 is calculated, an intermediate result 2 is obtained from the accumulator at the back end of the state, a calculation logic judgment 3>2 is called, and then 3 is returned to the accumulator result, and the accumulator result in the back end of the state is updated to be 3.

In this way, the first accumulator can continually store and update the history value for use by the first calculator during execution of the rules engine and ensure accuracy and consistency of the calculation.

In some embodiments, the rule engine module 130 further includes an event database 150, the event database 150 for storing the first historical event data generated by the data collection module and for sending the first historical event data to the rule generation module 120 in response to the first historical event query request of the rule generation module 120.

In some embodiments, the accumulator is stored in the event database 150, recalled from the state backend of the event database 150 when needed, and when the first calculator needs to recall the history value, it can obtain the corresponding history value from it by interacting with the state backend of the event database 150. This may be accomplished by querying a database for a particular field or record. The first calculator may use the acquired historical values to perform calculations and update the calculated results back into the event database 150 for the next use.

Using the event database 150 as the storage back-end for the accumulator may have the following benefits: the data is persisted in the event database 150, which retains the data even after the rules engine is restarted or the system fails. And the event database 150 is typically designed to support efficient read and write operations, providing fast data access capabilities. By storing the accumulator value in event database 150, data consistency between multiple rule engine instances or components may be ensured because they may share the same state backend.

In summary, the first filter is configured to filter data that satisfies the rule condition, the first calculator is configured to perform a calculation operation on the data according to the rule definition, and the first accumulator is configured to accumulate the statistical result during the rule execution. These components work cooperatively to enable the rules engine to perform corresponding screening, calculation, and statistical operations based on specific rule definitions and input data.

In some embodiments, the first rule includes a simple rule calculation, wherein the simple rule calculation directly reads the event message to make the rule determination. For example, it is determined whether the current behavioral event is a search shampoo and it is checked whether the event type is a search. The rule calculation may be performed as follows:

S1, reading an event message: the rules engine reads the event message, which contains data describing the user's behavior.

S2, extracting field values: the required field values are extracted from the event message, for example the values of the action event field and the event type field.

S3, judging simple rules: and (5) performing simple rule judgment on the extracted field value. In this example, it may be determined whether the current behavioral event is a search shampoo and checked whether the event type is a search.

S4, if the action event field value is "search shampoo" and the operation type field value is "search", the rule is judged to be true, and the rule condition is met. If the above condition is not satisfied, the rule is judged to be false, which indicates that the rule condition is not satisfied.

The simple rule calculation method is suitable for rule judgment scenes which only need to simply compare or calculate fields in the event message. By directly reading the field value of the event message, whether the event accords with the rule condition can be rapidly judged.

In some embodiments, the rule analysis system 100 further includes an object tag library 170, where the object tag library 170 is configured to store object tag information to enable the rule generation module 120 to generate the first rule according to a first object tag corresponding to the first rule.

The rule analysis system determines an object tag corresponding to the first rule by querying an object tag library. An object tag is information used to identify and describe a particular object and may include attributes, categories, identifiers, etc. of the object. And the system finds the corresponding object label in the object label library according to the definition of the first rule or the related information. Once the first object tag corresponding to the first rule is determined, the system performs serialization processing on the object information corresponding to the object tag. Serialization is the process of converting object information into a format that can be stored or transmitted. The system writes the serialized first object information into the first rule for use by the rule engine module in a subsequent rule analysis process. By associating a first rule with its corresponding first object tag and writing the serialized object information into the first rule, the rule analysis system is able to take into account specific properties and information of the object during the rule generation process. Therefore, the rule generating module can dynamically generate rules applicable to different objects according to the object labels, and the flexibility and applicability of the rules are improved.

In some embodiments, the components involved in the object tag library 170 include a data search Engine (ES) and an efficient compressed bitmap (RoaringBitmap). A data search Engine (ES) is a search engine system for storing massive amounts of data. RoaringBitmap is a small-memory lightweight data storage container for storing small amounts of data, and has efficient concurrency performance. Offline calculations are performed daily using Spark, and the object tag library 170 is updated, i.e., the data is processed and calculated according to predefined rules and conditions to update the tag information. At the same time, the rule generation module 120 is notified of the update of the data representation. The rule generation module 120, upon receiving notification of the portrait data update, reloads RoaringBitmap the crowd and updates the rule. The CDC (CHANGE DATA Capture) listening system is used to monitor changes in data and dynamically update rules as RoaringBitmap changes. And when the rule is issued, searching the ES to screen out the crowd meeting the condition. The ID information in the search result is stored in RoaringBitmap, and then RoaringBitmap in which the ID information is stored is serialized into a string format and stored in MySQL together with rules, and updated in real time. The rules are associated with the events by event IDs to form a list of people for determining which people the rules apply to. The scheme realizes high-performance concurrent processing and real-time updating of event data by comprehensively applying technologies and components such as a data search engine, roaringBitmap, an offline computing task, a rule generation module 120, CDC and the like. The method can rapidly screen out the crowd meeting the conditions from the mass data, and update the rules in real time according to the change of the portrait data, so as to better serve application scenes such as personalized recommendation, coupon distribution, advertisement orientation and the like.

In some embodiments, the first rule further includes portrait type rule calculation, first obtaining RoaringBitmap user groups in the rule. RoaringBitmap of the rules that include the specific crowd are queried by the rule generation module 120 in the object tag library 170 and written into the first rule when the rule is generated. RoaringBitmap are stored in the form of strings, which need to be deserialized and converted into RoaringBitmap objects in memory. In the rule calculation process, it is determined whether the current user exists in RoaringBitmap by calling the container (user) method of RoaringBitmap objects. Taking the example of a population with special tags (e.g., advanced VIP users), it may be determined whether the user satisfies the condition by determining whether the user's ID is in the corresponding RoaringBitmap. Through the query and judgment of RoaringBitmap, the specific crowd meeting the rule definition can be efficiently screened out. If the user ID exists in RoaringBitmap corresponding to the rule, that is, the user satisfies the rule condition, a corresponding operation or process may be performed.

Referring to fig. 6, in some embodiments, the first rule further includes an accumulated rule calculation, and fig. 6 is a schematic flow chart of the accumulated rule calculation, in the accumulated rule calculation, firstly determining an actuator corresponding to an accumulated event dimension, and screening required event information through a filter; next, check the state backend for the accumulator associated with the current event dimension, if there is an accumulator in the state backend, use the calculator to calculate the accumulator, accumulate or otherwise operate according to rules. If the accumulator does not exist in the state back end, a new accumulator is created through the calculator, and the initial value of the accumulator is initialized according to the rule; the calculator calculates the accumulator according to the rule, then stores the calculation result in the accumulator at the back end of the state, and updates the value of the accumulator, and in the subsequent calculation process, when the calculator needs to calculate again, the calculator can acquire the latest accumulator value from the back end of the state; this ensures continuity and accuracy of the calculation.

Through the flow, the recent data can be calculated in real time, whether the rule is met or not is judged according to the configured conditions and the threshold value, and meanwhile, the calculation result is saved to the state rear end for subsequent use. The accumulated rule calculation is suitable for the scene requiring continuous statistics and accumulation, and can conveniently carry out data analysis and decision.

In some embodiments, the first rule further includes a batch-type rule calculation that can calculate historical data results meeting the condition by performing corresponding query and aggregation operations in the event database 150; the accumulator is updated according to the historical data result obtained by calculation and is used for storing and tracking the accumulated value, and the result of off-line calculation every day is added into the accumulator, so that the accumulated value is continuously updated; in the rule judging stage, directly inquiring the result stored in the accumulator, taking the example that the number of days that the user uses the app in the last half month is more than 10 days, and judging whether the user accords with the condition or not by inquiring the corresponding statistical value in the accumulator; if the statistics in the accumulator satisfy the condition that the number of days the user uses the app for the last half month is greater than 10 days, the rule is judged to be satisfied. Such batch-type rule calculations are applicable to scenarios where statistics and analysis of historical data over a period of time is required.

In some embodiments, the first rule further includes a behavior-sequential rule calculation, which, like the cumulative rule calculation, also requires rule initialization and updating of the accumulator. For behavior sequence rules involving timing functions, the timer may be registered using TIMERSERVICE of Flink. After a specific action occurs, a timer is registered through TIMERSERVICE and a trigger time is set. The program waits for a timer to trigger to make the relevant calculations and decisions at a particular point in time. When the timer is triggered, the calculation logic associated with the rule is executed. Taking the example that the user searches for the keyword containing "shampoo", clicks on the details, then adds to the shopping cart, and does not pay for 10 minutes, when the user performs this series of actions, a timer triggered after 10 minutes is registered. After the timer is triggered, the calculation program checks whether the user has paid within 10 minutes after registering the timer, and if not, the rule condition is satisfied. The calculation of the behavior sequence type rule can calculate and judge a specific behavior sequence by registering a timer and waiting for triggering. The rule calculation mode is suitable for scenes needing to consider the behavior sequence and the time interval, and can capture specific modes and rules in the user behavior sequence.

Referring to FIG. 7, in some embodiments, there may be multiple business rules for each event dimension to be computed, which are computed serially, i.e., the next rule is computed after the previous rule is computed. While the computation between the different dimensions is performed in parallel. An executor is a template responsible for executing all sub-rule calculations under one business rule. The specific work of the executor is to calculate according to the configured rule and to carry out logic operation to judge whether the final result meets the condition. The executor is also responsible for saving the latest accumulator state. When no existing abstract rule exists in the business rules, a technical developer can form a new executor according to the configuration of the event and the dimension. This means that the actuator templates are dynamically configurable and generated according to business needs.

In some embodiments, the rule analysis system 100 further includes a rule database 160 for storing the first rule generated by the rule generation module 120. Rule database 160 may be a persistent storage system, such as a relational database or a distributed storage system, for long-term storage of rules. The rule database 160 sends the stored first rule to the rule engine module 130 by way of rule stream data. When data in the rules database 160 changes, the CDC listener will capture the corresponding update event and notify the rules engine module 130.

In addition, the embodiment of the application also provides a rule analysis method of the rule analysis system, which is applied to the rule analysis system 100.

Referring to fig. 8, a flowchart of a rule analysis method of the rule analysis system according to an embodiment of the present application includes steps 810 to 830:

Step 810, obtain the first event data and send the first event data to the rules engine module 130 via the event stream data.

Step 820 generates a first rule corresponding to the first event data from the object input information and sends the first rule to the rule engine module 130 via the rule flow data.

In step 830, trigger recognition is performed on the first rule based on the first event data, and a corresponding trigger result is determined according to the triggered first rule.

The flow chart of the rule analysis method describes a rule analysis process in a rule analysis system. By acquiring the first event data, generating the corresponding first rule and triggering and identifying the rule based on the first event data, the system can analyze and process the business rule in real time. The method can help the system to dynamically match and trigger the rules according to the actual data and the rules so as to realize real-time rule analysis and processing.

The content in the embodiment of the rule analysis system is applicable to the rule analysis method of the rule analysis system of the embodiment, the function specifically realized by the application method is the same as that of the embodiment of the rule analysis system, and the achieved beneficial effects are the same as those of the embodiment of the rule analysis system.

The embodiment of the application also provides a storage medium, which is a computer readable storage medium, and the storage medium stores a computer program, and the computer program realizes the rule analysis method of the rule analysis system when being executed by a processor.

The memory, as a non-transitory computer readable storage medium, may be used to store non-transitory software programs as well as non-transitory computer executable programs. In addition, the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory optionally includes memory remotely located relative to the processor, the remote memory being connectable to the processor through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The embodiments described in the embodiments of the present application are for more clearly describing the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application, and those skilled in the art can know that, with the evolution of technology and the appearance of new application scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.

It will be appreciated by persons skilled in the art that the embodiments of the application are not limited by the illustrations, and that more or fewer steps than those shown may be included, or certain steps may be combined, or different steps may be included.

The above described apparatus embodiments are merely illustrative, wherein the units illustrated as separate components may or may not be physically separate, i.e. may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

Those of ordinary skill in the art will appreciate that all or some of the steps, circuits, functional modules/units in the apparatus, and methods disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof.

The terms "first," "second," "third," "fourth," and the like in the description of the application and in the above figures, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the application described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, circuit, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed or inherent to such process, method, article, or apparatus.

It should be noted that, the structure of the rule analysis system described in the embodiment of the present application is to more clearly describe the technical solution of the embodiment of the present application, and does not constitute a limitation on the technical solution provided in the embodiment of the present application, and those skilled in the art can know that, with the evolution of the device architecture and the appearance of the new application scenario, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems.

It will be appreciated by those skilled in the art that the rule analysis system shown in the figures is not limiting of embodiments of the application and may include more or fewer components than shown, or certain components in combination, or a different arrangement of components. The foregoing description of the preferred embodiments of the present application is provided by way of illustration only and not as a definition of the limits of the claims. Any modifications, equivalent substitutions and improvements made by those skilled in the art without departing from the scope and spirit of the embodiments of the present application shall fall within the scope of the claims of the embodiments of the present application.

Claims

1. The rule analysis system is characterized by comprising a data acquisition module, a rule generation module and a rule engine module;

2. The rule analysis system of claim 1 wherein the first event comprises a user behavior event and a business operation event; the data acquisition module comprises a user event acquisition module and a service event acquisition module;

3. The rule analysis system of claim 2 further comprising a data preprocessing module for preprocessing the first event data;

The preprocessing the first event data includes:

4. A rule analysis system according to claim 3, wherein the rule engine module further comprises a data processing unit for data processing the first event data and the first rule; the data processing of the first event data and the first rule includes:

5. The rule analysis system of claim 4 wherein the rule engine module further comprises a trigger identification unit for trigger identification with the first rule based on the first event dimension doublet; the triggering identification according to the first event dimension tuple and the first rule comprises the following steps:

6. The rule analysis system of claim 5, wherein the first executor comprises a first filter, a first calculator, and a first accumulator;

7. The rule analysis system of claim 1, wherein the rule analysis system further comprises an event database;

8. The rule analysis system of claim 1 further comprising an object tag library for storing the object tag information to cause the rule generation module to generate the first rule based on a first object tag corresponding to the first rule;

9. A rule analysis method of a rule analysis system, wherein the method is applied to a rule analysis system according to any one of claims 1 to 8, the method comprising:

10. A computer readable storage medium having stored thereon a computer program, which when executed by a processor implements the rule analysis method of the rule analysis system of claim 9.