Banking cloud environment metering and charging analysis method and system, medium and equipment

Abstract

The application discloses a kind of banking multi-cloud environment under metering and charging analysis method and system, medium, equipment, which comprises: to meet the demand of banking multi-cloud environment cross cloud metering and charging, build each cloud platform adapter, collect the calculation and storage resource original message data (including cluster architecture identification) returned by API.Map the original data to a unified measurement unit metadata and preprocess, determine the resource usage data volume.Based on cluster architecture identification, distinguish between with / without management node resources, separate the management node cost according to their respective logic, allocate indirect costs according to the available amount of business resource units, and form the unit price of each business resource unit.The analysis result is obtained by aggregating the usage data volume and unit price, and the metering and charging analysis report is formed and outputted.The problems of resource metering heterogeneity, billing and business disconnection, and insufficient cost control accuracy in multi-cloud environment can be effectively solved, providing technical support for resource management and cost optimization in the process of digital transformation of banks.

Description

Technical Field

[0001] This application relates to the fields of financial technology and cloud computing technology, and in particular to a metering and billing analysis method, system, medium, and equipment for the banking industry in a multi-cloud environment. Background Technology

[0002] As the digital transformation of the banking industry deepens, the reliance of financial services on cloud computing resources continues to increase. To meet the needs of elastic business expansion, disaster recovery backup, and avoiding vendor lock-in, the banking industry generally adopts a multi-cloud architecture model that uses resources from multiple cloud service providers' cloud platforms. Under this model, the resource types (such as computing resources and storage resources) of different cloud service providers differ significantly in terms of metering standards, interface specifications, and data formats, leading to severe challenges in the statistics and cost accounting of resource usage across cloud platforms. Summary of the Invention

[0003] In view of this, this application provides a metering and billing analysis method, system, medium, and equipment for the banking industry in a multi-cloud environment, which can effectively solve problems such as heterogeneous resource metering, disconnect between billing and business, and insufficient accuracy of cost control in a multi-cloud environment, and provide technical support for resource management and cost optimization in the digital transformation of banks.

[0004] According to one aspect of this application, a metering and billing analysis method for a multi-cloud environment in the banking industry is provided, the method comprising: When the banking industry uses cloud platform resources from multiple cloud service providers and requires cross-cloud platform resource metering and billing, adapters suitable for each cloud platform are constructed. The adapters collect the raw message data returned by the cloud platform resources through the API interface. The cloud platform resources are divided into computing resources and storage resources according to resource type. The raw message data includes cluster architecture identifiers. For any type of cloud platform resource, the original message data corresponding to the cloud platform resource is mapped to metadata with a unified unit of measurement, and the metadata is preprocessed. Based on the preprocessed metadata, the amount of data used by the cloud platform resource of that resource type is determined. By using the cluster architecture identifier in the original message data, cloud platform resources are divided into resources with management nodes and resources without management nodes according to the resource architecture. The cost of management nodes is extracted according to the cost allocation logic of each resource architecture, and the indirect costs are allocated according to the availability of business resource units until the unit price of usage fee for each business resource unit is formed. Among them, the management node does not directly provide business computing or storage services, but its cost is included in the cost allocation of cloud platform resources. Cloud platform resources are used as a statistical dimension, and the usage data volume and usage fee unit price of cloud platform resources are calculated based on the business resource units that actually carry the business. By aggregating the usage data and unit price of cloud platform resources, the metering and billing analysis results of cloud platform resources are obtained. By combining the metering and billing analysis results of various cloud platform resources, a metering and billing analysis report for the banking industry in a multi-cloud environment is generated and output.

[0005] According to another aspect of this application, a metering and billing analysis system for a multi-cloud environment in the banking industry is provided, the system comprising: The data acquisition module is used when the banking industry uses cloud platform resources from multiple cloud service providers and needs to perform cross-cloud platform resource metering and billing. It constructs an adapter suitable for each cloud platform and collects the raw message data returned by the cloud platform resources through the API interface through the adapter. The cloud platform resources are divided into computing resources and storage resources according to resource type. The raw message data includes cluster architecture identifier. The data processing module is used to map the original message data corresponding to the cloud platform resource of any resource type into metadata with a unified unit of measurement, perform data preprocessing on the metadata, and determine the amount of data used by the cloud platform resource of the resource type based on the preprocessed metadata. The cost attribution module is used to divide cloud platform resources into resources with and without management nodes based on the cluster architecture identifier in the original message data. It then separates the management node cost for each of the two resource architectures according to their respective cost allocation logic, and allocates indirect costs according to the availability of business resource units until a unit price for each business resource unit is formed. The management node does not directly provide business computing or storage services, but its cost is included in the cost allocation of cloud platform resources. Cloud platform resources are used as a statistical dimension, and the amount of data used and the unit price for use of cloud platform resources are calculated based on the business resource units that actually carry the business. The report generation module is used to aggregate the usage data and unit price of cloud platform resources to obtain the metering and billing analysis results of cloud platform resources. By combining the metering and billing analysis results of various cloud platform resources, it generates and outputs the metering and billing analysis report of the banking industry in a multi-cloud environment.

[0006] According to another aspect of this application, a medium is provided having a computer program stored thereon, which, when executed by a processor, implements the above-described metering and billing analysis method in a multi-cloud environment of the banking industry.

[0007] According to another aspect of this application, an apparatus is provided, including a medium, a processor, and a computer program stored on the medium and executable on the processor, wherein the processor executes the program to implement the above-described metering and billing analysis method in a multi-cloud environment of the banking industry.

