Performance index day-level real-time drying method and system based on double-lookboard decoupling architecture

Abstract

The application provides a performance index daily real-time airing method and system based on a double-board decoupling architecture, and relates to the technical field of data processing. The technical scheme provided by the application limits the high-frequency write operation of the first update event to the first storage area, and shields the addressing request for the second storage area during the write process, eliminating the interference of the daily write operation on the second storage area. At the same time, the first result data is state-locked after completing data output, ensuring that it is not affected by the underlying data change within the display period. When the second update event is triggered, the second result data is written into the second storage area with a cycle version identifier for version solidification, so that the formal examination result data forms an independent version record. Therefore, the daily airing data can be refreshed at a high frequency, and the formal examination result data can be version-solidified at the storage level and is not affected by the daily write operation.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a method and system for daily real-time display of performance indicators based on a dual-Kanban decoupled architecture. Background Technology

[0002] In the field of enterprise performance management, performance appraisal systems need to calculate and display the performance indicators of each assessed unit in real time on a daily basis, and output confirmed official appraisal results at the end of the appraisal period. Therefore, how to simultaneously handle the frequently updated daily data and the stable official appraisal results data within the same system has become a pressing problem to be solved in this scenario.

[0003] In related technologies, performance evaluation systems typically employ a single storage architecture to hold the two types of data mentioned above. Daily calculation tasks and periodic assessment confirmation tasks share the same storage area and the same write control strategy. After each calculation task is executed, the latest result is overwritten into this storage area. However, in practical applications, because two types of write operations with different trigger frequencies operate on the same storage area and follow the same overwrite strategy, the daily calculation task will overwrite the already written formal assessment result data when triggered in each unit time slice. This prevents the formal assessment results from being version-fixed at the storage level, ultimately causing the system to be unable to maintain high-frequency refresh of daily data while ensuring the long-term stability of the formal assessment result data. Summary of the Invention

[0004] This application provides a method and system for daily real-time performance indicator display based on a dual-Kanban decoupled architecture. It can ensure that the official assessment results data are version-fixed at the storage level and are not overwritten by daily write operations while the daily display data is refreshed frequently.

[0005] Firstly, this application provides a daily real-time performance indicator display method based on a dual-Kanban decoupled architecture, applicable to a performance appraisal system. The method includes: In the storage system corresponding to the performance evaluation system, a first storage area and a second storage area are configured to be isolated from each other, and an asymmetric first write control policy and a second write control policy are configured for the first storage area and the second storage area respectively; wherein, the write permission of the first storage area is bound to the first update event, the write permission of the second storage area is bound to the second update event, and the triggering frequency of the first update event is higher than the triggering frequency of the second update event. In response to the first update event, the system obtains the first data set within the current unit time slice from the data source, processes the first data set based on preset calculation rules to generate first result data, and writes the first result data to the first storage area according to the first write control strategy; during the writing of the first result data, addressing requests to the second storage area are blocked. After the data output is completed based on the first storage area, the state lock is performed on the first result data written in the first storage area, so that the first result data will no longer respond to changes in the underlying data in the data source before the next first update event is triggered. In response to the second update event, the second data set is acquired in batches according to the complete time window covered by the target period. The second data set is processed based on the calculation rules to generate the second result data. The second result data is written to the second storage area with the period version identifier for version fixation.

[0006] By adopting the above technical solution, a first storage area and a second storage area are configured to be isolated from each other in the storage system and bound to asymmetric write control strategies. This restricts the high-frequency write operations of the first update event to the first storage area, and during the write process, address requests to the second storage area are blocked, eliminating interference from daily write operations to the second storage area. Simultaneously, the first result data undergoes state locking after data output, ensuring it is not affected by underlying data changes during the display period. When the second update event is triggered, the second result data is written to the second storage area with a periodic version identifier for version fixing, making the formal assessment result data an independent version record. Therefore, while the daily data display is refreshed frequently, it ensures that the formal assessment result data is version-fixed at the storage level and is not affected by daily write operations.

[0007] Secondly, this application provides a daily real-time performance indicator display system based on a dual-Kanban decoupled architecture, the system comprising: The storage isolation configuration module is used to configure a first storage area and a second storage area that are isolated from each other in the storage system corresponding to the performance evaluation system, and to configure an asymmetric first write control policy and a second write control policy for the first storage area and the second storage area respectively; wherein, the write permission of the first storage area is bound to the first update event, the write permission of the second storage area is bound to the second update event, and the triggering frequency of the first update event is higher than the triggering frequency of the second update event. The daily-level data processing module is used to respond to the first update event, obtain the first data set within the current unit time slice from the data source, process the first data set according to preset calculation rules to generate first result data, and write the first result data to the first storage area according to the first write control strategy; during the writing of the first result data, addressing requests to the second storage area are blocked. The data state locking module is used to lock the state of the first result data written in the first storage area after the data output is completed based on the first storage area, so that the first result data will no longer respond to changes in the underlying data in the data source before the next first update event is triggered. The periodic data solidification module is used to respond to the second update event, batch acquire the second data set according to the complete time window covered by the target period, process the second data set based on the calculation rules to generate the second result data, and write the second result data into the second storage area with the periodic version identifier for version solidification.

[0008] Thirdly, this application provides a computer storage medium that stores multiple instructions adapted for loading by a processor and executing any of the methods described above.

[0009] Fourthly, this application provides an electronic device including a processor, a memory, and a transceiver. The memory is used to store instructions, the transceiver is used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform any of the methods described above.

[0010] In summary, the beneficial effects of the technical solution of this application include: By adopting the above technical solution, a first storage area and a second storage area are configured to be isolated from each other in the storage system and bound to asymmetric write control strategies. This restricts the high-frequency write operations of the first update event to the first storage area, and during the write process, address requests to the second storage area are blocked, eliminating interference from daily write operations to the second storage area. Simultaneously, the first result data undergoes state locking after data output, ensuring it is not affected by underlying data changes during the display period. When the second update event is triggered, the second result data is written to the second storage area with a periodic version identifier for version fixing, making the formal assessment result data an independent version record. Therefore, while the daily data display is refreshed frequently, it ensures that the formal assessment result data is version-fixed at the storage level and is not affected by daily write operations. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating a method for daily real-time performance indicator display based on a dual-Kanban decoupling architecture, according to an embodiment of this application. Figure 2 This is a schematic diagram of the structure of a daily real-time performance indicator drying system based on a dual-Kanban decoupling architecture according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0012] Explanation of reference numerals in the attached drawings: 300, electronic device; 301, processor; 302, communication bus; 303, user interface; 304, network interface; 305, memory. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0014] In the description of the embodiments of this application, words such as "illustrative," "for example," or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "illustrative," "for example," or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Rather, the use of words such as "illustrative," "for example," or "for example" is intended to present the relevant concepts in a specific manner.

[0015] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0016] This application applies to a digital performance evaluation management scenario for large group enterprises. In this scenario, the enterprise needs to standardize the evaluation and supervision of the operating performance indicators of its subordinate units at all levels. The evaluation involves multiple business departments, a large number of evaluation indicators and corresponding indicator factors, and the indicator factor data is scattered across multiple business systems. Enterprises typically build a data platform to uniformly collect, clean, and aggregate the indicator factor data from various business systems. At the end of the evaluation period, the performance evaluation system reads the factor data in batches from the data platform, centrally calculates the completion value, score, and ranking of each indicator using pre-configured calculation formulas, and generates the evaluation results. Based on this, managers further propose a management need to monitor the progress and ranking trends of each unit's indicators in real time on a daily basis throughout the evaluation period.

