A method, system, device and medium for determining a state of use of a bare metal resource

Abstract

The application relates to the field of bare metal resource processing, in particular to a bare metal resource use state determination method, system, device and medium, the method comprising: determining a query start time and a query end time of a query area; for any preconfigured bare metal resource related business table, determining an effective start snapshot record of the query start time and a change history snapshot record of a target statistical interval; applying the change history snapshot record in the order of snapshot time, forming a continuous resource state evolution sequence in the target statistical interval; taking the bare metal device as the association main shaft at each time node of the resource state evolution sequence, fusing the plurality of preconfigured bare metal resource related business tables, and constructing a bare metal business state portrait of the bare metal device at the time; and calculating a resource analysis index according to the bare metal business state portrait corresponding to each time node of the resource state evolution sequence.

Description

Technical Field

[0001] This application relates to the field of bare metal resource processing, and in particular to a method, system, device and medium for determining the usage status of bare metal resources. Background Technology

[0002] In bare metal computing platforms, the platform typically needs to analyze the historical usage of resources, such as the number of registered, used, recycled, reserved, restricted, peak concurrent usage, and usage duration of bare metal resources in a certain region or time period, in order to support operational analysis, capacity planning, scheduling optimization, and resource management decisions.

[0003] In existing technologies, common resource status statistics methods mainly fall into the following categories. The first category involves directly performing real-time aggregation queries based on the current business database. This method can only obtain the current status and cannot accurately answer historical analysis questions such as whether a resource was in use at a specific historical moment, when the peak concurrency occurred within an hour, or the duration of resource usage within a certain time interval. The second category involves generating full snapshots at fixed intervals, such as saving a resource status cross-section hourly or daily. While this method can support some historical queries, if multiple status changes occur between two snapshot times, it cannot accurately restore the true state at intermediate moments and is difficult to support continuous temporal calculation scenarios such as hourly peak detection and duration accumulation. The third category involves recording resource changes based on database change logs and then restoring historical states through log replay. This type of solution has some role in general data recovery and historical tracing, but it typically focuses more on single-table data recovery, data recovery at a specified point in time, or data disaster recovery backup, lacking multi-table status fusion and interval status progression calculation mechanisms for bare metal resource operation analysis scenarios.

[0004] While database change log replay solutions can recover historical data, their primary design goals are data recovery and disaster recovery backup, typically focusing on single-table data recovery. In bare metal platform scenarios, the final business state of resources is often determined by the combined state of multiple pre-configured bare metal resource-related business tables. Single-table log replay cannot restore the business state after multi-table association, making it difficult to directly use for operational analysis.

[0005] Therefore, how to accurately and comprehensively obtain the state of bare metal is an urgent problem to be solved in this field. Summary of the Invention

[0006] The purpose of this application is to provide a method, system, device, and medium for determining the usage status of bare metal resources. This method can incrementally update the status by applying change records starting from a valid snapshot at the time of query, forming a continuous status evolution sequence. Then, it integrates multiple pre-configured bare metal resource-related business tables to construct a bare metal business status profile, thereby calculating resource analysis indicators corresponding to historical status calculation requests. Since the status profile covers the complete business status at each change time, the calculated analysis indicators can truly reflect the actual fluctuations in resource usage during the statistical period.

[0007] Firstly, a method for determining the usage status of bare metal resources is provided, including:

[0008] In response to a request to calculate the historical status of bare metal resources, the query start time and query end time of the query area are determined. For any pre-configured bare metal resource-related business table, a valid start snapshot record for the query start time of the query area and a change history snapshot record for the target statistical interval are determined from the full historical snapshot storage. The target statistical interval represents the time interval from the query start time to the query end time. The pre-configured bare metal resource-related business tables include one or more of the following: bare metal equipment table, bare metal resource table, hardware table, wiring relationship table, power supply equipment table, and reserved record table. For any pre-configured bare metal resource-related business table, the query start time and query end time of the query area are determined. The valid initial snapshot record at the start time is used as the initial state baseline. The change history snapshot records are applied one by one in chronological order of snapshot time to incrementally update the current state set of bare metal resources, forming a continuous resource state evolution sequence within the target statistical interval. At each time node of the resource state evolution sequence, the states of multiple pre-configured bare metal resource-related business tables are merged with bare metal equipment as the main correlation axis to construct a bare metal business state profile at that time. Based on the bare metal business state profile corresponding to each time node of the resource state evolution sequence, the resource analysis indicators corresponding to the historical state calculation request are calculated.

[0009] In a preferred embodiment, this application may be further configured to: before responding to a request to calculate the historical status of bare metal resources, further include: listening to database change logs, obtaining change events for each row of data in multiple pre-configured bare metal resource-related business tables associated with each bare metal resource; converting the data corresponding to each change event into a historical snapshot record and storing it in the full historical snapshot storage, wherein each historical snapshot record includes at least the snapshot time and the change content.

[0010] In a preferred embodiment, this application can be further configured to: convert the data corresponding to each change event into a historical snapshot record and store it in the full historical snapshot storage, including: if the change event is an insert operation event or an update operation event, then extract the changed field value as the change content of the historical snapshot record; if the change event is a delete operation event, then extract the field value before deletion as the change content of the historical snapshot record, and add a deletion marker field to the historical snapshot record.

[0011] In a preferred embodiment, this application can be further configured as follows: the historical snapshot record further includes: time series information; for any pre-configured bare metal resource-related business table, determining the valid starting snapshot record of the query start time of the query area from the full historical snapshot storage includes: for any pre-configured bare metal resource-related business table, extracting all candidate historical snapshot records related to bare metal resources generated before the query start time of the query area from the full historical snapshot storage, and grouping all candidate historical snapshot records; sorting multiple candidate historical snapshot records in each group according to the time series information; selecting the first record after sorting from each group as the final valid snapshot record of the query start time.

[0012] In a preferred embodiment, this application can be further configured as follows: the time-series information includes a snapshot time, a synchronization version number, and sorting parameters; for multiple candidate historical snapshot records in each group, sorting is performed according to the time-series information, including: arranging in descending order of the snapshot time; during the sorting process, if the snapshot times of multiple candidate records are tied for the largest, then sorting is performed according to the synchronization version number; if both the snapshot time and the synchronization version number of multiple candidate records are tied for the largest, then sorting is performed according to the sorting parameters corresponding to the pre-configured bare metal resource related business table categories.

[0013] In a preferred embodiment, this application can be further configured as follows: the resource analysis indicators include at least one of concurrent usage peak, peak time, and usage duration; based on the bare metal business status profile corresponding to each time node of the resource status evolution sequence, the resource analysis indicators corresponding to the historical status calculation request are calculated, including: at each change time point within the target statistical interval, the number of bare metal resources in the used state in the complete bare metal business status profile at the change time point is counted, the maximum number among all change time points is taken as the concurrent usage peak, and the time point corresponding to the maximum number is recorded as the peak time; based on the time interval between each adjacent change time point within the target statistical interval, the duration of each bare metal resource in the used state is accumulated to obtain the usage duration.

[0014] In a preferred embodiment, this application may be further configured to include: writing the resource analysis indicators into a cache according to statistical time units; pre-calculating the resource analysis indicators for a specified time unit and writing them into the cache at a preset warm-up time; when a duplicate query request is received, reading and returning the corresponding resource analysis indicators from the cache; if the cache is not hit, performing the calculation of the resource analysis indicators and writing the calculation results into the cache.

