IDC machine room equipment data management method and device, medium and electronic equipment

Abstract

The invention discloses an equipment data management method and device of an IDC machine room, a medium and electronic equipment, and relates to the technical field of data management, and the method comprises the steps that index definition and mapping rules of a data source are uniformly stored in a configuration center, and the configuration center externally provides an interface template; the request source registers in the configuration center and pulls the connection information, the encryption credential and the interface template; according to the interface template, generating connection configuration for connection; according to the invention, the original index definition, the target index definition and the mapping rule of each data source are uniformly stored in the configuration center, and a standardized interface template is provided for the outside, so that an administrator can realize visual management and versioning control of indexes and mapping, and after the configuration is changed, the configuration center automatically pushes and updates to all on-line acquisition nodes, so that the management efficiency is improved. Manual one-by-one modification is not needed, so that the risk of manual configuration errors is reduced, and the operation and maintenance efficiency and the system maintainability are greatly improved.

Description

Technical Field

[0001] The present invention relates to the technical field of data management, and in particular to a method, device, medium and electronic equipment for managing equipment data in an IDC computer room. Background Art

[0002] With the large-scale deployment of various business systems and cloud services, the operating indicators generated by servers, storage devices, network equipment, cooling and power supply equipment in IDC (computer room) are characterized by large number, diverse types and frequent updates. Each equipment manufacturer defines a variety of original monitoring indicators for its own products, and their naming conventions, data types and collection interfaces are different. As a result, the computer room operation and maintenance system needs to maintain a large number of configuration files scattered in various collection plug-ins or scripts. At the same time, the mapping relationship and subscription strategy of equipment indicators lack unified management. When adding new equipment or adjusting monitoring items, manual editing, batch distribution or service restart are often required, resulting in high operation and maintenance costs and easy problems. Wrong. The conversion logic from raw indicators to unified target indicators is usually embedded in the code of each plug-in, which does not support online updates or version rollbacks. Once the rules are changed, the system needs to be shut down for upgrades. Each node also lacks efficient data quality verification and reliable storage mechanisms. Data loss or duplicate writing is prone to occur during network jitter or database failure. The existing solution cannot meet the dynamic configuration management, real-time mapping conversion and high-availability data collection requirements in large-scale, multi-tenant, heterogeneous equipment environments. There is an urgent need for a data management method for computer room equipment that combines centralized configuration, online hot updates, streaming conversion and reliable storage to improve the system's maintainability, scalability and data integrity. Existing data management systems store indicator definitions and mapping rules in local configuration files or hard-coded formats. Configurations are scattered across multiple instances, lacking unified management. Configuration changes must be manually updated on each instance or distributed in batches via scripts, which can easily lead to omissions and version inconsistencies. In view of the above technical defects, a solution is now proposed. Summary of the Invention

[0003] In view of the deficiencies in the prior art, the present invention provides a method, apparatus, medium and electronic equipment for managing equipment data in an IDC computer room.

[0004] To achieve the above objectives, the present invention is implemented through the following technical solutions: a method, apparatus, medium and electronic equipment for managing device data in an IDC computer room, including: S1. The indicator definitions and mapping rules of the data source are uniformly stored in the configuration center, and the configuration center provides interface templates to the outside world; S2. The request source registers with the configuration center and pulls connection information, encryption credentials, and interface templates; generates a connection configuration based on the interface template and connects; S3. Use SchemaRegistry to manage the mapping rules between original indicators and target indicators; S4. The request source initiates a data query request to the data source interface according to the connection configuration. The data source returns the original indicator requested from the last timestamp to the SchemaRegistry. The SchemaRegistry maps it according to the mapping rules and sends it to the request source. S5. The upload source converts the received original indicators into target indicators through the streaming ETL engine and performs numerical verification; SchemaRegistry pushes the converted target indicator data into the database and returns a confirmation message ACK to the upload source after successful storage.

[0005] The configuration center maintains an original indicator library, in which the original indicator records include: indicator unique identifier, indicator name, data type, unit, upper and lower limits, default sampling frequency and description information; The configuration center maintains a target indicator library, wherein the target indicator records in the library include: target indicator unique identifier, business semantic label, data type, unit, grouping information and default alarm threshold; The configuration center maintains a mapping rule set, in which each rule defines the corresponding relationship between the source original indicator and the target indicator, the conversion type and the rule version.

[0006] The request source sends a registration request message to the configuration center, which grants the corresponding access permission domain and role based on the certificate signature; the configuration center issues an interface template in IDL format; the request source uses connection information, credential reference, log, monitoring configuration, and current limiting elements to generate a connection configuration for connection.

