Power-sensitive database lightweight supervision method and system based on metadata analysis

Abstract

The present application relates to the technical field of electric power data supervision, and particularly relates to a power sensitive database lightweight supervision method and system based on metadata analysis, comprising the following steps: S1: constructing an electric power scene exclusive metadata analysis dimension system and a benchmark rule, the analysis dimension system comprising four dimensions of business core degree, security risk degree, data sensitive attribute and dynamic attribute, each dimension being provided with an electric power exclusive index, determining the benchmark weight of each dimension and index, and initializing sensitive data identification, metadata weight level mapping and supervision weight level matching rule; in the present scheme, the four-dimensional analysis system exclusive to electric power is constructed, the metadata accurate weight level division is realized by combining a weighted grading algorithm, a five-level differentiated supervision configuration and resource elastic allocation mechanism are established, a real-time matching engine and flexible adjustment rule are matched, and through a closed-loop optimization and dynamic adaptation mechanism, the accuracy of electric power sensitive data supervision, the lightweight of operation, the timeliness of response and the long-term adaptability are realized.

Description

Technical Field

[0001] This invention relates to the field of power data monitoring technology, and in particular to a lightweight monitoring method and system for power-sensitive databases based on metadata parsing. Background Technology

[0002] The power sensitive data metadata database is a core data carrier that stores metadata related to core business operations in the power industry (such as grid dispatching, new energy grid connection, equipment operation and maintenance, and user electricity consumption). It records key information such as data structure, business relationships, security configuration, and dynamic characteristics, and serves as the fundamental support for ensuring the stable operation of the power system and preventing data security risks. Lightweight supervision refers to a supervision model that, under the premise of meeting the compliance requirements for sensitive data supervision, minimizes the occupation of hardware resources such as server CPU and memory through differentiated resource allocation and low-intrusion execution, so as not to affect the 24-hour uninterrupted operation of the power database.

[0003] Traditional regulatory methods have several significant shortcomings: First, metadata parsing is limited to a single dimension, failing to design targeted indicators tailored to specific power industry business scenarios (such as dispatch instruction execution and new energy grid connection dispatch), relying solely on general basic attribute classifications, leading to large errors in the classification of sensitive data weight levels; second, the regulatory model is "one-size-fits-all," lacking differentiated configurations corresponding to data sensitivity levels, resulting in severe resource waste due to full-scale real-time monitoring, while static monitoring cannot promptly capture anomalies; third, the weight level classification is disconnected from regulatory execution, leading to delayed matching and a lack of flexible adjustment mechanisms, making it difficult to adapt to special scenarios such as peak business periods and grid maintenance; fourth, the regulatory system is static, unable to dynamically adapt to new power business additions (such as virtual power plants and energy storage dispatch), policy updates, and the needs of handling safety incidents, resulting in poor long-term adaptability. Summary of the Invention

[0004] The technical problems addressed include: a single dimension for metadata parsing, a "one-size-fits-all" regulatory model, and a disconnect between authority classification and regulatory enforcement.

[0005] To address this, this invention proposes a lightweight regulatory method and system for power-sensitive databases based on metadata parsing. It constructs a four-dimensional parsing system specific to the power sector, comprising "business core level + security risk level + data sensitivity attributes + dynamic attributes," and combines this with a weighted hierarchical algorithm to achieve precise metadata weight classification. A five-level differentiated regulatory configuration and flexible resource allocation mechanism are established, coupled with a real-time matching engine and flexible adjustment rules for "metadata weight level - regulatory weight level." Through a closed-loop optimization and dynamic adaptation mechanism of "weight optimization → weight level correction → regulatory configuration adjustment → matching rule update," the system achieves precision in power-sensitive data supervision, lightweight operation, timely response, and long-term adaptability, effectively solving the core pain points of traditional regulation.

[0006] To address the shortcomings of existing technologies, this invention provides a lightweight regulatory method and system for power-sensitive databases based on metadata parsing, thereby solving the technical problems mentioned in the background section.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] A lightweight regulatory approach for power-sensitive databases based on metadata parsing includes the following steps:

[0009] S1: Construct an analytical dimension system that includes business coreness, security risk, data sensitivity attributes, dynamic attributes, and electricity-specific indicators, and determine the benchmark weights of each analytical dimension and indicator;

[0010] S2: Collect metadata from multiple sources according to the S1 parsing dimension, and output standardized metadata after preprocessing;

[0011] S3: Based on the baseline weight of the S1 indicator and the standardized metadata of S2, the score is calculated according to the weighted summation formula and mapped to the P1-P5 metadata weight levels;

[0012] S4: Define four dimensions of supervision: resource input, verification depth, response priority, and supervision frequency, configure differentiated standards for the five levels of supervision authority from R1 to R5, and establish a flexible resource allocation mechanism;

[0013] S5: Build a matching engine to achieve real-time matching of metadata authority level and regulatory authority level through rigid matching rules and flexible adjustment rules;

[0014] S6: Implement differentiated supervision based on matching authority level to handle resource conflicts;

[0015] S7: Establish a quantitative indicator system, and optimize it through closed-loop and dynamically adapt it to match changes in the scenario.

[0016] In one possible implementation, the weighted summation formula in step S3 is: ,in:

[0017] For the first The benchmark weight of each indicator, For the first The quantified value of each indicator;

[0018] The calculated weighted scores are mapped to five levels of metadata weights, P1-P5. After the initial weight level determination, a weight level label is generated for each piece of metadata.

[0019] In one possible implementation, the five levels of regulatory authority in S4 correspond to different resource input weights, while also matching different levels of response priority weights.

[0020] In one possible implementation, the S5 matching engine is a weighted dynamic matching rule engine, which includes a rule layer, an execution layer, and a verification layer. The rigid matching rule has a matching time of ≤10 seconds, while the flexible adjustment rule is designed for special scenarios related to peak business periods, major security incidents, and temporary business needs, allowing for dynamic adjustment of the rigid matching results.

[0021] In one possible implementation, S6's regulatory execution performs the corresponding regulatory operation based on the matched regulatory authority level. The regulatory execution of each authority level is based on four processing steps: metadata parsing, anomaly detection, alarm handling, and log recording.

[0022] In one possible implementation, a lightweight regulatory system based on metadata parsing of a power-sensitive database is executed using the above method:

[0023] The basic construction layer includes a power-specific parsing rule construction unit, a metadata collection and preprocessing unit, and a hierarchical regulatory configuration unit. The power-specific parsing rule construction unit performs the parsing dimension system construction and indicator benchmark weight setting in step S1. The metadata collection and preprocessing unit performs the metadata collection and preprocessing function in step S2. The hierarchical regulatory configuration unit performs the four-dimensional regulatory dimension definition and five-level regulatory authority differentiated configuration and resource elastic allocation mechanism establishment functions in step S4.

[0024] The core execution layer includes a metadata weight-level classification unit, a weight-level dynamic matching unit, and a lightweight supervision execution unit. The metadata weight-level classification unit performs the weighted calculation and indicator weight adjustment in step S3. The weight-level dynamic matching unit performs the weight-level dynamic matching rule engine construction, rigid matching rule and flexible adjustment rule matching and exception handling functions in step S5. The lightweight supervision execution unit performs differentiated supervision and resource conflict handling in step S6.

[0025] The optimization and adaptation layer includes a closed-loop optimization unit and a dynamic adaptation unit, which together perform the quantitative indicator system establishment of the S7 steps, closed-loop optimization and dynamic adaptation to match scene changes.

[0026] Beneficial effects compared to existing technologies:

[0027] 1. In this solution, a four-dimensional metadata parsing and weighted grading system specific to the power industry is constructed to achieve the accuracy of sensitive data weight classification. First, in the S1 stage, a four-dimensional parsing dimension of "business core degree + security risk degree + data sensitivity attribute + dynamic attribute" is established, incorporating power-specific indicators such as dispatch instruction correlation degree and new energy grid connection correlation degree. The baseline weight is determined by combining the analytic hierarchy process. Then, through the weighted score calculation and double-re-core mechanism in the S3 stage, the metadata weight classification (P1-P5) is made to fit the needs of power business and security, avoiding the problems of single dimension and large error in traditional static grading. This ensures that highly sensitive data such as dispatch instruction data and grid topology data are accurately classified, providing accurate basis for subsequent supervision.

[0028] 2. In this solution, a lightweight regulatory operation is achieved by establishing differentiated regulatory configurations and resource elasticity mechanisms corresponding to different authority levels. In the S4 stage, five regulatory authority levels (R1-R5) are designed for the five-level metadata authority level, and resources such as CPU ratio and verification depth are allocated differently. For example, the R5 authority level has a dedicated resource pool to ensure core regulation, while the R1 authority level operates with low power consumption. In the S6 stage, a "load monitoring-resource adjustment-breakpoint resume" mechanism is used to dynamically reduce low-level regulatory resources during peak business periods, and the overall regulatory CPU utilization rate is controlled at 1%-10%, which avoids the resource waste of traditional full-scale regulation and does not affect the stable 24-hour operation of the power database.

[0029] 3. In this solution, a real-time weight-level matching engine and flexible adjustment rules are built to achieve timeliness and flexibility in regulatory response. The S5 stage constructs a three-layer matching engine. Rigid matching rules ensure that regulatory weight-level matching is completed within 10 seconds after metadata weight-level changes, while flexible rules adapt to special scenarios—reducing the P3 weight-level regulatory intensity when the business is under extremely high load, and increasing the weight-level of the data involved in major security incidents. This solves the problems of disconnect between traditional regulatory classification and execution, and delayed response. For example, the regulatory weight-level of relevant data can be temporarily increased during power grid maintenance, taking into account both regulatory standardization and scenario flexibility.

[0030] 4. In this solution, a four-layer closed-loop optimization and dynamic adaptation mechanism is used to achieve long-term adaptability of the regulatory method. The S7 step is guided by quantitative indicators and continuously improves through a closed loop of "weight optimization → weight level correction → regulatory configuration adjustment → matching rule update". At the same time, it adapts to new business (such as virtual power plants), policy updates (such as new energy storage data security requirements), and security events. The indicator weight and regulatory configuration optimization are completed within 24 hours, avoiding the drawbacks of traditional static regulation, ensuring that the method is in line with the long-term development needs of the power industry, and improving the long-term effectiveness and adaptability of regulation. Attached Figure Description

[0031] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, the preferred embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0032] Figure 1 This is a flowchart of the method steps of the present invention;

[0033] Figure 2 This is a schematic diagram of the system framework of the present invention. Detailed Implementation

[0034] Preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. However, the present invention can also be implemented in various different forms, and therefore the present invention is not limited to the embodiments described below.

[0035] The technical solution in this application embodiment is to solve the problems mentioned in the background art, and the overall idea is as follows:

[0036] Example:

[0037] Please refer to Figure 2 As shown in the figure, this embodiment introduces a lightweight monitoring system for power-sensitive databases based on metadata parsing, including a basic construction layer, a core execution layer, and an optimization and adaptation layer, as detailed below:

[0038] The basic construction layer includes a power-specific parsing rule construction unit, a metadata collection and preprocessing unit, and a hierarchical supervision configuration unit. By building the parsing rules, high-quality metadata, and supervision configuration required for system operation, it provides "standards and data input" for the core execution links.

[0039] The power-specific parsing rule construction unit combines power business (dispatch, new energy grid connection, etc.) and safety standards to construct a four-dimensional metadata parsing dimension of "business core degree + safety risk degree + data sensitivity attribute + dynamic attribute", and clarifies the power-specific indicators of each dimension (such as the correlation of dispatch instructions); it uses the analytic hierarchy process to determine the benchmark weight (business core degree 35%, etc.) and initializes the rules for sensitive data identification and metadata-regulatory authority initial matching (P5→R5, etc.).

[0040] The metadata collection and preprocessing unit collects metadata through multiple sources: "log monitoring (capturing metadata changes) + business interface calls (obtaining business-related data such as SCADA / EMS) + database dictionary queries (collecting basic attributes such as table structure)". After processing through "duplicate removal (SHA-256 hash verification) → noise reduction (removing invalid data) → standardization (unifying 1-5 point scale index values) → quality verification (ensuring missing rate ≤0.5%)", it outputs high-quality standardized metadata.

[0041] The hierarchical regulatory configuration unit corresponds to five levels of metadata authority (P1-P5), defining four dimensions of regulatory "resource investment + verification depth + response priority + regulatory frequency" to configure core standards for the five levels of regulatory authority (R1-R5): for example, R5 (corresponding to P5) is equipped with a dedicated resource pool (CPU 8%-10%) and a 1-minute alarm response; R1 (corresponding to P1) is equipped with low-consumption resources (CPU ≤ 1%) and a 2-hour alarm response. At the same time, load-triggered resource elastic adjustment rules are set (e.g., only R5 / R4 are guaranteed under extremely high load).

[0042] The core execution layer includes a metadata authority-level classification unit, an authority-level dynamic matching unit, and a lightweight regulatory execution unit. By completing the metadata authority-level classification, authority-level matching, and differentiated regulatory execution, it is the core link of the system "from standard to action".

[0043] The metadata weighting and grading unit is based on the baseline weights and standardized metadata output from the base layer. The weighted score of the metadata is calculated using the formula S=Σ(index value × weight). The score range is mapped to 5 weight levels (P1-P5, e.g., 4.0-5.0 points → P5). The weights are dynamically adjusted in conjunction with security events, policies, etc., and then the weights are corrected by "automatic algorithm review (isolated forest to identify anomalies) + expert manual review (extracting 20% ​​of high-weight data)" to ensure accurate grading.

[0044] The dynamic matching unit for authority levels builds a simplified engine of "rule layer + execution layer": the rule layer stores rigid matching (P5→R5, etc., with a time limit of ≤10 seconds) and flexible adjustment (downgrading P3 regulatory authority level during peak business periods and escalating authority level for major security incidents) rules; the execution layer receives metadata authority levels, calls the rules to output the corresponding regulatory authority levels, and simultaneously displays the matching success rate (target ≥99.5%) and anomalies (such as missing authority levels) through visual monitoring.

[0045] The lightweight regulatory execution unit performs differentiated regulation according to the matching regulatory authority level (R1-R5): R5 / P5 data is subject to "real-time parsing + business link-level detection + automatic emergency handling (freezing abnormal accounts, etc.)"; R1 / P1 data is subject to "off-peak period parsing + basic attribute sampling detection + weekly processing"; at the same time, resource conflicts are handled through "load monitoring - graded demotion - breakpoint resume" to ensure that the regulatory CPU usage is 1%-10% without affecting business operations.

[0046] The optimization and adaptation layer includes a closed-loop optimization unit and a dynamic adaptation unit. Through closed-loop optimization and dynamic adaptation, it solves the static problem of traditional systems and ensures that the system adapts to changes in power scenarios in the long term.