[0015] Secondly, a bare metal resource usage status determination system is provided, comprising: a request parsing layer, used to determine the query start time and query end time of a query area in response to a request for calculating the historical status of bare metal resources; a snapshot extraction module, used to determine, for any pre-configured bare metal resource related business table, a valid start snapshot record of the query start time of the query area and change history snapshot records of a target statistical interval from the full historical snapshot storage, wherein the target statistical interval represents the time interval from the query start time to the query end time, and the pre-configured bare metal resource related business table includes one or more of a bare metal equipment table, a bare metal resource table, a hardware table, a wiring relationship table, a power supply equipment table, and a reserved record table; and an interval status advancement layer, used to determine, for any... A pre-configured bare metal resource-related business table uses the valid initial snapshot record at the query start time as the initial state baseline. The change history snapshot records are applied sequentially according to the snapshot times to incrementally update the current state set of bare metal resources, forming a continuous resource state evolution sequence within the target statistical interval. A multi-source state fusion layer is used to fuse the states of multiple pre-configured bare metal resource-related business tables at each time node of the resource state evolution sequence, with the bare metal device as the main correlation axis, to construct a bare metal business state profile at that moment. An indicator calculation layer is used to calculate the resource analysis indicators corresponding to the historical state calculation request based on the bare metal business state profile corresponding to each time node of the resource state evolution sequence.

[0016] Thirdly, an electronic device is provided, the electronic device including a memory and a processor, the memory storing a computer program, the processor executing the method of any one of the first aspects when running the computer program.

[0017] Fourthly, a computer-readable storage medium is provided, wherein at least one piece of program code is stored therein, the program code being loaded and executed by a processor to implement the method as described in any of the first aspects.

[0018] Fifthly, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the method as described in any of the first aspects.

[0019] In summary, the method provided in this application has the following beneficial technical effects:

[0020] In response to historical state calculation requests, the query start and end times are determined. For any pre-configured bare metal resource-related business table, a valid snapshot of the query start time is obtained as a baseline. Then, change records within the target statistical interval are extracted. Starting from the baseline, the change records are incrementally updated one by one according to the snapshot time sequence, forming a continuous state evolution sequence. Compared to the method of full replaying from the earliest log at each statistical time or interpolating based on periodic cross-sectional snapshots, the state advancement only updates when changes occur rather than rebuilding the entire state at each time unit. This makes the entire calculation process only related to changes, thus significantly reducing computational overhead while ensuring the accuracy of historical state restoration. Furthermore, at each time node of the evolution sequence, with the bare metal device as the associated axis, valid snapshot records of multiple pre-configured bare metal resource-related business tables associated with bare metal resources at the same time are merged to construct a bare metal business state profile of the bare metal device at that time. This fusion process aggregates the state information scattered in different pre-configured bare metal resource-related business tables with the device as the core, ensuring the consistency and completeness of resource usage status at each time node. Based on the bare metal business status profile corresponding to each time point, resource analysis indicators corresponding to historical status calculation requests are calculated. Since the status profile covers the complete business status at each change time, the calculated analysis indicators can truly reflect the actual fluctuation of resource usage during the statistical period.

[0021] In addition, this application also provides an apparatus, device, and medium, all of which have the aforementioned beneficial technical effects. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A flowchart illustrating a method for determining the usage status of bare metal resources provided in an embodiment of this application;

[0024] Figure 2 A flowchart for starting point snapshot extraction and interval state progression provided in this application embodiment;

[0025] Figure 3 A multi-source state fusion flowchart is provided for an embodiment of this application;

[0026] Figure 4 A flowchart for calculating and caching historical operating indicators is provided in this application embodiment;

[0027] Figure 5 This is a schematic diagram of a system for determining the usage status of bare metal resources provided in an embodiment of this application;

[0028] Figure 6 A schematic diagram of another bare metal resource usage status determination system provided in this application embodiment;

[0029] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of this application.

[0031] It should be noted that, in the optional embodiments of this application, the collection, use and processing of the data involved (such as database change logs, pre-configured bare metal resource-related business table data, historical snapshot records, etc.) must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0032] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0033] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0034] Current technologies primarily rely on direct database queries, periodic snapshots, and single-table log replays for historical status analysis of bare metal resources. However, existing solutions only obtain status data from a single data table or a fixed time frame, and heavily depend on the real-time status of the current database. This leads to poor accuracy in historical status reconstruction, difficulties in multi-table collaborative judgment, and high computational overhead from repeated full replays. Furthermore, the lack of mechanisms for integrating historical status of multi-source business objects and continuously advancing intervals for operational analysis scenarios poses significant challenges to the accuracy and query performance of historical status analysis in large-scale clusters and frequently changing scenarios.

[0035] This application primarily addresses at least one of the following technical problems: Existing methods based on the current database or periodic snapshots cannot accurately restore the true state of bare metal resources at any historical moment. Existing technologies lack a mechanism for fusing historical states of multi-source business objects for bare metal resource operation analysis. When multiple candidate historical records exist for the same resource, the lack of clear conflict resolution rules easily leads to incorrect state determination. Existing historical analysis methods typically require repeated full scans or full replays, which is difficult to meet the efficiency requirements of long-term windows and high-frequency query scenarios. Existing solutions struggle to simultaneously balance the accuracy of historical state restoration and the performance of querying operation analysis results.

[0036] This application applies to bare-metal computing platforms, edge computing management platforms, and other systems that require tracing, statistical analysis, and operational analysis of historical resource status. The platform needs to answer whether a resource is in use, reserved, or restricted at a given historical moment, and also needs to answer when the peak concurrency occurred within a given historical time period, the cumulative usage duration, and the distribution of resource usage across different hardware specifications within that time period. This application is applicable to such temporal status calculation scenarios oriented towards historical operational analysis and resource decision support.

[0037] The following is combined Figure 1 This application provides a detailed description of the method for determining the usage status of bare metal resources. This method overcomes the technical challenges of poor accuracy in historical status restoration, difficulties in multi-table collaborative judgment, and low performance in long-term window queries.

[0038] like Figure 1 As shown, the method provided in this application embodiment can be executed by an electronic device, and the method includes:

[0039] S101. In response to the request to calculate the historical status of bare metal resources, determine the query start time and query end time of the query area.

[0040] The historical status calculation request is used to indicate an instruction to calculate one or more resource analysis indicators for the usage status of bare metal resources within a specified historical time period within a query area. The query start time indicates the initial snapshot time to be queried. The snapshot time indicates the time when a business change occurred. The query area represents the scope to be queried, which can specifically be a geographical location range, data center, computing warehouse, GPU model, CPU model, memory specification, or a region of bare metal resources determined by resource policies, etc., which is not limited in this embodiment.

[0041] S102. For any pre-configured bare metal resource-related business table, determine the valid start snapshot record of the query start time of the query area from the full historical snapshot storage, as well as the change history snapshot record of the target statistical interval. The target statistical interval represents the time interval from the query start time to the query end time.

[0042] The pre-configured bare metal resource-related business tables include one or more of the following: bare metal equipment table, bare metal resource table, hardware table, wiring relationship table, power supply equipment table, and reserved record table;

[0043] Among them, the pre-configured bare metal resource-related business tables refer to the database tables in the bare metal resource platform related to resource status management, including but not limited to the bare metal equipment table, bare metal resource table, bare metal hardware table, wiring relationship table, power equipment table, and reservation record table corresponding to each business object such as bare metal equipment attributes, resource allocation status, hardware specifications, wiring relationships, power status, and reservation information.

[0044] Full history snapshot storage refers to a data storage system used to continuously save all historical change records of each business object. That is, each business change is recorded as an independent snapshot record with a snapshot time and can be appended to.