[0007] The configuration center introduces the SchemaRegistry component to centrally manage the mapping rules between original and target indicators. This includes: submitting a mapping rule document in JSONSchema format through an API, describing the original indicator name, target indicator name, field type, field meaning, default value, and conversion expression. The SchemaRegistry generates a globally unique SchemaID for each rule and persistently stores the rule and its metadata. Rules are then grouped by data source, and request sources can use the SchemaID and rule name to batch pull and incrementally update the latest rules through the subscription API. During the data query and push process, the request source performs field renaming, data type conversion, unit conversion, and expression-based derived field calculations according to the pulled rules to generate structured target indicators.

[0008] The request source sends a login request to the target data source, the login request carries the credentials and the plug-in identifier, then receives a session token returned by the target data source, and stores the token and the corresponding key in a local secure cache in the form of a key-value pair; The login request contains the plug-in identifier, session token, list of raw indicators to be subscribed, and subscription mode identifier; in the timed pull mode, a query request is initiated to the target data source according to the configured polling period, and the request carries the timestamp of the last pull and the session token; it is used to receive the newly added and changed raw indicator data and the latest timestamp returned by the target data source, and update the pull timestamp; SchemaRegistry verifies whether the SchemaID in the message header is consistent with the mapping rule version of the request source; if they are consistent, it calls the mapping engine to perform field renaming, type conversion, unit conversion, and custom expression calculation to generate a target indicator set that conforms to the target model. The target indicator set is grouped and encapsulated into a dispatch message, which is reliably delivered to the request source through the message queue and HTTPPush callback.

[0009] After the upload source receives the target indicators issued by the SchemaRegistry, it pushes them into the streaming ETL engine ingestion pipeline, performs field existence, data type and range checks based on the target Schema, and fills default values, discards or tags abnormal records according to the strategy.

[0010] The upload source calls the computing component to generate derived fields for indicators that need to be aggregated in real time; then, based on the metadata service, device information, geographic location, and business tags are added to enrich the data; the cleaned and enriched data is cached by batch size and written to the database in parallel through a distributed queue or a direct connection adaptation layer; after the database cluster completes the write, it returns a confirmation message ACK containing the start and end timestamps and the number of rows.

[0011] The device comprises: The configuration center manages the original indicators and target indicator definitions and mapping rules of all data sources, and provides interface templates to the outside world. It persistently stores the original indicator library and the target indicator library and maintains the mapping rule set. The configuration center uses the registration API for the request source to pull connection information, encryption credentials and interface templates to generate subsequent data access configurations. SchemaRegistry is responsible for centrally managing the mapping rules from original indicators to target indicators, assigning a unique SchemaID to each rule and storing it persistently; rules are published according to data source tags for request sources to pull in batches or incrementally through subscription APIs; during data query and push, SchemaRegistry calls the mapping engine to perform field renaming, data type conversion, unit conversion, and expression calculation, and ultimately outputs structured target indicators.

[0012] Equipment data management equipment in the IDC room includes: at least one processor; at least one memory for storing a plurality of programs; When the at least one program is executed by the at least one processor, the at least one processor implements the equipment data management method for the IDC computer room as claimed in any one of claims 1 to 7.

[0013] The processor-executable instructions are used to execute the equipment data management method for the IDC computer room as described in any one of claims 1 to 7 when executed by the processor.

[0014] The present invention provides a method, device, medium, and electronic device for managing device data in an IDC computer room. Compared with the prior art, it has the following advantages: The present invention stores the original indicator definitions, target indicator definitions, and mapping rules of the data source in a unified manner in the configuration center, and provides a standardized interface template to the outside world. This enables administrators to visually manage indicators and mappings. After configuration changes, the configuration center pushes updates to all online collection nodes, eliminating the need for manual modifications on each node. This reduces the risk of manual configuration errors and significantly improves operation and maintenance efficiency and system maintainability. The present invention introduces SchemaRegistry to centrally manage mapping rules and assigns a unique SchemaID to each rule. SchemaRegistry supports multiple mapping methods, including direct mapping, linear function, script mapping, and enumeration mapping, and can be updated incrementally online. This mechanism allows the system to only update mapping rules when new devices are connected or original indicators are changed, without having to modify the code, significantly enhancing compatibility with heterogeneous data sources and system scalability. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a schematic diagram of the principle framework of the present invention. DETAILED DESCRIPTION