[0008] By employing the aforementioned technical solutions, this application provides a metering and billing analysis method, system, medium, and equipment for the banking industry in a multi-cloud environment. To meet the cross-cloud metering and billing needs of the banking industry in a multi-cloud environment, adapters for each cloud platform are constructed to collect raw message data (including cluster architecture identifiers) of computing and storage resources returned by APIs. The raw data is mapped to unified metering unit metadata and preprocessed to determine the amount of data used for resources. Based on the cluster architecture identifier, resources with / without management nodes are distinguished, and management node costs are extracted according to their respective logics. Indirect costs are allocated according to the availability of business resource units to form a unit price for each business resource unit. The analysis results are obtained by aggregating the usage data volume and unit price, and a comprehensive metering and billing analysis report is generated and output. This effectively solves problems such as heterogeneous resource metering, disconnect between billing and business operations, and insufficient accuracy of cost control in a multi-cloud environment, providing technical support for resource management and cost optimization in the digital transformation of banks.

[0009] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This paper illustrates a flowchart of a metering and billing analysis method for the banking industry in a multi-cloud environment, as provided in an embodiment of this application. Figure 2 This paper illustrates a flowchart of another metering and billing analysis method for the banking industry in a multi-cloud environment, provided by an embodiment of this application. Figure 3 This paper illustrates a schematic diagram of the structure of a metering and billing analysis system for the banking industry in a multi-cloud environment, as provided in an embodiment of this application. Detailed Implementation

[0011] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0012] This embodiment provides a metering and billing analysis method for the banking industry in a multi-cloud environment, such as... Figure 1 As shown, the method includes: Step 101: When the banking industry uses cloud platform resources from multiple cloud service providers and requires cross-cloud platform resource metering and billing, an adapter suitable for each cloud platform is constructed. The adapter collects the raw message data returned by the cloud platform resources through the API interface. The cloud platform resources are divided into computing resources and storage resources according to resource type. The raw message data includes the cluster architecture identifier. Step 102: For any type of cloud platform resource, map the original message data corresponding to the cloud platform resource to metadata with a unified unit of measurement, perform data preprocessing on the metadata, and determine the amount of data used by the cloud platform resource of the resource type based on the preprocessed metadata. Step 103: Using the cluster architecture identifier in the original message data, the cloud platform resources are divided into resources with management nodes and resources without management nodes according to the resource architecture. The cost of management nodes is extracted according to the cost allocation logic of each resource architecture, and the indirect costs are allocated according to the availability of business resource units until the unit price of usage fee for each business resource unit is formed. Among them, the management node does not directly provide business computing or storage services, but its cost is included in the cost allocation of cloud platform resources. Cloud platform resources are used as a statistical dimension. The amount of data used by cloud platform resources and the unit price of usage fee are calculated based on the business resource units that actually carry the business. Step 104: Aggregate the usage data volume and unit price of cloud platform resources to obtain the metering and billing analysis results of cloud platform resources. Combine the metering and billing analysis results of various cloud platform resources to form and output the metering and billing analysis report of the banking industry in a multi-cloud environment.

[0013] In the above embodiments of this application, by building dedicated adapters for different cloud service providers, the problems of large differences in API interfaces and heterogeneous raw message data structures across multiple cloud platforms can be effectively solved. Data collection can be supported at configurable frequencies such as daily / hourly, including Huawei Cloud adapters, traditional cloud adapters, object storage adapters, CMDB adapters, etc. In particular, the adapters are only responsible for obtaining the raw message data returned by the API without processing it, ensuring the originality of the data, while adapting to the interface characteristics of different cloud platforms.

[0014] To this end, the underlying complexity is shielded by an adapter, enabling reliable collection of raw data (including key cluster architecture identifiers) of core resources such as computing and storage resources, laying a data foundation for subsequent processing.

[0015] Next, the raw data of different resource types from various cloud platforms are mapped to metadata with a unified unit of measurement. After preprocessing, the amount of data used is determined, eliminating the incomparability of data caused by differences in the measurement standards and units of cloud service providers. This enables horizontal comparison and aggregation analysis of computing and storage resource usage across cloud platforms, providing an accurate basis for resource optimization. To achieve unified measurement standards, the specific steps are as follows: For computing resources: Huawei Cloud "ECS Elastic Cloud Server CPU", VMware virtual machine vCPU, etc., are uniformly mapped to the unit of measurement "vcpu"; For storage resources: centralized block storage, object storage, and file storage are uniformly measured according to the actual available capacity, and the capacity unit is standardized as "GB".

[0016] Next, the cluster architecture is used to distinguish between resources containing management nodes and pure business resources, and cost allocation logic is designed for each. The costs of management nodes that do not directly provide business services are precisely separated, and indirect costs are scientifically allocated based on the actual availability of business resource units. Finally, a precise unit price for usage based on the actual business unit is calculated. This mechanism ensures that cost accounting closely aligns with actual business consumption, avoids cost distortions caused by traditional extensive allocation, and improves cost transparency and the rationality of allocation.

[0017] Ultimately, the system automatically aggregates usage data from various cloud platforms and their corresponding precise unit prices, generating multi-dimensional metering and billing analysis results. This results in a comprehensive analytical report that meets the stringent management requirements of the banking industry. This highly automated process reduces human intervention and error risks, and the output report data is traceable and logically auditable, effectively supporting core needs such as cost control, budget preparation, service pricing, and compliance supervision.