[0045] A valid start snapshot record represents a historical snapshot record that accurately reflects the true state of the business object at the start of the query. If multiple snapshots exist at the start of the query, the final record is selected from all candidate snapshots before the start of the query after conflict resolution. A change history snapshot record represents all historical snapshot records generated within the target statistical interval, i.e., all change records whose snapshot time falls after the start of the query and before the end of the query.

[0046] S103. For any pre-configured bare metal resource-related business table, take the valid initial snapshot record at the start time of the query as the starting state baseline, and apply the change history snapshot records one by one in the order of the snapshot times, so as to incrementally update the current state set of bare metal resources and form a continuous resource state evolution sequence within the target statistical interval.

[0047] The current state set represents a snapshot cache of the state of each bare metal resource, continuously maintained during the interval advancement process and reflecting the latest business state of each resource at the current advancement moment. The resource state evolution sequence represents a sequence of resource state sets arranged chronologically within the target statistical interval, with each time node recording the immediate state of all resources at that moment.

[0048] In this embodiment, valid initial snapshot records from the query start time can be loaded into the current state set to complete state initialization. Each change record is retrieved sequentially from the change history snapshot records in chronological order of snapshot time. For each change record, the state entry corresponding to the same business primary key in the current state set is determined, and the entry is updated using the field values ​​from the change record. After each update, the snapshot of the current state set is recorded as a state node in the evolution sequence, and the snapshot time of the change record is associated as the timestamp of the state node. By sequentially processing all change records within the target statistical interval, a resource state evolution sequence is ultimately formed. This process does not require a full reconstructing of the state at each statistical time point; instead, incremental updates are performed based on the state at the previous time point.

[0049] S104. At each time point in the resource status evolution sequence, taking bare metal equipment as the main axis of association, the status of multiple pre-configured bare metal resource-related business tables are merged to construct a bare metal business status profile at that moment.

[0050] In the fusion process, the bare metal device serves as the primary key, and an identifier field is used to link historical snapshots of different pre-configured bare metal resource-related business tables. This identifier includes fields such as the device ID and serial number of the bare metal device. Through this identifier, all snapshot records belonging to the same physical device across multiple pre-configured bare metal resource-related business tables, including resource tables, hardware tables, wiring tables, power supply tables, and reservation tables, can be linked. The bare metal business status profile represents a multi-dimensional set of information about the comprehensive business status of a specific bare metal device at a given time point, constructed after merging the statuses of multiple pre-configured bare metal resource-related business tables. This profile includes, but is not limited to, bare metal device attributes such as specifications and model; resource status such as in use, idle, or being recycled; hardware status such as normal operation or fault; wiring status such as connected or unconnected; power supply status such as normal power supply, limited power supply, or power outage; and reservation status such as reserved or unreserved, among other structured status data.

[0051] Specifically, the process iterates through each moment in the resource state evolution sequence. For each moment, it first retrieves the final valid snapshot record of each business primary key in all pre-configured bare metal resource-related business tables at that moment. Using the bare metal device identifier as the association axis, it associates snapshot records belonging to the same bare metal resource device in the bare metal device table, bare metal resource table, bare metal hardware table, wiring relationship table, power supply equipment table, and reserved record table. Furthermore, for each bare metal device at each moment, a bare metal business state profile is generated, forming a complete profile set corresponding to a given time node.

[0052] In one implementation, the specific execution process of multi-source state fusion is as follows: The resource status field value of the device at a specified target time is obtained by associating the bare metal device identifier field with the bare metal device ID in the bare metal resource table; the detailed specification information of the bare metal device is obtained by associating the hardware identifier field with the bare metal device ID in the hardware specification table; the current wiring status of the device is obtained by associating the wiring relationship identifier field of the bare metal device with the wiring relationship table; the power supply device identifier field of the wiring relationship table is associated with the power supply device table to obtain the power supply status of the associated power supply device at a specified time; and the resource identifier field of the reserved record table is associated with the bare metal device ID to determine whether the device is in a reserved state at a specified time, so that the multi-dimensional state information of the same bare metal device at the target time is aggregated into a complete bare metal business state profile.

[0053] S105. Based on the bare metal business status profile corresponding to each time node in the resource status evolution sequence, calculate the resource analysis indicators corresponding to the historical status calculation requests.

[0054] The resource analysis indicators describe the usage of bare metal resources within the target statistical interval. These indicators include, but are not limited to, peak concurrent usage, peak time, and usage duration. Peak concurrent usage represents the maximum number of resources simultaneously in use at a given moment; peak time indicates the specific time when the peak concurrent usage occurred; and usage duration represents the cumulative duration a resource has been in use.

[0055] As can be seen, in this embodiment of the application, by using the effective initial snapshot record as a baseline for incremental updates instead of full replay, the computational overhead is significantly reduced while ensuring the accuracy of historical state restoration; the business state profile constructed by multi-source state fusion covers the complete business state at each change moment, so that the calculated analysis indicators can truly reflect the actual fluctuation of resource usage during the statistical period.

[0056] Furthermore, in one feasible approach, during the fusion process, the overall status of the bare metal device at any given moment is determined based on the business status field in the valid snapshot records of each pre-configured bare metal resource-related business table. For example, if the resource table shows the device is currently in use and the power supply table shows the associated power supply is in normal power supply status, the overall business status of the device is determined to be in normal use; if the resource table shows the device is idle, but the power supply table shows the associated power supply is in a restricted state, the overall business status of the device is determined to be restricted, rather than idle.

[0057] Furthermore, the start time and end time of the query in the corresponding query area can be different. If they are different, it corresponds to a state calculation request within a certain period of time. If they are the same, it means that the state calculation request is for the same time. This application embodiment is not limited, and users can set it according to actual needs, as long as it can achieve the purpose of this application.

[0058] In one possible implementation, in this embodiment of the application, complete full-history snapshot data is pre-built. In response to the historical state calculation request, the method of this embodiment of the application further includes: listening to the database change log and obtaining the change events of each row of data in multiple pre-configured bare metal resource-related business tables associated with each bare metal resource;

[0059] The database change log records change events for each row of data in the pre-configured bare metal resource-related business tables. The types of change events include, but are not limited to, insert, update, and delete operations. The content of each change event further includes: the snapshot time at the time of the change, the content of the change, and the corresponding business primary key. The business primary key is used to distinguish different business objects, such as the device ID in the bare metal equipment table, the resource ID in the bare metal resource table, and the reservation ID in the reservation record table.

[0060] The data corresponding to each change event is converted into historical snapshot records and stored in the full historical snapshot storage. Each historical snapshot record includes at least the snapshot time and the changed content.

[0061] When any row of data in any pre-configured bare metal resource-related business table is inserted, updated, or deleted, the database writes the corresponding change event to the change log stream; the change log is parsed to extract the operation type, change timestamp, business primary key value, and change content of each change event.

[0062] Specifically, the values ​​of various business fields involved in the change event are extracted as the change content fields for the historical snapshot record. Furthermore, the current system time can be appended as the storage time field for the historical snapshot record; the storage time indicates the time the snapshot was written to storage. After the conversion is complete, the historical snapshot record is appended to the full historical snapshot storage. Newly generated snapshot records are always appended to the end of the storage; existing snapshot records are not modified or deleted.

[0063] As can be seen, in this embodiment, by monitoring the database change log, the change events of each row of data in multiple pre-configured bare metal resource-related business tables associated with each bare metal resource are obtained; the data corresponding to each change event is converted into historical snapshot records and stored in the full historical snapshot storage. Since the full historical snapshot storage accumulates snapshot records corresponding to all change events, no matter how many changes occur within the statistical interval, the specific content of each state change can be traced back from this storage.