[0016] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0017] See also Figure 1 ,This application provides a device data management method, apparatus, medium and electronic equipment for an IDC computer room, including: S1, storing the indicator definition and mapping rules of the data source in a unified manner in a configuration center, and the configuration center provides an interface template to the outside; S2. The request source registers with the configuration center and pulls connection information, encryption credentials, and interface templates; generates a connection configuration based on the interface template and connects; S3. Use SchemaRegistry to manage the mapping rules between original indicators and target indicators; S4. The request source initiates a data query request to the data source interface according to the connection configuration. The data source returns the original indicator requested from the last timestamp to the SchemaRegistry. The SchemaRegistry maps it according to the mapping rules and sends it to the request source. S5. The upload source converts the received original indicators into target indicators through the streaming ETL engine and performs numerical verification; SchemaRegistry pushes the converted target indicator data into the database and returns a confirmation message ACK to the upload source after successful storage.

[0018] The configuration center maintains the original indicator library. The original indicator records in the library include: indicator unique identifier, indicator name, data type, unit, upper and lower limits, default sampling frequency and description information; The configuration center maintains a target indicator library. The target indicator records in the library include: target indicator unique identifier, business semantic label, data type, unit, grouping information, and default alarm threshold; The configuration center maintains a mapping rule set. Each rule in the rule set defines the correspondence between the source original indicator and the target indicator, the conversion type, and the rule version.

[0019] The configuration center persistently stores the original indicator library in a relational database or distributed metadata storage. Each record in the original indicator library includes: MetricID, which is used to globally uniquely identify the metric; Metric name (MetricName) and detailed description (Description); Data type (DataType), including integer, floating point, Boolean or enumeration; Unit (Unit), such as "℃", "%RH", "Mbps", etc.; The upper and lower limits of the value (MinValue, MaxValue); Default sampling frequency (DefaultInterval), in seconds; Device type and status (Enabled / Disabled); Multi-dimensional indexing of the original indicator database, including indexing by MetricID, DeviceType, DataType, and update time, to support efficient query and paging retrieval; The configuration center maintains a target indicator database in the same storage system. Each record in the target indicator database includes: Target indicator unique identifier (TargetID); Business semantic tags (SemanticTag), such as "cabinet inlet temperature" and "power supply output current"; The data type (DataType) and unit (Unit) are consistent with the original indicator library format; Indicator group information (GroupID), such as "environmental monitoring group" and "power monitoring group"; Default alarm thresholds (WarnHigh, WarnLow) and corresponding alarm levels (Severity); Visual display properties (DisplayFormat), such as the number of decimal places and chart type; Supports multi-language localization of target indicators, including multi-language versions of indicator names and descriptions.

[0020] The configuration center maintains a mapping rule set. Each rule in the mapping rule set includes: The source original indicator MetricID list and the corresponding target indicator TargetID; Conversion type (MappingType), including "direct mapping", "linear function mapping", "script mapping" or "enumeration mapping"; Transform expressions or scripts (Expression / Script), which support JavaScript, Python, or SQL UDF for script mapping; Rule version number (Version) and effective time window (EffectiveFrom, EffectiveTo); Conflict resolution strategy (ConflictPolicy), such as "Last published first" or "Explicit overwrite"; All mapping rules are versioned: Administrators can submit new versions through the interface or API. The system automatically retains historical versions and supports rollback by version.

[0021] The request source sends a registration request message to the configuration center, which grants the corresponding access permission domain and role based on the certificate signature. The configuration center issues an interface template in IDL format. The request source uses connection information, credential references, logs, monitoring configuration, and current limiting elements to generate a connection configuration for connection.

[0022] The configuration center introduces the SchemaRegistry component to centrally manage the mapping rules between source and target metrics. This includes submitting mapping rule documents in JSON Schema format through the API, describing the source metric name, target metric name, field type, field meaning, default value, and conversion expression. SchemaRegistry generates a globally unique SchemaID for each rule and persistently stores the rule and its metadata. Rules are then grouped by data source, and request sources can use the SchemaID and rule name to batch pull and incrementally update the latest rules through the subscription API. A new Schema Registry module has been added to the Configuration Center to centrally manage the mapping rules from source metrics to target metrics. The process involves operations or developers submitting mapping rules in JSON Schema or Avro Schema format in the console (or through the API), specifying the source field name, target field name, data type, default value, and conversion expression. A unique SchemaID and metadata are automatically generated. When rules are updated, the Registry automatically verifies differences between the new and old rules based on full compatibility, forward compatibility, or backward compatibility policies, rejects incompatible changes, and returns a difference report. After approval, rules are published by data source group or tag. Requesters can use the SchemaID or name to pull the latest rules or incremental updates through the subscription API. At runtime, the requester passes the pulled rules to the built-in mapping engine to perform field renaming, type conversion, unit conversion, and expression-based derived field calculations to generate target metrics that meet the requirements of the target system. The Schema Registry also monitors the number of rule calls, success rate, average latency, and error distribution in real time, and maintains a complete change history and call log to ensure traceability and compliance of the mapping process.