[0017] In this scenario, the data refresh pipeline, calculation processing module, and display interface output of the existing performance appraisal system are all coupled to a single performance appraisal result storage area. If daily high-frequency data refreshes are allowed to meet process monitoring needs, each refresh will overwrite the stored historical calculation version, and confirmed performance appraisal result data will be lost and untraceable. If the refresh frequency is limited to protect the version integrity of the performance appraisal results, daily process monitoring within the performance appraisal period cannot be achieved. In other words, under the single storage area architecture, there is an irreconcilable technical conflict between the requirements of "high-frequency data updates required for process monitoring" and "version solidification and traceability required for performance appraisal results."

[0018] Please see Figure 1 This document presents a flowchart illustrating a daily real-time performance indicator (PI) disclosure method based on a dual-Kanban decoupling architecture, as provided in this application embodiment. This method can be implemented using a computer program, a microcontroller, or run on a daily real-time PI disclosure system based on a von Neumann architecture and a dual-Kanban decoupling architecture. The computer program can be integrated into the application or run as a standalone utility application. The specific steps of the daily real-time PI disclosure method based on the dual-Kanban decoupling architecture are described in detail below.

[0019] S101: Configure a first storage area and a second storage area that are isolated from each other in the storage system corresponding to the performance evaluation system, and configure an asymmetric first write control policy and a second write control policy for the first storage area and the second storage area respectively; wherein, the write permission of the first storage area is bound to the first update event, the write permission of the second storage area is bound to the second update event, and the triggering frequency of the first update event is higher than the triggering frequency of the second update event. The performance evaluation system refers to the application system used to centrally calculate, score, and display the operating performance indicators of units at various levels. The storage system refers to the data persistence infrastructure upon which the performance evaluation system relies, including but not limited to relational databases, distributed file systems, or data warehouses. The first storage area refers to the data storage area for high-frequency process monitoring scenarios, used to receive indicator calculation results data refreshed and written at daily or higher frequencies. For example, it can be used to store the daily completion values, expected scores, and ranking information of various indicators for each unit under evaluation. The second storage area refers to the data storage area for periodic evaluation result release scenarios, used to receive formal evaluation result data triggered by the evaluation cycle, and supports the fixed storage and traceability of historical versions. Mutual isolation means that the first and second storage areas are independent of each other in the data write path; a write operation on one side does not affect the data content and version status of the other. Asymmetric first and second write control strategies mean that the write permission judgment rules bound to the two storage areas are different, responding to different types of trigger events and rejecting write requests from unauthorized trigger sources. The first update event refers to a data refresh event automatically triggered at a preset high-frequency time interval; for example, its trigger frequency can be set to once per calendar day. The second update event refers to a batch data write event triggered by the arrival of a signal according to the assessment cycle, such as once a month, quarter, or year. The triggering frequency of the first update event is higher than that of the second update event, indicating that the first update event is triggered significantly more times than the second update event within the same time period.

[0020] Specifically, during the initialization phase, the system establishes two independent data storage areas on the write path within the storage system according to configuration instructions. The first storage area is configured to only receive write requests from the first update event trigger source. That is, when the daily timed refresh pipeline triggers a data write operation, the write operation can only be executed after being verified by the first write control strategy, and the written content is the indicator result data extracted and calculated on that day. The second storage area is configured to only receive write requests from the second update event trigger source. That is, when the assessment period arrives, the batch calculation results triggered by the assessment period event can be written, and the second write control strategy explicitly rejects any write requests carrying the identifier of the first update event trigger source. Through this asymmetric write control strategy configuration, the data write operations generated by the daily high-frequency refresh pipeline are strictly limited to the first storage area, and will not reach or overwrite the assessment result version already fixed in the second storage area, thereby decoupling the process monitoring data channel from the assessment result data channel at the technical architecture level.

[0021] In some embodiments, the isolation between the first storage area and the second storage area and the configuration of write control policies can be achieved in various ways: Optionally, physical isolation can be used, that is, different database instances or different database tables can be created for the first storage area and the second storage area in the storage system, an access control list that only allows daily scheduled task service accounts to write to the database table corresponding to the first storage area can be configured, an access control list that only allows assessment period triggered service accounts to write to the database table corresponding to the second storage area can be configured, and cross-table write permission interception rules can be set at the database level, so that write requests holding the first update event trigger source identifier can be blocked. When attempting to access the table corresponding to the second storage area, the database access control layer directly rejects the request. Alternatively, a logical isolation approach can be adopted, where the first and second storage areas share the same table structure within the same database. However, a data version identifier field and a storage area affiliation identifier field are added to the table, marking each data record as belonging to either the first or second storage area. Simultaneously, policy determination logic is implemented at the write interface layer. When a write request arrives, the system parses the trigger source identifier carried in the request and matches it against the pre-configured write control policy. Write operation is only allowed if the trigger source identifier matches the update event type bound to the target storage area; otherwise, a rejection response is returned. It is understood that other methods can also be used to implement isolation configuration and write permission control between the first and second storage areas, such as message routing isolation at the middleware level or policy distribution through an application-layer write proxy service; these are not limited here.

[0022] S102: In response to the first update event, obtain the first data set within the current unit time slice from the data source, process the first data set according to the preset calculation rules to generate the first result data, and write the first result data to the first storage area according to the first write control strategy; during the writing of the first result data, block addressing requests to the second storage area. The first update event refers to a data refresh event that is automatically triggered at a preset high-frequency cycle. For example, this event can be configured to be automatically triggered during a preset time period at midnight every day. The data source refers to the upstream data platform that provides indicator factor data to the performance evaluation system, such as the indicator factor summary table generated after cleaning and preprocessing in the enterprise data platform. The current unit time slice refers to the smallest time granularity period corresponding to the triggering of this first update event. For example, when the unit time slice is a natural day, it represents the latest available data slice for that day. The first data set refers to the set of factor data extracted from the data source that covers all or part of the assessed indicators, where each record contains an indicator identifier, a factor identifier, and the corresponding factor value. The preset calculation rules refer to the set of indicator evaluation calculation formulas pre-configured in the performance evaluation system, including completion value calculation rules, addition / deduction judgment rules, and score calculation rules, used to convert the raw factor data into the indicator's completion value, expected score, and ranking. The first result data refers to the daily indicator calculation result generated based on the first data set after processing by the preset calculation rules, where each record contains fields such as indicator identifier, the unit to which it belongs, the daily completion value, the daily expected score, and the daily ranking position. Targeted write means that the target address of the write operation is explicitly limited to the first storage area and does not involve other storage areas.

[0023] Specifically, when the preset daily timed trigger conditions are met, the system automatically initiates the first update event, which drives the data refresh pipeline to start execution. The pipeline first extracts the latest indicator factor data that has been synchronized and preprocessed by each business system within the current unit time slice from the indicator factor summary table of the data source, forming the first data set. Subsequently, the system groups the first data set according to indicator identifiers, substitutes the factor data within each indicator group into the pre-configured calculation formula for that indicator, and the formula execution module parses and executes the calculation. The calculation process includes: substituting factor values ​​into the formula to obtain the daily completion value of the indicator according to the completion value calculation rules; judging the deviation between the completion value and the target value or benchmark value according to the scoring rules and calculating the addition or subtraction values; combining the completion value and the addition or subtraction values ​​according to the scoring rules to obtain the expected score; and determining the ranking position by horizontally comparing the expected scores of each assessed unit for the same indicator. There are no data dependencies between the indicators, allowing for independent parallel calculation to improve processing efficiency. After the calculation is completed, the system collects the first result data of all indicators, and verifies that the trigger source identifier of this write operation is the first update event according to the first write control strategy. Then, the first result data is written to the first storage area with the date as the data identifier. During the entire write operation, the system explicitly limits the addressing range to the first storage area and does not initiate any read or write addressing requests to the second storage area, so that the version of the assessment result data that has been fixed in the second storage area remains completely consistent before and after this operation.