[0018] Specifically, for cloud platform resources, it can comprehensively cover 18 types of resources commonly used in multi-cloud deployments in banks, including 15 types of computing resources and 3 types of storage resources: Computing resources, such as Huawei Cloud ARM virtual machines, Huawei Cloud X86 virtual machines, Huawei Cloud C86 virtual machines, Huawei Cloud ARM bare metal, Huawei Cloud X86 bare metal, Huawei Cloud C86 bare metal, Huawei Cloud ARM virtual machine containers, Huawei Cloud C86 virtual machine containers, Huawei Cloud bare metal containers, traditional cloud virtual machines (VMWARE), traditional cloud hard disk storage (storage used by VMware), traditional cloud X86 virtual machine containers, traditional cloud bare metal, and traditional cloud C86 physical machine containers.

[0019] Storage resources, such as centralized block storage resources, object storage resources, and file storage resources (NAS).

[0020] Optionally, in step 103, the management node cost is separated for each of the two resource architectures according to their respective cost allocation logic, and the indirect cost is allocated according to the availability of business resource units until a unit price for the usage fee of each business resource unit is formed, including: Step 1031: For resources containing management nodes, extract the total cost of management nodes and the total available service capacity of the cluster from the original message data. Based on the ratio of the available capacity of each service resource unit to the total available service capacity of the cluster, use the available capacity ratio method to allocate the total cost of management nodes to each service resource unit to form the unit price of usage fee for each service resource unit. Step 1032: For resources without management nodes, extract the actual available capacity of the resources directly from the original message data, and deduct the basic space reserved by default by the cloud platform to obtain the effective capacity of the business. Based on the effective capacity of the business, allocate the total cost of the resources to form the unit price of the usage fee for each business resource unit.

[0021] In the above embodiments of this application, the cost of computing and storage resources is directly attributed to specific business systems and business departments through cost allocation rules. For example, the cost of a database server dedicated to a certain business system is directly included in the cost of the business department corresponding to that business system, ensuring that costs are accurately matched with business value.

[0022] Alternatively, a "resource unit price calculation model" can be established, which involves developing differentiated unit price calculation rules based on differences in cloud architecture. This avoids reliance on any proprietary system, ensuring universal compatibility. Specifically: For resources with management nodes: the cost of management nodes is allocated to the cost of available computing or storage capacity. For example, for Huawei Cloud full-stack cloud virtual machines, the cost of management nodes needs to be allocated to the cost of available vCPUs in the virtualization cluster to form the final unit price. For resources without management nodes (such as centralized block storage): the cost is directly calculated and allocated to the available capacity. For example, for centralized block storage, the cost is allocated by capacity in GB, and the unit price is determined per GB.

[0023] Furthermore, regarding resources that include management nodes, taking Huawei Cloud full-stack cloud virtual machines as an example, for instance: The total cost incurred by all management nodes within the cluster (such as hardware / software costs for the virtualization management platform and control nodes) is parsed from the raw message data. The total available capacity (e.g., the total number of available vCPUs) of all business resource units (such as virtual machines) in the cluster is extracted as the total available service capacity of the cluster. For each business resource unit (such as a single virtual machine), the proportion of its available capacity (e.g., 4-core vCPUs) to the total available capacity of the cluster is calculated as the allocation ratio. The total cost of the management nodes is allocated to each business resource unit according to the above ratio. The allocated management node cost is then added to the direct cost of the business resource unit (such as the basic cost of vCPUs) to form the unit price for each business resource unit. By allocating the management node cost according to the proportion of the available capacity of the business resource unit, it ensures that the management cost is linked to the actual service carrying capacity and avoids excessive cost allocation to idle resource units.

[0024] For resources without a management node, taking centralized block storage as an example: The total capacity of storage resources is obtained from the original message data, which is taken as the actual available capacity. Based on the cloud platform's default rules (such as reserving 10% space for performance), the effective capacity for the business is calculated. The total cost of this storage resource is obtained, and the total cost is allocated to the effective business capacity to form a unit price per GB. By deducting the reserved space, the focus is on the actual available resources, ensuring that the cost allocation matches the actual business needs and avoiding paying for unavailable capacity.

[0025] In summary, both methods are based on standard fields (such as cost, capacity, and cluster identifier) ​​in the original message data for calculation, without relying on cloud platform proprietary interfaces or systems. They can be adapted to the differentiated architectures of mainstream service providers such as Huawei Cloud and Alibaba Cloud, ensuring the model's universality in multi-cloud environments.

[0026] Optionally, in step 104, the metering and billing analysis results of various cloud platform resources are integrated to generate and output a metering and billing analysis report for the banking industry in a multi-cloud environment, including: Step 1041: Through a three-level tagging system, the metering and billing analysis results of various cloud platform resources are integrated to form and output a metering and billing analysis report for the banking industry in a multi-cloud environment. The three-level tagging system includes resource type, cloud service provider, and business system.

[0027] In the embodiments described above, the three-level tagging system enhances the business value of metering and billing data through multi-dimensional aggregation and analysis. Specifically, the resource type dimension unifies metering standards, enabling horizontal cost comparison of similar resources across clouds; the cloud service provider dimension clarifies the itemized costs of each service provider, supporting supplier management and negotiation decisions; and the business system dimension accurately associates resource consumption with specific application systems or departments, ensuring that costs are traceable to the ultimate responsible unit. The three elements work together to form a complete "resource-location-attribution" topology, satisfying banks' need for refined analysis of resource utilization efficiency while providing a transparent and auditable data foundation for cross-departmental cost allocation, budget optimization, and cloud architecture planning, effectively supporting the core requirements of multi-cloud governance in the banking industry.