[0023] The present invention stores the original indicator definitions, target indicator definitions, and mapping rules of the data source in a unified manner in the configuration center, and provides a standardized interface template to the outside world. This enables administrators to visually manage indicators and mappings. After configuration changes, the configuration center pushes updates to all online collection nodes, eliminating the need for manual modifications on each node. This reduces the risk of manual configuration errors and significantly improves operation and maintenance efficiency and system maintainability. During the data query and push process, the request source performs field renaming, data type conversion, unit conversion, and expression-based derived field calculations according to the pulled rules to generate structured target indicators.

[0024] The request source sends a login request to the target data source, which carries the credentials and plug-in identifier. The target data source then receives a session token and stores the token and the corresponding key in a local secure cache as a key-value pair. The request source sends a login request to the target data source through the TLS / SSL channel based on the target data source address, port, communication protocol, and encryption credentials obtained from the configuration center. The login request payload contains at least the plugin ID and credentials. After the target data source verifies the credentials, it returns a session token with an expiration time. The request source stores the SessionToken and the corresponding key as a key-value pair in the local secure cache and sets an automatic refresh timer for the token, with the trigger interval being less than 75% of the token expiration time. When the token refresh timer is triggered, the request source automatically sends a token renewal request to the target data source to ensure the continued validity of the persistent connection and subscription session. After login, the request source constructs a subscription request, which includes the plugin identifier, the current valid session token, a list of raw indicator identifiers to be subscribed, and the selected subscription mode identifier (real-time push or scheduled pull). In scheduled pull mode, the request source starts the scheduled task according to the polling cycle issued by the configuration center. Each time a scheduled task is triggered, the request source sends a data query request to the target data source, and the request carries the timestamp of the last successful pull (LastTimestamp) and the current SessionToken The login request contains the plugin identifier, session token, list of raw metrics to be subscribed, and subscription mode identifier. In the scheduled pull mode, a query request is sent to the target data source according to the configured polling period. The request carries the timestamp of the last pull and the session token. The request is used to receive the newly added and changed raw metric data and the latest timestamp returned by the target data source, and update the pull timestamp. The request source sends a login request to the target data source through the TLS channel based on the connection information and credentials issued by the configuration center. The request payload includes the plugin's unique identifier (PluginID) and authentication credentials. After the data source verifies the credentials, it returns a session token (SessionToken). The plugin stores this token and the corresponding key as a key-value pair in the local secure cache and includes this token in all subsequent requests. After receiving the query request, the data source retrieves the raw indicator data that has been added or changed since the LastTimestamp and includes the maximum timestamp (NewTimestamp) of this data in the response. After receiving the response, the request source updates the NewTimestamp to the LastTimestamp of the next query to ensure that no data is missed or duplicated. The request source calls the mapping engine to perform the following operations in sequence: Field renaming: rename the original indicator field to the target indicator field name according to the mapping rules; Data type conversion: convert the original data type (String, Float, Int, etc.) to the target type and perform overflow or precision checks; Unit conversion: convert the original value from the source unit to the target unit according to the conversion factor in the rule; Expression-based derivative calculation: Executes custom expressions or scripts defined in the rule, calculates derived field values, and appends them to the target record; After the mapping conversion is completed, the request source groups all target indicator records according to business groups or batch sizes to generate several messages to be sent; the request source reliably delivers the messages to be sent to the upstream system through a dual-channel method of high-throughput message queues (such as Kafka) and HTTP Push callbacks; for each sent message, the request source maintains an ACK timer locally and clears the corresponding timer after receiving the confirmation message returned by the upstream system; if the ACK is not received within the timeout, the message is resent according to the exponential backoff strategy, and messages that exceed the maximum number of retries are written to the local dead letter queue and trigger an alarm.