[0024] In some embodiments, the process of obtaining the first dataset from the data source and completing the calculation and writing can be implemented in several ways: Optionally, it can be implemented by configuring a timed cascaded data refresh pipeline, which includes at least two sequentially triggered task nodes. The first task node is responsible for extracting the latest indicator factor data of the day from the data source at a preset time and caching it to a temporary work area. The second task node starts after the data ready signal of the first task node is confirmed and calls the formula execution module to perform parallel calculations on each indicator factor data group to generate the first result data. After the calculation is completed, the writing module injects the result into the first storage area according to the first writing control strategy. Optionally, it can be implemented by an event-driven message queue architecture, that is, after the data source completes the daily factor data update, it publishes a data ready message to the message queue. The performance evaluation system subscribes to the message as the trigger signal for the first update event. After receiving the message, it starts the factor data retrieval task to obtain the first data set from the data source, and then pushes the first data set to the computing service cluster for distributed parallel calculation to generate the first result data. Finally, the writing service completes the targeted writing to the first storage area according to the writing control strategy and confirms that the second storage area is not addressed. It is understandable that other methods can be used to orchestrate the data extraction, computation, and targeted writing processes, such as scheduling through a workflow engine or unified management through a batch processing framework; this is not limited here.

[0025] S103: After the data output is completed based on the first storage area, the state lock is performed on the first result data written in the first storage area this time, so that the first result data will no longer respond to changes in the underlying data in the data source before the next first update event is triggered; Specifically, "Data output based on the first storage area" refers to the process where the system reads the first result data written that day from the first storage area and renders it into a user-facing interface using a preset view template. For example, it generates a daily dimension dashboard display page with the assessed unit as the row and the indicator as the column. "State locking" refers to setting an immutable or frozen flag on the first result data written that day in the first storage area, preventing this batch of data from responding to any incremental changes or overwrite requests from the data source during the locking period. "Before the next first update event triggers" refers to the time interval from the moment this state lock takes effect until the moment the first update event on the next natural day is triggered again and a new round of data refresh and writing is completed. "No longer responding to changes in the underlying data in the data source" means that during the locking period, even if the indicator factor data in the data source is updated or corrected, the locked first result data in the first storage area will not be recalculated or overwritten. All users will see the same data version when accessing the display interface corresponding to the first storage area during this time interval.

[0026] Specifically, after step S102 completes the writing of the first result data and the system reads the data for view rendering output, the system performs a state locking operation on the batch of data in the first storage area, identified by the current date. After locking, the batch of data enters a static display state, and no further data refresh, writing, or overwriting operations are accepted for the rest of the day. Even if the underlying factor data in the data source changes during subsequent periods of the day (for example, a business system performs data correction and re-upload during the day), these changes will not trigger the recalculation and update of the locked data in the first storage area. The system will only release the locking state of the previous day's data when the next first update event is triggered, execute a new round of data extraction, calculation, and writing processes, and re-lock the newly written data, forming a daily cycle.

[0027] In some embodiments, the state locking of the first result data can be implemented in several ways: Optionally, it can be achieved by setting a status flag field for each batch of data records written in the data table of the first storage area. When the data writing is completed and the view is rendered and output, the system updates the status flag field of the batch of records from "writable" to "frozen". Any subsequent write request checks the status flag of the target record before execution. If it is "frozen", the write operation is rejected until the next first update event is triggered. The system then resets the status flag of the old record or archives the old record before writing the new data. Optionally, it can be achieved by setting time window control logic at the write interface layer. That is, the system maintains a write completion timestamp for the current day. Within the time window after this timestamp and before the next first update event is triggered, the write interface returns a rejection response to all write requests for the data of the current day in the first storage area, thereby achieving the locking effect at the interface level without modifying the field status of the underlying data records. It is understood that other methods can also be used to implement the state locking mechanism, such as through row-level locking in the database or by migrating the locked data to a read-only copy, etc., which are not limited here.

[0028] S104: In response to the second update event, the second data set is obtained in batches according to the complete time window covered by the target period, the second data set is processed based on the calculation rules to generate the second result data, and the second result data is written to the second storage area with the period version identifier for version fixation.

[0029] Specifically, when the assessment period arrives, the system triggers a second update event. Unlike step S102, which only extracts data from a single time slice of the day, this step extracts batch data from the data source according to the complete time window covered by the target period, obtaining all indicator factor data for all target dates within the period, forming a second data set. Subsequently, the system processes the second data set based on the same preset calculation rules as step S102, but its calculation method is fundamentally different from the daily calculation: the daily calculation only generates estimated results based on single-day data slices, while the formal assessment calculation in this step is based on the summary calculation of all factor data within the complete time window of the assessment period. For example, it performs summary processing such as accumulating, averaging, or taking the final value of the factor values ​​for each day within the period before substituting them into the calculation formula, thereby generating second result data such as the formal assessment score, details of addition and subtraction, and final ranking covering the entire assessment period. After the calculation is completed, the system adds a period version identifier containing the period start and end time and the period identifier to the second result data. After verifying that the trigger source of this write operation is the second update event according to the second write control strategy, the second result data with the period version identifier is written to the second storage area for version fixation.

[0030] In some embodiments, the response to the second update event and the version solidification of the second result data can be implemented in several ways: Optionally, it can be implemented through a timed triggering mechanism based on a periodic calendar. That is, the system pre-configures an assessment period calendar table. When the system date reaches the end date of the period marked in the calendar table, a second update event signal is automatically generated. Subsequently, a batch extraction task independent of the daily pipeline is started to obtain the second data set from the data source according to the complete time window. An independent assessment calculation module performs summary calculation to generate the second result data. Finally, the result is written to the second storage area with the period identifier as the primary key, and the record is marked as a solidified version to prevent subsequent overwriting. Optionally, it can be implemented through a combination of manual triggering by management personnel and system confirmation. That is, after the assessment period ends and the data verification is completed, the authorized management personnel initiate an assessment result generation command on the system interface as the trigger signal for the second update event. After receiving the command, the system extracts all factor data from the data source in batches according to the start and end time range of the period and performs formal calculation. After the calculation result is confirmed online by the management personnel, a period version identifier is attached and written to the second storage area and version locking is performed. After locking, the version data can only support read and trace query operations. It is understandable that other methods can be used to trigger the second update event and write the version fixation process, such as through an approval flow engine or through automatic execution after multi-level confirmation, which is not limited here.

[0031] Based on the above embodiments, as an optional implementation method, in S101, a first storage area and a second storage area that are isolated from each other are configured in the storage system corresponding to the performance evaluation system, and an asymmetric first write control strategy and a second write control strategy are configured for the first storage area and the second storage area respectively. This can be specifically implemented through the following steps S201-S204.

