Early warning data screening method based on rule analysis and dynamic triggering

Abstract

The invention discloses an early warning data screening method based on rule analysis and dynamic triggering, and belongs to the technical field of data early warning. The method comprises the following steps: analyzing an early warning rule configuration table, generating workdays, dynamically calculating weekly / monthly valid dates in combination with a holiday table, recursively generating annual sequence screening on natural days, and customizing and directly extracting three frequency type dynamic screening logics of a preset date; a dynamic task scheduling mechanism is constructed based on Spring Boot, data rescreening and timed early warning state check of dynamic screening logic are triggered in real time during rule change through priority improvement and thread semaphore control, and in the dynamic updating process, B-Tree single-column index, composite index and function index are adopted to optimize query efficiency. The service coverage capability, the real-time response speed and the high concurrency performance of the early warning system are remarkably improved, and the method is particularly suitable for complex scenes needing high-frequency rule adjustment such as finance and government affairs.

Description

Technical Field

[0001] The present invention relates to the technical field of data early warning, and mainly relates to an early warning data screening method based on rule parsing and dynamic triggering. Background Art

[0002] With the increasing informatization of enterprises, dynamic early warning systems have become a core tool for business risk management in sectors such as finance and government. Existing early warning solutions based on rule configuration and timed triggering have initially achieved automated generation and remediation of early warning data through the concurrent execution of multiple businesses, personalized rule configuration, and fault-tolerance mechanisms.

[0003] For example, the Chinese invention patent with publication number CN106951339A discloses a timed warning method based on data analysis, which uses a rule configuration module to define the warning period, threshold and organizational scope, and drives the warning analysis module through a timer to execute multi-threaded tasks, supporting organizations at all levels to dynamically adjust warning rules. However, in complex business scenarios, the above patent is limited to fixed periods (such as days, weeks, and months) because the warning frequency type is difficult to adapt to scenarios that require a holiday schedule or custom dates, resulting in rigid warning date screening logic. In addition, the above patent relies on timer polling updates after the rules are changed, lacks a real-time trigger mechanism, and is prone to data lag due to task accumulation.

[0004] To address these issues, a new early warning data screening method is urgently needed that integrates dynamic rule parsing and efficient task scheduling. While supporting multiple frequency types (such as weekdays, calendar days, and custom ones), this method, through prioritized task scheduling and index optimization strategies, enables real-time response to rule changes and high-throughput data retrieval. This approach must overcome the technical barriers of traditional timed early warning systems in terms of flexibility, real-time performance, and performance, providing more accurate and efficient early warning decision support for multi-level organizations. Summary of the Invention

[0005] In order to solve the above problems existing in the prior art, the present application provides a warning data screening method based on rule parsing and dynamic triggering.

[0006] The technical solution of this application is as follows:

[0007] A method for screening early warning data based on rule parsing and dynamic triggering, the method comprising:

[0008] Parse the warning rule configuration table to extract the warning frequency type, warning time, and warning zone authority, and generate corresponding filtering logic based on different warning frequency types, including weekdays, natural days, and custom.

[0009] Based on the generated screening logic, the original business data table is screened in combination with the warning time and warning zone authority to obtain the screening results, which are then inserted into the business warning information table;

[0010] A dynamic timed task scheduling mechanism based on Spring Boot is preset, and the dynamic timed task scheduling mechanism is used to realize the dynamic update of the business warning information table. During the dynamic update process, the business warning information table is queried based on B-Tree single column index, composite index and function index to locate the warning data that needs to be dynamically updated.

[0011] Preferably, when parsing the warning rule configuration table, a time range, a frequency parameter, a start sequence number, an end sequence number and a custom date set are also obtained, wherein the frequency parameter includes weekly or monthly;

[0012] Generate corresponding filtering logic for the three types of warning frequencies: working day, natural day, and custom, as follows:

[0013] If the warning frequency type is working day, determine the date screening interval in the working day table based on the time range. Use the SQL window function to group and sort the dates in the working day table by week or month according to the frequency parameter, starting sequence number, and ending sequence number. Generate the weekly or monthly working day sequence number, and select the working day date set corresponding to the working day sequence number that meets the starting sequence number to the ending sequence number.

[0014] If the warning frequency type is natural day, generate a natural day date sequence for the whole year through recursive query of the database, and filter the natural day date set of each week or month based on the frequency parameter, the starting sequence number and the ending sequence number;

[0015] If the warning frequency type is custom, directly extract the custom date set.

[0016] Preferably, data screening is performed on the business original data table based on screening logic, warning time and zoning authority, specifically:

[0017] Convert the warning time field into a standard date format to obtain a warning date set, match the warning date set with the date set corresponding to the screening logic generated according to the required warning frequency type, and obtain a successfully matched warning date set; filter the original table of business data, and the screening conditions include that the corresponding date of the business data is within the successfully matched warning date set, and the zoning code of the business data is consistent with the warning zoning authority, output the business data that meets the screening conditions, and obtain the screening results.