[0047] The closed-loop optimization unit establishes quantitative evaluation indicators (weight level determination accuracy ≥99%, anomaly identification accuracy ≥95%, etc.) and generates an evaluation report monthly. It continuously improves the accuracy and efficiency of each link by following the closed loop of "weight optimization (adjusting indicator weights based on security events) → weight level correction (recalculating metadata weight level) → regulatory configuration adjustment (such as expanding the R5 resource pool) → matching rule update (solidifying commonly used flexible rules)".

[0048] Dynamic adaptation unit adapts to changes in power scenarios: when new business is added (such as virtual power plants), new analytical indicators are added and weights are assigned; when policies are updated (such as new energy storage data requirements), the weights of relevant indicators are increased; within 24 hours after a major safety incident, emergency optimization of weights, weight levels, and regulatory configurations is completed to ensure that the system does not become out of touch with actual needs.

[0049] Please refer to Figure 1 As shown, based on the above system, this embodiment also introduces a lightweight regulatory method for power-sensitive databases based on metadata parsing. The specific steps are as follows:

[0050] S1: Construction of a Metadata Parsing Dimension System and Initialization of Benchmark Rules for Power Scenarios

[0051] Based on the power industry data classification standards, a four-dimensional metadata parsing system is constructed, consisting of "business coreness + security risk level + data sensitivity attributes + dynamic attributes". Each dimension has its own core indicators specific to the power industry, ensuring that the parsing dimensions are aligned with the actual situation in the industry.

[0052] Business Coreness Dimension (Baseline Weight 35%): Measures the impact of data on the stable operation of the power system, including 3 indicators: dispatch instruction correlation (the closeness of correlation with real-time grid dispatch instructions), renewable energy grid connection correlation (the correlation with renewable energy grid connection dispatch and power prediction), and production and operation correlation (the correlation with equipment operation and maintenance and fault diagnosis).

[0053] Security risk level dimension (baseline weight 30%): assesses the scope and severity of data security incidents, including 3 indicators: access permission level (divided according to the three-level power access control), encryption status indicator (whether storage / transmission is encrypted), and risk impact scope (network-wide / regional / site-level / single user level).

[0054] Data Sensitive Attribute Dimension (Base Weight 25%): Focusing on the sensitive characteristics of the data itself, it includes three indicators: user privacy correlation (the degree of correlation with personal privacy information), production data correlation (the degree of correlation with core power production data), and confidentiality level indicators (classified according to power confidentiality regulations as top secret / confidential / secret / non-confidential).

[0055] Dynamic attribute dimension (baseline weight 10%): Reflects the dynamic change characteristics of data, including two indicators - data update frequency (seconds / minutes / hours / days and above) and access frequency (more than 10,000 times / day / thousands to 10,000 times / day / hundreds to thousands / day / less than 100 times / day).

[0056] Baseline rule initialization: Defining the core mapping logic

[0057] Sensitive data identification rules: Based on the classification standard for sensitive power data and combined with four-dimensional indicators, the logic for judging sensitive data is clarified. For example, "dispatch instruction correlation degree ≥ 0.8 and access permission is system administrator level" is judged as core sensitive data.

[0058] Metadata weighting mapping rules: Initialize 5 levels of metadata weights (P1-P5, P5 is the highest), and set the weighted score interval mapping relationship; weighted score = Σ (each indicator value × indicator baseline weight), the indicator value is quantified using a 1-5 point system, the score [4.0, 5.0] corresponds to P5, [3.0, 4.0) corresponds to P4, [2.0, 3.0) corresponds to P3, [1.0, 2.0) corresponds to P2, and [0, 1.0) corresponds to P1;

[0059] Regulatory authority matching rules: Initialize a one-to-one mapping of "metadata authority level - regulatory authority level" (P5→R5, P4→R4…P1→R1) to provide a basic association for subsequent regulatory configuration.

[0060] S2: Metadata Acquisition and Preprocessing of Power Sensitive Database

[0061] Based on the four-dimensional analysis dimensions and core indicators determined in S1, the scope of metadata collection is clarified to ensure that the collected metadata can cover all indicator calculation requirements, while avoiding resource waste caused by collecting irrelevant data.

[0062] Database object metadata includes database name, table name, field name, field type, field length, primary key, foreign key, index information, etc., corresponding to the "basic attributes" related data, supporting the basic association of various dimensional indicators.

[0063] Business-related metadata includes the business module to which the data belongs, the business process number, and the association identifier with core business systems (SCADA, EMS, PMS, etc.), which supports the calculation of various indicators in the "business coreness" dimension.

[0064] Security configuration metadata includes access permission configurations (user groups, roles, permission types), encryption algorithm types, encryption key status, data transmission protocols, etc., supporting the calculation of various indicators in the "security risk level" dimension.

[0065] Data feature metadata includes data update timestamps, update count statistics, access log records, data volume, data format, etc., supporting the calculation of various indicators in the "data sensitive attributes" and "dynamic attributes" dimensions.

[0066] The collected multi-source metadata undergoes a four-step preprocessing process: deduplication, noise reduction, format standardization, and data quality verification, to ensure that the data quality meets the requirements for hierarchical computing.

[0067] Deduplication: Based on unique metadata identifiers (such as a combination of "database name + table name + field name"), a hash verification algorithm (such as SHA-256) is used to identify and remove duplicate metadata. For example, if duplicate records of the same field are collected through both log monitoring and database dictionary queries, the latest record is retained by comparing hash values.

[0068] Noise reduction processing: Invalid and abnormal data are removed, including: ① Data with incorrect formatting (e.g., the permission level field is entered as "Administrator" instead of the default "System Administrator"); ② Logically contradictory data (e.g., the data update frequency is marked as "Real-time Update" but the access frequency is "Extremely Low Frequency Access," with no reasonable business explanation); ③ Data with missing key fields (e.g., missing metadata for "Business Module Association Identifier," making it impossible to calculate business core indicators). Data with missing key fields is marked as "Data to be Supplemented," and a second data collection is triggered (supplemented through API calls or manual entry).

[0069] Format standardization: Metadata from different sources and in different formats will be converted into a standardized format, including: ① Data type standardization (e.g., unifying the date format to "YYYY-MM-DDHH:MM:SS", and unifying numerical indicators to decimal format); ② Indicator value standardization (converting the descriptive data of each indicator into a quantitative value on a 1-5 scale, such as "System Administrator Level" corresponding to 5 points, "Business Administrator Level" corresponding to 4 points, "Ordinary Operator Level" corresponding to 3 points, and "Read-Only Access Level" corresponding to 2 points in "Access Permission Level"); ③ Field naming standardization (unifying the naming rule of "Dimension-Indicator-Attribute", such as "Business Core Degree-Scheduling Instruction Relevance Degree-Indicator Value").

[0070] Data quality verification: Establish a data quality verification indicator system, including completeness (key field missing rate ≤0.5%), accuracy (logical consistency of indicator values ​​≥99.8%), consistency (consistency of metadata field values ​​from different sources ≥99.5%), and timeliness (metadata collection and preprocessing completion time ≤30 minutes). For data that fails verification, trigger an anomaly alarm and re-collect data; if it still fails after three collections, it is marked as "abnormal metadata" and included in the manual review process.

[0071] S3: Metadata Weighted Hierarchical Calculation and Dynamic Adjustment of Weight Levels

[0072] The weighted score calculation for metadata uses the baseline weights of each dimension and indicator determined in S1, combined with the preprocessed quantitative values ​​of the indicators in S2, to calculate the weighted score for each piece of metadata using a weighted summation formula: Weighted Score ,in:

[0073] For the first The benchmark weight of each indicator ( );

[0074] For the first The quantitative value of each indicator (out of 1-5 points).