[0032] S201: Based on the preset isolation mode configuration parameters, establish a first storage area and a second storage area in the storage system using either physical isolation or logical isolation. Physical isolation involves deploying the first and second storage areas in different database instances or different data tables. Logical isolation involves deploying the first and second storage areas in the same database and distinguishing the data belonging to the first and second storage areas using a data version identifier field. The isolation mode configuration parameters are configuration items pre-set during system initialization to specify the isolation method used between the first and second storage areas. Physical isolation means deploying the two storage areas in separate database instances or separate tables, making them independent at the storage media level and preventing them from sharing tablespaces. Logical isolation means storing data from both storage areas in the same database within the same one or more tables, distinguishing records belonging to either the first or second storage area by attaching a data version identifier field to each record. The data version identifier field is an identifier field attached to each data record, used to mark the storage area to which the record belongs. For example, a field value of "daily" indicates daily calculation results belonging to the first storage area, while a field value of "manual" indicates manually corrected results belonging to the second storage area.

[0033] Specifically, this step is executed during the system initialization phase. Based on the isolation mode configuration parameters, a first storage area and a second storage area are established in the storage system. When the isolation mode configuration parameters are specified as physical isolation, the system creates two independent storage structures in the storage system. For example, two independent data tables are created on the same database server, or separate data tables are created in different database instances. The first and second storage areas each have independent table structures and storage space, and read / write operations in either storage area do not affect the data files in the other. When the isolation mode configuration parameters are specified as logical isolation, the system adds a data version identifier field to the data tables in the same database. All data records are stored in the same table, and the different values ​​of the data version identifier field distinguish the ownership of each record. For example, for the same indicator of the same assessed unit, the data version identifier field of the score record written by daily automatic calculation is "daily," while the data version identifier field of the score record written by manual correction is "manual." When reading, the system filters the data in the corresponding storage area based on this field value.

[0034] S202: Configure the first write control policy on the write interface of the first storage area. The first write control policy includes: binding the write permission of the first storage area to the trigger source identifier corresponding to the first update event, so that the first storage area only receives write requests carrying the trigger source identifier of the first update event. The write interface refers to the unified entry point exposed by the storage area for receiving data write operations. All requests to write data to this storage area must be verified and forwarded through this interface. The trigger source identifier is the source tag information attached to each write request, used to uniquely indicate which type of update event initiated the write request. For example, the trigger source identifier for the first update event is "AUTO_DAILY", and the trigger source identifier for the second update event is "MANUAL_MODIFY".

[0035] Specifically, this step configures access control for the write interface of the first storage area after its establishment. The system registers the first write control policy with the write interface of the first storage area. The core rule of this policy is to establish a one-to-one binding relationship between the write permissions of the first storage area and the trigger source identifier of the first update event. After the configuration takes effect, when the write interface of the first storage area receives any write request, it first reads the trigger source identifier carried by the request and determines whether it is consistent with the trigger source identifier of the first update event. If they are consistent, the request passes the permission verification and the write operation is executed normally; if they are inconsistent, the request is directly intercepted by the write interface, and the data is not written to the first storage area. Through this binding mechanism, the first storage area only allows the writing of daily calculation results automatically generated by the timed cascaded data refresh pipeline; any write operation not initiated by the first update event is excluded.

[0036] S203: Configure the second write control policy on the write interface of the second storage area. The second write control policy includes: binding the write permission of the second storage area to the trigger source identifier corresponding to the second update event, and rejecting write requests that carry the trigger source identifier of the first update event. Specifically, this step configures access control for the write interface of the second storage area. The configuration method is consistent with the structure of the first write control policy, but the binding objects are reversed. The system registers the second write control policy with the write interface of the second storage area. This policy contains two rules: the first rule is an allow rule, binding the write permission of the second storage area to the trigger source identifier of the second update event. Write operations are only allowed when the trigger source identifier carried by the write request matches the trigger source identifier of the second update event. The second rule is a deny rule, explicitly denying write requests carrying the trigger source identifier of the first update event. The combined effect of the two rules is that the second storage area only accepts write requests generated by the second update event triggered by manual correction operations, while daily calculation results automatically triggered by the timed cascaded data refresh pipeline cannot be written to the second storage area. For example, when a timed task initiates a write request to the second storage area after completing daily calculations, the trigger source identifier carried by this request is "AUTO_DAILY". The second write control policy recognizes this and denies the request, ensuring that the daily automatic calculation results will not overwrite or be mixed with manually corrected data.

[0037] S204: When the first storage area or the second storage area is addressed, the trigger source identifier carried by this write request is matched with the first write control policy and the second write control policy respectively, and the write request is allowed or blocked according to the matching result.

[0038] Specifically, this step describes the actual verification and execution process when each write request arrives at the storage area during the runtime phase. When any write request points to the first or second storage area, the storage system first determines the target storage area addressed by the request, and then extracts the trigger source identifier carried in the request header or request parameters. If the target storage area is the first storage area, the extracted trigger source identifier is compared with the trigger source identifier bound in the first write control policy. If they match, the write operation is allowed; otherwise, the request is blocked and a rejection response is returned. If the target storage area is the second storage area, the trigger source identifier is compared with the trigger source identifier bound in the second write control policy, and it is checked whether the identifier belongs to the explicit rejection list. If the comparison passes and the identifier is not in the rejection list, the write operation is allowed; otherwise, it is blocked. This matching and verification process is automatically executed every time a write request arrives, thereby continuously ensuring data write isolation between the first and second storage areas during the runtime phase and preventing data from different sources from being written to the wrong storage area.

[0039] Based on the above embodiments, the method further includes the following for addressing the masking write requirement in S102: When the first update event is triggered, the addressing range of this write operation is limited to the first storage area, and the storage address of the second storage area is not included in the addressing list of this write operation; during the execution of the write operation of the first result data, any write request that is triggered by the first update event and targets the second storage area is rejected; after the first result data is written, the data content and data version of the second storage area remain unchanged from the state before the write operation was initiated.

[0040] The addressing range refers to the set of storage areas that a single write operation is allowed to access during execution. The write operation can only perform data writing within the storage areas contained in this set. The addressing list is a list of target storage addresses generated by the system when a write operation is initiated. This list explicitly lists all storage area addresses targeted by this write operation. For example, if the addressing list only contains the table address of the first storage area, the data to be written to disk by the write operation will only target the data table corresponding to the first storage area. The data version refers to the version number or version timestamp corresponding to the data record in the storage area. The data version is updated after each successful data write operation, used to identify the update status of the data record. For example, if the data version is "V3" before the write operation is executed, the data version changes to "V4" after successful execution.

[0041] Specifically, this step performs an addressing range limitation operation at the moment the first update event is triggered. When the first update event is triggered, the system generates the addressing list for this write operation, writing only the storage address of the first storage area to the list, excluding the storage address of the second storage area. This limitation operation is completed before the actual write operation, meaning the second storage area is excluded during the addressing list generation phase. This is achieved by hard-coding or binding the write target parameter to the storage address of the first storage area through configuration mapping in the event handling logic of the first update event, without adding an address entry for the second storage area to the addressing list. Therefore, when the write operation subsequently performs data write to disk, it cannot obtain the address information of the second storage area from the addressing list, and the write operation is completely isolated from the second storage area at the physical path level.

[0042] The previous step excluded addresses of the second storage area from the source through the addressing list generation rules. This step sets up interception checks during the execution phase of the write operation to prevent write requests to the second storage area from bypassing the addressing list restrictions due to abnormal calls, concurrent tasks, or program errors during execution. During the execution of the write operation of the first result data, if the storage system receives a write request, and the trigger source identifier carried by the request matches the identifier corresponding to the first update event, and the target address of the request points to the second storage area, then the storage system's write interface directly rejects the request and returns a rejection response; the data is not written to the second storage area. This rejection is based on the simultaneous fulfillment of two conditions: first, the trigger source identifier matches the first update event; and second, the write target address matches the second storage area. Rejection is executed when both conditions are met, thus forming dual write isolation protection for the second storage area during runtime.