[0018] Preferably, the dynamic timed task scheduling mechanism is used to execute the timed triggered warning data screening task and the timed triggered warning status inspection task. The timed triggered warning data screening task is specifically to filter the data that meets the warning rules from the business original data table according to the timing time and update it to the business warning information table; the timed triggered warning status inspection task is specifically to determine whether the warning data in the business warning information table exceeds the disposal time limit.

[0019] Preferably, the dynamic timed task scheduling mechanism is also used to execute the warning rule change triggering screening task, and when the warning rule configuration table is modified, the screening logic is immediately called to regenerate the business warning information table.

[0020] Preferably, the dynamic scheduled task scheduling mechanism executes tasks based on an abstract task scheduler, a task container, and a task information interface. Specifically:

[0021] During initialization, a fixed-period abstract task scheduler is registered. The abstract task scheduler polls the task information source table. The task types stored in the task information source table include warning data screening tasks and warning status check tasks. The task path of the warning data screening task points to the steps of screening and inserting the date set in the warning rule configuration table into the business warning information table. The task path of the warning status check task points to the steps of determining whether the warning data is overdue according to the disposal time limit.

[0022] When the abstract task scheduler polls the task information source table, if it detects that the task type is an early warning data screening task and the associated early warning rule configuration has changed, it immediately raises the priority of the task to the highest level and triggers the task container to register or update the task. The task container records the task information, scheduling instance and thread semaphore of each task. The thread semaphore is a semaphore allocated to each task for controlling concurrent execution;

[0023] When a rule change triggers a screening task, the thread semaphore recorded in the task container ensures that only one instance of the task corresponding to the ID in the same warning rule configuration table is executed at the same time; the scheduling instance maintained in the task container is bound to the ID corresponding to the warning rule configuration table, and when the task is canceled, the unexecuted task queue corresponding to the ID in the warning rule configuration table is cleared synchronously, wherein the association between the ID corresponding to the warning rule configuration table and the task is realized through the task information interface.

[0024] Preferably, the B-Tree single-column index is created for the warning zoning authority field, the composite index is created for the combination field of the warning zoning authority and the warning rule code, and the function index is created based on the cutoff date field of the warning time.

[0025] Preferably, the method further comprises triggering a scheduled acquisition task at the end of each year, acquiring holiday information for the next year from a third-party interface, and updating the working day data in the working day table based on the holiday information.

[0026] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and runnable on the processor. When the processor executes the program, it implements a warning data screening method based on rule parsing and dynamic triggering as described in the present invention.

[0027] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a warning data screening method based on rule parsing and dynamic triggering as described in the present invention.

[0028] Compared with the prior art, the present invention has the following beneficial effects:

[0029] 1) The present invention provides a warning data screening method based on rule parsing and dynamic triggering. This method targets three frequency types: weekdays, natural days, and custom ones. For example, it recursively generates a natural day sequence and dynamically generates a date set by calculating the weekday sequence number in combination with the holiday table. This method enables flexible screening of user-required warnings and significantly improves the adaptability of the warning system to complex business scenarios.

[0030] 2) The present invention provides a warning data screening method based on rule parsing and dynamic triggering, which implements real-time updating and status checking of warning data through a dynamic timed task scheduling mechanism based on Spring Boot. When the warning rule configuration changes, the abstract task scheduler can immediately increase the task priority and trigger data re-screening, while controlling task concurrency through thread semaphores to avoid resource conflicts. The dynamic timed task scheduling mechanism ensures the real-time nature of warning data and the stability of the warning system, and is particularly suitable for high-frequency rule changes or large-scale warning scenarios;

[0031] 3) The present invention provides a warning data screening method based on rule parsing and dynamic triggering. Through the combination strategy of B-Tree single-column index, composite index and function index, data can be quickly located when the business warning information table is dynamically updated. Furthermore, the function index optimizes query efficiency based on the cutoff date of the warning time field, and the composite index reduces the scanning range by combining the zone code and the rule code. By combining the above-mentioned index design with the dynamic task scheduling mechanism, the early warning system can achieve efficient response in a high-concurrency, large-data volume environment, avoiding performance bottlenecks caused by data expansion. DETAILED DESCRIPTION

[0032] The specific embodiments of the present invention are described below to facilitate understanding of the present invention by those skilled in the art. However, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those skilled in the art, as long as various changes are within the spirit and scope of the present invention as defined and determined by the appended claims, these changes are obvious, and all inventions and creations utilizing the concepts of the present invention are protected.

[0033] The present invention provides the following technical solution: a warning data screening method based on rule analysis and dynamic triggering.

[0034] Example 1:

[0035] This embodiment provides a warning data screening method based on rule parsing and dynamic triggering, the method comprising:

[0036] S1. Parse the warning rule configuration table. The warning rule configuration table is used to store warning rules. Users can determine the parameters of the warning rules according to their needs, including the warning frequency type, warning time, warning zone authority, time range, frequency parameter, start sequence number, end sequence number, and custom date set. By configuring these key information, different warning rules can be flexibly defined to meet diverse business needs.