[0075] For example, the quantitative values ​​and weights of the metadata related to a certain scheduling instruction are as follows: scheduling instruction correlation (V=5, W=0.15), new energy grid connection correlation (V=2, W=0.12), production and operation correlation (V=3, W=0.08), access permission level (V=5, W=0.12), encryption status (V=5, W=0.10), risk impact scope (V=4, W=0.08), user privacy correlation (V=2, W=0.10), production data correlation (V=5, W=0.10), confidentiality level (V=4, W=0.05), data update frequency (V=5, W=0.06), and access frequency (V=4, W=0.04). The weighted score S = 5 × 0.15 + 2 × 0.12 + 3 × 0.08 + 5 × 0.12 + 5 × 0.10 + 4 × 0.08 + 2 × 0.10 + 5 × 0.10 + 4 × 0.05 + 5 × 0.06 + 4 × 0.04 = 0.75 + 0.24 + 0.24 + 0.60 + 0.50 + 0.32 + 0.20 + 0.50 + 0.20 + 0.30 + 0.16 = 4.01 points, corresponding to weight level P5.

[0076] Initial determination of metadata weight level: Based on the weight level mapping benchmark rules initialized in S1, the calculated weighted score is mapped to 5 levels of metadata weight level (P1-P5):

[0077] P5 weight level (highest level): score ∈ [4.0, 5.0], corresponding to core sensitive data (such as dispatch instruction data, power grid topology data).

[0078] P4 weight level: score ∈ [3.0, 4.0), corresponding to highly sensitive data (such as real-time output data of new energy units, core operating parameter data of equipment).

[0079] P3 weight level: score ∈ [2.0, 3.0), corresponding to sensitive data (such as user electricity bill data, equipment operation and maintenance record data).

[0080] P2 weight level: score ∈ [1.0, 2.0), corresponding to low-sensitivity data (such as power science popularization data, non-confidential industry report data).

[0081] P1 weight level (lowest level): score ∈ [0, 1.0), corresponding to non-sensitive data (such as publicly available power service information, historical statistical data backup).

[0082] After the initial weight level determination, a weight level tag is generated for each piece of metadata and stored in the metadata weight level management library. At the same time, the basis for the weight level determination (values ​​of each indicator, weight, and weighted score) is recorded to facilitate subsequent traceability and auditing.

[0083] S4: Construction of a Weighted Allocation System Based on Regulatory Authority

[0084] Definition of regulatory weighting dimensions: Construct a four-dimensional regulatory weighting dimension consisting of "resource input weight + verification depth weight + response priority weight + regulatory frequency weight". Each dimension is positively correlated with the metadata weight level. That is, the higher the metadata weight level, the stronger the configuration of the regulatory weighting dimension, while also taking into account resource consumption control.

[0085] Resource allocation weight: This refers to the proportion of server CPU, memory, bandwidth, and other hardware resources allocated to this regulatory authority level. The core objective is to ensure that the regulatory resource requirements of high-authority metadata are met, while avoiding excessive resource consumption by low-authority metadata. Resource allocation weight is quantified as a percentage, and the total resource allocation is controlled within 10% of the total available database resources (to ensure no impact on business operations).

[0086] Verification depth weight: This refers to the granularity of verification of metadata and corresponding business data during the regulatory process. The higher the verification depth, the higher the accuracy of sensitive data anomaly identification, but the higher the resource consumption. It is quantified using a "weight coefficient" (0.2-1.0), with a higher weight coefficient indicating a deeper verification depth.

[0087] Response priority weight: This refers to the timeliness and processing priority of the monitoring system's alarm response when metadata anomalies occur (such as permission changes or data leakage risks). The higher the priority, the more timely the anomaly handling and the lower the security risk. It is quantified using a "weight coefficient" (0.2-1.0), with a higher weight coefficient indicating a higher response priority.

[0088] Regulatory frequency weight: This refers to the interval between the monitoring system's parsing and verification of metadata. The higher the monitoring frequency, the more timely the anomaly detection, but the higher the resource consumption. It is quantified using a "weight coefficient" (0.2-1.0), with a higher weight coefficient indicating a higher monitoring frequency.

[0089] Level-based regulatory authority configuration: Based on the principle that "the higher the metadata authority level, the stronger the regulatory weighting dimension configuration", specific configuration standards are set for the five levels of regulatory authority (R1-R5, with R5 being the highest level). The four-dimensional weighting dimension configuration of each regulatory authority level is coordinated with each other to ensure "precise regulation at high authority levels and lightweight regulation at low authority levels".

[0090] R5 regulatory authority level (corresponding to P5 metadata authority level):

[0091] Resource allocation weighting: CPU 8%-10%, memory 10%-12%, bandwidth 10%-15%, configure a dedicated regulatory resource pool (physically isolated) to avoid competing for resources with other regulatory authorities and ensure regulatory stability.

[0092] Verification depth weight: 1.0 (highest level), employing dual verification of "business link level + full field level". Business link level verification: Tracing the flow status of business data corresponding to metadata throughout the entire business process (such as the entire link from the generation of scheduling instructions to the execution feedback), checking for anomalies such as unauthorized access and data tampering; Full field level verification: Verifying each field corresponding to metadata, including field value integrity, format consistency, encryption status validity, and permission configuration rationality.

[0093] Response priority weight: 1.0 (highest level), alarm response time ≤ 1 minute, processing priority is "Special". After an anomaly occurs, multiple alarms will be triggered within 1 minute (system pop-up, SMS, telephone, WeChat Work), the account of abnormal operation (such as unauthorized access account) will be automatically frozen, and the data recovery plan (for data tampering and loss anomalies) will be activated.

[0094] Supervision frequency weight: 1.0 (highest level), adopting the "real-time incremental parsing + full verification every 5 minutes" mode. Real-time incremental parsing: Captures metadata changes (such as field modifications and permission adjustments) in real time through log monitoring and immediately performs anomaly verification; Full verification every 5 minutes: Performs a full-dimensional verification of all metadata at the P5 authority level to ensure no anomalies are missed.

[0095] R4 regulatory authority level (corresponding to P4 metadata authority level):

[0096] Resource allocation weighting: CPU 5%-8%, memory 7%-10%, bandwidth 8%-12%, and a priority resource pool (prioritized when resources are scarce).

[0097] Validation depth weight: 0.8, using "table-level + core field-level" validation. Table-level validation: Checking whether there are any abnormal changes to the table structure, indexes, and constraints corresponding to the metadata; Core field-level validation: Focusing on validating core sensitive fields corresponding to the metadata (such as production data association fields and access permission fields), while non-core fields are validated by sampling (sampling ratio ≥ 50%).

[0098] Response priority weight: 0.8, alarm response time ≤ 5 minutes, processing priority is "Level 1". After an anomaly occurs, a system pop-up and SMS alarm will be triggered within 5 minutes, the abnormal operation log will be automatically recorded, and the business administrator will be notified for handling. If it is not handled within 15 minutes, it will be escalated to a telephone alarm.

[0099] Regulatory frequency weight: 0.8, adopting a "5-minute incremental parsing + 30-minute full verification" mode. 5-minute incremental parsing: Captures and verifies metadata changes within the last 5 minutes; 30-minute full verification: Performs a full-dimensional verification of all metadata at the P4 weight level.

[0100] R3 regulatory authority level (corresponding to P3 metadata authority level):

[0101] Resource allocation weighting: CPU 3%-5%, memory 5%-7%, bandwidth 5%-8%, configured with a standard resource pool.