[0064] In one feasible approach, the data corresponding to each change event is converted into historical snapshot records and stored in a full historical snapshot store. This includes: if the change event is an insert operation event or an update operation event, the changed field values ​​are extracted as the changed content of the historical snapshot record; if the change event is a delete operation event, the field values ​​before deletion are extracted as the changed content of the historical snapshot record, and a deletion marker field is added to the historical snapshot record.

[0065] The deletion flag field indicates the tagging information used to identify that the corresponding historical snapshot record originated from the deletion operation. The snapshot conversion of the deletion operation preserves the complete business state image before deletion, so that the deleted resources can still participate in the state restoration at the historical moment after deletion.

[0066] In scenarios with frequent resource changes, multiple candidate records for the same resource may exist before a certain query time, especially when two or more snapshot records are generated within the same millisecond for the same primary key. Even if the snapshot time is accurate to the millisecond, it's impossible to determine which snapshot to select for the query start time solely based on the time field. Therefore, auxiliary fields such as synchronization version, deletion status, reservation status, and business status are needed for combined priority determination; otherwise, errors in historical status selection can easily occur, leading to distortions in statistical results such as peak usage, usage duration, and status distribution. Therefore, in one feasible approach, to accurately determine the valid starting snapshot record for the query start time from the full historical snapshot storage and resolve the ambiguity in status selection when multiple candidate snapshots exist under the same business primary key, this application also provides a specific implementation method for sorting and selecting based on time sequence identifiers. Specifically, historical snapshot records also include: time sequence information;

[0067] For any pre-configured bare metal resource-related business table, determine the valid starting snapshot record of the query start time for the query region from the full historical snapshot storage, including:

[0068] For any pre-configured bare metal resource-related business table, extract all candidate historical snapshot records related to bare metal resources generated before the query start time of the query area from the full historical snapshot storage, and group all candidate historical snapshot records.

[0069] In this embodiment of the application, the data can be grouped according to the business primary key or the resource identifier to select the most effective historical snapshot record.

[0070] In one feasible approach, the candidate snapshot set can be grouped by business primary key, grouping multiple candidate snapshots belonging to the same business primary key into the same group. For a group containing only one candidate snapshot, that unique candidate snapshot is directly used as the valid starting snapshot record for that business primary key. The following uses the business primary key as the grouping basis; however, other bases can be used in practice, all within the scope of protection of this application.

[0071] For each group of multiple candidate historical snapshot records, sort them according to time sequence information; select the first record after sorting from each group as the final valid snapshot record at the start time of the query.

[0072] Specifically, to employ adaptive conflict resolution strategies for different types of pre-configured bare metal resource-related business tables and eliminate ambiguity in the status of multiple candidate records with the same primary key at the same snapshot time granularity, the time-series information includes the snapshot time, synchronization version number, and sorting parameters. For multiple candidate historical snapshot records in each group, sorting is performed based on the time-series information, including: sorting in descending order of snapshot time; during the sorting process, if multiple candidate records have the same maximum snapshot time, sorting is performed by synchronization version number; if multiple candidate records have the same maximum snapshot time and synchronization version number, sorting is performed according to the sorting parameters corresponding to the pre-configured bare metal resource-related business table category. The synchronization version number represents the version identifier carried by the business object itself, i.e., the version number field that increments or updates with each business change.

[0073] For multiple candidate historical snapshot records under the same business primary key in each group, the specific rules for sorting based on the time sequence identifier are as follows: They are sorted in descending order of snapshot time, meaning the record with the later snapshot time is listed first. If the snapshot times of multiple candidate records can be clearly distinguished (i.e., there are no ties), the record with the largest snapshot time is directly selected, i.e., the record that ranks first after sorting, as the final valid snapshot record. For resource objects with a synchronization version field, the version number can be used as a conflict resolution factor for candidate records; generally, records with higher version values ​​have higher priority. If multiple candidate records have the same largest snapshot time (i.e., multiple records have the same largest snapshot time), then among these records with the same largest snapshot time, they are further sorted in descending order of synchronization version number, and the record with the largest synchronization version number is selected as the final valid snapshot record.

[0074] In one feasible approach, storage time can be introduced between the snapshot time and the synchronized version, with a longer storage time ranking higher.

[0075] Furthermore, based on the business semantics of different pre-configured bare metal resource-related business tables, in extreme cases where neither the snapshot time nor the synchronization version number can be distinguished, a sorting parameter can be introduced for further sorting:

[0076] When the pre-configured bare metal resource-related business table to which the candidate historical snapshot record belongs is a bare metal resource table, if multiple candidate records have the same maximum snapshot time and synchronization version number, they are further sorted in descending order of deletion flag, i.e., records with a valid deletion flag are ranked first, prioritizing records in the deletion state. If there are still ties, they are sorted in ascending order of reservation status, i.e., records with smaller reservation status values ​​are ranked first in priority. The record at the top of the sorted list is taken as the final valid snapshot record. For the reservation status, 0 means not reserved, i.e., the bare metal resource is not currently locked by the reservation process of a specific business scenario; 1 means reserved, i.e., the bare metal resource is currently locked by the reservation process of a specific business scenario to ensure resource availability for that business scenario. Before the reserved status is released, the resource is not used or scheduled as a regular allocatable resource in other businesses.

[0077] When the pre-configured bare metal resource-related business table to which the candidate historical snapshot record belongs is the bare metal equipment table, if multiple candidate records have the same maximum snapshot time and synchronization version number, they are further sorted in reverse order according to the deletion mark, and the record that is first after sorting is taken as the final valid snapshot record.

[0078] When the pre-configured bare metal resource-related business table to which the candidate historical snapshot record belongs is a reserved record table, if multiple candidate records have the same maximum snapshot time, they are further sorted in reverse order according to the reserved status field, and the record that is first after sorting is taken as the final valid snapshot record.

[0079] In this embodiment, records are sorted in reverse chronological order by snapshot time, prioritizing the location of change records closest to the query start time. During the sorting process, if multiple candidate records have the same maximum snapshot time, they are sorted by synchronization version number. Since the synchronization version number reflects the order of change events at the same snapshot time, it can further distinguish the order of multiple change operations occurring at the same time. If multiple candidate records have the same maximum snapshot time and synchronization version number, they are sorted according to the sorting parameters corresponding to the pre-configured bare metal resource-related business table categories. These sorting parameters preset priority rules for the characteristics of different pre-configured bare metal resource-related business tables, thus ensuring that a unique final valid record can still be determined even when timestamps and version numbers cannot be distinguished. Through the above-described progressively refined sorting logic, the selection of valid starting snapshot records can maintain determinism and uniqueness under various boundary conditions, ensuring the accurate establishment of the state baseline and providing a reliable starting state benchmark for subsequent incremental updates and state fusion.

[0080] In one feasible approach, resource analysis metrics include at least one of peak concurrent usage, peak time, and usage duration; based on the bare metal business state profile corresponding to each time point in the resource state evolution sequence, resource analysis metrics corresponding to historical state calculation requests are calculated, including:

[0081] S1051. At each change time point within the target statistical interval, count the number of bare metal resources in use in the complete bare metal business status profile at the change time point, take the maximum number among all change time points as the peak concurrent usage, and record the time point corresponding to the maximum number as the peak moment.

[0082] Here, the change time point represents the moment when a change record occurs in the resource state evolution sequence, that is, the time point corresponding to each application of the change snapshot record during the interval advancement process. The peak concurrent usage represents the maximum number of bare metal resources that are simultaneously in use at any given moment within the entire target statistical interval.