[0037] In this embodiment, the warning frequency types include working days, natural days and custom, and the warning frequency type is defined as WARN_FREQ_TYPE. When the value is 1, it means that the warning frequency is calculated according to working days, when the value is 2, it means that the warning frequency is calculated according to natural days, and when the value is 3, it means that the warning frequency is calculated according to custom dates; the time range includes a start time and an end time, and the start time is defined as START_TIME and the end time is defined as END_TIME; the frequency parameter includes weekly or monthly, and the frequency parameter is defined as FREQ. When the value is 1, it means that the frequency is weekly, and when the value is 2, it means that the frequency is monthly; the starting sequence number is defined as START_NUM, and the ending sequence number is defined as END_NUM. The starting sequence number is actually the date when the calculation starts, and the ending sequence number is actually the date when the calculation ends;

[0038] Generate corresponding filtering logic for the three types of warning frequencies: working day, natural day, and custom, as follows:

[0039] S11. If the warning frequency type is working day, in order to accurately locate the working day data range that needs to be analyzed and avoid interference from irrelevant data, determine the date filtering interval in the working day table based on the time range. The working table stores all working day information for the year and has only two table fields: working table ID and working day date DAY. The data format is, for example: 1. YYYY-MM-DD, where 1 is the working table ID and YYYY-MM-DD is the working day date DAY;

[0040] According to the frequency parameter, starting sequence number and ending sequence number, the dates in the working day table are grouped and sorted by week or month through SQL window functions to generate weekly or monthly working day sequence numbers. The working day date set corresponding to the working day sequence numbers that meet the starting sequence number to the ending sequence number is selected to accurately select the working days that meet the conditions to ensure the accuracy of the warning data;

[0041] Among them, the SQL window function is used to group and sort the dates in the workday table by week or month to generate the weekly or monthly workday serial numbers, including:

[0042] Use the SQL function SUBSTR(DAY,6,2) to extract the month information. Because the date DAY is usually in the format of YYYY-MM-DD, the SUBSTR function intercepts a substring from the string. Starting from the 6th character, a string of length 2 is intercepted to get the month. For example, if DAY is YYYY-MM-DD, SUBSTR(DAY,6,2) returns MM, which represents the MM month. This step divides the date by month, making it easier to count and filter by month.

[0043] Use the SQL statement TO_DATE(DAY,'YYYY-MM-DD') to convert the string type date to the internal date type of the database. It is worth noting that the date string format 'YYYY-MM-DD' needs to be specified here so that the database knows how to parse the string. For example, if DAY is YYYY-MM-DD, TO_DATE(DAY,'YYYY-MM-DD') converts it to the date type; use the SQL statement TO_CHAR(...,'IW') to convert the date type data to the string type and output it in the 'IW' format. 'IW' represents the ISO week number, that is, the week of the current date is the number of weeks in the year, which can be approximately regarded as the number of weeks in the month. For example, for the date YYYY-05-06, the function may return 19, indicating that it is in the 19th week of the year. This step accurately determines the week of the date and provides a basis for filtering by week.

[0044] Use the SQL statement TO_CHAR(TO_DATE(DAY,'YYYY-MM-DD'),'D') to convert the date string to a date type, and then to a string type. The 'D' format indicates the day of the week. In most databases, Sunday is 1, Monday is 2, and so on. For example, YYYY-MM-DD (Tuesday) will return 3. Then use the SQL statement TO_NUMBER(...) to convert the string type number to a numeric type to facilitate subsequent calculations. Subtract 1 from the converted numeric type to make the day of the week count starting from 0 (that is, Monday is 0, Tuesday is 1, and so on). Therefore, for YYYY-MM-DD (Tuesday), after calculation, 3-1=2 is obtained. This step unifies the counting method of the days of the week to facilitate logical judgment.

[0045] Use the window function ROW_NUMBER() OVER(PARTITION BY TO_CHAR(TO_DATE(DAY,'YYYY-MM-DD'),'IW') ORDER BY ID) to determine the weekday of the week. ROW_NUMBER() assigns a unique row number to each row in the query result set, OVER() specifies the partitioning and sorting rules of the window function, PARTITION BY TO_CHAR(TO_DATE(DAY,'YYYY-MM-DD'),'IW') partitions the date by the week, grouping dates in the same week. For example, all dates in week 19 are grouped together. ORDER BY ID is used to sort by the ID field within each partition and then assign row numbers to the sorted rows. This determines the weekday of the week the date falls on, which is the weekday sequence number corresponding to each week. This step clarifies the order of each weekday in the week so that filtering can be performed based on the starting and ending sequence numbers.

[0046] We also use the window function ROW_NUMBER() OVER (PARTITION BY SUBSTR (DAY, 6, 2) ORDER BY ID). PARTITION BY SUBSTR (DAY, 6, 2) partitions the date by month, grouping dates in the same month. For example, all dates in May are grouped together. ORDER BY ID sorts the date by the ID field within each partition and assigns a row number. This determines the weekday of the month, which is the corresponding weekday sequence number for each month. This step determines the order of each weekday in the month, meeting the requirement of filtering by month.