[0102] Validation depth weight: 0.6, using "field-level + key field sampling" validation. Field-level validation: Checking whether the field attributes (type, length, constraints), encryption status, and permission configuration of metadata are abnormal; Key field sampling: Performing 100% validation on key fields with high sensitivity attributes (such as user privacy-related fields), and sampling ratio of ≥30% for other fields.

[0103] Response priority weight: 0.6, alarm response time ≤ 15 minutes, processing priority is "Level 2". After an anomaly occurs, a system pop-up and WeChat alarm will be triggered within 15 minutes, an anomaly log will be recorded, and a regular administrator will be notified for handling.

[0104] Regulatory frequency weight: 0.6, adopting the "incremental parsing every 30 minutes + full verification every 2 hours" mode. Incremental parsing every 30 minutes: captures and verifies metadata changes within the past 30 minutes; full verification every 2 hours: performs a full-dimensional verification of all metadata at the P3 authority level.

[0105] R2 regulatory authority level (corresponding to P2 metadata authority level):

[0106] Resource allocation weighting: CPU 1%-3%, memory 3%-5%, bandwidth 3%-5%, configure a low-priority resource pool.

[0107] Validation depth weight: 0.4, using "key field level + basic attribute" validation. Key field level validation: only core sensitive key fields (such as confidentiality level fields) are 100% validated; basic attribute validation: check whether there are any abnormal changes in the basic attributes of metadata (table name, field name, data type).

[0108] Response priority weight: 0.4, alarm response time ≤ 30 minutes, processing priority is "Level 3". After an anomaly occurs, a system pop-up alarm will be triggered within 30 minutes, and an anomaly log will be recorded, which will be handled periodically by operations and maintenance personnel (e.g., once a day).

[0109] Regulatory frequency weight: 0.4, adopting the "incremental parsing every 2 hours + full verification once a day" mode. Incremental parsing every 2 hours: capturing and verifying metadata changes within the past 2 hours; Full verification once a day: performing a full-dimensional verification of all metadata at the P2 level during off-peak business hours (such as 3-4 am).

[0110] R1 regulatory authority level (corresponding to P1 metadata authority level):

[0111] Resource allocation weights: CPU ≤1%, memory ≤3%, bandwidth ≤3%, configure the lowest priority resource pool.

[0112] Verification depth weight: 0.2, using "basic attribute sampling + anomaly log screening" verification. Basic attribute sampling: Sampling and verification of basic attributes of metadata (sampling ratio ≥ 10%); Anomaly log screening: Only screening of serious anomaly logs in the database (such as database crash logs, malicious attack logs), without additional verification.

[0113] Response priority weight: 0.2, alarm response time ≤ 2 hours, processing priority is "Level 4". After an anomaly occurs, a system alarm will be triggered within 2 hours, an anomaly log will be recorded, and it will be handled by maintenance personnel weekly.

[0114] Regulatory frequency weight: 0.2, adopting a "daily incremental parsing + weekly full verification" mode. Daily incremental parsing: Capturing and verifying daily metadata changes during off-peak business hours; Weekly full verification: Performing a full-dimensional verification of all P1-level metadata during off-peak business hours on weekends (such as 2-3 AM on Sunday).

[0115] Flexible allocation mechanism for regulatory resources: To further achieve the "lightweight" goal and avoid conflicts between regulatory and operational resources, a flexible allocation mechanism for regulatory resources is established, adjusting the allocation of regulatory resources based on real-time operational load data from a power-sensitive database.

[0116] Business load monitoring: Real-time monitoring of database load metrics such as CPU utilization, memory usage, disk I / O, and concurrent connections. Set load thresholds: normal load (CPU utilization ≤ 70%), high load (CPU utilization 70%-85%), and ultra-high load (CPU utilization > 85%).

[0117] Resource adjustment strategy:

[0118] Under normal load: allocate resources according to the above-mentioned regulatory authority level configuration standards to ensure that the regulatory intensity meets the requirements;

[0119] Under high load: reduce the resource allocation weights of R2 and R1 weight levels (reduce CPU usage by 50% each), suspend the full verification of R1 weight level, and postpone its execution until the load returns to normal;

[0120] Under extremely high load: Only ensure resource allocation for R5 and R4 priority levels (maintain configuration standards), suspend incremental parsing and full verification for R3, R2, and R1 priority levels, activate the "breakpoint resume" mechanism, and resume monitoring from the pause point after the load drops to a normal level to ensure uninterrupted monitoring.

[0121] S5: Building and Executing a Weighted Dynamic Matching Rule Engine

[0122] Matching rule engine architecture design: A three-layer matching rule engine architecture of "rule layer + execution layer + verification layer" is designed to ensure that the matching process is efficient, accurate, and traceable.

[0123] Rule layer: Stores matching rules between "metadata authority level and regulatory authority level", including rigid matching rules, flexible adjustment rules, and exception handling rules. The rules adopt a configurable format (such as JSON format) and support dynamic updates.

[0124] Execution layer: Responsible for receiving metadata authority labels output by S3, calling the matching rules of the rule layer, performing matching calculations, outputting the corresponding regulatory authority, and storing the matching results in the authority matching result library.

[0125] Verification layer: Responsible for verifying the accuracy of matching results, identifying matching anomalies (such as weight mismatch or matching delay), and triggering correction processes.

[0126] Core matching rule design:

[0127] Rigid matching rules: Based on the "one-to-one mapping" principle, a fixed mapping relationship is preset between metadata authority level and regulatory authority level to ensure the basic accuracy of matching.

[0128] P5 metadata authority level → R5 regulatory authority level;

[0129] P4 metadata authority level → R4 regulatory authority level;

[0130] P3 metadata authority level → R3 regulatory authority level;

[0131] P2 metadata authority level → R2 regulatory authority level;

[0132] P1 metadata authority level → R1 regulatory authority level.

[0133] The rigid matching rule is triggered when the metadata authority level is determined or changed. The matching trigger time is ≤10 seconds, that is, after the metadata authority level is determined or changed, the matching with the regulatory authority level is completed within 10 seconds.

[0134] Flexible adjustment rules: For special scenarios (such as peak business periods, major security incidents, and temporary business needs), dynamic adjustments to rigid matching results are allowed to ensure matching flexibility.

[0135] Adjustments during peak business periods: When the database is under extremely high load (CPU utilization > 85%) for a duration of ≥ 10 minutes, the matching result of the P3 metadata weight level will be automatically adjusted from R3 to R2 (reducing the regulatory intensity), and rigid matching will be restored within 10 seconds after the load returns to normal.

[0136] Major security incident adjustment: When a major data security incident occurs (such as the risk of P5-level data leakage), the authority level of all metadata involved in the incident will be automatically upgraded by 1 level (e.g., from P4 to P5), and the corresponding regulatory authority level will be upgraded simultaneously (from R4 to R5). Rigid matching will be restored within 24 hours after the incident is handled.

[0137] Temporary business requirement adjustment: Supports manual initiation of temporary adjustment requests (such as during power emergency repairs, when it is necessary to increase the supervision intensity of emergency repair data). After approval by both the security administrator and the business administrator, the matching relationship between metadata authority level and supervision authority level can be temporarily adjusted. The adjustment is valid for a maximum of 72 hours, and the rigid matching will be automatically restored upon expiration.

[0138] Anomaly Handling Rules: For anomalies occurring during the matching process (such as missing metadata weights, conflicting matching results, or matching delays), the following handling rules are defined:

[0139] Metadata missing authority level: If the metadata has not been assigned an authority level label, it will be automatically matched to the R3 regulatory authority level (medium intensity regulatory), and an alarm will be triggered to notify the operation and maintenance personnel to supplement the authority level label;