[0043] After the first result data is written, the data content in the second storage area remains completely consistent with that before the write operation was initiated; no records have been added, modified, or deleted. Simultaneously, the data version number or version timestamp in the second storage area remains consistent with that before the write operation, with no version increment or update. This unchanged state ensures that data written by manual correction operations in the second storage area will not be overwritten, tampered with, or generate dirty data due to the daily automatic calculation write operation triggered by the first update event, thus maintaining the integrity and independence of the data in the second storage area.

[0044] Based on the above embodiments, as an optional implementation method, the method of obtaining the first data set within the current unit time slice from the data source in response to the first update event in S102, and processing the first data set based on preset calculation rules to generate the first result data can be specifically implemented through the following steps S301-S303.

[0045] S301: A timed cascaded data refresh pipeline covering the data source to the first storage area is pre-configured in the performance appraisal system. The timed cascaded data refresh pipeline includes a first task node and a second task node that are triggered sequentially at a preset time interval, and a buffer time window is set between the first task node and the second task node. The timed cascading data refresh pipeline refers to an automated data processing link pre-configured in the performance evaluation system, consisting of multiple task nodes connected in a fixed sequence. The first task node is the starting execution node in the pipeline responsible for extracting indicator factor data from the data source. The second task node is the execution node located after the first task node, responsible for performing calculations on the extracted data. The buffer time window is a fixed waiting time interval reserved between the completion of the first task node and the start of the second task node.

[0046] Specifically, this step is executed during the system deployment or initial configuration phase, establishing an automated execution chain for subsequent daily data updates. The system pre-configures a complete data processing pipeline from the data source to the first storage area within the performance evaluation system. This pipeline consists of a first task node and a second task node connected in series, with a buffer time window between the two nodes. The first task node is responsible for data extraction, starting first when the first update event is triggered, extracting the latest indicator factor data from the data source to the system's internal temporary workspace. The second task node is responsible for calculation and processing, starting after the first task node completes and waiting for the buffer time window before starting, performing calculations on the data in the temporary workspace and writing the results to the first storage area. The buffer time window provides sufficient time for the first task node to write the data to disk, ensuring that the data read by the second task node is complete and consistent when it starts. For example, if the first task node is configured to start data extraction at 2:00 AM daily, and the buffer time window is set to 30 minutes, then the second task node will automatically start calculation and processing at 2:30 AM.

[0047] S302: When the first update event triggers the timed cascaded data refresh pipeline at a preset time, the first task node extracts the first set of preprocessed data within the current unit time slice from the data source; Specifically, when the system clock reaches a preset time, the first update event is triggered, and the timed cascading data refresh pipeline is immediately started. The pipeline first activates the first task node. The first task node, according to the pre-configured data source connection information and extraction rules, initiates an extraction request to the factor summary table of the data source through the data interface. The extraction scope is limited to the indicator factor data within the current unit time slice. The first task node only extracts factor records from the data source that have undergone data cleaning, format standardization, and validity verification by the upstream business system; that is, it only reads data that has passed preprocessing quality inspection marking. After extraction, the first task node writes all qualified factor records into the system's internal temporary workspace, forming the first data set. For example, in a scenario where the time slice is based on a natural day, the first task node reads all indicator factor records marked as valid up to midnight of that day from the factor summary table of the data platform at 2:00 AM each day. This includes the factor values ​​corresponding to each indicator of each assessed unit, and writes them to the temporary workspace for subsequent calculation and processing.

[0048] S303: After the buffer time window expires and the data ready state of the first task node is established, the second task node is started. The second task node groups the first data set according to the object identifier according to the preset calculation rules and performs calculations independently and in parallel on each group to obtain the first result data.

[0049] The "data ready" status refers to the successful execution confirmation status returned after the first task node has completed all data extraction operations and the extraction results have been completely written to the temporary workspace. The object identifier refers to the identification information used to uniquely distinguish each assessed unit, such as the unit code of each subordinate enterprise.

[0050] Specifically, this step is executed after the buffer window expires, and is conditional upon the data readiness status of the first task node. When the buffer window expires, the system checks whether the first task node has returned a success signal and confirms that the data has been completely written to disk. If both conditions are met, the second task node is started. If the buffer window expires but the data readiness status is not met, the second task node waits until the data readiness status is confirmed before starting. After the second task node starts, it reads the first data set from the temporary workspace, groups the data according to the object identifier, and groups all indicator factor data belonging to the same assessed unit into the same calculation group. After grouping, there is no data dependency between the calculation groups. The second task node performs calculations independently and in parallel for each group, that is, it simultaneously substitutes the indicator data of multiple assessed units into the preset calculation rules for calculation. Within each calculation group, the system sequentially substitutes the factor data of each indicator into the corresponding calculation rules to calculate the daily completion value and expected score of each indicator for that unit. Then, it horizontally sorts the units according to the expected scores of the same indicator to determine the daily ranking position. After all calculation groups are completed, the results of each group are summarized to form the first result data. For example, for the thirty assessed units under the group, the second task node divides the first data set into thirty calculation groups according to the unit code. The thirty calculation groups simultaneously perform the completion value and score calculation of their respective indicators, and finally summarize them into the first result data containing the calculation results of all indicators of all units.

[0051] Based on the above embodiments, the method further includes the following steps for generating the first result data in S102: In the process of generating the first result data in response to the first update event, for each indicator result in the first result data, the original values ​​of each data factor on which the indicator depends, the intermediate variables substituted into the calculation process according to the preset calculation rules, and the data source information of each data factor are collected synchronously to form a calculation process record bound to the indicator result. The calculation process record is written into the first storage area along with the first result data, and the association between the calculation process record and the corresponding indicator result is established. In response to a traceability request for any indicator result in the first result data, the corresponding calculation process record is read from the first storage area according to the correlation relationship, and presented layer by layer in the order of the original value of the data factor, the calculation rule substitution process, and the data factor collection link from the data source to the first storage area.

[0052] In this context, "index result" refers to each independent calculated output item in the first result data. Each index result corresponds to a specific business indicator calculation value. For example, in a power load forecasting scenario, the predicted load value for a certain day is an index result. "Data factor" refers to the various input data elements involved in the calculation of an index result. The calculation of an index result depends on the values ​​of one or more data factors. For example, the historical load values, temperature data, and humidity data used to calculate the predicted load value each constitute independent data factors. "Raw value" refers to the unprocessed initial value of the data factor obtained directly from the data source before being substituted into the calculation rules. "Intermediate variable" refers to the transitional calculated value that is not the final result generated during the execution of the preset calculation rules. For example, in a multi-step calculation, the output of the first step is used as the input of the second step; the output value of the first step is an intermediate variable. Data source information describes the origin of each data factor, including the data source name, table name, field name, and data acquisition time. For example, the data source information for a certain data factor might be recorded as "Data source: meteorological database, table name: daily temperature report, field: average daily temperature, acquisition time: 00:10 on a certain day of a certain month of a certain year." The calculation process record is a complete set of records that aggregates the original values, intermediate variables, and data source information of the aforementioned data factors. This set of records is bound to its corresponding indicator result and stored to fully reconstruct the generation process of the indicator result. The acquisition path refers to the complete transmission path of the data factor from the original data source through intermediate processing stages to the first storage area. This path records the flow trajectory of the data factor at each node. For example, the acquisition path for a certain temperature data factor might be "meteorological database daily temperature report → data acquisition interface → data cleaning module → first storage area indicator calculation input table." This path indicates that after the data factor is collected from the meteorological database, it is transmitted through the data acquisition interface, processed by the data cleaning module, and finally written into the indicator calculation input table in the first storage area.