[0047] Use the SQL statement GROUP BY WEEK_NUMBER to group the date data determined in the above steps (the month, week number, day of the week, week number, and week number of the month have been clearly defined) by week. GROUP BY will group data with the same week number into one group. Then use the MAX(DAY) function to find the maximum value of the DAY field in each group, that is, the maximum date in the group, that is, the maximum weekday date of the week. Similarly, use the SQL statement GROUP BY MONTH_NUMBER to group the date data determined in the above steps (the month, week number, day of the week, week number, and weekday of the month have been clearly defined) by month. Find the maximum value of the DAY field in each group, that is, the maximum date in the group, that is, the maximum weekday date of the month.

[0048] Preferably, since working day information is only known at the end of the previous year, for example, working day data for 2025, holiday adjustment information will not be released until around the end of 2024, the method further includes triggering a scheduled acquisition task at the end of each year (for example, from December 1 to December 31), acquiring holiday information for the next year from a third-party interface or a government website, and updating the working day data in the working day table based on the holiday information;

[0049] S12. If the warning frequency type is natural day, generate a natural day date sequence for the entire year through a recursive database query, and filter a natural day date set for each week or month based on the frequency parameter, the start sequence number, and the end sequence number;

[0050] Among them, the parsing logic of natural days is similar to that of working days, except that there is no need to obtain date information from the working day table. Instead, you can directly use the database's built-in functions. The current date is truncated to January 1 of the current year through the TRUNC(SYSDATE,'YEAR') function; further, 12 months are added to January 1 of the current year through the ADD_MONTHS(TRUNC(SYSDATE,'YEAR'),12) function to obtain January 1 of the next year; the difference in the number of days from January 1 of the current year to January 1 of the next year is calculated through ADD_MONTHS(TRUNC(SYSDATE,'YEAR'),12)-TRUNC(SYSDATE,'YEAR'), which is actually the total number of days in the current year; a sequence from 1 to the total number of days in the current year is generated through CONNECT BY LEVEL<=ADD_MONTHS(TRUNC(SYSDATE,'YEAR'),12)-TRUNC(SYSDATE,'YEAR'), where CONNECT BY is a keyword used to generate recursive queries in Oracle databases. LEVEL is a pseudo column. In recursive queries, LEVEL increases from 1.

[0051] By adding LEVEL-1 to January 1 of the current year, you can get the date of each day starting from January 1. For example, when LEVEL=1, you get YYYY-01-01; when LEVEL=2, you get YYYY-01-02, and so on.

[0052] Convert the dates obtained by incrementing above into a string in the specified format of YYYY-MM-DD using the function statement TO_CHAR(TRUNC(SYSDATE,'YEAR')+LEVEL-1,'YYYY-MM-DD') to obtain the final natural day date sequence for the entire year.

[0053] S13. If the warning frequency type is custom, directly extract the custom date set;

[0054] S14. For ease of understanding, further examples are given: if the warning frequency type WARN_FREQ_TYPE is set to 1 (indicating working days), the frequency parameter FREQ is set to 1 (indicating weekly), the starting sequence number START_NUM is 3, the ending sequence number END_NUM is 6, and the time range is May 1, 2025 - May 31, 2025, based on the settings of this embodiment, only the data from the 3rd to the 6th working days are filtered each week. For example, in the first week (assuming May 1 is Thursday), the data from the 3rd working day (possibly Friday) to the 6th working day (next Wednesday) of this week will be filtered out; if the warning frequency type WARN_FREQ _TYPE is 2 (natural day), the frequency parameter FREQ is 2 (monthly), the starting sequence number START_NUM is 5, the ending sequence number END_NUM is 10, and the time range is June 1, 202X - June 30, 202X. That is, within the month of June, data from the 5th to the 10th day is filtered. The days here are natural days, regardless of whether these days are weekdays or holidays. When the warning frequency type WARN_FREQ_TYPE is 3 (custom), the user selects July 5, July 10, and July 15, 202X in the custom date set, which means that only data from these three days is filtered.

[0055] It is worth noting that some of the functions mentioned in step S1 are specific functions of a specific database, for example, TRUNC is a function specific to the Oracle database, but this embodiment does not limit the running database and function application of the above steps. The above is only an example for easy understanding. In actual application, users can flexibly select the corresponding function to achieve the same function according to the type of database used. For example, if a MySQL database is used, the DATE_FORMAT function can be used instead of the TO_CHAR function to convert the date format, and the DATE_ADD function can be used instead of the ADD_MONTHS function to perform date addition and subtraction operations, etc. Through the above analysis of the warning rule configuration table and the screening logic generated for different warning frequency types, the warning date data that meets the business needs can be efficiently and accurately screened out.

[0056] S2. Based on the generated screening logic, combined with the warning time and warning zone authority, the original business data table is screened to obtain the screening results, and the screening results are inserted into the business warning information table. Specifically:

[0057] Convert the warning time field to the standard date format YYYY-MM-DD to obtain a warning date set, match the warning date set with the date set corresponding to the screening logic generated according to the required warning frequency type, and obtain a successfully matched warning date set; filter the original business data table, and the screening conditions include that the date corresponding to the business data is within the successfully matched warning date set and the division code of the business data is consistent with the warning division authority; output the business data that meets the screening conditions to obtain the screening results;

[0058] In traditional date calculation, weekend adjustments can cause confusion between working days and holidays. This embodiment avoids this effect by setting the "working day" warning frequency type. Data is filtered only according to normal working days, solving the problem caused by weekend adjustments being holidays. The natural day calculation method does not consider the difference between working days and holidays, which is suitable for scenarios that require high date continuity and do not need to distinguish between working days. The customized method is very flexible and users can filter only the data of specific dates according to their special needs to meet personalized business requirements. At the same time, the mechanism of automatically updating working day data every year ensures the accuracy and reliability of the entire warning system.

[0059] S3. Preset a dynamic timed task scheduling mechanism based on Spring Boot and use it to dynamically update the business warning information table. During the dynamic update process, the business warning information table is queried based on B-Tree single-column indexes, composite indexes, and function indexes to locate warning data that needs to be dynamically updated.

[0060] S31, the dynamic timed task scheduling mechanism is used to execute the timed trigger warning data screening task and the timed trigger warning status check task. The timed trigger warning data screening task specifically filters data that meets the warning rules from the business original data table according to the timed time and updates it to the business warning information table; the timed trigger warning status check task specifically determines whether the warning data in the business warning information table exceeds the disposal time limit, and the disposal time limit is pre-set according to user needs; the dynamic timed task scheduling mechanism is also used to execute the warning rule change trigger warning data screening task. When the warning rule configuration table is modified, the screening logic is immediately called to regenerate the business warning information table;

[0061] S32. In this embodiment, in order to reduce code redundancy, frameworks such as xxl-job are not introduced. Instead, the scheduled tasks provided by springboot are used. However, the scheduled tasks provided by springboot are static, and their task execution time is defined by a fixed Cron expression, and are loaded and registered when the application starts. It lacks the ability to dynamically manage tasks, which makes it impossible for the early warning system to start, stop, update or register new tasks during runtime, severely limiting the flexibility and maintainability of the early warning system. In order to solve this problem, this embodiment provides a dynamic scheduled task scheduling mechanism based on the Spring Boot framework, which supports dynamic loading of tasks from external configuration at runtime, realizes the addition, deletion, modification and query of tasks, and real-time registration and update, and has the characteristics of thread safety, support for CRON expressions, and avoidance of task re-entry. The dynamic scheduled task scheduling mechanism executes tasks based on an abstract task scheduler, a task container, and a task information interface. Specifically:

[0062] When the early warning system is initialized, a fixed-period abstract task scheduler is registered. The abstract task scheduler polls the task information source table at fixed intervals. The task types stored in the task information source table include early warning data screening tasks and early warning status check tasks. The task path of the early warning data screening task points to the steps of screening and inserting the date set in the early warning rule configuration table into the business early warning information table, and the task path of the early warning status check task points to the steps of determining whether the early warning data has expired according to the disposal time limit.

[0063] When the abstract task scheduler polls the task information source table, if it detects that the task type is an early warning data screening task and the associated early warning rule configuration has changed, it immediately raises the priority of the task to the highest level and triggers the task container to register or update the task. The task container maintains a task mapping table that records the task information, scheduling instance and thread semaphore of each task. The thread semaphore is allocated to each task and is used to control concurrent execution and avoid concurrent execution of tasks (prevent reentrancy);

[0064] When a rule change triggers a screening task, the thread semaphore recorded in the task container ensures that only one instance of the task corresponding to the ID in the same warning rule configuration table is executed at the same time; the scheduling instance maintained in the task container is bound to the ID corresponding to the warning rule configuration table, and the unexecuted task queue corresponding to the ID in the warning rule configuration table is cleared synchronously when the task is canceled. The association between the ID corresponding to the warning rule configuration table and the task is realized through the task information interface. The task information interface uniformly describes the basic attributes of the task, including the unique identification of the task and the task execution time plan. It also provides a method for judging whether the task is valid and whether the configuration has changed, providing a standardized information description and interaction basis for the entire task scheduling mechanism;