[0140] Matching result conflict: If the same metadata matches two different regulatory authority levels at the same time (such as matching R3 and R4 at the same time due to rule conflict), the "higher is better" principle will be automatically adopted (matching R4), and the conflict log will be recorded, triggering rule review;

[0141] Matching Delay: If no matching result is output after more than 30 seconds after the matching is triggered, the matching engine will be automatically restarted and the matching will be re-executed. If the delay still occurs after restarting, an alarm will be triggered to notify the technicians to troubleshoot the problem.

[0142] Matching execution flow:

[0143] Matching trigger: When S3 completes the metadata weight level determination or weight level change, it automatically sends a trigger signal to the matching rule engine, and transmits information such as the unique metadata identifier, weight level label, and weight level change time.

[0144] Rule Invocation: After receiving the trigger signal, the execution layer invokes the rigid matching rule from the rule layer and queries the corresponding regulatory authority level based on the metadata authority level label;

[0145] Flexible adjustment judgment: The execution layer queries the current database load status, whether there is a major security incident, and whether there is a temporary adjustment request. If the flexible adjustment conditions are met, the adjustment logic is executed; otherwise, the rigid matching result is directly output.

[0146] Results storage and feedback: Store the matching results (metadata identifier, metadata authority level, regulatory authority level, matching time, matching rules) in the authority level matching result database, and feed back the regulatory authority level information to the S6 regulatory execution module;

[0147] Verification layer verification: The verification layer reads the matching results from the authority-level matching result library in real time and verifies whether the "metadata authority-regulatory authority" conforms to the rigid rules (except for special scenarios) and whether the matching time is ≤10 seconds. If there are any abnormalities, the correction process (such as re-matching or manual review) is triggered.

[0148] Weighted Matching Visual Monitoring: Build a weighted matching visual dashboard to support real-time monitoring of the matching process and results, including:

[0149] Matching Overview: Displays the current metadata authority distribution, regulatory authority distribution, matching success rate (target ≥ 99.5%), and average matching time.

[0150] Detailed query: Supports querying matching details by metadata authority level, regulatory authority level, matching time, matching rules, and other conditions;

[0151] Anomaly Alerts: Real-time display of the number, details, and processing status of matching anomalies (such as conflicts, delays, and missing weights);

[0152] Rule management: Supports adding, modifying, deleting, enabling / disabling matching rules, with all operations recorded.

[0153] S6: Lightweight Regulatory Implementation and Resource Conflict Resolution

[0154] Regulatory execution process: Based on the matched regulatory authority level (R1-R5), the corresponding regulatory operation is executed. The regulatory execution process for each authority level includes four core steps: "metadata parsing → anomaly detection → alarm handling → log recording". The specific execution standards are based on the S4 configuration.

[0155] R5 regulatory authority level execution process (corresponding P5 metadata):

[0156] Metadata parsing: Employs "real-time incremental parsing + full parsing every 5 minutes". Real-time incremental parsing captures every change in metadata (such as field modification, permission adjustment, encryption status change) through a log listening agent, and the parsed content includes the change type, change time, operator, and indicator values ​​before and after the change; full parsing every 5 minutes re-parses all metadata at the P5 authority level using four-dimensional indicators to ensure that the parsing results are consistent with the actual state.

[0157] Anomaly detection employs a "business link level + full field level" verification approach. Business link level verification traces the flow path of business data corresponding to metadata in systems such as SCADA and EMS through business system interface call logs, checking for unauthorized access (e.g., access from unauthorized IPs), data tampering (e.g., abnormal changes to field values), and data leakage (e.g., abnormal downloads or batch exports). Full field level verification verifies all fields of metadata one by one, including field type consistency (e.g., whether numeric fields have been changed to character types), encryption status validity (e.g., whether encryption keys have expired), permission configuration rationality (e.g., whether ordinary users have modification permissions), and indicator value logical consistency (e.g., whether the correlation between scheduling instructions and actual business operations).

[0158] Alarm Handling: Response time ≤ 1 minute, triggering alarms through multiple channels (system pop-ups, SMS, telephone, WeChat Work), and automatically executing emergency handling operations: for unauthorized access anomalies, freezing the operating account and blocking the access IP; for data tampering anomalies, triggering data recovery (restoring original data from the backup database); for data leakage anomalies, interrupting data transmission and disabling export permissions. After alarm handling, a handling report is generated, recording the handling time, handling method, and handling result.

[0159] Log recording: Record full-process logs, including parsing logs (parsing time, parsing content, parsing result), detection logs (detection time, detection item, detection result), alarm logs (alarm time, alarm type, alarm channel), and handling logs (handling time, handler, handling method, handling result). The logs are retained for ≥3 years.

[0160] R4 regulatory authority level execution process (corresponding P4 metadata):

[0161] Metadata parsing: Employs "incremental parsing every 5 minutes + full parsing every 30 minutes". Incremental parsing every 5 minutes captures and parses metadata changes within the past 5 minutes; full parsing every 30 minutes re-parses all P4-level metadata using four-dimensional metrics.

[0162] Anomaly detection: A combination of table-level and core field-level verification is employed. Table-level verification checks for anomalies in the table structure (e.g., field additions / deletions, index changes) and constraints (e.g., primary key constraints, foreign key constraints). Core field-level verification performs 100% validation on core sensitive fields such as production data association fields and access permission fields. Non-core fields are sampled and validated (sampling ratio ≥ 50%) to check for field value integrity, format consistency, and encryption status.

[0163] Alarm Handling: Response time ≤ 5 minutes, triggering system pop-up and SMS alarms, automatically recording abnormal operation logs, and notifying business administrators for handling. If not handled within 15 minutes, it escalates to a telephone alarm. Handling operations are primarily manual, supplemented by automated handling (e.g., only automatically recording logs, not automatically freezing accounts). A handling report is generated upon completion of the handling.

[0164] Log recording: Record parsing logs, detection logs, alarm logs, and handling logs, with a retention period of ≥2 years.

[0165] R3 regulatory authority level execution process (corresponding P3 metadata):

[0166] Metadata parsing: Employs "incremental parsing every 30 minutes + full parsing every 2 hours". Incremental parsing every 30 minutes captures and parses metadata changes within the past 30 minutes; full parsing every 2 hours re-parses all P3-level metadata using four-dimensional metrics.

[0167] Anomaly detection: A "field-level + key field sampling" verification method is used. Field-level verification: Checking for anomalies in metadata field attributes, encryption status, and permission configurations; Key field sampling verification: 100% verification of key fields such as user privacy-related fields, with a sampling rate of ≥30% for other fields.

[0168] Alarm Handling: Response time ≤ 15 minutes, triggering system pop-ups and WeChat enterprise alerts to notify regular administrators for handling. Handling method is manual, and the handling result is recorded after completion.

[0169] Log recording: Record parsing logs, detection logs, and alarm logs, and retain them for a period of ≥1 year.

[0170] R2 regulatory authority level execution process (corresponding P2 metadata):

[0171] Metadata parsing: Employs "incremental parsing every 2 hours + full parsing once a day". Incremental parsing every 2 hours captures and parses metadata changes within the past 2 hours; the full parsing once a day is performed between 3 and 4 AM.

[0172] Anomaly detection: Verification is performed using both "key field level" and "basic attribute" methods. Key field level verification: 100% verification is performed on core sensitive fields such as those indicating classification levels. Basic attribute verification: The basic attributes of metadata, such as table names, field names, and data types, are checked for any abnormal changes.

[0173] Alarm handling: The response time is ≤30 minutes. If a system pop-up alarm is triggered, it will be handled by the operation and maintenance personnel on a daily basis, and the handling results will be recorded in the operation and maintenance log.