[0028] Optionally, in step 1041, a metering and billing analysis report for the banking industry under a multi-cloud environment is generated and output by integrating the metering and billing analysis results of various cloud platform resources through a three-level tagging system. The three-level tagging system includes resource type, cloud service provider, and business system, specifically including: Step 10411: Using resource type as the primary label, calculate the total cost of cloud platform resources of each resource type in a multi-cloud environment, as well as the proportion of the cost of cloud platform resources of each resource type to the total cost, to obtain the cost structure analysis results of cloud platform resources on the primary label. Step 10412: Using cloud service providers as secondary labels, summarize the measurement results of cloud platform resources of all resource types within the cloud platform of a single cloud service provider. At the same time, break down the unit cost of the same type of resources on each cloud platform, compare the cost of the same type of resources among different service providers, and obtain the cross-platform cost difference analysis results of cloud platform resources on the secondary labels. Step 10413: Using business systems as the third-level labels, the usage data volume and unit price of each cloud platform resource are mapped to the specific business being carried, and business value indicators are associated to obtain the business value association analysis results of cloud platform resources on the third-level labels. Step 10414: Summarize the analysis results of cloud platform resources on the first-level, second-level, and third-level tags respectively, and generate and output a metering and billing analysis report containing a three-level tag system in the multi-cloud environment of the banking industry.

[0029] In the above embodiments of this application, cost attribution and allocation principles can be designed, that is, a multi-level cost attribution mechanism for banks can be designed to achieve accurate cost allocation, which can be distinguished from the existing single-dimensional or proprietary system-dependent allocation schemes. A three-level labeling system can be constructed, including first-level labels (organizational structure: head office / branch / sub-branch), second-level labels (business departments: retail department, corporate department, technology department, etc.), and third-level labels (business systems: core business system, mobile banking system, etc.).

[0030] Furthermore, for the primary tag, we analyze the cost structure of resource types: Raw cost data for all resource types is extracted from the metering and billing systems of various cloud platforms and categorized and summarized by resource type (compute, storage, network, database, etc.). The percentage of cost for each resource type in the total cost is calculated as follows: Resource type percentage = Total cost of that resource type / Total cost of all resources × 100%. This allows for quick identification of the resource type with the highest cost percentage, providing direction for resource optimization and budget allocation.

[0031] Analysis of cross-platform cost differences for cloud service providers regarding secondary tags: Metering results for all resource types within a cloud service provider's platform (Alibaba Cloud, Huawei Cloud, AWS, etc.) are aggregated to form a "Service Provider-Resource Type" matrix. Unit costs (e.g., cost per core of computing resources, cost per GB of storage) are calculated for the same type of resource: Unit Cost = Total Cost of Resource Type / Total Usage of Resource Type. Specifically, a cross-service provider unit cost comparison table can be generated, highlighting the difference rate. This allows for the identification of low-cost, high-performance service providers, providing data support for supplier negotiations and resource procurement strategies.

[0032] For three-level tags, business system value correlation analysis: This algorithm links the usage of resources on each cloud platform (such as computing time and storage capacity) with the unit price to specific business systems, generating a detailed table of "Business System - Resource Type - Cost". It extracts core value indicators (such as transaction volume, number of users, and revenue) from each business system and calculates the unit value cost: Unit Value Cost = Total Resource Cost / Business Value Indicator. It can also compare the unit value costs of different business systems, generate a ranking table, and identify outliers. This reveals the correlation between resource consumption and business output, supporting business system optimization and resource reallocation decisions.

[0033] Finally, the analysis results of the first-level tags (resource type), second-level tags (cloud service providers), and third-level tags (business systems) are integrated into a unified report, forming a three-level tag cube of "resource-service provider-business". Combined with organizational structure tags (head office / branch / sub-branch) and business department tags (retail / corporate / technology), costs are further attributed to specific responsibility units. Key indicators (such as total cost percentage and unit value cost ranking) are displayed through dynamic dashboards, supporting filtering and drill-down analysis by tag dimension. Standardized reports (Excel / PDF) or real-time data interfaces are generated for the finance department to allocate costs, the technology department to optimize resource allocation, and the business department to evaluate the return on investment.

[0034] To this end, a three-level labeling system and a multi-level attribution mechanism are used to achieve cost transparency from the resource layer to the business layer and from the technology dimension to the organizational dimension, supporting banks to achieve the dual goals of "precise cost reduction" and "high efficiency" in a multi-cloud environment.

[0035] Optionally, in step 102, data preprocessing is performed on the metadata, specifically including: Step 1021: Check whether the metadata contains necessary fields, mark the missing fields as abnormal and collect them again. The necessary fields include at least one of resource ID, resource usage and usage time. Step 1022: Unify the timestamp format of metadata across different cloud platforms; Step 1023: Unify the message structure of heterogeneous cloud data from different cloud platforms into a single-layer dictionary and array format; Step 1024: Adjust the metadata structure by row-to-column conversion and field merging to obtain the preprocessed metadata.