[0065] For ease of understanding, further examples are given: when the early warning system is started, the abstract task scheduler will register an abstract task scheduler with the ScheduledTaskRegistrar timed task register. The abstract task scheduler performs a poll every 10 seconds to periodically refresh the task list. Each time it polls, it first obtains all task configurations through the listTaskInfo() function. This function is used to fully obtain the configuration information of all tasks. When the abstract task scheduler polls the task information source table according to a fixed period, it needs to know the details of all tasks in the current early warning system, including task type, task execution time plan, associated early warning rule configuration, etc. The listTaskInfo() function is responsible for extracting this information from the task information source table or related data storage, and returning a list containing all task configurations; then call DSCo in sequence. The container.checkTask() function carefully processes the obtained task configuration, performing different operations based on the task's status (first registration, registered with configuration changes, or invalid). Specifically, if the task is discovered for the first time and the configuration is valid, the DSContainer.checkTask() function triggers the task registration process, formally incorporating the task into the task scheduling mechanism for subsequent scheduled execution. If the task has already been registered but the associated configuration (such as alert rules or execution time) has changed, the function first cancels the original task registration and then re-registers the newly configured task to ensure that the task executes according to the latest rules. If the task is deemed invalid (for example, if the associated alert rules have been deleted), the DSContainer.checkTask() function cancels the task registration and removes it from the task scheduling mechanism. When a task is triggered, the alert system first attempts to obtain a thread semaphore to ensure that the task is not already executing, ensuring safe execution.After successfully obtaining the thread semaphore, the doProcess() function will be called to execute the specific task logic. For example, when the early warning data screening task is triggered, the early warning system first obtains the thread semaphore of the task. After confirming that it can be executed, the doProcess() function implemented by the task subclass is called to complete the data screening and update operations. After completing the task logic, the thread semaphore is released to prepare for the execution of subsequent tasks. Among them, the doProcess() function is a specific task logic execution function implemented by the task subclass. Each different type of task (such as early warning data screening task, early warning status check task) will have its own unique business logic. The doProcess() function is used to implement these specific business logics. For example, in the early warning data screening task, the doProcess() function will filter the qualified data from the business original data table according to the early warning rule configuration table, and update it to the business early warning information table; in the early warning status check task, the doProcess() function will determine whether the early warning data in the business early warning information table exceeds the disposal time limit;.

[0066] The above-mentioned dynamic timed task scheduling mechanism has the ability to support dynamic configuration, which allows dynamic loading, modification and closing of tasks when the early warning system is running, greatly improving the flexibility and adaptability of the early warning system. By introducing the semaphore mechanism, thread-safe execution is achieved, fundamentally eliminating the risk of task re-entry and ensuring the stability of the system. The task logic is decoupled and has strong flexibility and scalability. It can easily expand multiple task subclasses to meet the needs of different business scenarios. Moreover, this embodiment is based on the official Spring interface extension, which is a lightweight integration with good compatibility with existing systems, reducing development and maintenance costs. In addition, the dynamic timed task scheduling mechanism also has strong task awareness, supports accurate perception of task "status" and "configuration changes", can automatically adapt task behavior, and ensures that the system always runs efficiently;

[0067] S33. To achieve efficient storage of warning data and optimize query performance, this embodiment uses a multi-level index optimization strategy to optimize the storage of the business warning information table. The following are the specific creation methods and functions of various indexes:

[0068] S331. Considering that warning zones are frequently used in actual applications and are high-frequency filtering conditions, a B-Tree single-column index is created for the warning zone authority field. This single-column index can quickly locate warning data within a specific zone, avoiding a full table scan each time, and significantly improving the efficiency of queries based on the zone dimension.

[0069] S332. In actual business scenarios, there are complex query requirements with high concurrency and multiple conditions, such as filtering data based on both warning zone permissions and warning rule codes. Therefore, a composite index is created for the combined fields of warning zone permissions and warning rule codes. This composite index strategy can effectively reduce table return operations during queries, accelerate data location and extraction under joint conditions, and greatly improve the performance of multi-dimensional filtering and display of warning data.

[0070] S333. The task status field is often queried for equality, so a hash index is theoretically a more suitable choice. However, if an Oracle database is used, hash indexes are not supported. Therefore, this embodiment still uses a B-Tree index. To achieve efficient query results similar to a hash index, index selectivity is optimized, and a complex index is created by combining the status field with highly selective fields. This allows for efficient queries on the task status field. Since queries on the warning date often involve time range queries, a B-Tree index is used for this field. This index can quickly locate warning data within a specified time range, improving query performance based on the time dimension.

[0071] S334. In order to further optimize the quick query based on the "date" dimension, such as realizing today's warning, monthly statistics and other functions, a function index is created. In this embodiment, the business warning information table is defined as WARN_PROBLEM_ALL_DATA, and an index of IDX_TRUNC_WARN_TIME is created in the business warning information table. The index is based on the result of applying the TRUNC function to the warning time WARN_TIME field. The purpose is to improve the execution efficiency of queries involving the TRUNC (WARN_TIME) condition. A function index is created based on the truncated date field of the warning time. The function index can quickly filter out warning data that meets the specific date conditions, effectively improving the statistical and query efficiency based on the date dimension.

[0072] Through the above-mentioned multi-level index optimization strategy, this embodiment has significantly improved the query performance, multi-dimensional screening and display of warning data storage. During the dynamic update process, the above-mentioned multi-level index optimization strategy can efficiently locate the data that needs to be updated, thereby improving the performance and efficiency of the entire update operation, and providing strong support for the efficient operation of the early warning system.

[0073] Example 2:

[0074] This embodiment provides a warning data screening method based on rule parsing and dynamic triggering. On the basis of Example 1, if the holiday data for the next year is not obtained in time, the traditional logic cannot automatically calculate the temporary working days. This embodiment constructs a holiday prediction model. When it is detected that the working day table data for the next year is empty, the historical holiday data (the adjustment rules of the past five years) is automatically called to train the holiday prediction model; based on the trained holiday prediction model, a predicted working day table is generated, and it is automatically calibrated after obtaining real data.