[0174] Log recording: Record parsing logs and exception logs, and retain them for ≥6 months.

[0175] R1 regulatory authority level execution process (corresponding P1 metadata):

[0176] Metadata parsing: A combination of daily incremental parsing and weekly full parsing is employed. Daily incremental parsing is performed between 3 and 4 AM; weekly full parsing is performed between 2 and 3 AM on Sunday.

[0177] Anomaly detection: Verification is performed using "basic attribute sampling + anomaly log screening". Basic attribute sampling verification: Metadata basic attributes are sampled and verified (sampling ratio ≥ 10%); Anomaly log screening: Only serious anomaly logs in the database (such as database crash logs, malicious attack logs) are screened.

[0178] Alarm handling: If the response time is ≤2 hours, a system alarm will be triggered and handled by the maintenance personnel on a weekly basis.

[0179] Log recording: Record exception logs and retain them for at least 3 months.

[0180] Resource conflict resolution mechanism: To avoid resource contention between regulatory enforcement and the operation of power-sensitive database services, a resource conflict resolution mechanism of "load monitoring - resource adjustment - breakpoint resumption" is established.

[0181] Real-time load monitoring: Monitor load metrics such as CPU utilization, memory usage, disk I / O, and concurrent connections in real time using database monitoring tools (such as Zabbix and Prometheus), with a monitoring frequency of once per second.

[0182] Resource conflict determination: When the load index reaches the preset threshold (such as CPU utilization > 80%), it is determined to be a resource conflict, triggering the resource adjustment process.

[0183] Resource adjustment strategy:

[0184] Mild conflict (CPU utilization 80%-85%): Reduce the monitoring frequency of R2 and R1 priority levels (e.g., change the full parsing of R2 from once a day to once every two days) to reduce resource consumption;

[0185] Moderate conflict (CPU utilization 85%-90%): Suspend incremental resolution at the R3, R2, and R1 priority levels, and only retain supervisory execution at the R5 and R4 priority levels;

[0186] Severe conflict (CPU utilization > 90%): Only R5-level real-time incremental parsing and anomaly detection are retained, while all other ownership-level regulatory executions are suspended to ensure the normal operation of core businesses.

[0187] Resume execution mechanism: Paused monitoring tasks record breakpoint information (such as pause time, range of parsed metadata, and incomplete detection items). When the load returns to normal (CPU utilization ≤ 70% for 10 minutes), monitoring execution resumes from the breakpoint to avoid repeated parsing and detection and ensure uninterrupted monitoring.

[0188] Enhanced supervision for special scenarios: For special scenarios in the power industry (such as grid maintenance, power supply for major events, and large-scale grid connection of new energy sources), a strengthened supervision mechanism will be established to temporarily increase the regulatory intensity of relevant metadata.

[0189] Scene recognition: Identify the start and end times of special scenes, the business modules involved, and the scope of metadata through business system interface calls or manual input;

[0190] Regulatory adjustments: The metadata authority level will be automatically upgraded by 1-2 levels (e.g., during power grid maintenance, the metadata authority level related to maintenance will be upgraded from P4 to P5), and the corresponding regulatory authority level will be upgraded accordingly. Regulatory configurations will be executed according to the upgraded authority level.

[0191] Recovery mechanism: After the special scenario ends, the metadata authority level and regulatory authority level will be automatically restored to their original state to ensure that no additional resources are occupied for a long time.

[0192] S7: Closed-loop optimization and dynamic adaptation

[0193] Closed-loop optimization indicator system: Establish a closed-loop optimization indicator system to evaluate the effectiveness of each stage of the regulatory method through quantitative indicators and determine the direction of optimization.

[0194] Metadata classification indicators: accuracy of weight level determination (target ≥ 99%), rationality of weight adjustment (match between adjusted weight level and actual business ≥ 98%), and stability of weight level (number of weight level changes ≤ 2 times within a quarter).

[0195] Weighted matching metrics: Matching success rate (target ≥ 99.5%), Matching time (target ≤ 10 seconds), Matching anomaly rate (target ≤ 0.5%).

[0196] Regulatory enforcement indicators: Anomaly identification accuracy (target ≥ 95%), anomaly underreporting rate (target ≤ 1%), anomaly false alarm rate (target ≤ 0.5%), resource consumption rate (target ≤ 10%), and business impact (target ≤ 0.1%).

[0197] Dynamic adaptation indicators: policy adaptation timeliness rate (target ≥ 99%), business change adaptation timeliness rate (target ≥ 98%), and security incident response timeliness rate (target ≥ 99%).

[0198] Collect the above-mentioned indicator data monthly, generate a closed-loop optimization indicator evaluation report, identify indicators that do not meet the standards (such as false alarm rate of 0.8% > 0.5%), and determine the key areas for optimization.

[0199] A four-layer closed-loop optimization process is established: "Metadata weight optimization → Metadata weight level correction → Regulatory configuration adjustment → Matching rule update". Each layer of optimization is based on the evaluation results of the previous layer and actual needs.

[0200] First layer: Metadata weight optimization (based on security incidents and regulatory effectiveness)

[0201] Optimize trigger conditions: ① Security event correlation degree ≥ 0.3 (refer to S3 weight dynamic adjustment mechanism); ② Metadata classification indicators do not meet the standards (e.g., the accuracy rate of weight level determination is 98% < 99%); ③ Regulatory enforcement indicators do not meet the standards (e.g., the anomaly underreporting rate is 1.2% > 1%).

[0202] Optimization methods: For indicators with high correlation to safety events, increase their weight (adjustment range ≤ 20% of initial weight); for indicators that lead to inaccurate weight determination, adjust their quantitative standards (e.g., refine the 5-point judgment standard for "dispatch instruction correlation" from "closely correlated" to "directly correlated with dispatch instruction generation and execution"); for indicators that lead to missed anomaly reports, increase their weight or optimize the indicator definition (e.g., supplement the "energy storage data correlation" indicator).

[0203] Optimized output: Updated metadata dimensions and indicator weight table, revised indicator quantification standard.

[0204] Second layer: Metadata weight-level correction (based on weight optimization and regulatory feedback)

[0205] Correction trigger conditions: ① After the metadata weight optimization is completed; ② During the supervision process, a mismatch is found between the weight level and the actual security risk (such as frequent high-risk anomalies in P3 weight level metadata); ③ Expert review finds that the weight level determination is incorrect.

[0206] Correction method: Based on the updated weight table, recalculate the weighted score and weight level of all metadata; for high-risk, low-weight metadata reported by regulators, manually review and increase its weight level; for low-risk, high-weight metadata, manually review and decrease its weight level.

[0207] Corrected output: Corrected metadata weight level tag set, weight level correction record.

[0208] Third layer: Regulatory configuration adjustment (based on authority level correction and resource consumption feedback)

[0209] Adjustment trigger conditions: ① After the metadata authority level correction is completed (e.g., the proportion of P5 authority level metadata increases); ② Regulatory execution indicators are not met (e.g., resource consumption rate 12% > 10%); ③ Frequent resource conflicts (≥ 5 severe conflicts per month).

[0210] Adjustment methods: If the proportion of high-priority metadata increases, expand the resource pool for the corresponding regulatory authority level (e.g., increase the CPU proportion of R5 authority level from 8%-10% to 10%-12%); if the resource consumption rate exceeds the standard, optimize the regulatory frequency of low-priority metadata (e.g., change the full parsing of R1 authority level from once a week to once every two weeks); if resource conflicts are frequent, refine the resource elastic allocation rules (e.g., add a rule to "suspend full verification of R3 authority level when there is a moderate conflict").

