Data processing method and device, medium and program product
By generating a rule configuration table and utilizing the inversion operator and field type mapping, combined with columnar storage and caching technology, the inefficiency and performance issues of traditional configuration management solutions are solved, achieving second-level rule changes and high-performance matching, thereby improving the system's response speed and memory utilization efficiency.
Patent Information
- Application Number
- CN202510882144.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-27
- Publication Date
- 2025-11-07
AI Technical Summary
Traditional configuration management solutions suffer from problems such as inefficient rule iteration, degraded performance of multi-condition matching, rigid weight models, and insufficient storage and query optimization in e-commerce marketing and industrial equipment control. This results in long rule change effective times, slow response, and high memory consumption.
By parsing the input conditions, a rule configuration table is generated, and the final SQL template is generated using the inversion operator, field type mapping, and weights. Combined with columnar storage, memory preloading, and parameter normalization caching technology, zero-code rule configuration and high-performance matching are achieved.
The time for rule changes to take effect has been reduced from hours to seconds, significantly reducing response time and memory usage. It also supports automatic arbitration of multiple rule conflicts, improving system maintainability and scalability, and meeting the high-performance requirements of e-commerce flash sales and industrial real-time control.
Smart Images

Figure CN120910094A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of data processing, in particular to a data processing method, device, medium and program product. BACKGROUND
[0002] In the scenarios of e-commerce marketing, industrial equipment regulation and control, and the like, which require real-time multi-dimensional condition combination matching, the traditional configuration management scheme has the pain points of low efficiency of rule iteration (requiring technical intervention and an online cycle of more than 2 hours), poor performance of multi-condition matching (1000 rules with an average response of 420 ms), rigid weight model (adjustment requiring reconstruction of structure with a time consumption of more than 48 hours), and insufficient storage query optimization (100 million rules with a memory occupation of 21 GB).
[0003] Therefore, there is an urgent need for a method capable of facilitating rule configuration and reducing rule change effective time. SUMMARY
[0004] To this end, the present application provides a data processing method, system, electronic device and computer program product to at least partially solve the above technical problems.
[0005] The present application provides a data processing method, comprising the following method steps: In response to receiving an input condition, parsing the input condition to obtain a key-value pair, an operator and a weight; Based on a preset conversion logic, converting and mapping the key-value pair and the operator, including, inverting the operator to obtain an inverted operator, mapping a field type, and generating a query condition; Generating a rule configuration table, the rule configuration table comprising the mapping field type field, the weight field and the rule ID field; Based on the inverted operator, the field type, the query condition and the weight, generating a final SQL template.
[0006] Another aspect of the present application also provides a data processing device, comprising: A parsing module configured to, in response to receiving an input condition, parse the input condition to obtain a key-value pair, an operator and a weight; A conversion and mapping module configured to, based on a preset conversion logic, convert and map the key-value pair and the operator, including, inverting the operator to obtain an inverted operator, mapping a field type, and generating a query condition; A first generation module configured to generate a rule configuration table, the rule configuration table comprising the mapping field type field, the weight field and the rule ID field; A second generation module configured to, based on the inverted operator, the field type, the query condition and the weight, generate a final SQL template.
[0007] Another aspect of the present application also provides an electronic device, comprising: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the data processing method as described above.
[0008] Another aspect of the present application provides a computer-readable storage medium having stored thereon computer program instructions executable by a processor to implement the data processing method as described above.
[0009] Another aspect of the present application provides a computer program product comprising a computer program, which, when executed by a processor, implements the data processing method as described above.
[0010] The scheme provided by the embodiments of the present application realizes rule zero-code configuration through a visual interface, business personnel can independently manage rules, the rule change effective time is compressed from the hour level to the second level, and the business logic is decoupled from the code; the operator is reversed to generate an indexable SQL, combined with columnar storage, memory preloading and parameter normalization caching technology, the matching response time is greatly reduced and the memory occupation is greatly reduced under the condition of ten thousand rules, which meets the strict requirements of e-commerce, industrial real-time regulation and other high performance requirements; atomic weight arbitration is supported, and when multiple rules conflict, the highest priority rule is matched in descending order of weight, and machine learning can also be combined to dynamically adjust the weight based on data, reduce the dependence on artificial experience, and improve the strategy optimization efficiency; numerical, enumerated and logical combination conditions are supported, the rule update is guaranteed without service interruption through the caching mechanism, the technical architecture is decoupled in layers, and the maintainability and scalability are significantly improved. BRIEF DESCRIPTION OF DRAWINGS
[0011] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can also be obtained without creative labor on the basis of these drawings.
[0012] Other features, objects and advantages of the present application will become more apparent from the following detailed description of the non-limiting embodiments, with reference to the following drawings: Figure 1 A data processing method provided by an embodiment of the present application.
[0013] Figure 2 is a structural schematic diagram of a data processing device provided by an embodiment of the present application.
[0014] Figure 3 Figure 1 is a schematic diagram of a device according to an embodiment of the application. DETAILED DESCRIPTION
[0015] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of the present application.
[0016] In a typical configuration of the present application, the devices of the terminal and the service network each include one or more processors (CPU), input / output interfaces, network interfaces and memories.
[0017] The memory can include non-persistent memory in computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash memory. The memory is an example of computer-readable media.
[0018] The computer-readable media include non-transitory and transitory, removable and non-removable media implemented in any method or technology for storage of information such as computer program instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), or other optical storage, magnetic cassettes, magnetic tape disks storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices.
[0019] The radius scheme widely used at present mainly includes single RADIUS server, DNS-based load balancing and other methods. Due to large user level, multiple requests, daily product upgrade iteration and other non-smooth transition methods, the service cannot guarantee high stability. DNS-based load balancing uses DNS resolution to distribute requests to different RADIUS servers to achieve load balancing and failover. However, DNS-based load balancing lacks real-time and accurate control, and it is difficult to cope with complex load balancing strategies. The prior art has certain limitations in processing real-time requests and dynamic load adjustment, and it is difficult to cope with rapidly changing request load and traffic patterns.
[0020] To address the aforementioned problems, this application proposes a data processing method. The technical solution of this application will be described in detail below with reference to various embodiments.
[0021] like Figure 1 As shown in the diagram, an embodiment of the present invention discloses a data processing method, including the following method steps: Step S10: In response to receiving the input condition, parse the input condition to obtain key-value pairs, operators, and weights.
[0022] In some embodiments, a visual interface is provided that supports inputting natural language rules. Input rules (such as "Inventory > 100 && Product Category ∈ ('Electronic Products', 'Books')") are parsed into a list of atomic conditions, containing keys, operators, and values. An example is shown below: Input example: { "rule":"Inventory > 100 &&Product Category ∈ ('Electronic Products', 'Books')", }"weight":90 Parsing output: Atomic condition list: [{"key":"Inventory Quantity","op":">","value":100},{"key":"Product Category","op":"","value":["∈Electronics","Books"]}] Among them, for the input condition, rule: business condition expression, is composed of two atomic conditions combined by && (logical AND).
[0023] Condition 1: Inventory > 100
[0024] This means that the condition is triggered when the inventory quantity is greater than 100.
[0025] Condition 2: Product category ∈ ('Electronic Products', 'Books')
[0026] This condition is triggered when the product category is electronics or books.
[0027] weight: Weight value 90, used for priority arbitration when multiple rules conflict, the larger the value, the higher the priority.
[0028] For the parsed output, the first condition is: inventory quantity > 100.
[0029] key: Inventory quantity (business field name, representing the inventory quantity).
[0030] op:> (operator, meaning "greater than").
[0031] value: 100 (numeric threshold).
[0032] type: numeric condition (corresponding to i-series fields).
[0033] 2. Second condition: commodity category ∈ electronic products or books
[0034] key: commodity category (business field name, representing commodity category).
[0035] op: ∈ (operator, indicating optional enumeration value).
[0036] value: ["electronic products", "books"] (enumeration value).
[0037] type: enumeration condition (corresponding to v-series fields), indicating that the commodity category belongs to the specified enumeration value set.
[0038] Step S20, based on the preset conversion logic, converting and mapping the key-value pair and operator, including, inverting the operator to obtain the inverted operator, mapping the field type, and generating the query condition.
[0039] In some embodiments, the exemplary preset conversion logic is shown in the following table:
[0040] Among them, the logical mapping of user operators and inverted operators includes: 1. > (greater than) → < (less than) Used for the inversion of numeric conditions, for example, the user defines "inventory > 100", which is actually converted to "inventory < current inventory value" to utilize database indexing.
[0041] By inverting the operator, the original condition (such as A > B) is converted to an equivalent reverse condition (such as B < A), so that the database can quickly filter records that meet the condition through indexing, avoiding full table scanning.
[0042] Field mapping: numeric conditions are mapped to i-series fields (such as i0-i15), each field corresponding to a business numeric attribute (such as i3 corresponding to "inventory").
[0043] 2. ∈ (belongs to) → ANY() (any element matching)
[0044] Used for set matching of enumeration conditions, for example, the user defines "commodity category ∈ ('electronic products', 'books')", which is converted to "commodity category ID contains any one of the mapped enumeration IDs".
[0045] First, the enumeration value (such as "electronic products") is converted to an integer ID (such as 2001) through the Mapping table.
[0046] Using the ANY (v series field) IN (ID list) expression, determine whether any target ID exists in the array of enumeration type fields.
[0047] Field mapping: enumeration type condition is mapped to v series field (such as v0-v15), and the field stores the ID list corresponding to the enumeration value (such as "2001,2002").
[0048] 3. && (logical and) -> AND (logical and)
[0049] Used to combine multiple atomic conditions, for example, "inventory > 100 && commodity category ∈ ('electronic products', 'books')" is converted to "i3 < {inventory value} AND ANY (v2) IN ({ID list})".
[0050] Directly convert the user logic AND operator into the AND operator of SQL, and ensure that multiple conditions are met at the same time to hit the rule.
[0051] It can be understood that the type and number of user operators can be set based on actual application scenarios, and the above table is only an example, and the present embodiment is not limited.
[0052] Step S20, generating a rule configuration table, the rule configuration table includes the mapping field type field, the weight field and the rule ID field.
[0053] In some embodiments, based on the above conversion logic, in the implementation of the conversion process, the rule configuration table is dynamically generated.
[0054] Exemplarily, the specific implementation process of the above implementation conversion includes: 1. For numerical value type condition processing Original condition: inventory > 100 -> converted: ALTER TABLE ConfigRule ADD COLUMN i3 INT; -- Pre-allocate 16 fields, and dynamically expand fields when insufficient INSERT INTO ConfigRule (i3,weight) VALUES (100, 90); Generate SQL condition: i3 < {current inventory} Specifically, "inventory > 100" is a numerical business condition, indicating that when the inventory quantity is greater than 100, the corresponding rule is triggered (such as applying a certain promotion strategy). Convert the business logic into a SQL expression that can be efficiently queried by the database, and store the rule parameters to achieve dynamic matching, quickly filter the rules that meet the conditions by comparing the real-time inventory value with the rule threshold. At the same time, use database field indexing to speed up the query and avoid full traversal of the rules.
[0055] In the above example, the numerical condition is mapped to the i series field (such as i0-i15), and each field corresponds to a business numerical attribute. Here, i3 is assigned to the "inventory" field (numbered in the order of business attributes, such as i0, i1, etc. have been assigned to other attributes). If the pre-set 16 i series fields are not enough, the system can automatically add new fields (such as i16, i17, etc.), without the need to modify the table structure, and can be flexibly expanded. The i3 field stores the original condition 100 (i.e. the rule). The weight field stores the rule weight 90, which is used for priority sorting in the case of multiple rule conflicts (the higher the weight, the higher the priority).
[0056] The operator inversion logic is as follows: according to the conversion logic table, the numerical operator > needs to be inverted to < (see the conversion logic table above). That is, the SQL condition i3 < current inventory (i3 is the stored threshold 100).
[0057] The inverted condition i3 <{current inventory} can use the index of the i3 field (such as B-tree index) in the database to quickly locate the records that meet the condition, avoiding full table scanning. For example: when the current inventory is 120, querying i3 < 120 can directly filter out the rules with i3 values less than 120 (such as the original condition 100, 50, etc.) through the index, and then sort by weight to get the highest value.
[0058] 2. Enumerated condition processing
[0059] Original condition: commodity category ∈ ("electronic products", "books") → converted: SELECT map_id INTO @id1, @id2 FROM Mapping WHERE key='commodity category' AND value IN ('electronic products','books'); INSERT INTO ConfigRule(v2, weight) VALUES ('@id1,@id2', 90); - Generate SQL condition (i.e. query condition): ANY(v2) IN (@id1, @id2) Specifically, "commodity category ∈ ('electronic products', 'books')" is an enumerated business condition, indicating that when the commodity category belongs to "electronic products" or "books", the corresponding rule (such as applying a certain marketing strategy) is triggered. Convert the enumerated value to an integer ID that can be efficiently processed by the database, and store the enumerated condition and weight of the rule. Match the set of integer IDs (such as ANY(v2) IN (ID list)) to speed up the query using database indexing, and achieve efficient matching. The mapping relationship between enumerated values and IDs can be maintained through the Mapping table, supporting the addition or modification of business enumerated values (such as adding the "audio-visual products" category), and realizing dynamic mapping.
[0060] Preferably, the enumerated value of the enumerated type is mapped to an integer ID. For example, the enumerated value mapping table Mapping is used to store the corresponding relationship between business enumerated values and integer IDs, and the structure is as follows:
[0061] Wherein, key: business attribute name (such as "commodity category"); value: enumerated value (such as "electronic products"); map_id: corresponding unique integer ID (such as 2001).
[0062] Through key='commodity category', the enumerated attribute is located, and then the target enumerated value is filtered through value IN ('electronic products', 'books'), and the corresponding map_id is stored in variables @id1 (2001) and @id2 (2002).
[0063] In one embodiment, the enumerated type condition is mapped to the v series field (such as v0-v15), and each field corresponds to a business enumerated attribute. Here, v2 is assigned to the "commodity category" attribute (which may be numbered in the order of business attributes, such as v0, v1, etc. have been assigned to other attributes). The v2 field stores the ID list corresponding to the enumerated value in the format of string splicing (such as "2001,2002"), and it should be noted that @id1, @id2 will be replaced by specific values (not variable names) in actual execution. The weight field stores the rule weight 90, which is used for priority ordering in the case of multiple rule conflicts.
[0064] According to the conversion logic table, the enumerated type operator ∈ is converted to the ANY() IN expression of SQL (see the conversion logic table above). The original condition "commodity category ∈ ('electronic products', 'books')" is equivalent to "commodity category ID contains 2001 or 2002", so the condition is generated: ANY(v2) IN (2001, 2002) ANY(v2): indicates any element in the ID list stored in the v2 field (such as "2001, 2002").
[0065] In some embodiments, although the v series field stores an ID list in the form of a string, through the combination of the ANY() function and the IN operator, the database can quickly traverse the list elements and match the target ID, avoiding the performance loss of parsing the string line by line.
[0066] Step S40, based on the inverse operator, field type, query condition and weight, generate the final SQL template.
[0067] In some embodiments, the final SQL template is as follows: SELECT config_id, weight FROM ConfigRule WHERE i3 < {input_inventory} -- inverse of inventory > 100 AND ANY(v2) IN ({mapped_ids}) -- commodity category enumeration mapping ORDER BY weight DESC LIMIT 1; Preferably, in response to user input parameters, based on the rule configuration table, the final SQL template is executed to return the corresponding rule; wherein the final SQL template includes, arranging the results in descending order of weight, returning the first record after sorting, that is, the rule ID field value of the highest weight rule.
[0068] Specifically, the final SQL template is used to filter the highest weight rule that meets the dynamic condition from the rule configuration table ConfigRule table, and the specific process is: matching inventory and commodity category conditions; arranging in descending order of weight to ensure that high priority rules are given priority; only returning one highest weight rule to achieve accurate arbitration.
[0069] Wherein, the specific meaning of the SQL statement is explained as follows: 1. SELECT config_id, weight The query result returns the rule unique identifier config_id and the weight weight.
[0070] config_id is used to associate the specific content of the rule (such as promotion strategy, parameter package); weight is used for priority sorting when there are multiple rules in conflict (the larger the value, the higher the priority).
[0071] FROM ConfigRule
[0072] In some embodiments, the ConfigRule table (i.e., the rule configuration table) stores dynamic configuration rules, containing the following core fields: numeric fields (i series): such as i3 stores the threshold of inventory (“inventory” is mapped to i3); enumerated fields (v series): such as v2 stores the ID list of the mapped commodity category; weight: rule weight, used for sorting.
[0073] As an example, the specific content of the ConfigRule table is shown in the following table:
[0074] The table structure is explained as follows:
[0075] The i series and v series fields are pre-set to 16 (i0-i15, v0-v15) and can be dynamically expanded to support more business attributes. The mapping relationship between the field name and the business attribute is maintained through metadata management (such as the RuleColumnMapping table, the specific table structure and content, which will not be described in this embodiment). Take i3 and v2 as examples: i3→inventory, v2→commodity category.
[0076] 3.WHERE i3<{input_inventory} AND ANY(v2) IN ({mapped_ids})
[0077] Among them, condition 1: i3 < {input_inventory}
[0078] The original condition “inventory>100” is converted to i3<{input_inventory}, where i3 stores the threshold 100 and {input_inventory} is the real-time inventory value (such as 120, which can be read from the database or input by the user). When the real-time inventory is greater than the threshold 100, i3<{input_inventory} is established (such as 100<120). The index of the i series field in the database (such as B-tree index) can be used to quickly filter out rules whose threshold is less than the real-time inventory.
[0079] Among them, condition 2: ANY(v2) IN ({mapped_ids})
[0080] The `Mapping` table converts enumerated values (e.g., "electronic products") into integer IDs (e.g., 2001), and `{mapped_ids}` is a list of IDs (e.g., 2001, 2002). `ANY(v2) IN (...)` means that any target ID exists in the ID list stored in the `v2` field (e.g., if `v2="2001,2002"`, it matches either 2001 or 2002). The enumerated field `v2` is stored as a comma-separated string of IDs. The `ANY()` function parses the list and matches the strings, avoiding a full table scan. The `AND` operator ensures that the rule is matched only if both conditions are met simultaneously.
[0081] 4. ORDER BY weight DESC
[0082] If multiple rules meet the conditions (such as multiple rules with inventory > 100 and matching categories), the rule with the highest weight will be ranked first.
[0083] 5.LIMIT 1
[0084] Only the first record after sorting is returned, i.e. the rule with the highest weight, to achieve a single arbitration when multiple rules conflict.
[0085] The conversion logic for dynamic parameters in SQL statements: 1. {input_inventory} Source: Real-time inventory value.
[0086] Conversion: Directly substitute i3<{input_inventory} as a numerical parameter, no additional processing is required.
[0087] 2.{mapped_ids}
[0088] Source: User-input enumeration values (e.g., "electronic products" or "books"); The corresponding integer ID can be obtained by querying the Mapping table (e.g., SELECT map_id FROM Mapping WHERE key='product category' AND value IN ('electronic products','books') returns 2001,2002).
[0089] Conversion: Concatenate into ANY(v2) IN (2001,2002) condition to achieve matching of enumeration value sets (enumeration type conditions are converted using ANY() IN).
[0090] Preferably, the numerical data is stored in columnar format.
[0091] Specifically, column storage is a database storage method that stores the data of the same column in a table in a centralized manner, rather than storing all column data by row as in row storage. Column storage stores, for example, the values of the i3 field of all rows in a centralized manner, then stores the values of the v2 field of all rows, and so on. The traditional row storage mode has the following problems when processing large-scale numerical type conditional queries: 1) low efficiency of full table scanning, the query needs to traverse all fields of each row, such as filtering only records with i3<100, still needs to read v2, weight and other irrelevant fields. 2) high memory occupation: in the row storage mode, mixed storage of field data types, cannot be compressed and optimized for numerical type fields.
[0092] The preferred embodiment adopts column storage, reduces disk IO and memory occupation, and speeds up numerical type conditional filtering (such as i3<{input_inventory}) through column storage and compression. And by using the compression characteristics of numerical data (such as integer encoding, difference compression), the storage space is reduced and the storage cost is reduced.
[0093] In some embodiments, the i3 field stores integers (such as inventory threshold 100), and the compression efficiency of column storage for numerical data is significantly higher than that for mixed type data. Optionally, the compression algorithm can use prefix compression: store the common prefix for consecutive integers (such as 100, 150, 200) to reduce redundant data; or bitmap index: establish a bitmap for high-frequency numerical values (such as common inventory thresholds) to quickly locate rows that meet the conditions (such as i3<120 can be filtered directly through the bitmap). The specific compression process is not described here.
[0094] Preferably, the rule data in the rule configuration table is loaded into memory at one time, and a hash map of rule ID and all rule field values is constructed in memory, and the complete rule data is obtained in memory based on the returned rule ID field value through the hash map.
[0095] Specifically, full loading is performed in the service startup phase (such as when the application program startup script or the container is initialized), and the rule data in the database table ConfigRule is loaded into memory at one time to avoid frequent access to the disk during subsequent business requests and improve query performance. A hash map (Hash Map) is constructed in memory, with config_id as the key and the complete data of the rule (such as i series, v series field values, weight, etc.) as the value. The example structure is as follows: {'1001': {'i3': 100, 'v2': '2001,2002', 'weight': 90}, '2001': {'i5': 80, 'weight': 85}} config_id is the unique identifier of the rule, which is used as the key of the hash table to achieve O(1) time complexity for fast query. The value stores all field values of the rule, which is convenient for business logic to read directly. It can be understood that the memory access speed is tens of thousands of times faster than the disk, avoiding the delay of the traditional scheme "SQL query → disk read → result return", and the hash mapping in the memory can directly filter the data combined with the condition parameters (such as quickly screening the rules that meet the conditions through i3<{input_inventory}), without the participation of the database in the intermediate calculation.
[0096] In some embodiments, when the SQL query returns the config_id, the complete data of the rule can be obtained directly in the memory through the hash mapping, without the need for secondary query of the database. Combined with the parameter hash (such as MD5("inventory=120&categories=2001")), the config_id is bound with the parameter hash, and the next same parameter request can directly return the result from the cache.
[0097] Preferably, based on the intersection of the user input parameters and the condition fields in the rule configuration table, only the parameters that match the user input parameters and the configured rule table are retained; based on the intersection, a normalized parameter set is generated and a parameter hash is calculated, where normalization can include filtering invalid parameters and generating a unique hash key cache mechanism, and based on the parameter hash as the cache key, the corresponding query result is stored.
[0098] Exemplarily, the specific implementation process can include that when the input parameter is `{"grade":25,"color":"red"}`: 1. Type conversion: Boolean: true → 1, false → 0 String: query the Mapping table to get "red"→1001 2. Generate a normalized parameter set: {grade:25,color:1001} 3. Calculate the parameter hash: MD5("grade=25&color=1001")→"a1b2c3" In some embodiments, in a dynamic condition matching scenario, the user's request parameters can contain invalid fields or unconfigured conditions (such as an undefined "color" attribute). Through parameter normalization caching, invalid parameters can be filtered, only valid parameters that match the actual configured conditions are retained, reducing invalid calculations; at the same time, different types of parameters (such as strings, Booleans) are converted to a unified format (such as integer ID) that the database can recognize; based on the normalized parameters, a unique hash value is generated, the query result is cached to avoid repeated SQL execution, thereby realizing cache acceleration query.
[0099] As an example, the user parameter {"grade": 25, "color": "red"}→ intersection with the configured condition is {"grade": 25, "color": "red"} (assuming "color" is a valid configuration field)→ after type conversion, it is {"grade": 25, "color": 1001}.
[0100] Normalized parameter set sorting: to avoid the influence of parameter order on the hash result, the string is spliced after sorting by field name. For example, {"color": 1001, "grade": 25} is sorted as "grade=25&color=1001".
[0101] Hash calculation: use MD5 or other hash algorithms to generate a unique identifier (such as MD5("grade=25&color=1001")→ "a1b2c3").
[0102] Hash value usage: as a cache key, store the corresponding query result (such as the hit config_id or rule details), and the same parameter request can directly get the result from the cache through the hash value, without the need to execute SQL again.
[0103] Through the preferred embodiment, only valid parameters are processed, improving the efficiency of condition matching (such as only calculating the rules of grade=25, not full table scanning), while improving the cache hit rate, repeated parameter requests directly return results from memory cache without accessing the database. For example: the first request {"grade": 25, "color": "red"}→ execute SQL and cache the result; the second request with the same parameters directly gets the result from the cache, and the response time is reduced from milliseconds to nanoseconds.
[0104] As an example of an application scenario, the e-commerce platform marketing strategy configuration scenario, the specific implementation process is as follows: Configuration rules: Rule 1: user level > 20 and member type ∈ ('high-level member')→ weight 90 (i2=20, v1=3001 (high-level member ID)).
[0105] Rule 2: User level > 10 → Weight 85 (i2 = 10).
[0106] User request parameters: {"grade":25,"member_type":"Advanced Member"} Processing flow: Find the intersection: both grade and member_type are valid configuration fields.
[0107] Type conversion: grade=25 (numeric, reserved); member_type="Advanced Member" → Converted to v1=3001 via the Mapping table.
[0108] Generate a normalized parameter set: {"grade":25,"member_type":3001} Calculate the hash: MD5("grade=25&member_type=3001")→"c3d4e5" Cache lookup: First request: Execute SQL SELECT config_id FROM ConfigRule WHERE i2 < 25 ANDANY(v1) IN (3001) ORDER BY weight DESC LIMIT 1 → Rule 1 (config_id=1001) is hit and stored in the cache.
[0109] Subsequent requests with the same parameters: retrieve config_id=1001 directly from the cache, without needing to query the database again.
[0110] As another example application scenario, the emergency triage scenario, the specific implementation process is as follows: The specific business requirement is to dynamically assign response levels based on the patient's vital signs in a medical emergency setting: User input criteria: body temperature ≥39℃ or respiratory rate >30 breaths / min → Emergency access (weight 95).
[0111] User input condition parsing: When a patient's body temperature is ≥39℃ or their respiratory rate is >30 breaths / min, the "emergency access" strategy is triggered, with a weight of 95 (highest priority). Meeting either of these two conditions will trigger the rule (logical OR) to ensure high-risk patients receive rapid treatment.
[0112] Condition type analysis: Numeric condition 1: Body temperature ≥ 39℃ (range condition, including equality).
[0113] Numeric condition 2: Respiratory rate > 30 BPM (pure greater-than condition).
[0114] Operator conversion logic: Convert user operators to database-indexable inverse operators according to numeric operator inversion rules:
[0115] Original condition "Body temperature ≥ 39℃" is equivalent to "39℃ ≤ Body temperature", which becomes "Body temperature < real-time body temperature value" after inversion, so the threshold 39 is stored and matched by i5 < real-time body temperature.
[0116] Similarly, "Respiratory rate > 30 BPM" becomes "30 < real-time respiratory rate" after inversion → store threshold 30, and query condition is i6 < real-time respiratory rate.
[0117] The storage form of rules in ConfigRule table is:
[0118] SQL generation and execution: Input parameters: Patient A: Body temperature 40℃, respiratory rate 25 BPM → satisfies "Body temperature ≥ 39℃"; Patient B: Body temperature 38℃, respiratory rate 35 BPM → satisfies "Respiratory rate > 30 BPM"; Patient C: Body temperature 37℃, respiratory rate 20 BPM → does not satisfy any condition.
[0119] Executed SQL statement: SELECT config_id FROM ConfigRule WHERE i5 < 40 OR i6 < 35 -- real-time body temperature = 40, respiratory rate = 35 ORDER BY weight DESC LIMIT 1; Condition analysis: i5 < 40: For patient A, body temperature 40℃ > 39℃, i5 = 39 satisfies 39 < 40, condition is true.
[0120] i6 < 35: For patient B, respiratory rate 35 BPM > 30 BPM, i6 = 30 satisfies 30 < 35, condition is true.
[0121] Logical OR: Either of the two conditions triggers the rule, so patients A and B both hit the rule.
[0122] Result return: Since rule 2801 has the highest weight (95) and meets the condition, it directly returns config_id=2801, triggering the "emergency channel" strategy.
[0123] Preferably, based on the condition parameters, rule metadata, and business indicators, the weight is dynamically adjusted by a pre-trained machine learning model.
[0124] In some embodiments, exemplary condition parameters can include: numerical condition threshold (such as 100 in "inventory > 100", corresponding to i series field value); enumeration condition mapping ID (such as "product category ∈ electronic products" corresponding to 2001, corresponding to v series field value); condition combination method (such as AND / OR, affecting the complexity of rule matching).
[0125] Rule metadata can include: rule effective time, invalid time; rule applicable business scenario label (such as "promotion", "risk control", "device optimization"); initial weight value (manual configuration value). Business indicators can be: e-commerce scenarios: conversion rate, average order value, order volume; industrial scenarios: device failure rate, energy consumption reduction rate, production efficiency; medical scenarios: emergency response time, patient cure rate.
[0126] In some embodiments, the weight can be dynamically adjusted based on business needs. Specifically, a suitable algorithm type can be selected according to business goals. Among them, the regression model is suitable for numerical targets such as conversion rate, and the classification model is suitable for binary classification targets such as whether the rule is effective. It can be understood that other types of machine learning algorithms can also be selected according to different business goals.
[0127] Taking the "conversion rate improvement" in the e-commerce scenario as an example, the training process of the random forest regression model can include: Input features: rule features: inventory threshold (i3), promotion label ID (v4), initial weight (weight_initial); environment features: time (whether it is double 11), user level (grade); historical performance: number of hits in the past 7 days, average response time. Output label: conversion rate after rule hit (conversion_rate).
[0128] Training goal: establish model f(features)→predict conversion rate, and maximize predicted conversion rate by adjusting weight weight.
[0129] Optimization process: Initialize weights: Use artificial weights (e.g., rule 1 weight 90, rule 2 weight 85) as initial values. Simulation adjustment: Generate multiple weight candidate values for each rule (e.g., 90→92, 85→88); predict conversion rate under each candidate weight through the model (e.g., rule 1 weight 92, predicted conversion rate increases from 15% to 18%).
[0130] Select the optimal solution: Choose the weight combination that maximizes overall conversion rate (e.g., rule 1 weight 92, rule 2 weight 88).
[0131] As an example, based on the trained random forest regression model, an example of dynamic adjustment is implemented: An e-commerce platform has three promotion rules: Rule A: New user first order over 99 yuan, reduce 30 yuan (initial weight 90); Rule B: Old user over 299 yuan, reduce 80 yuan (initial weight 85); Rule C: Member Day 85% off (initial weight 80).
[0132] Current problem: Overall conversion rate is 12%, Rule B has low usage but high average order value, Rule C has low average order value but high conversion rate.
[0133] After analyzing historical data, it is found that Rule A: New user conversion rate is 18%, but average order value is only 110 yuan (limited profit space). Rule B: Old user conversion rate is only 9% after triggering, but average order value reaches 320 yuan (high profit contribution). Rule C: Member Day conversion rate is 22%, but average order value is compressed to 150 yuan due to discount. High-value users (historical consumption ≥5000 yuan): significantly respond to Rule B, conversion rate can reach 15%. Price-sensitive users (average order value ≤150 yuan): Rule C conversion rate is as high as 28%.
[0134] The model adjusts the weights according to the user's real-time characteristics, and the adjustment strategy is: When a new user visits: Rule A weight is increased to 95 (strengthening new user conversion). Rule B weight is reduced to 70 (new users do not meet the conditions, avoiding interference). When a high-value old user visits: Rule B weight is increased to 92 (promoting high average order value orders). Rule C weight is reduced to 75 (discounts have low appeal to high-value users). When an ordinary old user visits: Rule C weight is increased to 90 (stimulating price-sensitive users to place orders).
[0135] For example, user B (member, historical consumption 8000 yuan), the model identifies as a high-value user: member level 3, historical consumption 8000 yuan. Adjusted weights: Rule B (92)> Rule A (85)> Rule C (75). Rule B is preferentially displayed: "over 299 yuan, reduce 80 yuan", user places an order of 350 yuan of goods, conversion rate increases from 9% to 15%.
[0136] Through dynamic adjustment of weights by machine learning, the e-commerce platform realizes accurate reach, automatically recommends the most suitable promotion rules according to user characteristics; profit optimization, while improving conversion rate, taking into account single price and conversion of high-value users; agile response, without manual intervention, automatically adapt to business changes.
[0137] Figure 2 A data processing apparatus 200 is shown. The apparatus embodiment corresponds to the method embodiment shown in Figure 1 The apparatus can be specifically applied to various electronic devices.
[0138] As Figure 2 shown, the data processing apparatus 200 provided by the embodiments of the present application comprises: The parsing module 201 is configured to parse the input condition to obtain a key-value pair, an operator and a weight in response to receiving the input condition; The conversion and mapping module 202 is configured to convert and map the key-value pair and the operator based on a preset conversion logic, including inverting the operator to obtain an inverted operator, mapping a field type, and generating a query condition; The first generation module 203 is configured to generate a rule configuration table, the rule configuration table comprising the mapping field type field, the weight field and the rule ID field; The second generation module 204 is configured to generate a final SQL template based on the inverted operator, the field type, the query condition and the weight.
[0139] Based on the same inventive concept, the embodiments of the present application also provide an electronic device, the method corresponding to the electronic device can be the method in the foregoing embodiments, and the problem solving principle thereof is similar to the method. The electronic device provided by the embodiments of the present application comprises: at least one processor; and a memory communicatively connected with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method and / or technical solution of the plurality of embodiments of the present application.
[0140] The electronic device can be a user device, or a device integrated by a user device and a network device through a network, or also can be an application program running on the above device, the user device includes but is not limited to computers, mobile phones, tablet computers, smart watches, wristbands and various terminal devices, and the network device includes but is not limited to network hosts, single network servers, multiple network server sets or cloud computing-based computer sets, which can be used to realize part of the processing function when setting an alarm. Here, the cloud is composed of a large number of hosts or network servers based on cloud computing, wherein cloud computing is a kind of distributed computing, which is composed of a virtual computer formed by a group of loosely coupled computer sets.
[0141] Figure 3 The structure of a device suitable for implementing the method and / or technical scheme in the embodiments of the present application is shown, the device 300 includes a central processing unit (CPU, Central Processing Unit) 301, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM, Read Only Memory) 302 or the program loaded from the storage part 308 to the random access memory (RAM, Random Access Memory) 303. In the RAM 303, various programs and data required for system operation are also stored. The CPU 301, the ROM 302 and the RAM 303 are connected to each other through the bus 304. The input / output (I / O, Input / Output) interface 305 is also connected to the bus 304.
[0142] The following components are connected to the I / O interface 305: the input part 306 including a keyboard, a mouse, a touch screen, a microphone, an infrared sensor, etc.; the output part 307 including a cathode ray tube (CRT, Cathode Ray Tube), a liquid crystal display (LCD, Liquid Crystal Display), an LED display, an OLED display, etc., and a speaker, etc.; the storage part 308 including one or more computer readable media such as a hard disk, an optical disk, a magnetic disk, a semiconductor memory, etc.; and the communication part 309 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication part 309 performs communication processing via a network such as the Internet.
[0143] In particular, the methods and / or embodiments of this application can be implemented as a computer program product. For example, embodiments disclosed herein include a computer program product comprising a computer program tangibly embodied on a computer readable medium, the computer program containing program code for executing the methods illustrated in the flowcharts. When the computer program is executed by a central processing unit (CPU) 301, the aforementioned functions defined in the methods of this application are performed.
[0144] Another embodiment of this application provides a computer readable storage medium having stored thereon computer-executable program code which, when executed by a processor, causes the processor to carry out the method and / or technical solutions of any one or more of the above embodiments of this application.
[0145] In particular, the embodiments can take the form of one or more computer program products. The computer program product can be embodied in any combinations of the computer readable media. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In this document, the computer readable storage medium can be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
[0146] A computer readable signal medium can include a propagated data signal with computer readable program code embodied therein, for use by or in connection with an instruction execution system, apparatus, or device. The computer readable signal medium can be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
[0147] Program code embodied on a computer readable medium can be transmitted using any appropriate medium, including but not limited to wireless, wire line, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
[0148] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).
[0149] The flow diagrams and block diagrams in the drawings are representative of the architectural, functional, and operational aspects of possible implementations of apparatuses, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a segment, or a portion of code, which comprises one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may
[0150] Those skilled in the art can clearly understand that, for the convenience and brevity, the specific working process of the system, device and unit described above can refer to the corresponding process in the foregoing method embodiments, which will not be described here.
[0151] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented by other ways. For example, the device embodiments described above are merely schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or page components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or components shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0152] The units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, i.e. may be located in one place, or may be distributed on multiple network units. Part or all of the units may be selected according to actual needs to achieve the purpose of the embodiment.
[0153] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present alone, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of hardware plus software functional unit.
[0154] The integrated unit realized in the form of software functional unit can be stored in a computer readable storage medium. The software functional unit is stored in a storage medium, including a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute part of the steps of the method described in each embodiment of the present application. The storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, and various program code storage media.
[0155] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of each embodiment of the present application.
[0156] In addition, it is obvious that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. The plurality of units or devices stated in the device claim can also be realized by one unit or device through software or hardware. The words first, second, etc. are used to indicate names, and do not indicate any specific order.
Claims
1. A data processing method, characterized by, The method comprises the following steps: In response to receiving an input condition, parsing the input condition to obtain key-value pairs, operators and weights; Based on the preset conversion logic, the key-value pairs and operators are converted and mapped, including reversing the operators to obtain reversed operators, mapping field types, and generating query conditions; A rule configuration table is generated, which includes the mapping field type field, the weight field and the rule ID field; Based on the reversed operators, field types, query conditions and weights, a final SQL template is generated.
2. The data processing method of claim 1, wherein: In response to user input parameters, based on the rule configuration table, the final SQL template is executed to return the corresponding rule; wherein the final SQL template includes arranging the results in descending order of weight, and returning the first record after sorting, which is the rule ID field value of the highest weight rule.
3. The data processing method of claim 1, wherein: The mapping field type includes numerical type, enumeration type or logical combination; wherein the numerical type is stored in column form, and the enumeration values of the enumeration type are mapped into integer type ID.
4. The data processing method of claim 3, wherein, Further comprising: Rule data in the rule configuration table is loaded into memory at one time, and a hash mapping of rule ID and all rule field values is constructed in memory, and based on the returned rule ID field value, the complete rule data is obtained in memory through the hash mapping.
5. The data processing method of claim 3, wherein, Further comprising: Based on the condition field in the rule configuration table and the user input parameters, the intersection of the two is taken to only keep the parameters that match the user input parameters and the configured rule table; Based on the intersection, a normalized parameter set is generated and a parameter hash is calculated, and the corresponding query result is stored based on the parameter hash as a cache key.
6. The data processing method of claim 5, wherein, Further comprising: Based on the condition parameters, rule metadata and business indicators, the weights are dynamically adjusted through a pre-trained machine learning model.
7. A data processing apparatus, characterized by, Comprise: A parsing module for parsing the input condition to obtain key-value pairs, operators and weights in response to receiving the input condition; A conversion and mapping module for converting and mapping the key-value pairs and operators based on the preset conversion logic, including reversing the operators to obtain reversed operators, mapping field types, and generating query conditions; A first generation module for generating a rule configuration table, which includes the mapping field type field, the weight field and the rule ID field; A second generation module for generating a final SQL template based on the reversed operators, field types, query conditions and weights.
8. An electronic device, comprising: At least one processor; And a memory connected in communication with the at least one processor; wherein The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.
9. A computer readable medium having stored thereon computer program instructions, the computer program instructions executable by a processor to implement the method of any one of claims 1-6.
10. A computer program product comprising a computer program which, when executed by a processor, implements the method of any one of claims 1-6.