[0053] Specifically, this step is executed synchronously during the generation of the first result data triggered by the first update event. That is, the collection of the calculation process record and the calculation of the indicator result occur simultaneously, rather than retrospectively collecting data after the indicator result calculation is completed. The implementation method is as follows: a process record collection module is embedded in the execution engine of the preset calculation rules. When the execution engine reads the value of a data factor from the data source, the process record collection module synchronously records the original value of that data factor and its data source information. When the execution engine completes a calculation step and generates an intermediate variable, the process record collection module synchronously captures the value of that intermediate variable and the calculation step number it belongs to. After the complete calculation process of an indicator result is completed, the process record collection module encapsulates all the original values ​​of all data factors, all the values ​​of all intermediate variables, and all the data source information collected in this calculation into a calculation process record, and binds and marks this record with the indicator result of this calculation. The marking method is to write a unique identifier of the indicator result into the calculation process record.

[0054] The write operation writes the first result data and the calculation process record together in the first storage area within the same write transaction, ensuring the atomicity of both write operations. This means that both writes succeed simultaneously or fail simultaneously, preventing situations where the indicator result is written but the calculation process record is missing. The relationship is established by setting a common association key field for the indicator result table and the calculation process record table in the first storage area. This association key field stores the unique identifier value of the indicator result. Each record in the indicator result table forms a one-to-one or one-to-many mapping relationship with records in the calculation process record table that carry the same association key value. For example, if the unique identifier of a record in the indicator result table is "IR-20240110-001", then all records in the calculation process record table with the association key field value of "IR-20240110-001" are the corresponding calculation process records for that indicator result. After this relationship is written, when performing a traceback query on any indicator result, the value of the association key field can accurately locate all the corresponding process data in the calculation process record table.

[0055] The storage system extracts the unique identifier of the indicator result to be traced from the traceability request. Using this unique identifier as the association key query value, it searches the calculation process record table in the first storage area for all records with the same association key field value, and reads the matching calculation process record. After reading, it unfolds and presents the results in three layers: The first layer unfolds and presents the original value layer of the data factors, listing the original values ​​of all data factors on which the indicator result depends, showing the initial value of each data factor before being substituted into the calculation; the second layer unfolds and presents the calculation rule substitution process layer, showing the execution steps of the preset calculation rules in sequence, including the specific location where the original values ​​of each data factor are substituted into the calculation rules and the intermediate variable values ​​generated by each calculation step, restoring the complete calculation chain from input data to output indicator result; the third layer unfolds and presents the acquisition link layer, showing the complete flow path of each data factor from the original data source to the first storage area and the processing operations of each node, enabling the initiator of the traceability request to confirm the authenticity of the source and the integrity of the transmission of each data factor.

[0056] Specifically, the methods for evaluating the data from the first and second storage areas also include: The data interface maps the first result data in the first storage area to the daily dimension dashboard view. In response to the user's access request to the daily dimension dashboard view, it returns the indicator completion value, expected score and ranking data of each assessed unit within the current unit time slice. The data interface maps the second result data in the second storage area to the assessment dimension dashboard view. In response to the user's access request to the assessment dimension dashboard view, it returns the official assessment result data of each assessed unit corresponding to the target period. The write operation triggered by the first update event does not affect the second storage area. The data refresh in the first storage area within subsequent unit time slices does not change the second result data already written in the second storage area. The assessment result data presented in the assessment dimension dashboard view remains unchanged from the version written by the second update event.

[0057] The daily-dimensional dashboard view is a front-end visualization page that displays data at a unit time slice granularity. This page presents real-time dynamic assessment data for each assessed unit with a daily minimum display period. The data interface refers to the data communication channel between the dashboard view and the storage area. The dashboard view retrieves data from the storage area by calling this interface; for example, the daily-dimensional dashboard view reads the first result data by calling the data interface of the first storage area. The indicator completion value refers to the actual achievement value of a specific assessment indicator for an assessed unit within the current unit time slice. For example, if a power supply unit's actual calculated line loss rate on a certain day is 3.2%, this value is the indicator completion value. The expected score refers to the score value of the assessed unit within the current unit time slice, calculated based on the indicator completion value and preset scoring rules. The ranking data refers to the position of each assessed unit after arranging the expected scores of all assessed units within the current unit time slice in descending order.

[0058] The assessment dimension dashboard view is a front-end visualization page that displays data with the target period as the time granularity. This page presents the official assessment results of each assessed unit after manual correction, using the assessment period as the display unit. For example, it displays the official assessment results of each unit on a monthly or ten-day period. The official assessment result data refers to the final assessment data written to the second storage area after confirmation through manual correction. This data serves as the official assessment basis for each assessed unit within the target period, and is distinct from the estimated data that is updated daily in the first storage area.

[0059] Specifically, this step establishes a data mapping relationship between the first result data in the first storage area and the daily dimension dashboard view. The implementation is as follows: In the data interface configuration of the daily dimension dashboard view, the target data source for data queries is specified as the first storage area. A field-level mapping is established between the query parameters of the interface and the table structure fields of the first result data in the first storage area. That is, the "Indicator Completion Value" field displayed in the dashboard view is mapped to the indicator calculation result field in the first result data table, the "Expected Score" field is mapped to the scoring result field in the first result data table, and the "Rank Data" field is mapped to the position field generated after sorting by the expected score in descending order. When a user initiates an access request to the daily dimension dashboard view, the data interface uses the time identifier of the current unit time slice as the query condition, retrieves the first result data of all assessed units corresponding to the current unit time slice from the first storage area, encapsulates the indicator completion value, expected score, and ranking data of each assessed unit into response data, and returns it to the daily dimension dashboard view for rendering and display. Since the first result data in the first storage area is updated with each triggering of the first update event, the data displayed in the daily dimension dashboard view always reflects the latest daily automatic calculation results.

[0060] In the data interface configuration of the assessment dimension dashboard view, the target data source for data queries is specified as the second storage area, and a mapping relationship is established between the period identifier field in the query parameters of the interface and the period version identifier field of the second result data in the second storage area. When a user initiates an access request to the assessment dimension dashboard view, the data interface obtains the period identifier of the target period selected by the user from the request parameters. Using this period identifier as the query condition, it retrieves the second result data of all assessed units corresponding to the target period from the second storage area, and encapsulates the official assessment indicator values, official scores, and official rankings of each assessed unit into response data and returns it to the assessment dimension dashboard view for rendering and display. The data displayed in this view comes from the second storage area and is completely independent of the data in the first storage area, ensuring that the user sees the official assessment results that have been manually corrected and confirmed in the assessment dimension dashboard view.