[0211] Output adjustments: Updated regulatory authority-level weighted configuration table and revised resource elastic allocation rules.

[0212] Fourth layer: Matching rule update (based on weight level correction and matching anomalies)

[0213] Update trigger conditions: ① Metadata weight level correction completed; ② Matching indicators not met (e.g., matching anomaly rate 0.8% > 0.5%); ③ Frequent adjustment needs in special scenarios (e.g., ≥ 3 temporary business adjustments per month).

[0214] Update method: If the metadata authority level range is adjusted (such as adding a new P6 authority level), add the corresponding regulatory authority level (R6) and matching rules; if the matching anomaly rate is high, optimize the flexible adjustment rules (such as refining the load threshold judgment criteria during peak business periods); if there are frequent temporary adjustment needs, convert commonly used temporary adjustment rules into fixed flexible rules (such as "during power grid maintenance, the authority level of maintenance-related metadata is automatically upgraded by 1 level").

[0215] Updated output: Updated weight-level matching rule set and matching rule engine configuration file.

[0216] Dynamic adaptation mechanism:

[0217] Business Change Adaptation: When new power businesses are added (such as virtual power plants, energy storage dispatch) or adjusted, corresponding indicators (such as "virtual power plant dispatch correlation" and "energy storage charging and discharging data correlation") are added to the parsing dimension system of S1, weights are assigned in S3, and regulatory configurations are adjusted in S4 to ensure that the metadata of new businesses is effectively regulated.

[0218] Policy update adaptation: Track policy updates. If a new sensitive data type (such as "electricity market transaction data") is added to the policy, a corresponding indicator (such as "electricity market transaction correlation") will be added to the analysis dimension system, the weight of the relevant indicator will be increased, and the regulatory configuration will be adjusted (such as setting the metadata weight level corresponding to the transaction data to P4 or above).

[0219] Security incident adaptation: After a major security incident occurs, the emergency optimization process is initiated to complete the adjustment of relevant indicator weights, correction of metadata weight levels, and strengthening of regulatory configurations within 24 hours to prevent similar incidents from happening again.

[0220] Finally, it should be noted that the above embodiments are merely examples for clearly illustrating the present invention and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A lightweight regulatory method for power-sensitive databases based on metadata parsing, characterized in that, Includes the following steps: S1: Construct an analytical dimension system that includes business coreness, security risk, data sensitivity attributes, dynamic attributes, and electricity-specific indicators, and determine the benchmark weights of each analytical dimension and indicator; Metadata weight mapping rules: Initialize 5 levels of metadata weights, namely P1-P5, where P5 is the highest, and set the weighted score interval mapping relationship; Weighted score = Σ (each indicator value × indicator baseline weight), with indicator values ​​quantified using a 1-5 point system; Regulatory authority matching rules: Initialize a one-to-one mapping between metadata authority level and regulatory authority level, providing a basic association for subsequent regulatory configuration; S2: Collect metadata from multiple sources according to the dimensions of S1 parsing, and output standardized metadata after preprocessing, including data type standardization, indicator value standardization, and field naming standardization. Establish a data quality verification indicator system. For data that fails the verification, trigger an anomaly alarm and re-collect data. If the data still fails after three collections, it is marked as abnormal metadata and included in the manual review process. S3: Based on the baseline weight of the S1 indicator and the standardized metadata of S2, the score is calculated according to the weighted summation formula and mapped to the P1-P5 metadata weight levels; The weighted summation formula is: ,in: For the first The benchmark weight of each indicator, For the first The quantified value of each indicator; The calculated weighted scores are mapped to five levels of metadata weights, P1-P5. After the initial weight level determination, a weight level label is generated for each piece of metadata. S4: Define four dimensions of supervision: resource input, verification depth, response priority, and supervision frequency, configure differentiated standards for the five levels of supervision authority from R1 to R5, and establish a flexible resource allocation mechanism; The five levels of regulatory authority correspond to different resource input weights and are matched with different levels of response priority weights. It constructs a four-dimensional regulatory weighting dimension, which includes resource input weight, verification depth weight, response priority weight, and regulatory frequency weight. Each dimension is positively correlated with the metadata authority level. That is, the higher the metadata authority level, the stronger the configuration of the regulatory weighting dimension, while also taking into account resource consumption control. Strengthen the configuration of the five-level regulatory authority, that is, based on the principle that the higher the metadata authority level, the higher the intensity of the regulatory weighting dimension configuration, set configuration standards for the five-level regulatory authority, and the four-dimensional weighting dimension configuration of each regulatory authority level is coordinated with each other; The resource elastic allocation mechanism is: During normal load, resources are allocated according to the regulatory authority-level configuration standard; When under high load, reduce the resource allocation weights of R2 and R1 weight levels, suspend the full verification of R1 weight level, and postpone its execution until the load returns to normal. When under extremely high load, only the resource allocation of R5 and R4 priority levels is guaranteed, incremental parsing and full verification of R3, R2 and R1 priority levels are suspended, and the breakpoint resume mechanism is activated. After the load drops to a normal level, monitoring is resumed from the pause point to ensure uninterrupted monitoring. S5: Build a matching engine to achieve real-time matching of metadata authority level and regulatory authority level through rigid matching rules and flexible adjustment rules; S6: Implement differentiated supervision based on matching authority level to handle resource conflicts; S7: Establish a quantitative indicator system, and optimize it through closed-loop and dynamically adapt it to match changes in the scenario.

2. The lightweight regulatory method for power-sensitive databases based on metadata parsing as described in claim 1, characterized in that, The S5 matching engine is a weighted dynamic matching rule engine, which includes a rule layer, an execution layer, and a verification layer. The rigid matching rule has a matching time of ≤10 seconds, while the flexible adjustment rule is designed for special scenarios related to peak business periods, major security incidents, and temporary business needs, allowing for dynamic adjustment of the rigid matching results.

3. The lightweight regulatory method for power-sensitive databases based on metadata parsing as described in claim 1, characterized in that, S6's regulatory execution executes the corresponding regulatory operations based on the matched regulatory authority level. The regulatory execution of each authority level is based on four processing steps: metadata parsing, anomaly detection, alarm handling, and log recording.

4. A lightweight monitoring system for power-sensitive databases based on metadata parsing, implementing the method as described in any one of claims 1 to 3, characterized in that: The basic construction layer includes a power-specific parsing rule construction unit, a metadata collection and preprocessing unit, and a hierarchical regulatory configuration unit. The power-specific parsing rule construction unit performs the parsing dimension system construction and indicator benchmark weight setting in step S1. The metadata collection and preprocessing unit performs the metadata collection and preprocessing function in step S2. The hierarchical regulatory configuration unit performs the four-dimensional regulatory dimension definition and five-level regulatory authority differentiated configuration and resource elastic allocation mechanism establishment functions in step S4. The core execution layer includes a metadata weight-level classification unit, a weight-level dynamic matching unit, and a lightweight supervision execution unit. The metadata weight-level classification unit performs the weighted calculation and indicator weight adjustment in step S3. The weight-level dynamic matching unit performs the weight-level dynamic matching rule engine construction, rigid matching rule and flexible adjustment rule matching and exception handling functions in step S5. The lightweight supervision execution unit performs differentiated supervision and resource conflict handling in step S6. The optimization and adaptation layer includes a closed-loop optimization unit and a dynamic adaptation unit, which together perform the quantitative indicator system establishment of the S7 steps, closed-loop optimization and dynamic adaptation to match scene changes.

Images