[0036] In the above embodiments of this application, the metadata corresponding to the collected raw message data can be preprocessed in multiple dimensions to ensure data quality and provide a reliable foundation for subsequent processing. For example, it can check whether the data contains necessary fields such as resource ID, resource usage, and usage duration. Data with missing fields is marked as abnormal and a supplementary collection mechanism is triggered. The timestamps of different cloud platforms are unified into the format "yyyy-MM-ddHH:mm:ss.SSS" to ensure consistency in the time dimension. The heterogeneous data message structures of different cloud platforms are unified into the format of "single-layer dictionary + array" to simplify the subsequent data processing flow. The data structure is adjusted by methods such as row-to-column conversion and field merging to reduce data redundancy and improve processing efficiency.

[0037] Optionally, before mapping the original message data corresponding to cloud platform resources to metadata in a unified unit of measurement, the method further includes: Step 105: For computing resources, define the units of measurement according to the dimensions of virtual machines, containers and bare metal servers respectively. The dimensions of virtual machines include the instance code, virtual name, number of vCPUs, memory size and storage capacity of the virtual machine; the dimensions of containers include the instance code, namespace name, namespace quota and storage capacity of the container; and the dimensions of bare metal servers include the instance code, namespace and device name of the bare metal server. Step 106: For storage resources, define the units of measurement according to the dimensions of centralized block storage, object storage, and file storage respectively. The dimensions of centralized block storage include the instance code, storage name, client hostname, and capacity of centralized block storage. The dimensions of object storage include the instance code, storage name, bucket name, and capacity of object storage. The dimensions of file storage include the instance code, storage name, client IP, file system name, and capacity of file storage.

[0038] In the above embodiments of this application, a unified measurement dimension system can be established to clarify the core measurement dimensions of computing and storage resources, ensuring data traceability and analyzability, and covering the core concerns of bank resource management. Specifically: The computing resource dimension includes: 1. Virtual Machine: Instance code, virtual machine name, number of vCPUs, memory size, storage capacity; 2. Container: Instance code, namespace name, namespace quota, storage capacity; 3. Bare metal server: instance code, namespace, device name.

[0039] Storage resource dimensions include: 1. Centralized block storage resources: instance code, storage name, client hostname, and capacity; 2. Object storage resources: instance code, storage name, bucket name, capacity; 3. File Storage Resource (NAS): Instance code, storage name, client IP, file system name, capacity.

[0040] Currently, resource metering and billing in multi-cloud environments and related technologies face four core problems that severely restrict the efficiency of resource management and cost optimization capabilities in the banking industry. These problems are as follows: 1. Inconsistent resource metering standards: Different cloud platforms use significantly different units of measurement (such as CPU count / virtual core count, storage capacity) and statistical rules for computing, storage and other resources. For example, the CPU metering of Huawei Cloud ECS is different from the vCPU statistical logic of VMware virtual machines, which makes it impossible for banks to compare the resource consumption levels of various cloud platforms. Existing multi-cloud capacity analysis technology has not solved this heterogeneous metering problem. 2. Billing rules are out of sync with business scenarios: Existing billing tools are mostly designed based on general cloud resources and do not take into account the characteristics of banking business (such as the differences in resource consumption characteristics between retail business and corporate business). Moreover, existing cost allocation schemes rely on proprietary systems and are only applicable to cost allocation within a single system. This results in the inability to accurately match cost allocation with business value and makes it difficult to support cost optimization decisions at the business level. 3. Lack of systematic cost control: Existing technologies mostly focus on optimizing a single link and have not formed a complete solution for the "measuring-billing-attribution" process. Banks cannot clearly grasp the distribution of resource costs of each business line and organizational structure on different cloud platforms, and cost optimization lacks data support. 4. Insufficient versatility and scalability: Some solutions rely on proprietary systems (such as SAPHANA) or are designed only for specific functions (such as login management and resource deployment), which cannot adapt to the dynamic expansion needs of multi-cloud deployment in banks. When adding new cloud platforms or new business scenarios, a lot of secondary development is required.

[0041] By applying the technical solution of this embodiment, the following beneficial effects are achieved: 1. Establish a unified metering system for multi-cloud resources: By constructing an abstract metering model, standardize the metering units and statistical rules for resources (CPU, storage) on different cloud platforms, achieve horizontal comparison of the consumption of allocated resources across clouds, and completely solve the problem of heterogeneous metering standards; 2. Achieve precise cost control and full-process coverage across multiple clouds: Based on unified metering data and scenario-based billing results, banks can monitor the resource cost distribution of various cloud platforms, business lines, and organizational structures in real time, providing full-process data support for cost optimization. 3. Strong scalability and universal compatibility: Supports access to new cloud platforms (such as Alibaba Cloud and Tencent Cloud) and new business scenarios (such as digital RMB business systems). Users only need to supplement the corresponding data structure according to this analysis method. There is no need to reconstruct the core system. The access cycle is shortened to within 7 working days. It does not depend on any proprietary system and is compatible with various bank multi-cloud deployment architectures. 4. More precise business adaptability: The three-level tagging system enables precise allocation of costs to business systems and departments, solving the problem of "strong universality but weak industry adaptability" of existing cost allocation schemes, and meeting the refined cost control needs of multiple departments and business scenarios in the banking industry.