[0061] At the data level, the addressing range of the write operation triggered by the first update event is limited to the first storage area. The second storage area is not in the addressing list of this write operation. Therefore, any write operation generated by the first update event cannot reach the second storage area. At the time level, when the first storage area is refreshed in a subsequent unit time slice due to a new first update event, this refresh operation only updates the first result data in the first storage area. The data content and version of the second result data already written in the second storage area remain unaffected. The resulting effect is that the data displayed in the daily dashboard view changes synchronously with the data refresh in the first storage area, reflecting the latest daily calculation results; while the data displayed in the assessment dashboard view always reads the second result data in the second storage area. The version of this data is fixed to the version written during the second update event and does not change due to any subsequent data refresh operations in the first storage area. The data sources of the two dashboard views are physically isolated from each other, ensuring that frequent updates of daily forecast data do not interfere with the stable display of formal assessment result data.

[0062] Based on the above embodiments, as an optional implementation method, step S104, which writes the second result data into the second storage area with a periodic version identifier for version solidification, specifically includes steps S401-S403.

[0063] S401: After the second result data is generated, add metadata fields including the start and end timestamps of the target period and the period identifier to the second result data to form a period version identifier; The target period refers to the specific time interval targeted by this manual correction operation. This interval has a clearly defined start and end time. For example, when a manual correction operation is performed on data from the first ten days of a month, that first ten days of the month is the target period for this operation. The period start and end timestamps are the precise timestamps corresponding to the start and end times of the target period. For example, the start timestamp is 00:00:00 on the first day of a certain month and year, and the end timestamp is 23:59:59 on the tenth day of a certain month and year. The period identifier is a unique code assigned to the target period to distinguish different periods, for example, represented as "P-202401-A". Metadata fields are fields attached to data records to describe the record's attribute information. They do not constitute business data content themselves, but rather mark attributes such as the data record's ownership, source, and time range. The period version identifier is a composite identifier composed of the period start and end timestamps and the period identifier, used to uniquely determine the period to which a second result data belongs and its version information.

[0064] Specifically, this step performs metadata appending immediately after the second result data is generated. A new metadata field is added to the data record of the second result data, writing the start and end timestamps of the target period into the corresponding fields, and simultaneously writing the period identifier of the target period into the period identifier field. The values ​​of these three fields together constitute the period version identifier of this second result data entry. The implementation is as follows: three metadata fields are preset in the data structure definition of the second result data: "period_start_ts", "period_end_ts", and "period_id". In the final step of the data generation stage, the data writing module extracts the start and end timestamps and period identifier values ​​of the target period from the request parameters of this manual correction operation and fills them into the above three fields. After filling, this second result data entry carries a complete period version identifier, which is used to locate and distinguish correction data of different periods in subsequent storage, retrieval, and tracing stages.

[0065] S402: Write the second result data with the attached periodic version identifier to the second storage area, and prevent the write operation triggered by the first update event from overwriting or deleting the second result data with the historical periodic version identifier already written in the second storage area; The historical cycle version identifier refers to the cycle version identifier carried by the second result data that was stored in the second storage area before the current write operation was initiated. These identifiers correspond to the correction cycles that have been completed in the past. For example, if the cycle identifier of the current write operation is "P-202402-A", then the cycle version identifier carried by the record with the cycle identifier "P-202401-A" that already exists in the second storage area is the historical cycle version identifier.

[0066] Specifically, this step includes two operations: writing and protection. The write operation appends the second result data, carrying the periodic version identifier, to the second storage area. This means adding the current data record after the existing data record in the second storage area, without replacing existing records. The protection operation takes effect when the daily automatic calculation write operation triggered by the first update event is executed. Specifically, a write protection rule is set in the write interface of the second storage area. When the trigger source identifier of the write request is the first update event, the write interface checks the periodic version identifier field of each existing data record in the second storage area. If the periodic version identifier field of the target record is not empty, the record is determined to be historical periodic correction data. The write interface refuses to perform overwrite or deletion operations on this record and returns a protection interception response. Therefore, the second result data for each historical period in the second storage area is completely preserved and not lost due to subsequent daily automatic calculation write operations.

[0067] S403: In response to an external traceability request, locate the second result data corresponding to the period version identifier from the second storage area according to the period identifier specified in the traceability request and return it.

[0068] An external traceability request refers to a data query request initiated by an external user or external caller. The purpose of this request is to obtain the correction result data within a specific historical period. The request content includes the period identifier of the target period to be traced. For example, an external user submits a traceability request through a data query interface, and the period identifier is specified as "P-202401-A" in the request parameters, indicating that the correction data corresponding to that period needs to be obtained.

[0069] Specifically, this step is triggered when the storage system receives an external traceability request. The storage system extracts the period identifier value from the request parameters of the traceability request and uses this period identifier value as a query condition to search and match data records in the second storage area. The search method is as follows: traverse the metadata fields of all data records in the second storage area, compare the period identifier field value of each record with the period identifier value specified in the traceability request, and when the two match, the record is the target record. After locating the target record, the storage system encapsulates the complete data content of the record (including business data fields and metadata fields) into response data and returns it to the initiator of the traceability request. If multiple records in the second storage area have period identifiers that match the value specified in the request, all matching records are returned as a result set to ensure that the traceability results cover all corrected data within that period.

[0070] Please see Figure 2This illustration shows a schematic diagram of a daily real-time performance indicator monitoring system based on a dual-Kanban decoupling architecture, provided in an exemplary embodiment of this application. This system can be implemented as all or part of a larger system through software, hardware, or a combination of both. The daily real-time performance indicator monitoring system based on a dual-Kanban decoupling architecture includes: The storage isolation configuration module is used to configure a first storage area and a second storage area that are isolated from each other in the storage system corresponding to the performance evaluation system, and to configure an asymmetric first write control policy and a second write control policy for the first storage area and the second storage area respectively; wherein, the write permission of the first storage area is bound to the first update event, the write permission of the second storage area is bound to the second update event, and the triggering frequency of the first update event is higher than the triggering frequency of the second update event. The daily-level data processing module is used to respond to the first update event, obtain the first data set within the current unit time slice from the data source, process the first data set according to preset calculation rules to generate first result data, and write the first result data to the first storage area according to the first write control strategy; during the writing of the first result data, addressing requests to the second storage area are blocked. The data state locking module is used to lock the state of the first result data written in the first storage area after the data output is completed based on the first storage area, so that the first result data will no longer respond to changes in the underlying data in the data source before the next first update event is triggered. The periodic data solidification module is used to respond to the second update event, batch acquire the second data set according to the complete time window covered by the target period, process the second data set based on the calculation rules to generate the second result data, and write the second result data into the second storage area with the periodic version identifier for version solidification.

[0071] This application also provides a computer storage medium that can store multiple instructions. The instructions are adapted to be loaded and executed by a processor as described above for the daily real-time performance indicator display method based on a dual-Kanban decoupling architecture. For the specific execution process, please refer to the detailed description of the embodiments, which will not be repeated here.

[0072] Please see Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 3 As shown, the electronic device 300 may include: at least one processor 301, at least one network interface 304, user interface 303, memory 305, and at least one communication bus 302.

[0073] The communication bus 302 is used to enable communication between these components.

[0074] The user interface 303 may include a display screen and a camera.

[0075] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0076] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 305, and by calling data stored in the memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of digital signal processing, field-programmable gate array, or programmable logic array. The processor 301 may integrate one or more of the following: a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.

[0077] The memory 305 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 305 may include a non-transitory computer-readable medium. The memory 305 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data involved in the various method embodiments described above, etc. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned processor 301. Figure 3 As shown, the memory 305, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for a daily real-time performance indicator display method based on a dual-Kanban decoupling architecture.