[0075] The holiday prediction model includes a rule engine and an LSTM residual correction module:

[0076] The rule engine is used to extract fixed patterns from input data. The input data mainly includes two parts: structured historical adjustment records and workday table snapshots. Among them, the historical adjustment records need to extract key information from the holiday arrangement notices issued by the government, such as the start and end dates of statutory holidays such as the Spring Festival and National Day, and the number of days of adjustment and compensation (such as "Spring Festival holiday is 7 days, and 2 weekends need to be compensated"), and store them as historical database tables; the workday table snapshots need to integrate the daily tag data (working days, weekends, holidays) maintained in the past five years, and add special event tags.

[0077] Perform data preprocessing on the input data, including:

[0078] Align the same holidays across different years to a unified time base. For example, the week of the Spring Festival is set as the "base week" to eliminate the misalignment between the lunar calendar and the Gregorian calendar. Define a dynamic window for each holiday (usually from 7 days before to 7 days after the holiday) to cover the holiday preparation period and the compensation period. Use natural language processing technology to convert unstructured compensation notice text into machine-readable rule vectors. For example, encode "1 day of make-up work before National Day" as [holiday_type=3, offset=-2, compensate_days=1], where offset represents the offset of the make-up work day relative to the holiday start date.

[0079] Furthermore, an example is given to illustrate how the rule engine extracts fixed patterns from input data: by analyzing the records of Spring Festival holiday adjustments, it was found that the average compensation ratio of the Spring Festival holiday in the past five years was 0.3 (that is, one make-up day is required for every three days of holiday), and the make-up day is usually scheduled on the Saturday of the week before the holiday. These patterns are summarized as parameters in the prediction rule configuration file, which are used to generate basic forecasts for the next year. In specific implementation, the rule engine will traverse each holiday type, calculate the Gregorian calendar date based on its historical anchor date (such as the first day of the first lunar month of the Spring Festival), and determine the location of the make-up day based on the compensation ratio and the distance to the adjacent weekend. If there is a significant fluctuation in the historical pattern of a holiday (such as the National Day holiday is extended to 8 days due to special policies in a certain year), the anomaly detection mechanism will be triggered, and the data of that year will be temporarily ignored to avoid noise interference;

[0080] The LSTM residual correction module is responsible for capturing nonlinear features that the rule engine cannot cover. This module takes the difference sequence between the rule prediction results and the actual shift adjustment date as input (for example, if the rule predicts that the make-up shift date is January 28, and the actual date is January 29, the difference is +1 day). Through three layers of hidden units, it learns the impact of policy fine-tuning and emergencies (such as extreme weather) on shift adjustment decisions.

[0081] Preferably, the LSTM residual correction module is trained using a rolling window strategy, using data from the previous five years (excluding the current year) as the basis, gradually adding new year data to verify the model's generalization ability, and using Huber Loss as the loss function to balance the impact of outliers. The trained LSTM residual correction module can output a date offset correction value. For example, when predicting the 2025 Spring Festival make-up day, if the rule engine predicts January 25, and the LSTM outputs a +2-day correction based on the recent policy tightening trend, the final prediction result will be adjusted to January 27.

[0082] When the early warning system detects that the workday table for the next year is empty, the model enters the temporary table generation process. First, the rule engine is invoked to generate a basic forecast, including all statutory holidays and their corresponding make-up days. The LSTM residual correction module then fine-tunes the placement of make-up days to generate a revised temporary workday table. This table is stored as a database record, containing fields such as date, whether it is a workday, and confidence level (initial value is 90%), for the early warning system to access.

[0083] This embodiment also includes a dynamic calibration mechanism. If the actual adjustment data for the next year is subsequently obtained, the dynamic calibration mechanism will be activated: the difference between the prediction and the actual value (such as the number of misjudged days and the compensation ratio error) will be calculated, the weight of the LSTM residual correction module will be updated through backpropagation, and the compensation ratio parameters of the rule engine will be adjusted.

[0084] Preferably, to cope with extreme policy changes (such as the sudden cancellation of all holidays), the early warning system will mark low-confidence prediction areas and trigger a manual review process to avoid relying entirely on automated decision-making.

[0085] Example 3:

[0086] The present invention further provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method for screening early warning data based on rule parsing and dynamic triggering as described in any embodiment of the present invention is implemented;

[0087] Example 4:

[0088] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a warning data screening method based on rule parsing and dynamic triggering as described in any embodiment of the present invention.

[0089] It is worth noting that the electronic device and computer-readable storage medium described in the present invention are based on the same inventive concept as the method described in the present invention, and will not be described in detail here.

[0090] The above descriptions are merely embodiments of the present invention and are not intended to limit the scope of the present invention. Any direct or indirect application in other related technical fields shall also be included in the scope of patent protection of the present invention.

Claims