[0042] In one specific embodiment, such as Figure 2As shown, the metering and billing analysis process for multi-cloud environments in the banking industry relies on standardized data collection and a multi-level cost attribution system to achieve unified cross-platform management. First, considering the heterogeneous resource characteristics of different cloud service providers, a data collector adapted to the API interfaces of each platform is built. This collector uses API adapters to selectively capture raw messages of computing and storage resources, focusing on extracting key information such as resource identifiers, usage, and cluster architecture identifiers. Simultaneously, a data processing module filters outliers to ensure the accuracy of the raw data. Based on a unified resource abstraction model, the collected raw data is mapped to standardized metadata according to resource type (computing / storage). For example, the units of CPU core count and storage capacity on different platforms are uniformly converted to UCC (Unified Computing Unit) and UCS (Unified Storage Unit). Data cleaning and standardization are then completed through a resource pricing calculation model, forming basic data that can be compared across platforms. In the cost allocation stage, the cluster architecture identifier in the raw messages is used to distinguish between management node and business node resources. While management nodes do not directly handle business operations, their costs must be allocated to each business unit based on the number of business nodes. Business nodes, in turn, require the sum of direct costs and allocated management costs, combined with the total amount of business resource units (e.g., UCC / UCS consumption) to calculate the unit price per unit of business resource. This process, through a multi-level cost attribution mechanism, ensures that indirect costs are accurately allocated to the resource units actually carrying the business, avoiding interference from management costs on the unit price. After standardized data processing, a unified measurement dimension system is used to perform multi-dimensional aggregation analysis of multi-cloud resources. Horizontally, the total usage and cost of resources on each platform are statistically analyzed by cloud service provider; vertically, the cost structure is broken down by resource type. A cross-cloud cost precision analysis module compares the unit cost differences of the same type of resources across different platforms. Finally, multi-dimensional reports are generated based on the multi-level cost attribution results, intuitively displaying the resource type proportion, service provider cost differences, and the correlation between business system resource consumption and value. This provides decision support for resource optimization and budget allocation. Simultaneously, the report generation and control modules enable dynamic cost monitoring and optimization suggestion output.

[0043] To address this, a unified abstract metering model for multi-cloud resources was constructed, breaking through the heterogeneous barriers of metering standards across different cloud platforms and achieving quantitative comparability of cross-cloud resource allocation. Scenario-based billing rules deeply adapted to banking business scenarios were established, providing metering and billing data across multiple dimensions such as organizational structure, business departments, and business systems, achieving a precise correlation mapping between "resource cost" and "business value." A closed-loop solution encompassing "metering-billing-attribution" was created, improving the systematic nature and accuracy of multi-cloud resource cost management. A generalized and highly scalable technical architecture was provided, supporting rapid integration of new cloud platforms and new business scenarios without requiring core system reconstruction, adapting to the dynamic needs of bank digital transformation. Simultaneously, the following technical issues were resolved: 1. The problem of heterogeneous resource metering standards among different cloud service providers: Break through the barriers of differences in measurement units and statistical rules for resources such as CPU and storage in multi-cloud environments, realize the quantitative comparability and unified management of cross-cloud resource consumption, and fill the gap in metering standardization of existing multi-cloud management technologies. 2. Issues of mismatch between billing rules and banking business and fragmented cost allocation: Fill the rule gaps of general cloud billing tools in banking business scenarios, establish differentiated billing logic adapted to different resource types and business attributes, and solve the problems of "dedicated system dependence and single system limitation" in existing cost allocation solutions; 3. The lack of systematic and accurate multi-cloud resource cost control: By standardizing metering, scenario-based billing, and multi-level attribution, we provide banks with clear cross-cloud resource cost data, solving the problem of inefficient cost control caused by the "single-link optimization and lack of full-process optimization" of existing technologies; 4. Addressing the issues of insufficient compatibility and versatility in accessing new cloud platforms and new business scenarios: Providing a scalable and universal technical architecture that supports adaptation to new cloud platforms and access to new business scenarios without system reconstruction, overcoming the shortcomings of existing solutions in terms of dependence on proprietary systems and weak scalability.

[0044] Furthermore, embodiments of this application provide a metering and billing analysis system for the banking industry in a multi-cloud environment, such as... Figure 3 As shown, the system includes: The data acquisition module 201 is used to construct adapters suitable for each cloud platform when the banking industry uses cloud platform resources from multiple cloud service providers and needs to perform cross-cloud platform resource metering and billing. The adapters collect the raw message data returned by the cloud platform resources through the API interface. The cloud platform resources are divided into computing resources and storage resources according to resource type. The raw message data includes cluster architecture identifiers. Data processing module 202 is used to map the original message data corresponding to the cloud platform resource of any resource type to metadata with a unified unit of measurement, perform data preprocessing on the metadata, and determine the amount of data used by the cloud platform resource of the resource type based on the preprocessed metadata. The cost attribution module 203 is used to divide cloud platform resources into resources with management nodes and resources without management nodes according to the cluster architecture identifier in the original message data. It separates the cost of management nodes for each of the two resource architectures according to their respective cost allocation logic, and allocates indirect costs according to the availability of business resource units until a unit price for each business resource unit is formed. Among them, the management node does not directly provide business computing or storage services, but its cost is included in the cost allocation of cloud platform resources. Cloud platform resources are used as a statistical dimension, and the amount of data used and the unit price for use of cloud platform resources are calculated based on the business resource units that actually carry the business. The report generation module 204 is used to aggregate the usage data and unit price of cloud platform resources to obtain the metering and billing analysis results of cloud platform resources. By combining the metering and billing analysis results of various cloud platform resources, it generates and outputs a metering and billing analysis report for the banking industry in a multi-cloud environment.

[0045] System management module 205 is used to provide user management, permission management, parameter configuration and log management functions.