[0083] Specifically, the process iterates through each time point in the resource state evolution sequence. For each time point, it filters out bare metal device records in use from the bare metal business state profile set for that node, and counts the concurrent usage at that moment. During the iteration, a current maximum value is maintained. Whenever the concurrent usage at a certain moment exceeds the current maximum value, the maximum value is updated and the timestamp of that moment is recorded. After the iteration is complete, the maximum value is the peak concurrent usage, and the corresponding timestamp is the peak moment.

[0084] S1052. Based on the time interval between each adjacent change time point within the target statistical interval, the duration of each bare metal resource in use is accumulated to obtain the usage time.

[0085] Each bare metal device is tracked independently, and its state change trajectory in the resource state evolution sequence is traversed. For two adjacent change points t1 and t2 (t1 < t2), if the bare metal device is in use in the bare metal business state profile at time t1, then the device's usage time contribution within the time interval [t1, t2) is (t2 - t1). This time period is accumulated into the device's cumulative usage time value. For the entire target statistical interval, the sum of the usage time contributions of all bare metal devices is the total usage time; average utilization rate = total usage time / (total number of devices involved in the calculation * total duration of the target statistical interval).

[0086] Concurrent usage peak and peak time are statistically analyzed point-by-point based on the accurate bare metal business status profile after multi-source fusion. Usage duration is accurately calculated based on the interval accumulation algorithm between adjacent change time points. This makes the analysis indicators not only accurately reflect the actual usage, but also support flexible drill-down analysis by device granularity or by region granularity, providing reliable data support for capacity planning and resource management decisions.

[0087] In one feasible approach, a caching mechanism is added to improve response efficiency in high-frequency repetitive query scenarios and reduce the overhead of repeated calculations for the same statistical time units. The method further includes: writing resource analysis metrics into the cache according to statistical time units; pre-calculating resource analysis metrics for a specified time unit and writing them into the cache at a preset warm-up time; when a repetitive query request is received, reading and returning the corresponding resource analysis metrics from the cache; if the cache is not found, performing the calculation of the resource analysis metrics and writing the calculation result into the cache.

[0088] In one implementation, the system also includes a scheduled preheating task. Based on historical query popularity statistics, the system determines the statistical time units requiring preheating (e.g., each hourly interval within the last 24 hours). At the preset preheating time (e.g., during the early morning off-peak business period), the system performs a complete historical state calculation process for each of the aforementioned statistical time units and writes the calculation results to a cache. When upper-layer services initiate query requests for the aforementioned time units during the day, the system directly returns the results from the cache, eliminating the need for real-time calculation and significantly reducing query latency.

[0089] As can be seen, in this embodiment, the calculated resource analysis indicators are written to the cache according to statistical time units, and the indicators for a specified time unit are pre-calculated and written to the cache at a preset warm-up time. When a duplicate query request is received subsequently, the resource analysis indicator is directly read from the cache and returned without re-executing the calculation process.

[0090] Furthermore, the calculation of resource analysis metrics corresponding to historical state calculation requests also includes: obtaining grouping dimension parameters, which include at least one of the following: computing power warehouse, GPU model, CPU model, and memory specifications; grouping the bare metal device set according to the grouping dimension parameters to form multiple device groups; and independently performing concurrent usage statistics and usage duration accumulation within each device group to obtain the resource analysis metrics corresponding to each device group.

[0091] In one implementation, the system supports grouped statistics by specification dimension. When a historical state calculation request containing grouping dimension parameters is received, the system groups the bare metal devices participating in the calculation according to the grouping dimension parameters. For example, when the grouping dimension is GPU model, the system divides all devices into several device groups according to GPU model (such as V100, A100, T4, etc.). Within each device group, the system independently executes a complete calculation process: independently restores the state baseline of the group at the start of the query, independently extracts the change records of the group within the target statistical interval, independently performs state advancement and multi-source fusion, and independently calculates indicators such as peak concurrency, peak time, and usage duration. Through grouped statistics, the system can output the usage status of each specification of resource separately, making it easier for operators to identify the usage differences of different specification resource pools.

[0092] When calculating resource analysis metrics, a grouping dimension parameter is obtained. This parameter includes at least one of the following: computing power warehouse, GPU model, CPU model, or memory specification. The bare metal device set is then grouped according to this grouping dimension parameter, forming multiple device groups. Within each device group, concurrent usage statistics and cumulative usage time are independently performed to obtain the resource analysis metrics corresponding to each device group. This grouping statistical mechanism allows users to observe differentiated characteristics of resource usage from different hardware specification dimensions. For example, users can separately view the peak usage and utilization rate of two resource pools with GPU models V100 and A100, thereby accurately identifying which specification has resource shortages and which specification has idle resources, providing refined data support for differentiated capacity planning and procurement decisions.

[0093] Based on any of the above embodiments, this application continuously monitors the insertion, update, and deletion operations of pre-configured bare metal resource-related business tables through a database change log collection mechanism. Each change is converted into a timestamped historical snapshot record and written to a fully historical snapshot storage, forming a continuously appendable fully historical change snapshot library. For insertion and update operations, the system extracts the changed field values ​​as historical snapshot content; for deletion operations, the system extracts the field values ​​before deletion as historical snapshot content and adds a deletion marker field to retain the business status information before deletion, enabling the deletion process to participate in subsequent historical state restoration. Each historical snapshot record includes at least a data primary key, data table metadata, snapshot time, storage time, and deletion status.

[0094] Furthermore, an embodiment of this application provides a flowchart including:

[0095] Step 1: Continuously monitor the database change logs of the pre-configured bare metal resource-related business tables and convert each insert, update, or delete operation into a historical snapshot record.

[0096] Step 2: The system writes the historical snapshot records to the full historical snapshot storage, where the deletion operation retains the image before deletion and adds a deletion mark.

[0097] See Figure 2 , Figure 2 A flowchart for starting point snapshot extraction and interval state advancement provided in this application embodiment includes: selecting a region and time range, extracting the snapshot baseline before the query start time, grouping candidate records by primary key, executing conflict resolution rules, forming a set of starting states, extracting interval change records, advancing the current state of resources one by one, and obtaining the state of each time within the hour window.

[0098] Step three: Upon receiving a historical state calculation request, the system determines the query area, query start time, and query end time. Furthermore, the historical state calculation request can also include the granularity of the requested metrics; the granularity varies depending on the business scenario and time range. The historical state calculation request can also include a set of resource primary keys, or hardware specification filtering conditions or model filtering conditions, to limit the range of bare metal resources participating in the calculation.

[0099] Step four: The system extracts candidate records of various business objects from the full historical snapshot database before the query start time and groups them by primary key.

[0100] A business function includes a pre-configured bare metal resource-related business table. Within this table, multiple records may exist for the same snapshot time. Although the snapshot time is accurate to milliseconds, there is still a small probability that the same primary key data will be changed twice within the same millisecond. The purpose of grouping is to compress multiple historical snapshots of the same business object into a single valid state of that object at the target time, and to create a state timeline that progresses by object during interval calculations, thus avoiding duplicate counting and misjudgment of state.

[0101] Step 5: For multiple candidate records under the same business primary key, especially when there are multiple snapshot records for the same primary key at the same snapshot time, the system performs a judgment based on a combination of priority rules such as synchronization version, deletion status, reservation status, and business status to determine the final valid status at the start time of the query and form the initial status baseline.

[0102] There may not be a historical snapshot at the time the query starts. In this case, it is necessary to determine the last valid record at the time the query starts based on the most recent historical snapshot record before the time the query starts.