[0025] SchemaRegistry verifies whether the SchemaID in the message header is consistent with the mapping rule version of the request source; if they are consistent, it calls the mapping engine to perform field renaming, type conversion, unit conversion, and custom expression calculation to generate a target indicator set that conforms to the target model. The target indicator set is grouped and encapsulated into a dispatch message, which is reliably delivered to the request source through the message queue and HTTPPush callback.

[0026] After the upload source receives the target indicators issued by the SchemaRegistry, it pushes them into the streaming ETL engine ingestion pipeline, performs field existence, data type and range checks based on the target Schema, and fills default values, discards or tags abnormal records according to the strategy.

[0027] The upload source performs streaming calculations on the target metrics that require real-time statistics or aggregation based on predefined aggregation window configurations (such as sliding window length and sliding step size). Use the Compute Engine to perform aggregation functions (such as sum, count, average, maximum / minimum values) on the data within the aggregation window and generate intermediate aggregation results; For business indicators that require complex derivations, the uploaded source calls the derivative calculation module, which calculates derived fields based on the original and aggregated results according to pre-configured functions or scripts (such as script mapping and UDF) and appends them to the data stream.

[0028] For indicators that require real-time aggregation, the upload source calls the computing component to complete the generation of derived fields. It then enriches the data by adding device information, geographic location, and business tags based on the metadata service. The cleaned and enriched data is cached by batch size and written to the database in parallel through a distributed queue or a direct connection adapter layer. After completing the write, the database cluster returns an acknowledgment message ACK containing the start and end timestamps and the number of rows.

[0029] After successfully writing each batch, the database cluster returns an acknowledgment message (ACK) containing the start and end timestamps (StartTimestamp, EndTimestamp) and the number of rows written (RowCount). The upload source clears the corresponding cached batch after receiving the ACK. If the ACK is not received within the timeout period, the batch is resent according to the retry strategy (such as fixed interval retry, exponential backoff). Batches that fail after the maximum number of retries will be transferred to the local persistent "dead letter queue" and trigger the alarm process for manual intervention or automatic downgrade processing. The device includes: The configuration center manages the original indicators and target indicator definitions and mapping rules of all data sources, and provides interface templates to the outside world. It persistently stores the original indicator library and the target indicator library and maintains the mapping rule set. The configuration center uses the registration API for the request source to pull connection information, encryption credentials and interface templates to generate subsequent data access configurations. SchemaRegistry is responsible for centrally managing the mapping rules from original indicators to target indicators, assigning a unique SchemaID to each rule and storing it persistently; rules are published according to data source tags for request sources to pull in batches or incrementally through subscription APIs; during data query and push, SchemaRegistry calls the mapping engine to perform field renaming, data type conversion, unit conversion, and expression calculation, and ultimately outputs structured target indicators.

[0030] Equipment data management equipment in the IDC room includes: at least one processor; at least one memory for storing a plurality of programs; When at least one program is executed by at least one processor, the at least one processor implements the device data management method for an IDC computer room as claimed in any one of claims 17 .

[0031] The processor-executable instructions are used to execute the equipment data management method for an IDC computer room as described in any one of claims 1 to 7 when executed by the processor.

[0032] The present invention introduces SchemaRegistry to centrally manage mapping rules and assigns a unique SchemaID to each rule. SchemaRegistry supports multiple mapping methods, including direct mapping, linear function, script mapping, and enumeration mapping, and can be updated incrementally online. This mechanism allows the system to only update mapping rules when new devices are connected or original indicators are changed, without having to modify the code, significantly enhancing compatibility with heterogeneous data sources and system scalability.

[0033] Some of the data in the above formulas are dimensionless and numerically calculated. Meanwhile, the contents not described in detail in this specification belong to the prior art known to those skilled in the art.

[0034] The above embodiments are only used to illustrate the technical method of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical method of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical method of the present invention.

Claims

1. The device data management method of the IDC computer room is characterized by: include: S1. The indicator definitions and mapping rules of the data source are uniformly stored in the configuration center, and the configuration center provides interface templates to the outside world; S2. The request source registers with the configuration center and pulls connection information, encryption credentials, and interface templates; generates a connection configuration based on the interface template and connects; S3. Use SchemaRegistry to manage the mapping rules between original indicators and target indicators; S4. The request source initiates a data query request to the data source interface according to the connection configuration. The data source returns the original indicator requested from the last timestamp to the SchemaRegistry. The SchemaRegistry maps it according to the mapping rules and sends it to the request source. S5. The upload source converts the received original indicators into target indicators through the streaming ETL engine and performs numerical verification; SchemaRegistry pushes the converted target indicator data into the database and returns a confirmation message ACK to the upload source after successful storage.