[0046] In the above embodiments of this application, the data acquisition module 201 is responsible for collecting the original metering data of the allocated resources from various cloud platforms. It adopts a timed acquisition mode with a configurable acquisition frequency (which can be set to once a day by default), balancing system performance and data timeliness, and supporting interface adaptation for different cloud platforms. The data processing module 202 may include a data cleaning unit, a standardization mapping unit, and a cost calculation unit, which respectively complete data quality verification, heterogeneous data standardization conversion, and cost accounting. It does not rely on proprietary systems and is adaptable to various bank IT architectures. The cost attribution module 203 performs cost attribution based on a three-level tagging system and supports group-based cost attribution. The system provides multi-dimensional cost analysis across organizational structure, business departments, and business lines, offering customizable query and export functions to meet the bank's refined management needs. The report generation module 204 supports outputting reports in multiple formats such as Excel and PDF. The report content covers core data such as total resource volume and total price trend charts, resource usage and billing invoices for each system, and resource cost rankings, intuitively presenting cost distribution and changing trends. The system management module 205 includes functions such as user management, permission management, parameter configuration, and log management, ensuring the system's secure operation and maintainability, supporting permission isolation for different roles, and adapting to the bank's strict security management requirements.

[0047] It should be noted that other corresponding descriptions of the functional units involved in the metering and billing analysis system for a multi-cloud environment in the banking industry provided in this application embodiment can be found in the following references. Figures 1 to 2 The corresponding descriptions in the method will not be repeated here.

[0048] Based on the above, Figures 1 to 2 Accordingly, this application also provides a medium on which a computer program is stored, which, when executed by a processor, implements the above-described method. Figures 1 to 2 The method for metering and billing analysis in a multi-cloud environment in the banking industry is shown.

[0049] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to enable a device (such as personal computer, server, or network device, etc.) to execute the methods described in various implementation scenarios of this application.

[0050] Based on the above, Figures 1 to 2 The method shown, and Figure 3 To achieve the above objectives, the virtual system embodiment shown in this application also provides a device, which may be a personal computer, server, network device, etc. This device includes a medium and a processor; the medium is used to store a computer program; the processor is used to execute the computer program to achieve the above-described objectives. Figures 1 to 2 The method for metering and billing analysis in a multi-cloud environment in the banking industry is shown.

[0051] Optionally, the device may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Bluetooth interfaces, Wi-Fi interfaces), etc.

[0052] Those skilled in the art will understand that the device structure provided in this embodiment does not constitute a limitation on the device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0053] The medium may also include an operating system and a network communication module. The operating system is a program that manages and stores the device's hardware and software resources, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the medium, as well as communication with other hardware and software within the physical device.

[0054] Through the above description of the implementation methods, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware systems, or it can be implemented using hardware to meet the cross-cloud metering and billing needs of the banking industry in a multi-cloud environment. It involves constructing adapters for each cloud platform and collecting raw message data (including cluster architecture identifiers) of computing and storage resources returned by APIs. The raw data is mapped to unified metering unit metadata and preprocessed to determine the amount of data used for resources. Based on the cluster architecture identifier, resources with / without management nodes are distinguished, and management node costs are extracted according to their respective logics. Indirect costs are allocated according to the availability of business resource units to form a unit price for each business resource unit. The data volume and unit price are aggregated to obtain analysis results, and a comprehensive metering and billing analysis report is generated and output. This effectively solves problems such as heterogeneous resource metering, disconnect between billing and business operations, and insufficient accuracy of cost control in a multi-cloud environment, providing technical support for resource management and cost optimization in the digital transformation of banks.

[0055] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application. Those skilled in the art will understand that the modules in the system of the embodiment scenario can be distributed throughout the system of the embodiment scenario as described, or they can be modified to reside in one or more systems different from this embodiment scenario. The modules of the above-described embodiment scenario can be combined into one module, or further divided into multiple sub-modules.

[0056] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of any particular implementation scenario. The above disclosures are merely a few specific implementation scenarios of this application; however, this application is not limited thereto, and any modifications that can be made by those skilled in the art should fall within the protection scope of this application.

Claims

1. A metering and billing analysis method for the banking industry in a multi-cloud environment, characterized in that, The method includes: When the banking industry uses cloud platform resources from multiple cloud service providers and requires cross-cloud platform resource metering and billing, adapters suitable for each cloud platform are constructed. The adapters collect the raw message data returned by the cloud platform resources through the API interface. The cloud platform resources are divided into computing resources and storage resources according to resource type. The raw message data includes cluster architecture identifiers. For any type of cloud platform resource, the original message data corresponding to the cloud platform resource is mapped to metadata with a unified unit of measurement, and the metadata is preprocessed. Based on the preprocessed metadata, the amount of data used by the cloud platform resource of that resource type is determined. By using the cluster architecture identifier in the original message data, cloud platform resources are divided into resources with management nodes and resources without management nodes according to the resource architecture. The cost of management nodes is extracted according to the cost allocation logic of each resource architecture, and the indirect costs are allocated according to the availability of business resource units until the unit price of usage fee for each business resource unit is formed. Among them, the management node does not directly provide business computing or storage services, but its cost is included in the cost allocation of cloud platform resources. Cloud platform resources are used as a statistical dimension, and the usage data volume and usage fee unit price of cloud platform resources are calculated based on the business resource units that actually carry the business. By aggregating the usage data and unit price of cloud platform resources, the metering and billing analysis results of cloud platform resources are obtained. By combining the metering and billing analysis results of various cloud platform resources, a metering and billing analysis report for the banking industry in a multi-cloud environment is generated and output.