1. A warning data screening method based on rule analysis and dynamic triggering, characterized in that: The method comprises: Parse the warning rule configuration table to extract the warning frequency type, warning time, and warning zone authority, and generate corresponding filtering logic based on different warning frequency types, including weekdays, natural days, and custom. Based on the generated screening logic, the original business data table is screened in combination with the warning time and warning zone authority to obtain the screening results, which are then inserted into the business warning information table; A dynamic timed task scheduling mechanism based on Spring Boot is preset, and the dynamic timed task scheduling mechanism is used to realize the dynamic update of the business warning information table. During the dynamic update process, the business warning information table is queried based on B-Tree single column index, composite index and function index to locate the warning data that needs to be dynamically updated.

2. The method for screening early warning data based on rule analysis and dynamic triggering according to claim 1, characterized in that: When parsing the warning rule configuration table, the time range, frequency parameter, start sequence number, end sequence number and custom date set are also obtained, wherein the frequency parameter includes weekly or monthly; Generate corresponding filtering logic for the three types of warning frequencies: working day, natural day, and custom, as follows: If the warning frequency type is working day, determine the date screening interval in the working day table based on the time range. Use the SQL window function to group and sort the dates in the working day table by week or month according to the frequency parameter, starting sequence number, and ending sequence number. Generate the weekly or monthly working day sequence number, and select the working day date set corresponding to the working day sequence number that meets the starting sequence number to the ending sequence number. If the warning frequency type is natural day, generate a natural day date sequence for the whole year through recursive query of the database, and filter the natural day date set of each week or month based on the frequency parameter, the starting sequence number and the ending sequence number; If the warning frequency type is custom, directly extract the custom date set.

3. The method for screening early warning data based on rule analysis and dynamic triggering according to claim 2, characterized in that: The original business data table is screened based on the screening logic, warning time and zoning authority, specifically: Convert the warning time field into a standard date format to obtain a warning date set, match the warning date set with a date set corresponding to the screening logic generated according to the required warning frequency type, and obtain a successfully matched warning date set; The original table of business data is filtered. The filtering conditions include that the corresponding date of the business data is within the set of successfully matched warning dates, and the division code of the business data is consistent with the warning division authority. The business data that meets the filtering conditions is output to obtain the filtering results.

4. The method for screening early warning data based on rule analysis and dynamic triggering according to claim 1, characterized in that: The dynamic timed task scheduling mechanism is used to execute the timed triggered warning data screening task and the timed triggered warning status inspection task. The timed triggered warning data screening task is specifically to filter the data that meets the warning rules from the business original data table according to the timing time and update it to the business warning information table; the timed triggered warning status inspection task is specifically to determine whether the warning data in the business warning information table exceeds the disposal time limit.

5. The method for screening early warning data based on rule analysis and dynamic triggering according to claim 4, characterized in that: The dynamic timed task scheduling mechanism is also used to execute the warning rule change triggering warning data screening task. When the warning rule configuration table is modified, the screening logic is immediately called to regenerate the business warning information table.

6. The method for screening early warning data based on rule analysis and dynamic triggering according to claim 5, characterized in that: The dynamic timed task scheduling mechanism executes tasks based on the abstract task scheduler, task container and task information interface. Specifically: During initialization, a fixed-period abstract task scheduler is registered. The abstract task scheduler polls the task information source table. The task types stored in the task information source table include warning data screening tasks and warning status check tasks. The task path of the warning data screening task points to the steps of screening and inserting the date set in the warning rule configuration table into the business warning information table. The task path of the warning status check task points to the steps of determining whether the warning data is overdue according to the disposal time limit. When the abstract task scheduler polls the task information source table, if it detects that the task type is an early warning data screening task and the associated early warning rule configuration has changed, it immediately raises the priority of the task to the highest level and triggers the task container to register or update the task. The task container records the task information, scheduling instance and thread semaphore of each task. The thread semaphore is a semaphore allocated to each task for controlling concurrent execution; When a rule change triggers a screening task, the thread semaphore recorded in the task container ensures that only one instance of the task corresponding to the ID in the same warning rule configuration table is executed at the same time; the scheduling instance maintained in the task container is bound to the ID corresponding to the warning rule configuration table, and when the task is canceled, the unexecuted task queue corresponding to the ID in the warning rule configuration table is cleared synchronously, wherein the association between the ID corresponding to the warning rule configuration table and the task is realized through the task information interface.

7. The method for screening early warning data based on rule analysis and dynamic triggering according to claim 1, characterized in that: The B-Tree single-column index is created for the warning zoning authority field, the composite index is created for the combination field of the warning zoning authority and the warning rule code, and the function index is created based on the truncation date field of the warning time.

8. The method for screening early warning data based on rule analysis and dynamic triggering according to claim 2, characterized in that: The method further includes triggering a scheduled acquisition task at the end of each year to obtain holiday information for the next year from a third-party interface, and updating the working day data in the working day table based on the holiday information.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the method for screening early warning data based on rule parsing and dynamic triggering according to any one of claims 1 to 8 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method for screening early warning data based on rule parsing and dynamic triggering as described in any one of claims 1 to 8 is implemented.