[0103] When multiple candidate records exist under the same primary key, relying solely on the snapshot time field is insufficient to determine which snapshot should be used for the query's start time. Therefore, in addition to snapshot time filtering, the system further combines synchronization version, deletion status, reservation status, and business status fields to determine the final valid snapshot record for the query's start time. The confirmation priority can be, in order: time / write order priority, synchronization version priority, deletion status priority, and business status priority. It's important to note that not all pre-configured bare metal resource-related business tables use all fields. Different pre-configured bare metal resource-related business tables use different combinations based on business semantics. Specific implementations in this application are not limited to these combinations and can be set according to actual needs.

[0104] Taking the bare metal resource table as an example, the priority is: the larger the time, the higher the priority; the larger the synchronization version, the higher the priority; the larger the deletion status, the higher the priority; and the smaller the business status, the higher the priority.

[0105] The implementation method for selecting the final valid snapshot from multiple snapshots includes the following: When querying historical snapshots before the target time, the system does not return all snapshots with the same primary key to the business layer for individual judgment. Instead, it constructs an aggregate query grouped by business primary key during the snapshot query phase. Each primary key group is sorted according to a preset combination priority. The sorting field includes at least the snapshot time and may further include synchronization version, deletion status, reservation status, or business status fields depending on the business model. The system takes the first sorted snapshot from each primary key group as the final valid snapshot of that business object at the target time, thus forming the initial state baseline.

[0106] For bare metal resource snapshots, the system prioritizes them by descending order of store_time, descending order of sync_version, descending order of is_delete (business attribute; deleted records are always newer), and ascending order of reserve_status (business attribute; records already reserved are always newer). For bare metal device snapshots, the system prioritizes them by descending order of store_time, descending order of sync_version, and descending order of is_delete. For usage records, reservation records, and scheduling records, the system prioritizes them by descending order of store_time and descending order of status. After sorting, only the first record of each business primary key is retained as a valid status.

[0107] Step six: After the system extracts all change records within the query range, it advances the resource status set one by one in chronological order.

[0108] After obtaining the baseline state at the start of the query, the system further extracts change records within the query time interval and advances the current state set one by one in chronological order, thus forming a continuous resource state evolution process within the target interval. The interval advancement method does not require a full reconstruction of the state at each statistical moment, but rather performs incremental updates based on the state at the previous moment, thereby improving the efficiency of historical state calculation.

[0109] Further, see Figure 3 , Figure 3 A multi-source state fusion flowchart provided for embodiments of this application includes: reading bare metal resource status, reading bare metal device status, reading wiring relationships and power status, reading hardware and reserved status, unified time axis association fusion, and determining statuses such as registration in progress / use in progress / recycling in progress / reservation in progress / restriction.

[0110] Step 7: The system integrates the resource status with the status of related objects such as bare metal equipment, hardware, wiring, power supply, and reservations on the same time axis to form a bare metal resource temporal status model for operation analysis, which is called a profile.

[0111] Furthermore, this application does not only perform status calculations on a single resource table, but integrates the historical states from multiple sources, including bare metal equipment tables, resource tables, hardware tables, wiring relationship tables, power equipment tables, and reservation record tables, along a unified timeline to construct a temporal status model of bare metal resources that can be used for operational analysis. Based on this temporal status model, the system uniformly determines the registration, usage, recycling, reservation, and restricted states of each bare metal resource at a target time or within a target interval. During the integration process, bare_metal.id is used as the main axis for bare metal equipment. Resource status is obtained using bm_resource.bm_id, specifications are obtained using hardware snapshots, wiring relationships are associated using bare_metal.connection_id, power equipment is associated using bm_connection.power_id, and computing hubs are associated using bare_metal.computing_hub_id. Finally, the multi-source historical snapshots are compressed into a complete status profile of a single bare metal equipment at the same point in time.

[0112] Further, see Figure 4 , Figure 4 A flowchart for calculating and caching historical operating indicators is provided for an embodiment of this application, including: traversing the state set by hourly window, calculating the number of in use, recording the hourly peak and peak time, accumulating the duration of resource usage, grouping by dimensions such as data center GPU, PU memory, etc., writing to the cache and outputting the analysis results.

[0113] Step 8: Based on the fused state model, the system calculates the registration volume, usage volume, recycling volume, reserved volume, restricted volume, peak concurrent usage, peak time, and usage duration by hourly window or other statistical granularity.

[0114] Among them, the registration quantity represents the number of devices that have completed registration in the bare metal equipment; the usage quantity represents the status field in the bare metal resources (status=4 means in use); the recycling quantity represents the status field in the bare metal resources (status=10 means in recycling); the reserved quantity represents the status field in the reserved record table (status=1 means in progress); the restricted quantity represents the status field in the power equipment table (status=1); the concurrent usage peak, peak time, and usage duration represent the status fields in the bare metal resources (status=4 means in use).

[0115] The system calculates the concurrent usage, peak concurrent usage, peak time, usage duration, utilization rate, and resource status distribution by specification group based on the granularity information carried in the request or the default granularity. It also improves the response efficiency in repeated query scenarios through caching and timed preheating mechanisms.

[0116] Specifically, the resource status at a certain point in time is first restored based on the snapshot, then the resource status changes are advanced by hourly window or query interval, and finally the quantity, peak value and duration are counted.

[0117] The system uses the snapshot at the start of the query window as the initial resource state, reads resource change records within the window in the order of snapshot times, and maintains the resource state unchanged within each adjacent change time slice. For concurrency metrics, the system updates the resource state at each change point, counts the number of resources in use, takes the maximum value within the window as the peak concurrency, and records that change point as the peak time. For duration metrics, the system integrates the number of effective resources and the number of resources in use by time slice to obtain the total available resource duration and the total used resource duration, and calculates the utilization rate accordingly. For grouping metrics, the system groups the resource set by specifications such as computing power warehouse and GPU model, and performs concurrency statistics and duration integration independently within each group.

[0118] For example, if the query starts at time t1 and ends at time t2, then: at time t1, the final valid snapshot of each business primary key is retrieved from the historical snapshots of each pre-configured bare metal resource-related business table to form the initial state baseline. Within the t1-t2 interval, change snapshots of the pre-configured bare metal resource-related business tables, such as the bare metal device table, resource table, hardware table, wiring relationship table, power supply equipment table, reservation record table, and usage record table, are read. These change snapshots are arranged on the same time axis according to snapshot_time_long. Whenever a business object changes on the time axis, the system updates a certain dimension of the corresponding bare metal device's state, such as resource state, reservation state, hardware specifications, wiring state, and power supply state. The multi-dimensional states of the same bare metal device at the same point in time constitute the temporal state model of the device. Between two adjacent change points, the system considers the state to remain unchanged and calculates indicators such as concurrency, usage duration, utilization rate, restricted quantity, and reserved quantity based on this state.

[0119] Step nine: The system writes the calculation results to the cache by region and time unit, and returns the results to the upper-layer query service.

[0120] In one implementation, the platform database contains pre-configured bare metal resource-related business tables, including a bare metal equipment table, a bare metal resource table, a bare metal hardware table, a wiring relationship table, a power supply equipment table, and a reservation record table. During platform operation, the resource status continuously changes due to registration, activation, occupation, reclamation, power limiting, wiring adjustments, and reservations.

[0121] The system first uses a database change log collection component to monitor row-level changes in the pre-configured bare metal resource-related business tables. When the status of a bare metal resource changes from idle to in use, the system extracts the changed resource field content and writes it, along with the snapshot time and storage time, to the full historical snapshot database. When a resource record is deleted, the system extracts the field content before deletion, adds a deletion flag, and writes it to the full historical snapshot database. Thus, the system creates an independent and traceable historical snapshot for each change in business status.