2. The method according to claim 1, characterized in that, The process of separating management node costs for each of the two resource architectures and allocating indirect costs according to the availability of business resource units until a unit price for each business resource unit is formed includes: For resources containing management nodes, the total cost of management nodes and the total available service capacity of the cluster are extracted from the original message data. Based on the proportion of the available capacity of each service resource unit to the total available service capacity of the cluster, the total cost of management nodes is allocated to each service resource unit using the available capacity proportion method, forming the unit price of usage fee for each service resource unit. For resources without management nodes, the actual available capacity of the resources is extracted directly from the original message data, and the basic space reserved by default by the cloud platform is deducted to obtain the effective capacity of the business. The total cost of resources is allocated based on the effective capacity of the business to form the unit price of usage fee for each business resource unit.

3. The method according to claim 1, characterized in that, The combined metering and billing analysis results from various cloud platform resources are used to generate and output a metering and billing analysis report for the banking industry in a multi-cloud environment, including: By integrating the metering and billing analysis results of various cloud platform resources through a three-level tagging system, a metering and billing analysis report for the banking industry under a multi-cloud environment is generated and output. The three-level tagging system includes resource type, cloud service provider, and business system.

4. The method according to claim 3, characterized in that, The aforementioned three-level tagging system integrates the metering and billing analysis results of various cloud platform resources to generate and output metering and billing analysis reports for the banking industry in a multi-cloud environment, including: Using resource type as the primary label, we statistically analyze the total cost of cloud platform resources of each resource type in a multi-cloud environment, as well as the proportion of the cost of cloud platform resources of each resource type to the total cost, to obtain the cost structure analysis results of cloud platform resources on the primary label. Using cloud service providers as secondary labels, the metering results of all resource types within a single cloud service provider's cloud platform are aggregated. At the same time, the unit cost of the same type of resource on each cloud platform is broken down, and the cost of the same resource type between different service providers is compared to obtain the cross-platform cost difference analysis results of cloud platform resources on the secondary labels. Using business systems as the third-level labels, the usage data volume and unit price of each cloud platform resource are mapped to the specific business being carried, and business value indicators are associated to obtain the business value association analysis results of cloud platform resources on the third-level labels; The analysis results of cloud platform resources on the first-level, second-level, and third-level tags are summarized and output to form a metering and billing analysis report with a three-level tag system in the multi-cloud environment of the banking industry.

5. The method according to claim 1, characterized in that, The data preprocessing of metadata includes: Check whether the metadata contains necessary fields, mark the missing fields as anomalies and collect them again. The necessary fields include at least one of resource ID, resource usage, and usage time. Unify the timestamp format of metadata across different cloud platforms; Unify the message structure of heterogeneous cloud data from different cloud platforms into a single-layer dictionary and array format; By adjusting the metadata structure through row-to-column conversion and field merging, we obtain the preprocessed metadata.

6. The method according to any one of claims 1 to 5, characterized in that, Before mapping the original message data corresponding to cloud platform resources into metadata with a unified unit of measurement, the method further includes: For computing resources, measurement units are defined separately for virtual machines, containers, and bare metal servers. The virtual machine dimension includes the virtual machine instance code, virtual name, number of vCPUs, memory size, and storage capacity. The container dimension includes the container instance code, namespace name, namespace quota, and storage capacity. The bare metal server dimension includes the bare metal server instance code, namespace, and device name. For storage resources, measurement units are defined according to the dimensions of centralized block storage, object storage, and file storage. The dimensions of centralized block storage include the instance code, storage name, client hostname, and capacity. The dimensions of object storage include the instance code, storage name, bucket name, and capacity. The dimensions of file storage include the instance code, storage name, client IP, file system name, and capacity.

7. A metering and billing analysis system for the banking industry in a multi-cloud environment, characterized in that, The system includes: The data acquisition module is used when the banking industry uses cloud platform resources from multiple cloud service providers and needs to perform cross-cloud platform resource metering and billing. It constructs an adapter suitable for each cloud platform and collects the raw message data returned by the cloud platform resources through the API interface through the adapter. The cloud platform resources are divided into computing resources and storage resources according to resource type. The raw message data includes cluster architecture identifier. The data processing module is used to map the original message data corresponding to the cloud platform resource of any resource type into metadata with a unified unit of measurement, perform data preprocessing on the metadata, and determine the amount of data used by the cloud platform resource of the resource type based on the preprocessed metadata. The cost attribution module is used to divide cloud platform resources into resources with and without management nodes based on the cluster architecture identifier in the original message data. It then separates the management node cost for each of the two resource architectures according to their respective cost allocation logic, and allocates indirect costs according to the availability of business resource units until a unit price for each business resource unit is formed. The management node does not directly provide business computing or storage services, but its cost is included in the cost allocation of cloud platform resources. Cloud platform resources are used as a statistical dimension, and the amount of data used and the unit price for use of cloud platform resources are calculated based on the business resource units that actually carry the business. The report generation module is used to aggregate the usage data and unit price of cloud platform resources to obtain the metering and billing analysis results of cloud platform resources. By combining the metering and billing analysis results of various cloud platform resources, it generates and outputs the metering and billing analysis report of the banking industry in a multi-cloud environment.

8. The system according to claim 7, characterized in that, The system also includes: The system management module provides functions for user management, permission management, parameter configuration, and log management.

9. A medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method for metering and billing analysis in a multi-cloud environment of the banking industry as described in any one of claims 1 to 6.

10. An apparatus comprising a medium, a processor, and a computer program stored on the medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method for metering and billing analysis in a multi-cloud environment of the banking industry as described in any one of claims 1 to 6.

Images