[0078] exist Figure 3 In the electronic device 300 shown, the user interface 303 is mainly used to provide an input interface for the user and obtain the user input data; while the processor 301 can be used to call the application stored in the memory 305, which is a daily real-time performance indicator drying method based on a dual Kanban decoupling architecture. When executed by one or more processors, the electronic device executes one or more methods as described in the above embodiments.

[0079] An electronic device readable storage medium stores instructions that, when executed by one or more processors, cause the electronic device to perform one or more methods as described in the above embodiments.

[0080] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0081] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0082] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0083] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0084] The above are merely exemplary embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and practical application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure.

Claims

1. A method for daily real-time display of performance indicators based on a dual-Kanban decoupled architecture, characterized in that, The method, applied to a performance appraisal system, includes: In the storage system corresponding to the performance evaluation system, a first storage area and a second storage area are configured to be isolated from each other, and an asymmetric first write control policy and a second write control policy are configured for the first storage area and the second storage area respectively; wherein, the write permission of the first storage area is bound to a first update event, the write permission of the second storage area is bound to a second update event, and the triggering frequency of the first update event is higher than the triggering frequency of the second update event; In response to the first update event, the system obtains the first data set within the current unit time slice from the data source, processes the first data set based on preset calculation rules to generate first result data, and writes the first result data to the first storage area according to the first write control strategy; during the writing process of the first result data, addressing requests to the second storage area are blocked. After the data output is completed based on the first storage area, the state lock is performed on the first result data written in the first storage area this time, so that the first result data will no longer respond to changes in the underlying data in the data source before the next first update event is triggered; In response to the second update event, the second data set is acquired in batches according to the complete time window covered by the target period, the second data set is processed based on the calculation rules to generate the second result data, and the second result data is written into the second storage area with the period version identifier for version fixation.

2. The method according to claim 1, characterized in that, In the storage system corresponding to the performance evaluation system, a first storage area and a second storage area are configured to be isolated from each other, and an asymmetric first write control strategy and a second write control strategy are configured for the first storage area and the second storage area respectively, including: According to the preset isolation mode configuration parameters, the first storage area and the second storage area are established in the storage system in either physical isolation or logical isolation mode; wherein, the physical isolation mode is to deploy the first storage area and the second storage area in different database instances or different data tables; the logical isolation mode is to deploy the first storage area and the second storage area in the same database, and to distinguish the data belonging to the first storage area and the second storage area respectively by using a data version identifier field; Configure the first write control policy on the write interface of the first storage area. The first write control policy includes: binding the write permission of the first storage area to the trigger source identifier corresponding to the first update event, so that the first storage area only receives write requests carrying the trigger source identifier of the first update event. Configure the second write control policy on the write interface of the second storage area. The second write control policy includes: binding the write permission of the second storage area to the trigger source identifier corresponding to the second update event, and rejecting write requests that carry the trigger source identifier of the first update event. When the first storage area or the second storage area is addressed, the trigger source identifier carried by this write request is matched with the first write control policy and the second write control policy respectively, and the write request is allowed or blocked according to the matching result.

3. The method according to claim 2, characterized in that, The method further includes: When the first update event is triggered, the addressing range of this write operation is limited to the first storage area, and the storage address of the second storage area is not included in the addressing list of this write operation; During the execution of the write operation of the first result data, any write request triggered by the first update event and targeting the second storage area is rejected; After the first result data is written, the data content and data version in the second storage area remain unchanged from the state before the write operation was initiated.

4. The method according to claim 1, characterized in that, In response to the first update event, the first data set within the current unit time slice is obtained from the data source, and the first data set is processed based on preset calculation rules to generate first result data, including: A timed cascaded data refresh pipeline covering the data source to the first storage area is pre-configured in the performance evaluation system. The timed cascaded data refresh pipeline includes a first task node and a second task node that are triggered sequentially at a preset time interval, and a buffer time window is set between the first task node and the second task node. When the first update event triggers the timed cascaded data refresh pipeline at a preset time, the first task node extracts the first data set that has been preprocessed within the current unit time slice from the data source; After the buffer time window expires and the data ready state of the first task node is established, the second task node is started. The second task node groups the first data set by object identifier according to the preset calculation rules and performs calculations independently and in parallel on each group to obtain the first result data.

5. The method according to claim 1, characterized in that, The step of writing the second result data into the second storage area with a periodic version identifier for version persistence includes: After the second result data is generated, metadata fields including the start and end timestamps of the target period and the period identifier are added to the second result data to form a period version identifier; Write the second result data with the attached periodic version identifier to the second storage area, and prevent the write operation triggered by the first update event from overwriting or deleting the second result data with the historical periodic version identifier already written in the second storage area; In response to an external traceability request, the system locates and returns the second result data corresponding to the period version identifier from the second storage area based on the period identifier specified in the traceability request.

6. The method according to claim 1, characterized in that, The method further includes: During the process of generating the first result data in response to the first update event, for each indicator result in the first result data, the original values ​​of each data factor on which the indicator depends, the intermediate variables in the calculation process of the preset calculation rules, and the data source information of each data factor are collected synchronously to form a calculation process record bound to the indicator result. The calculation process record is written into the first storage area along with the first result data, and the association between the calculation process record and the corresponding indicator result is established; In response to a traceability request for any indicator result in the first result data, the corresponding calculation process record is read from the first storage area according to the correlation relationship, and presented layer by layer in the order of the original value of the data factor, the calculation rule substitution process, and the data factor acquisition link from the data source to the first storage area.

7. The method according to claim 1, characterized in that, The method further includes: The data interface maps the first result data in the first storage area to the daily dimension dashboard view. In response to the user's access request to the daily dimension dashboard view, it returns the indicator completion value, expected score and ranking data of each assessed unit within the current unit time slice. The data interface maps the second result data in the second storage area to the assessment dimension dashboard view, and in response to the user's access request to the assessment dimension dashboard view, returns the official assessment result data of each assessed unit corresponding to the target period. The write operation triggered by the first update event does not affect the second storage area. The data refresh of the first storage area in subsequent unit time slices does not change the second result data already written in the second storage area. The assessment result data presented in the assessment dimension dashboard view remains unchanged at the time of the second update event.

8. A daily real-time performance indicator display system based on a dual-Kanban decoupled architecture, characterized in that, The system includes: The storage isolation configuration module is used to configure a first storage area and a second storage area that are isolated from each other in the storage system corresponding to the performance evaluation system, and to configure an asymmetric first write control policy and a second write control policy for the first storage area and the second storage area respectively; wherein, the write permission of the first storage area is bound to a first update event, the write permission of the second storage area is bound to a second update event, and the triggering frequency of the first update event is higher than the triggering frequency of the second update event; The daily-level data processing module is used to respond to the first update event, obtain the first data set within the current unit time slice from the data source, process the first data set based on preset calculation rules to generate first result data, and write the first result data to the first storage area according to the first write control strategy; during the writing process of the first result data, addressing requests to the second storage area are blocked. The data state locking module is used to perform state locking on the first result data written in the first storage area after the data output is completed based on the first storage area, so that the first result data will no longer respond to changes in the underlying data in the data source before the next first update event is triggered. The periodic data solidification module is used to respond to the second update event, batch acquire the second data set according to the complete time window covered by the target period, process the second data set based on the calculation rules to generate the second result data, and write the second result data into the second storage area with the periodic version identifier for version solidification.

9. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions, which are adapted to be loaded by a processor and executed as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, The device includes a processor, a memory, and a transceiver, wherein the memory is used to store instructions, the transceiver is used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1 to 7.

Images