[0122] When an upper-layer business request queries the bare metal resource usage of a certain region for the past seven days, the system first determines the start time of the first hour to be statistically analyzed and reads the bare metal equipment snapshots, resource snapshots, wiring snapshots, and power supply snapshots prior to that start time from the full historical snapshot database. For cases where multiple candidate records exist under the same resource primary key, especially when multiple snapshot records exist within the same millisecond for the same primary key, the system, based on snapshot time filtering, further determines the final valid record according to a combination of priority rules such as synchronization version, deletion status, reservation status, and business status to obtain the final valid record at the query start time, forming the initial status baseline.

[0123] Subsequently, the system reads all resource change records from the start time to the end time of the query and advances the current state set one by one in chronological order. For example, when a resource changes from idle to in use and then from in use to being recycled within a certain hour, the system updates the current state of the resource in the state set in sequence and continuously calculates the number of resources in use within that hourly window; when the number of resources in use reaches the maximum value for that hour, the system records that moment as the peak concurrency moment for that hour.

[0124] After determining the peak value, the system further integrates the resource status at that peak moment with the historical status of the bare metal equipment table, wiring relationship table, and power supply equipment table. For example, if a resource itself is not in use, but its associated power supply equipment is in a restricted state at that moment, the system identifies the resource as a restricted resource; if the resource is in a reserved state, the system further identifies it as a reserved resource. This results not in a single table status, but rather a bare metal resource business status that can be directly used for operational analysis.

[0125] For usage duration statistics, the system first establishes an initial baseline state, then advances the state changes in chronological order, and accumulates the duration of each resource in use, ultimately obtaining the total usage duration, average utilization rate, and statistical results grouped by specification or region within the target time interval.

[0126] In high-frequency query scenarios, the system can also write historical statistical results generated by region and hour into the cache, and preheat the online region at fixed intervals. Subsequent queries with the same time unit can prioritize reading directly from the cache, and only perform interval advancement calculations on time units that are not hit, thus balancing the accuracy of historical state calculations and query response efficiency.

[0127] Through the above implementation methods, this application achieves the calculation of the historical usage status of bare metal resources based on full-historical change snapshots, multi-source state fusion, and interval advancement. Compared with existing methods that rely solely on the current database, only perform periodic cross-sectional snapshots, or only replay single-table logs, this application is more suitable for resource history analysis, capacity assessment, and operational decision support scenarios in bare metal computing power platforms.

[0128] The following describes a system provided by an embodiment of this application. The system described below can be referred to in correspondence with the method described above. The system of this embodiment is installed in an electronic device. Figure 5 , Figure 5 This is a structural block diagram of a system according to one embodiment of this application, including:

[0129] The request parsing layer is used to respond to requests for calculating the historical status of bare metal resources and determine the start and end times of the query for the query area.

[0130] The snapshot extraction layer is used to determine, for any pre-configured bare metal resource-related business table, the valid starting snapshot record of the query start time of the query area and the change history snapshot record of the target statistical interval from the full historical snapshot storage. The target statistical interval represents the time interval from the query start time to the query end time. The pre-configured bare metal resource-related business tables include one or more of the following: bare metal equipment table, bare metal resource table, hardware table, wiring relationship table, power supply equipment table, and reserved record table.

[0131] The interval state advancement layer is used to query any pre-configured bare metal resource-related business table, using the valid initial snapshot record at the start time of the query as the starting state baseline, and applying the change history snapshot records one by one in the order of the snapshot times, so as to incrementally update the current state set of bare metal resources and form a continuous resource state evolution sequence within the target statistical interval.

[0132] The multi-source state fusion layer is used to fuse the states of multiple pre-configured bare metal resource-related business tables at each time point of the resource state evolution sequence, with bare metal devices as the main correlation axis, to construct a bare metal business state profile at that moment.

[0133] The indicator calculation layer is used to calculate the resource analysis indicators corresponding to historical status calculation requests based on the bare metal business status profile corresponding to each time point in the resource status evolution sequence.

[0134] Among them, such as Figure 6 As shown, this application's snapshot construction layer continuously accumulates full-historical change snapshots from database change logs; the state recovery layer extracts the initial snapshot baseline and advances the state of interval changes; the state fusion layer merges various business objects such as bare metal equipment, resources, hardware, wiring, power supply, and reservations under a unified time axis; and the indicator output layer calculates and caches historical operational analysis results such as peak concurrency, usage duration, utilization rate, and group distribution. The change collection and historical snapshot generation module monitors database change logs, identifies insert, update, and delete events in pre-configured bare metal resource-related business tables, and converts each event into an independent historical snapshot record. For delete events, the module retains the image before deletion and adds a deletion marker, allowing the deletion process to participate in subsequent historical state restoration. The full-historical snapshot storage module continuously saves all historical snapshots of each business object, rather than just the current state. This module provides a unified data foundation for state extraction at any time, interval change querying, and historical operational analysis. The starting snapshot extraction layer extracts candidate records of various business objects before the query start time from the full-historical snapshot library, serving as the state baseline for interval state advancement calculations. The millisecond snapshot ambiguity resolution module addresses the issue of selecting the starting state when multiple candidate snapshots exist for the same business primary key at the same snapshot time granularity. This module doesn't solely rely on chronological order; instead, when snapshot times are identical and the final state cannot be determined solely by the time field, it combines synchronization version priority, deletion status priority, reservation status priority, and business status priority to select the target snapshot record as the starting state baseline. The interval change extraction and interval state advancement layer extracts all change records within the query time interval and advances the resource state set sequentially based on the starting state baseline, avoiding a full state restoration at each statistical time. The multi-source state fusion layer integrates various business objects such as bare metal equipment, resources, hardware, wiring, power supply, and reservations on a unified time axis, generating a temporal business state of bare metal resources available for operational analysis. The indicator calculation layer calculates indicators such as registration quantity, usage quantity, recovery quantity, reservation quantity, restricted quantity, peak concurrent usage, peak time, usage duration, and utilization rate based on the temporal business state model. The cache preheating and result output module is used to cache and preheat historical statistical results at the granularity of region, hour, etc., and output historical analysis results to the upper-layer query service to reduce the recalculation cost when repeated queries occur.

[0135] One possible implementation also includes: a change acquisition module for listening to database change logs and acquiring change events for each row of data in multiple pre-configured bare metal resource-related business tables associated with each bare metal resource; a historical snapshot generation module for converting the data corresponding to each change event into historical snapshot records; and a full historical snapshot storage module for storing historical snapshot records into a full historical snapshot storage, wherein each historical snapshot record includes at least the snapshot time and the change content.

[0136] In one feasible approach, the full history snapshot storage module is used to: if the change event is an insert operation event or an update operation event, extract the changed field values ​​as the changed content of the history snapshot record; if the change event is a delete operation event, extract the field values ​​before deletion as the changed content of the history snapshot record, and add a deletion marker field to the history snapshot record.

[0137] In one feasible approach, the historical snapshot record further includes: time-series information; and a snapshot extraction layer, used to: extract all candidate historical snapshot records related to bare metal resources generated before the query start time of the query area from the full historical snapshot storage for any pre-configured bare metal resource-related business table, and group all candidate historical snapshot records; sort multiple candidate historical snapshot records in each group according to the time-series information; and select the first record after sorting from each group as the final valid snapshot record at the query start time.

[0138] In one feasible approach, the time-series information includes the snapshot time, synchronization version number, and sorting parameters; the snapshot extraction layer is used to: sort in descending order of snapshot time; during the sorting process, if multiple candidate records have the same maximum snapshot time, then sort them according to the synchronization version number; if multiple candidate records have the same maximum snapshot time and synchronization version number, then sort them according to the sorting parameters corresponding to the pre-configured bare metal resource related business table categories.