2. The device data management method for an IDC computer room according to claim 1, characterized in that: The configuration center maintains an original indicator library, in which the original indicator records include: indicator unique identifier, indicator name, data type, unit, upper and lower limits, default sampling frequency and description information; The configuration center maintains a target indicator library, wherein the target indicator records in the library include: target indicator unique identifier, business semantic label, data type, unit, grouping information and default alarm threshold; The configuration center maintains a mapping rule set, in which each rule defines the corresponding relationship between the source original indicator and the target indicator, the conversion type and the rule version.

3. The device data management method for an IDC computer room according to claim 1, characterized in that: The request source sends a registration request message to the configuration center, which grants the corresponding access permission domain and role based on the certificate signature; the configuration center issues an interface template in IDL format; the request source uses connection information, credential reference, log, monitoring configuration, and current limiting elements to generate a connection configuration for connection.

4. The device data management method for an IDC computer room according to claim 1, characterized in that: The configuration center introduces the SchemaRegistry component to centrally manage the mapping rules between original and target indicators. This includes: submitting a mapping rule document in JSONSchema format through an API, describing the original indicator name, target indicator name, field type, field meaning, default value, and conversion expression. The SchemaRegistry generates a globally unique SchemaID for each rule and persistently stores the rule and its metadata. Rules are then grouped by data source, and request sources can use the SchemaID and rule name to batch pull and incrementally update the latest rules through the subscription API. During the data query and push process, the request source performs field renaming, data type conversion, unit conversion, and expression-based derived field calculations according to the pulled rules to generate structured target indicators.

5. The device data management method for an IDC computer room according to claim 1, characterized in that: The request source sends a login request to the target data source, the login request carries the credentials and the plug-in identifier, then receives a session token returned by the target data source, and stores the token and the corresponding key in a local secure cache in the form of a key-value pair; The login request contains the plugin identifier, session token, list of raw metrics to be subscribed, and subscription mode identifier; In the timed pull mode, a query request is sent to the target data source according to the configured polling period. The request carries the timestamp of the last pull and the session token. Used to receive the newly added and changed original indicator data and the latest timestamp returned by the target data source, and update the pull timestamp; SchemaRegistry verifies whether the SchemaID in the message header is consistent with the mapping rule version of the request source; if they are consistent, it calls the mapping engine to perform field renaming, type conversion, unit conversion, and custom expression calculation to generate a target indicator set that conforms to the target model. The target indicator set is grouped and encapsulated into a dispatch message, which is reliably delivered to the request source through the message queue and HTTPPush callback.

6. The device data management method for an IDC computer room according to claim 1, characterized in that: After the upload source receives the target indicators issued by the SchemaRegistry, it pushes them into the streaming ETL engine ingestion pipeline, performs field existence, data type and range checks based on the target Schema, and fills default values, discards or tags abnormal records according to the strategy.

7. The device data management method of an IDC computer room according to claim 1, characterized in that: The upload source calls the computing component to generate derived fields for indicators that need to be aggregated in real time; then, based on the metadata service, device information, geographic location, and business tags are added to enrich the data; the cleaned and enriched data is cached by batch size and written to the database in parallel through a distributed queue or a direct connection adaptation layer; after the database cluster completes the write, it returns a confirmation message ACK containing the start and end timestamps and the number of rows.

8. The equipment data management device of the IDC computer room is characterized by: The device comprises: The configuration center manages the original indicators and target indicator definitions and mapping rules of all data sources, and provides interface templates to the outside world. It persistently stores the original indicator library and the target indicator library and maintains the mapping rule set. The configuration center uses the registration API for the request source to pull connection information, encryption credentials and interface templates to generate subsequent data access configurations. SchemaRegistry is responsible for centrally managing the mapping rules from original indicators to target indicators, assigning a unique SchemaID to each rule and storing it persistently; rules are published according to data source tags for request sources to pull in batches or incrementally through subscription APIs; during data query and push, SchemaRegistry calls the mapping engine to perform field renaming, data type conversion, unit conversion, and expression calculation, and ultimately outputs structured target indicators.

9. The equipment data management equipment of the IDC computer room is characterized by: include: at least one processor; at least one memory for storing a plurality of programs; When the at least one program is executed by the at least one processor, the at least one processor implements the equipment data management method for the IDC computer room as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium storing instructions executable by a processor, characterized in that: The processor-executable instructions are used to execute the equipment data management method for the IDC computer room as described in any one of claims 1 to 7 when executed by the processor.

Images