[0139] In one feasible approach, resource analysis metrics include at least one of concurrent usage peak, peak time, and usage duration; the metric calculation layer is used to: at each change time point within the target statistical interval, count the number of bare metal resources in use in the complete bare metal business status profile at the change time point, take the maximum number among all change time points as the concurrent usage peak, and record the time point corresponding to the maximum number as the peak time; and accumulate the duration of each bare metal resource in use based on the time interval between each adjacent change time point within the target statistical interval to obtain the usage duration.

[0140] In one possible implementation, the system further includes: a cache preheating module, which writes resource analysis metrics into the cache according to statistical time units; at a preset preheating time, pre-calculates the resource analysis metrics for a specified time unit and writes them into the cache; when a duplicate query request is received, the system reads from the cache and returns the corresponding resource analysis metrics; if the cache is not hit, the system calculates the resource analysis metrics and writes the calculation results into the cache.

[0141] Figure 7 A structural diagram of an electronic device provided in an embodiment of this application, such as... Figure 7 As shown, the electronic device includes: a memory 60 for storing a computer program; and a processor 61 for executing the computer program to implement the steps of the method as described in the above embodiments.

[0142] The electronic devices provided in this embodiment may include, but are not limited to, smartphones, tablets, laptops, or desktop computers.

[0143] The processor 61 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 61 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 61 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 61 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0144] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 60 is used to store at least the following computer program 601, which, after being loaded and executed by the processor 61, is capable of implementing the relevant steps of the method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. The operating system 602 may include Windows, Unix, Linux, etc.

[0145] In some embodiments, the electronic device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0146] Those skilled in the art will understand that Figure 7 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0147] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, magnetic disks, or optical disks, and other media capable of storing program code.

[0148] Based on this, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described above.

[0149] Based on this, embodiments of this application also provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the above-described method. It should be understood that although the steps in the flowcharts of the accompanying drawings are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying drawings may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0150] The above are only some embodiments of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for determining the utilization status of bare metal resources, characterized in that, include: In response to the request to calculate the historical status of bare metal resources, determine the query start time and query end time for the query area; For any pre-configured bare metal resource-related business table, determine the valid start snapshot record of the query start time of the query area and the change history snapshot record of the target statistical interval from the full historical snapshot storage. The target statistical interval represents the time interval from the query start time to the query end time. The pre-configured bare metal resource-related business table includes one or more of the following: bare metal equipment table, bare metal resource table, hardware table, wiring relationship table, power supply equipment table, and reserved record table. For any pre-configured bare metal resource-related business table, the valid initial snapshot record at the query start time is used as the starting state baseline. The change history snapshot records are applied one by one in chronological order of the snapshot times to facilitate incremental updates to the current state set of bare metal resources, forming a continuous resource state evolution sequence within the target statistical interval. At each time point of the resource state evolution sequence, with bare metal equipment as the main axis of association, the states of multiple pre-configured bare metal resource-related business tables are merged to construct a bare metal business state profile at that moment. Based on the bare metal business status profile corresponding to each time point of the resource status evolution sequence, calculate the resource analysis indicators corresponding to the historical status calculation request.

2. The method according to claim 1, characterized in that, Prior to the request for historical state calculation of bare metal resources, the following are also included: Listen to the database change log and obtain the change events of each row of data in multiple pre-configured bare metal resource-related business tables associated with each bare metal resource; The data corresponding to each change event is converted into a historical snapshot record and stored in the full historical snapshot storage. Each historical snapshot record includes at least the snapshot time and the change content.

3. The method according to claim 2, characterized in that, Convert the data corresponding to each change event into historical snapshot records and store them in the full history snapshot storage, including: If the change event is an insert operation event or an update operation event, then the changed field value is extracted as the change content of the historical snapshot record; If the change event is a deletion operation event, the field value before deletion is extracted as the change content of the historical snapshot record, and a deletion mark field is added to the historical snapshot record.

4. The method according to claim 2, characterized in that, The historical snapshot records also include: time-series information; For any pre-configured bare metal resource-related business table, determine the valid starting snapshot record of the query start time for the query region from the full historical snapshot storage, including: For any pre-configured bare metal resource-related business table, extract all candidate historical snapshot records related to bare metal resources generated before the query start time of the query area from the full historical snapshot storage, and group all candidate historical snapshot records. For each group of multiple candidate historical snapshot records, sort them according to the time sequence information; Select the first record after sorting from each group as the final valid snapshot record at the start time of the query.

5. The method according to claim 4, characterized in that, The timing information includes the snapshot time, synchronization version number, and sorting parameters; For multiple candidate historical snapshot records in each group, sorting is performed based on the time-series information, including: Arranged in reverse order of the snapshot time, if multiple candidate records have the same maximum snapshot time during the sorting process, they are sorted according to the synchronization version number. If multiple candidate records have the same maximum snapshot time and synchronization version number, they are sorted according to the sorting parameters corresponding to the pre-configured bare metal resource related business table categories.

6. The method according to claim 1, characterized in that, The resource analysis metrics include at least one of peak concurrent usage, peak time, and usage duration. Based on the bare metal business status profile corresponding to each time point of the resource status evolution sequence, calculate the resource analysis indicators corresponding to the historical status calculation request, including: At each change time point within the target statistical interval, the number of bare metal resources in use in the complete bare metal business status profile at the change time point is counted. The maximum number at all change time points is taken as the peak concurrent usage, and the time point corresponding to the maximum number is recorded as the peak moment. Based on the time interval between each adjacent change time point within the target statistical interval, the duration of each bare metal resource in use is accumulated to obtain the usage duration.

7. The method according to claim 1, characterized in that, Also includes: The resource analysis indicators are written into the cache according to statistical time units; at a preset warm-up time, the resource analysis indicators for a specified time unit are pre-calculated and written into the cache. When a duplicate query request is received, the corresponding resource analysis metric is read from the cache and returned; if the cache is not hit, the resource analysis metric is calculated and the calculation result is written to the cache.

8. A system for determining the usage status of bare metal resources, characterized in that, include: The request parsing layer is used to respond to requests for calculating the historical status of bare metal resources and determine the start and end times of the query for the query area. The snapshot extraction module is used to determine, for any pre-configured bare metal resource-related business table, the valid starting snapshot record of the query start time of the query area and the change history snapshot record of the target statistical interval from the full historical snapshot storage. The target statistical interval represents the time interval from the query start time to the query end time. The pre-configured bare metal resource-related business table includes one or more of the following: bare metal equipment table, bare metal resource table, hardware table, wiring relationship table, power supply equipment table, and reserved record table. The interval state advancement layer is used to apply the change history snapshot records one by one according to the order of the snapshot times for any pre-configured bare metal resource related business table, taking the valid starting snapshot record at the query start time as the starting state baseline, so as to incrementally update the current state set of bare metal resources and form a continuous resource state evolution sequence within the target statistical interval. The multi-source state fusion layer is used to fuse the states of multiple pre-configured bare metal resource-related business tables at each time node of the resource state evolution sequence, with bare metal devices as the main correlation axis, to construct a bare metal business state profile at that moment. The indicator calculation layer is used to calculate the resource analysis indicators corresponding to the historical state calculation request based on the bare metal business state profile corresponding to each time node of the resource state evolution sequence.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the method according to any one of claims 1 to 7 when running the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one piece of program code, which is loaded and executed by a processor to implement the method as described in any one of claims 1 to 7.

Images