CN116383223A

CN116383223A - Asset data processing method, related device and storage medium

Info

Publication number: CN116383223A
Application number: CN202310316307.1A
Authority: CN
Inventors: 请求不公布姓名
Original assignee: Beijing Real AI Technology Co Ltd
Current assignee: Beijing Real AI Technology Co Ltd
Priority date: 2023-03-28
Filing date: 2023-03-28
Publication date: 2023-07-04

Abstract

The embodiment of the application relates to the field of data processing, and provides an asset data processing method, a related device and a storage medium. The method is applied to the server-side equipment, and comprises the following steps: acquiring asset data of a target service; the asset data is obtained through a user-defined resource technology of a Kubernetes system; acquiring a dynamic ontology based on the asset data and a historical asset relationship graph of the target business; the dynamic ontology is determined based on the changed assets of the target business, and the dynamic ontology comprises one of the business, the software asset and the hardware asset; and reconstructing the historical asset relationship graph by taking the dynamic ontology as a root node to obtain an updated asset relationship graph of the target business. According to the method, the dynamic ontology corresponding to the variable asset is constructed based on the asset data, and then the asset relationship graph of the target service is reconstructed by taking the dynamic ontology as a root node, so that the automatic management of the asset data is realized, an efficient data relationship form is formed between the asset and a service scene, and the maintenance efficiency of the asset data is effectively improved.

Description

Asset data processing method, related device and storage medium

Technical Field

The embodiment of the application relates to the field of data processing, in particular to an asset data processing method, a related device and a storage medium.

Background

With the business development of enterprises, the enterprises need to deploy various software and hardware assets matched with the business. Among these are various databases such as a relational database management system (e.g., mySQL), remote dictionary services (Remote Dictionary Server, redis), a distributed publish-subscribe messaging system (e.g., kafka), etc. The hardware assets are, for example, various hardware devices such as servers, switches, hard disks, central processing units (Central Processing Unit, CPU), graphics processors (Graphics Processing Unit, GPU), and the like.

In the related art, in order to maintain data relationships between various assets and business scenarios, a configuration management system, such as a configuration management database (Configuration Management Database, CMDB), corresponding to the various business scenarios is generally developed. In existing management systems, a corresponding data table is typically built for each asset individually, and each asset update requires structural modification of the data table of the asset concerned. However, in some application scenarios where the business frequently changes, in order to record the asset change caused by each business change in time, the data table structure of the asset needs to be manually changed, which is complex in operation, consumes manpower, and has low data maintenance efficiency.

Disclosure of Invention

The embodiment of the application provides an asset data processing method, a related device and a storage medium, which can realize automatic management of asset data and improve maintenance efficiency of the asset data.

In a first aspect, an embodiment of the present application provides an asset data processing method, where the method is applied to a server device, and the server device runs a Kubernetes system, and the method includes:

acquiring asset data of a target service; the asset data is obtained through a user-defined resource technology of a Kubernetes system;

acquiring a dynamic ontology based on the asset data and a historical asset relationship graph of the target business; the dynamic ontology is determined based on the changed assets of the target business, and the dynamic ontology comprises one of the business, the software asset and the hardware asset;

and reconstructing the historical asset relationship graph by taking the dynamic ontology as a root node to obtain an updated asset relationship graph of the target business.

In a second aspect, an embodiment of the present application provides an asset data processing device having a function of implementing an asset data processing method corresponding to the first aspect. The functions may be implemented by hardware, or may be implemented by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the functions described above, which may be software and/or hardware.

In one embodiment, the apparatus is applied to a server device, and the server device runs a Kubernetes system, and the apparatus includes:

the input-output module is configured to acquire asset data of a target service; the asset data is obtained through a user-defined resource technology of a Kubernetes system;

the processing module is configured to acquire a dynamic ontology based on the asset data and a historical asset relationship graph of the target business; the dynamic ontology is determined based on the changed assets of the target business, and the dynamic ontology comprises one of the business, the software asset and the hardware asset; and reconstructing the historical asset relationship graph by taking the dynamic ontology as a root node to obtain an updated asset relationship graph of the target business.

In a third aspect, embodiments of the present application provide a computing device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the asset data processing method described in the first aspect when executing the computer program.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium comprising instructions which, when run on a computer, cause the computer to perform the asset data processing method described in the first aspect.

Compared with the prior art, in the embodiment of the application, the asset data of the target business is acquired. The asset data can be obtained through the self-defined resource technology of the Kubernetes system, and the Kubernetes system can automatically monitor various assets of the target service in the cloud primary environment, so that a data base can be provided for automatic asset management of the target service. Further, a dynamic ontology is obtained based on the asset data of the target business and the historical asset relationship graph of the target business. The dynamic ontology is determined based on the change assets of the target business, and can be any one of business, software assets and hardware assets, so that the business change condition or asset change condition of the target business can be represented through the dynamic ontology. And finally, reconstructing a historical asset relationship graph by taking the dynamic ontology as a root node to obtain an updated asset relationship graph of the target business, wherein the updated asset relationship graph can visually display the data relationship between the variable asset and the target business. Compared with the asset change caused by each service change in the prior art, the method for managing the asset data needs to be manually changed, in the embodiment of the application, the dynamic ontology corresponding to the changed asset can be constructed based on the asset data, and further the asset relationship graph of the target service is reconstructed by taking the dynamic ontology as a root node, so that the automatic management of the asset data is realized, an efficient data relationship form is formed between the asset and a service scene, the difficulty in managing the asset data is greatly reduced, and the maintenance efficiency of the asset data is improved.

Drawings

The objects, features and advantages of the embodiments of the present application will become readily apparent from the detailed description of the embodiments of the present application read with reference to the accompanying drawings. Wherein:

FIG. 1 is a schematic diagram of an asset data processing system according to an embodiment of the present application;

FIG. 2 is a schematic flow chart of a method for processing asset data according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a method for asset data processing according to an embodiment of the present application;

FIG. 4 is a schematic illustration of an asset relationship graph according to an embodiment of the present application;

FIG. 5 is another schematic illustration of an asset relationship graph according to an embodiment of the present application;

FIG. 6 is a schematic diagram of an asset relationship graph construction process according to an embodiment of the present application;

FIG. 7 is a schematic diagram of an asset data processing device according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a computing device in an embodiment of the present application;

fig. 9 is a schematic structural diagram of a server in an embodiment of the present application.

In the drawings, the same or corresponding reference numerals indicate the same or corresponding parts.

Detailed Description

The terms first, second and the like in the description and in the claims of the embodiments and in the above-described figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or modules is not necessarily limited to those listed or explicitly listed or inherent to such process, method, article, or apparatus, but may include other steps or modules that may not be listed or inherent to such process, method, article, or apparatus, and the partitioning of such modules by embodiments of the present application may include only one logical partitioning, and may include additional partitioning by practical implementation, such that a plurality of modules may be combined or integrated in another system, or some features may be omitted or not implemented. In addition, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling between modules via interfaces, and the communication connection may be in electrical or other similar forms, which are not limited in this application. The modules or sub-modules described as separate components may or may not be physically separate, may or may not be physical modules, or may be distributed in a plurality of circuit modules, and some or all of the modules may be selected according to actual needs to achieve the purposes of the embodiments of the present application.

The embodiment of the application provides an asset data processing method which can be applied to an asset management scene and relates to at least one service device. For example, a service device includes an asset data processing device for performing the steps of the different stages of asset data processing. For example, the asset data processing device is configured to obtain asset data of a target service, and obtain a dynamic ontology based on the asset data and a historical asset relationship graph of the target service, so as to reconstruct the historical asset relationship graph with the dynamic ontology as a root node. The reconstructed updated asset relationship graph can visually display the data relationship between the variable asset and the target business, so that the asset data can be automatically managed, the difficulty of managing the asset data is greatly reduced, and the maintenance efficiency of the asset data is improved. The asset data processing device may acquire the asset data of the target service, and acquire the dynamic ontology based on the asset data and the historical asset relationship graph of the target service, so as to reconstruct an application program of the historical asset relationship graph by using the dynamic ontology as a root node, or acquire the dynamic ontology based on the asset data and the historical asset relationship graph of the target service, so as to reconstruct a server of the application program of the historical asset relationship graph by using the dynamic ontology as a root node.

The scheme provided by the embodiment of the application relates to cloud service, and is specifically described through the following embodiments:

among them, cloud Computing (Cloud Computing) is a Computing mode that distributes Computing tasks over a resource pool of a large number of computers, enabling various application systems to acquire Computing power, storage space, and information services as needed. The network that provides the resources is referred to as the "cloud". Resources in the cloud are infinitely expandable in the sense of users, and can be acquired at any time, used as needed, expanded at any time and paid for use as needed. Generalized cloud computing refers to the delivery and usage patterns of services, meaning that the required services are obtained in an on-demand, easily scalable manner over a network. Such services may be IT, software, internet related, or other services. Cloud Computing is a product of fusion of traditional computer and network technology developments such as Grid Computing (Grid Computing), distributed Computing (Distributed Computing), parallel Computing (Parallel Computing), utility Computing (Utility Computing), network storage (Network Storage Technologies), virtualization (Virtualization), load balancing (Load balancing), and the like.

With the development of the internet, real-time data flow and diversification of connected devices, and the promotion of demands of search services, social networks, mobile commerce, open collaboration and the like, cloud computing is rapidly developed. Unlike the previous parallel distributed computing, the generation of cloud computing will promote the revolutionary transformation of the whole internet mode and enterprise management mode in concept.

The cloud protogenesis is a set of cloud technology product system based on the technologies of container, micro-service and the like and established based on distributed deployment and unified transportation of the distributed cloud. After the cloud native technology is used, a developer does not need to consider the technical realization of the bottom layer, the elasticity and the distributed advantages of the cloud platform can be fully exerted, and quick deployment, expansion and contraction according to needs, delivery without shutdown and the like are realized.

The assets can be various software and hardware assets matched with the business. The software assets are, for example, various databases of a relational database management system (such as MySQL), redis, a distributed publish-subscribe messaging system (such as Kafka), and the like. The hardware assets are, for example, servers, switches, hard disks, CPUs, GPUs, and other various hardware devices.

In the asset management scenario in the related art, as the business of the enterprise develops, the enterprise needs to deploy various software and hardware assets matched with the business.

In order to maintain data relationships between various assets and business scenarios, a configuration management system, such as a configuration management database, is typically developed for each business scenario. In existing management systems, a corresponding data table is typically built for each asset individually, and each asset update requires structural modification of the data table of the asset concerned. However, in some application scenarios where the business frequently changes, in order to record the asset change caused by each business change in time, the data table structure of the asset needs to be manually changed, which is complex in operation, consumes manpower, and has low data maintenance efficiency.

Compared with the asset change caused by each service change in the prior art, the method and the device for managing the asset data have the advantages that the data management mode of the data structure table of the asset needs to be manually changed, in the embodiment of the application, the dynamic body corresponding to the changed asset can be constructed based on the asset data, and then the asset relation graph of the target service is reconstructed by taking the dynamic body as the root node, so that the automatic management of the asset data is realized, the efficient data relation form is formed between the asset and the service scene, the difficulty in managing the asset data is greatly reduced, and the maintenance efficiency of the asset data is improved.

In some embodiments, the asset data processing device is one or more. The plurality of asset data processing devices may be deployed in a distributed manner or in a centralized manner, and referring to fig. 1, the asset data processing method provided in the embodiments of the present application may be implemented based on one of the asset data processing systems shown in fig. 1. In fig. 1, the asset data processing devices a, B, C are respectively used for processing asset data of different businesses stored in the data center, namely, asset data of business a, asset data of business B, and asset data of business C. In practical applications, one asset data processing device may also be used to process asset data of multiple services, and the embodiments of the present application are not limited. Wherein the asset data processing device may be an application or a server.

It should be noted that, the server according to the embodiments of the present application may be an independent physical server, or may be a server cluster or a distributed system formed by a plurality of physical servers, or may be a cloud server that provides cloud services, a cloud database, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, and basic cloud computing services such as big data and an artificial intelligence platform.

Referring to fig. 2, fig. 2 is a flow chart of an asset data processing method according to an embodiment of the present application. The method can be applied to an asset data processing device in an asset management scene, and is executed by the asset data processing device to acquire asset data of a target service, and a dynamic ontology corresponding to a changed asset is constructed based on the asset data, so that the dynamic ontology is taken as a root node to reconstruct an asset relationship graph of the target service. The asset data processing method comprises the steps 201-203:

in step 201, asset data of a target business is acquired.

In the embodiment of the application, the target service refers to a service requiring asset management. Such as AI product services, cloud service product services, and after-market monitoring services.

Asset data, which is used primarily to describe asset information that needs to be invoked by a target business, such as asset name, asset classification, number of assets, asset usage, asset performance, asset rights, asset security level, and the like. It will be appreciated that in practical applications, the asset data includes, but is not limited to: hardware asset data, and/or software asset data, to which the target business relates. The type of asset data that needs to be of interest differs for different types of assets. For specific differences, see the description of the property information related to the asset below, which is not developed herein. In this way, the asset data can reflect the use condition of the asset, such as the property of the asset and the actual operation condition, related to the target business, so as to provide a foundation for the subsequent management of the service architecture of the target business. Further alternatively, the operation condition of the asset may be monitored by monitoring various index data of the asset, such as an operation duration, a device temperature, a data throughput, and the like, and further analyzing the operation condition of the asset according to one or more index data.

In an alternative design, asset data may be obtained through custom resource technology (Custom Resource Definition, CRD) of the container orchestration engine (Kubernetes, K8 s) system. The Kubernetes system is a container orchestration engine, supporting automated deployment, large scale scalability, and application containerization management. When an application is deployed in the production environment of the Kubernetes system, multiple instances of the application may be deployed to load balance application requests. By means of the container deployment mode, each container is isolated from each other, each container is provided with a file system, processes among the containers cannot affect each other, and computing resources can be distinguished. Compared with a virtual machine, the container can be rapidly deployed, and can migrate among different clouds and different versions of operating systems due to decoupling of the container from underlying facilities and machine file systems. The container occupies less resources and is quick to deploy, each application can be packaged into a container mirror image, the container is further advantageous due to the fact that each application is in one-to-one relation with the container, and the container is used for creating the container mirror image for the application, so that each application does not need to be combined with other application stacks and does not depend on a production environment infrastructure, and consistent environments can be provided from research, development to testing and production. Similarly, containers are lighter weight, more "transparent" than virtual machines, which is more convenient to monitor and manage.

Specifically, the asset data related to the target business can be customized by the Kubernetes system according to the actual application requirements. For example, the asset data of the target business may be custom set by the user in the target task creation interface. Alternatively, the asset data of the target business may be automatically configured under the setup of the asset management system. For example, a management task of a target business may be established in an asset management system, and guidance information corresponding to the management task is generated, the guidance information indicating the type of asset data to be set, and the asset data is automatically configured based on the hints of the guidance information and the actual business requirements. It can be understood that the type of the asset data set can be various business information related to the target business, various software and hardware assets deployed for the target business, and related information of the software and hardware assets. Related information for the software and hardware assets includes, but is not limited to, asset attributes, asset quantity, asset operating environment information.

Further alternatively, custom resource techniques may be applied to monitor index data for various assets in a target business, such as, for example, the run time of various hardware assets, device temperature, data throughput, etc., attributes, versions, functions, etc., of various software assets. For example, a custom asset object for monitoring target index data is created in the Kubernetes system and a corresponding Controller (Controller) is configured to initiate the Controller's monitoring (watch) mechanism. By editing custom fields in custom asset objects, the type of index data, the index data processing conditions, the processing flow, etc. that need to be monitored can be configured. Thus, under the watch mechanism, if the Controller monitors that the custom asset object changes, the Controller updates the monitored change condition of the custom asset object to the asset data of the corresponding service, for example, stores the current index data value as the asset data of the corresponding service. And if the Controller monitors that the custom asset object reaches the preset processing condition, executing a processing flow corresponding to the custom asset object. For example, after the running time of a certain hardware device (i.e. the custom asset object) is monitored to reach the set standby time, the running timeout warning for the certain device is triggered, so that the management end switches the running state of the device in time. Or if the equipment type of a certain hardware equipment is monitored to be changed, the corresponding equipment attribute information is updated in the asset relationship graph so as to record the changing condition of the equipment type. In one example, assuming that the asset data of the service a needs to be monitored, assuming that the asset of the service a includes the server a, the index data such as the equipment type, the operation duration, the operation temperature, the data throughput and the like of the server a is monitored through a watch mechanism, and if one or more of the index data changes, the change value of the index data is updated into the corresponding asset data to be used as a data base for subsequently updating the dynamic ontology.

In addition to the above-described monitoring of asset data according to the watch mechanism, the monitoring of asset data may be implemented by means of sensors or other information gathering modules deployed in hardware devices. For example, a temperature sensor in a hardware device is employed to monitor operating temperature as one of the hardware device's asset data.

In another alternative design, asset data of the target business may also be obtained through the cloud native service interface. Illustratively, a cloud native service interface is invoked to obtain configuration data of a target service from a cloud service end, so as to extract asset data from the configuration data.

Step 202, acquiring a dynamic ontology based on the asset data and the historical asset relationship graph of the target business.

In the embodiment of the application, the asset relationship graph is used for visually displaying the service architecture of the target business. In this application, for convenience of description, an already constructed asset relationship graph is referred to as a history asset relationship graph, and an asset relationship graph reconstructed in this embodiment is referred to as an updated asset relationship graph. In whatever asset relationship graph, various asset data related to the target business are included, which are recorded in the dynamic ontology.

In an embodiment of the present application, the dynamic ontology is determined based on a changing asset of the target business. In short, the dynamic body can update in real time according to the latest asset data monitored by the custom resource technology of the Kubernetes system (of course, the update period of the dynamic body can be set in practical application besides the real-time update), so that an implementation basis can be provided for the automatic management of the asset data by introducing the dynamic body.

In an embodiment of the present application, the dynamic ontology includes one of a business, a software asset, and a hardware asset. For example, the software asset may be a software algorithm used by the target business, various applications that implement the target business functions. The hardware assets may be servers, switches, hard disks, memory, central processing units, graphics processors. In addition to the physical devices, the assets may also be virtual resources deployed in cloud service devices, such as virtual machines, cloud servers, containers, container engines. The embodiment of the application is not limited to the types and the number of the assets, and can be configured according to actual application requirements.

It is understood that the attribute information corresponding to each asset includes, but is not limited to, one or more of the following: the number of assets, the asset classification, business information to which the assets belong, the asset security level, and asset authority information. The actual use condition of each asset can be reflected from different dimensions through the attribute information corresponding to each asset, and a data base is provided for the management of a subsequent target business service architecture. For example, the number of assets that can be currently invoked can be known by the number of assets, the type of assets that can be currently invoked can be known by the type of assets, whether or not there is a security risk for each asset currently can be monitored by the level of security of the assets, and so on.

It is worth noting that for different types of business, attribute information of different types of assets can be obtained, so that adaptability of the assets to target business is improved, and management efficiency of the assets is improved.

For a software asset deployed for the target business, in addition to the attribute information introduced above, the attribute information of the software asset includes at least one of the following information: database name, database address, algorithm name, algorithm version, algorithm mirror address.

For a hardware asset deployed for the target business, in addition to the attribute information introduced above, the attribute information of the hardware asset includes at least one of the following information: server information, switch information, hard disk information, memory information, central processor information, graphics processor information.

Whether the basic attribute information of the introduction, the attribute information of the software asset of the introduction, or the attribute information of the hardware asset of the introduction, can be automatically configured according to the target business requirement. In an alternative design, one implementation of step 202 may be specifically: extracting the to-be-processed assets of the target business from the asset data; selecting a change asset which is different from the history asset from the assets to be processed based on the history asset in the history asset relationship graph; and converting the change assets into dynamic ontologies through an ontology mapping model.

Taking the transition scenario shown in fig. 3 as an example, assume that server a is deployed with service a (i.e., the target service). To meet the data throughput monitoring requirement of the service a, the data throughput of the server a needs to be monitored, and based on this, in fig. 3, the data throughput set (i.e. the to-be-processed asset of the target service) of the server a at multiple times is acquired through the custom resource technology of the Kubernetes system.

Further, in fig. 3, it is assumed that the data throughput set is { [ t1, m1], [ t2, m2], [ t3, m3], [ t4, m4], [ t5, m5], [ t6, m6] }, where t1, t2, t3, t4, t5, t6 are the above-mentioned multiple times, and m1, m2, m3, m4, m5, m6 are the data throughput of the server a corresponding to each of the above-mentioned multiple times. Based on the above assumption, according to the historical assets in the historical asset map, namely the data throughput of the server a at the time points t1 to t4 { [ t1, m1], [ t2, m2], [ t3, m3], [ t4, m4] }, the change assets which are different from the historical assets are screened from the data throughput set, namely the data throughput of the server a at the time points t5 and t6 { [ t5, m5], [ t6, m6] }. Further, the dynamic ontology in the updated asset relationship map is obtained by processing the change assets { [ t5, m5], [ t6, m6] } through the ontology mapping model.

Further alternatively, the ontology mapping model may be pre-built through a cloud native service interface of the Kubernetes system. In the embodiment of the application, the ontology mapping model is used for converting the variable asset from the original data format to the storage format in the asset relationship map so as to realize automatic input of the variable asset and improve the asset data management efficiency. Specifically, for the asset to be monitored, an ontology mapping model matched with the asset attribute can be established, so that on the basis of establishing a mapping relation of the attribute information of the asset and the ontology mapping model in one-to-one correspondence, the corresponding ontology mapping model can be searched through the attribute information (such as an attribute field) of the asset, the conversion between the asset and the dynamic ontology is facilitated, and the asset data management efficiency is further improved.

Specifically, considering the convenience of asset data management, in order to improve the asset data management efficiency, in an alternative design, the conversion of the variant asset into the dynamic ontology through the ontology mapping model may be specifically implemented as: first, an attribute field of a variant asset is obtained from asset data. For example, an authentication interface (client) in the Kubernetes system may be used to obtain attribute information and attribute fields of the service related to the target service, for example, an attribute field of the custom resource type. Further, an ontology mapping model matched with the attribute field in the Kubernetes system is called, and the ontology mapping model is pre-established by a cloud native service in the Kubernetes system. And finally, inputting the variable assets into an ontology mapping model, and constructing a dynamic ontology through the ontology mapping model. Wherein the dynamic body comprises at least one of: asset identification, asset attributes, asset associations of changing assets.

Therefore, the ontology mapping model suitable for the cloud primary environment is introduced in the step 202, so that the automatic construction of the dynamic ontology can be realized, the processing efficiency of the asset data is greatly improved, the real-time updating and the real-time monitoring of the asset data are facilitated, and a foundation is provided for the automatic management of the asset data.

As an alternative design, before step 202, the similarity between the plurality of to-be-processed assets in the target service may also be obtained; and clustering the plurality of assets according to the similarity among the plurality of assets to be processed to obtain a clustering result. In practical applications, clustering bases include, but are not limited to, asset attributes (such as equipment attributes and software versions), asset deployment information (such as services to which an asset belongs, departments to which the asset belongs, products to which the asset belongs and business lines to which the asset belongs), asset storage information (such as mirror warehouse, database, mirror address, hardware storage space and cloud storage space); the clustering is not limited here according to the actual configuration. It can be understood that the plurality of assets associated with the target business are summarized into the corresponding categories through clustering, so that the same ontology mapping model can be applied to the assets to be processed in the same category for processing, the processing efficiency of asset data is further improved, and the maintenance difficulty of the ontology mapping model is effectively reduced.

As an alternative design, after step 202, the access frequency of the changing asset in the historical asset relationship atlas may also be obtained through custom resource technology. Further, a hierarchy in which the dynamic ontology is located in the updated asset relationship graph is set according to the access frequency. Wherein the hierarchy of the dynamic ontology is inversely related to the frequency of access of the variant assets that build the dynamic ontology. Therefore, the dynamic body with higher access frequency is arranged in a shallower hierarchy, the access time of the dynamic body can be further shortened, the access efficiency of the dynamic body is improved, and the convenience of asset data management is improved. For example, for the dynamic ontology related to the AI product, if the highest access frequency of the network card in the assets such as the network card, the hard disk, the memory and the like of the server is detected, the dynamic ontology corresponding to the network card can be set in the shallowest level, so that the assets required to be accessed can be quickly called after the dynamic ontology enters the asset relationship map related to the AI product, and the maintenance complexity of the asset relationship map is reduced.

And 203, reconstructing the historical asset relationship graph by taking the dynamic ontology as a root node to obtain an updated asset relationship graph of the target service.

In the embodiment of the application, the asset relationship graph is used for visually displaying the service architecture of the target business. Referring to the above, the already constructed asset relationship graph is referred to as a history asset relationship graph in this application, and the reconstructed asset relationship graph in this embodiment is referred to as an updated asset relationship graph.

Specifically, in an alternative design, to more clearly reflect the actual operational data changes of the individual assets, and the data relationships between the assets, the asset relationship graph includes, but is not limited to: dynamic ontologies built based on target business assets, and connection relationships between dynamic ontologies. The dynamic ontology is used for storing and visually displaying the target business assets and the attribute information thereof, so that the data change condition of the assets in actual operation can be directly monitored through the dynamic ontology. The connection relation between the dynamic bodies is used for reflecting the data flow relation between different assets, so that the change condition of the data flow relation between different assets can be directly obtained through the connection relation between the dynamic bodies.

For example, the asset relationship graph may be implemented as a tree structure as shown in FIG. 4. In the asset relationship graph shown in fig. 4, the data relationship between assets is described by the connection relationship between the dynamic ontologies of the assets, for example, the server belongs to an artificial intelligence (Artificial Intelligence, AI) product service group, so that a "server" model and a corresponding "AI product" (i.e., AI product service group) model can be created, and the data relationship between the server and the AI product service group can be described by creating the dynamic ontologies and the connection relationship between the dynamic ontologies. The AI technology is a comprehensive subject, and relates to a wide range of technologies, including hardware-level technologies and software-level technologies. Artificial intelligence infrastructure technologies generally include technologies such as sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, big data processing technologies, operation/interaction systems, mechatronics, and the like. The artificial intelligence software technology mainly comprises the directions of computer vision technology, voice processing technology, natural language processing technology, machine learning/deep learning and the like. The AI product may be a software product and/or a hardware product implemented using the techniques described above.

In the asset relationship graph shown in fig. 4, forward query and reverse query of each dynamic ontology are supported, and all dynamic ontologies related to the dynamic ontologies and related connection relations can be checked from any dynamic ontology, so that the asset relationship graph can be adapted to various asset management scenes, the flexibility of the asset relationship graph is greatly improved, and the application range of the asset relationship graph is expanded. Further alternatively, in an actual asset management scenario, any dynamic ontology in the asset relationship graph may be connected as a data monitoring interface to a corresponding management function, so that a corresponding operation is triggered by monitoring the update situation of this dynamic ontology. For example, the network card node of the server of the AI product shown in fig. 4 is used as a data monitoring interface to provide flow monitoring data for the flow prediction function deployed by the server, so that the support function for the server is triggered when the flow data exceeds a threshold value, and the server is prevented from being abnormal due to overlarge flow. In another alternative example, a plurality of dynamic ontologies may be further bound into a set of associated data monitoring interfaces, so that when each dynamic ontology in the set of data monitoring interfaces reaches a preset data monitoring condition, a corresponding operation is triggered.

Further optionally, in the asset relationship graph shown in fig. 4, any one of the dynamic ontology is selected, and the dynamic ontology can be switched to a detail description interface corresponding to the dynamic ontology, and the attribute information of the dynamic ontology can be modified and maintained in the interface, so that the convenience of the asset relationship graph is further improved, and the maintenance difficulty of the asset relationship graph is reduced.

In addition, in the embodiment of the application, in order to protect the security of product data, part of the dynamic ontology in the asset relationship graph may be set to be in a hidden state, and the dynamic ontology is only displayed when a user with viewing authority accesses the asset relationship graph. Still taking the asset relationship graph shown in fig. 4 as an example, in order to protect the information security of products such as AI products, remote office desktops, office auxiliary tools and the like, the dynamic body of software functions (such as functions a1 to d of AI products, functions u1 to z2 of remote office desktops and functions u1 to z2 of office auxiliary tools in fig. 4) and the dynamic body of software deployment information (such as a database of remote office desktops, mirror addresses of remote office desktops and mirror addresses of office auxiliary tools in fig. 4) are set to be in a hidden state, so as to obtain the asset relationship graph shown in fig. 5.

In practical applications, the asset relationship graph may be implemented in the form of other graphic information besides the tree structure shown in fig. 4 or fig. 5, which is not limited in the embodiment of the present application.

In the embodiment of the application, the asset relationship graph can visually display the service architecture of the target service, and various services, software asset information and hardware asset information can be organized and presented in the asset relationship graph in the form of a cloud primary data stream. In order to construct a data flow relationship between assets based on a form of cloud native data flow, thereby obtaining an asset relationship graph capable of representing a target business service architecture, in one possible design, referring to fig. 6, an initial construction process of the asset relationship graph may be implemented as the following steps 601 to 604:

in step 601, an attribute field of an asset to be created in a target service is obtained from asset data.

Step 602, based on the attribute field of the asset to be created, calling an ontology mapping model matched with the attribute field in the Kubernetes system, inputting the asset to be created into the ontology mapping model, and constructing the dynamic ontology of the asset to be created through the ontology mapping model.

Specifically, in one possible design, an asset to be created is obtained from asset data, and attribute information of the asset to be created. Further, an attribute field of the asset to be created is acquired from the attribute information of the asset to be created. Alternatively, the CRD field of the asset to be created may be acquired through a cloud native service interface in the Kubernetes system. After the attribute field is obtained, searching an ontology mapping model matched with the attribute field (such as a CRD field), and constructing a dynamic ontology of the asset to be created through the ontology mapping model. In practice, the dynamic ontology includes, but is not limited to: the tags and attribute nodes of the asset to be created.

It will be appreciated that the tags of the assets to be created are used to identify the assets to be created, and the attribute nodes associated with the assets to be created are used to visually expose the attribute characteristics of the respective assets.

Through steps 601 through 602 described above, a dynamic ontology of assets to be created can be constructed. Further, the data flow between assets to be created needs to be reflected by the connection relationships between the dynamic ontologies. Accordingly, how to establish a connection relationship between assets to be created will be described below.

And step 603, establishing a connection relation between dynamic ontologies according to the cloud primary data flow relation between the assets to be created so as to create a capital relationship map.

In the embodiment of the application, the asset relationship graph can visually display the service architecture of the target service, for example, hardware equipment, software service, various virtual resources and the like required to be used by the target service, and the software and hardware asset information can be organized and presented in the service link of the asset relationship graph in the form of a cloud primary data stream. For example, the service link is implemented as an AI product-related service link in the asset relationship graph as shown in fig. 4, where each dynamic ontology is respectively expressed from top to bottom as: the business department (i.e., the utility) to which the AI product interfaces, the product line to which the AI product belongs (i.e., the AI product line), the software asset (i.e., the AI product) with which the AI product is associated, the hardware asset (i.e., the server) that the AI product needs to invoke. The tree structure of fig. 4 further includes attribute nodes associated with a dynamic ontology, for example, the attribute nodes of the software asset associated with the AI product include Version1 (Version 1), version2 (Version 2), and the attribute nodes of the hardware asset required to be invoked by the AI product, i.e. network card, hard disk, and memory, corresponding to the functions a1 to c1 and a2 to d of the two versions. Further, selecting the attribute nodes such as the network card, the hard disk and the memory can check the corresponding attribute information. For example, the selected network card node may view various network card parameters, such as network card name, network card type, network card performance parameters, and the like.

In particular, in one possible design, the cloud native data flow relationship is assumed to include a service link to which the target business relates. Based on this assumption, in this step 603, the service links to which the asset to be created belongs may be divided first. Specifically, the assets to be created may be divided into service links set under the affiliated services according to the services to which the assets to be created belong. And sequentially connecting the labels of the assets to be created, to which the service links belong, according to the attribution relation of the assets to be created so as to construct the connection relation.

An initial asset relationship map (i.e., a history asset relationship map before the first reconstruction) can be created through steps 601-603, so as to visually display an initial service architecture of the target service, and realize efficient organization of various software and hardware asset information.

It can be understood that when the history asset relationship graph is reconstructed in the embodiment of the present application, the reconstruction is mainly needed: and a dynamic ontology constructed based on the variable assets in the target business and a connection relation related to the dynamic ontology. Specifically, to reconstruct the asset relationship graph, an alternative implementation of step 203 is: acquiring a cloud primary data stream of a target service; determining asset association relationships of the change assets in the target business based on the cloud primary data stream; and connecting the data flow relation between the dynamic ontology and other level nodes in the historical asset relation map based on the asset association relation by taking the dynamic ontology as a root node to obtain an updated asset relation map. The specific reconstruction is similar to the one described above for creating the initial asset relationship graph and will not be described further herein. By the method, the reconstruction of the asset relationship graph can be realized, so that the automatic management of the asset data is realized, the processing efficiency of the asset data is improved, and the real-time updating and the real-time monitoring of the asset data are facilitated.

In practical application, the change condition of each asset in the target service has a certain rule along with the type of the target service. For example, if the target business is a travel ticket business, the data processing amount of the business is greatly increased when the business approaches a public holiday, and in this case, more hardware devices (i.e., hardware assets) are required to be pre-expanded for the business, or corresponding patches (i.e., software assets) are required to be updated, so as to avoid the business system crash. For example, the target business is an AI customer service product of a shopping platform, and then, before the promotion period, the business needs to be pre-expanded to avoid the business system crash.

In response to the above, in an alternative design, the historical asset transition condition of the target business may also be obtained from the historical asset relationship atlas after step 203. In the embodiment of the application, the change condition of the historical assets comprises at least one of change time, change quantity and change type of the historical assets in the target business. Further, based on the asset data and the historical asset transition, a future asset transition of the updated asset relationship graph is predicted. It will be appreciated that the change in the history asset may be related to the target type of service, for example, in the above example, the number, bandwidth, and device type of the hardware devices in the travel ticket service are all related to the people's current travel situation in the public holiday, so that, according to the change in the history asset in the travel ticket service, the data throughput of the future travel ticket service may be predicted, so as to obtain the hardware device information (i.e. the future asset change situation) adapted to this data throughput. Finally, based on the future asset change condition, asset early warning information of the target business is generated in the updated asset relationship graph. The asset early warning information is used for indicating the change probability, change time or change quantity of various assets in the updated asset relationship graph. Taking travel ticket business as an example, based on hardware equipment information required in the future, a dynamic ontology matched with the hardware equipment information is generated in the asset relationship graph as an early warning entity, so that the hardware equipment information (such as equipment type, quantity and the like) required to be updated is indicated through the early warning entity. Of course, in practical application, the appearance of the early warning entity may be different from the appearance of the dynamic body corresponding to the deployed hardware device, for example, the distinguishing appearance of the early warning entity may be one of the following: brightness, color, shape, border lines.

Of course, in addition to the pre-warning entity, the asset pre-warning information may also be updated in the asset relationship graph in text or image form. For example, a dynamic ontology corresponding to an asset having an update probability that meets a set condition is highlighted to guide the user to select the dynamic ontology corresponding to the asset and to present a trend introduction of change (including, but not limited to, change probability, change time, number of changes, etc.) of the dynamic ontology in response to a selection instruction. The change trend introduction may be in the form of a chart or text, which is not limited herein.

Therefore, the asset early warning information generated by the steps can reflect the future asset change trend in the updated asset relationship graph so as to adjust the asset deployment mode of the target service in time, thereby being beneficial to realizing the automatic operation management of the target service.

In order to further protect the asset data security of the target service based on the asset relationship graph described above, similar to the hiding state described in the previous example, in the embodiment of the present application, the hiding part may also relate to a dynamic ontology of information security in the asset relationship graph, for example, the dynamic ontology is used to represent the device attribute information.

After receiving the viewing request of the target dynamic ontology, verifying the viewing operation authority of the user, and opening the viewing authority only for the user meeting the viewing condition. Specifically, if the viewing operation authority meets the preset viewing condition, displaying the target dynamic ontology in the asset relationship graph. Therefore, the property information security of the asset can be protected through the viewing condition of the dynamic body, and the security risk brought by viewing or tampering with the property information is prevented.

It is to be appreciated that the viewing conditions of the dynamic ontology may be preconfigured. For example, a corresponding administrator may be set at the time of creating the target service, whereby the viewing condition may be set as: a user with an administrator identity may view the dynamic ontologies contained by each dynamic ontology. Further alternatively, the identity of the docking department to which the target service belongs may be automatically set as an administrator.

In order to further protect the asset data security of the target business, in the embodiment of the present application, optionally, after the asset relationship graph is constructed, a maintenance operation request for the target dynamic body in the asset relationship graph may also be received, and the maintenance operation authority of the user is verified, and only the maintenance authority is opened for the user meeting the maintenance condition. Specifically, if the maintenance operation authority meets a preset maintenance condition, executing corresponding maintenance operation on the target dynamic body. Therefore, the user identity for executing the maintenance operation on the target dynamic body can be limited through the maintenance condition of the target dynamic body, thereby avoiding illegal users from executing illegal operation on the target dynamic body, protecting the information security of the asset and reducing the security risk of the asset data.

It will be appreciated that similar to the viewing conditions of the dynamic ontology, the maintenance conditions of the target dynamic ontology may also be preconfigured. For example, a corresponding administrator may be set at the time of creating the target business, whereby the maintenance condition of the target dynamic ontology may be set as: a user with an administrator identity may maintain various dynamic ontologies. Similarly, the identity of the docking department to which the target service belongs can also be directly and automatically set as an administrator. Further, according to the security risks of different maintenance operations, the administrator can be set to a plurality of levels, and different maintenance operation authorities are respectively opened for the administrators of different levels.

In the embodiment of the application, compared with the asset change caused by each service change in the prior art, the novel asset data management mode is provided, and the data management mode of the data structure table of the asset needs to be manually changed.

Having described the method of an embodiment of the present application, next, an asset data processing device of an embodiment of the present application is described with reference to fig. 7.

The asset data processing device 70 in the embodiment of the present application can implement the steps corresponding to the asset data processing method in the embodiment corresponding to fig. 2 described above. The functions performed by the asset data processing device 70 may be implemented by hardware or may be implemented by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the functions described above, which may be software and/or hardware. The asset data processing device 70 is applied to a server device that runs a Kubernetes system. The asset data processing device 70 may include an input/output module 701 and a processing module 702, where the functional implementation of the processing module 702 and the input/output module 701 may refer to the operations performed in the embodiment corresponding to fig. 2, and are not described herein. For example, the processing module 702 may be configured to control data transceiving operations of the input-output module 701.

In some embodiments, the input-output module 701 is further configured to obtain asset data of a target service; the asset data is obtained through a user-defined resource technology of a Kubernetes system;

The processing module 702 is further configured to obtain a dynamic ontology based on the asset data and a historical asset relationship graph of the target business; the dynamic ontology is determined based on the changed assets of the target business, and the dynamic ontology comprises one of business, software assets and hardware assets; and reconstructing the historical asset relationship graph by taking the dynamic body as a root node to obtain an updated asset relationship graph of the target service.

In some embodiments, the processing module 702, when obtaining the dynamic ontology based on the asset data and the historical asset relationship graph of the target business, is configured to:

extracting an asset to be processed of the target business from the asset data; selecting a change asset which is different from the history asset from the assets to be processed based on the history asset in the history asset relationship map; converting the variant assets into the dynamic ontology through an ontology mapping model; the ontology mapping model is used for converting the variant assets from an original data format to a storage format in an asset relationship graph.

In some embodiments, the processing module 702, when inputting the variant asset into an ontology mapping model and outputting the dynamic ontology from the ontology mapping model, is configured to:

Acquiring an attribute field of the change asset from the asset data; invoking an ontology mapping model matched with the attribute field in a Kubernetes system; the ontology mapping model is pre-established by a cloud native service in a Kubernetes system; inputting the change assets into the ontology mapping model, and constructing the dynamic ontology through the ontology mapping model; wherein the dynamic body comprises at least one of: asset identification, asset attributes, and asset associations of the variant asset.

In some embodiments, the processing module 702 is further configured to:

acquiring similarity among a plurality of assets to be processed in the target business before acquiring a dynamic ontology based on the asset data and a historical asset relationship graph of the target business; clustering the plurality of assets according to the similarity among the plurality of assets to be processed to obtain a clustering result; and the similar to-be-processed assets in the clustering result correspond to the same ontology mapping model.

In some embodiments, the processing module 702 is further configured to:

acquiring a dynamic ontology based on the asset data and a historical asset relationship graph of the target business, and then acquiring the access frequency of the change asset in the historical asset relationship graph through a custom resource technology; and setting the hierarchy of the dynamic ontology in the updated asset relationship graph according to the access frequency, wherein the hierarchy of the dynamic ontology is inversely related to the access frequency of the variable asset constructing the dynamic ontology.

In some embodiments, the processing module 702, when reconstructing the historical asset relationship graph with the dynamic ontology as a root node to obtain an updated asset relationship graph of the target service, is configured to:

acquiring a cloud primary data stream of the target service; determining asset association relationships of the change assets in the target business based on the cloud primary data stream; and taking the dynamic ontology as a root node, and connecting the data flow relation between the dynamic ontology and other level nodes in the historical asset relation map based on the asset association relation to obtain the updated asset relation map.

In some embodiments, the processing module 702 is further configured to:

after the dynamic ontology is taken as a root node and the history asset relationship graph is reconstructed to obtain an updated asset relationship graph of the target service, acquiring the history asset change condition of the target service from the history asset relationship graph; the historical asset transition condition includes at least one of: the change time, the change quantity and the change type of the history assets in the target business; predicting future asset change conditions of the updated asset relationship graph according to the asset data and the historical asset change conditions; generating asset early warning information of the target service in the updated asset relationship graph based on the future asset change condition; the asset early warning information is used for indicating the change probability, change time or change quantity of various assets in the updated asset relationship graph.

According to the method and the device for processing the asset data, the dynamic ontology corresponding to the variable asset can be constructed based on the asset data, and then the asset relationship map of the target service is reconstructed by taking the dynamic ontology as a root node, so that automatic management of the asset data is achieved, an efficient data relationship form is formed between the asset and a service scene, difficulty in managing the asset data is greatly reduced, and maintenance efficiency of the asset data is improved.

Having described the methods and apparatus of the embodiments of the present application, a description will now be made of a computer-readable storage medium of the embodiments of the present application, which may be an optical disc, having stored thereon a computer program (i.e., a program product) that, when executed by a processor, implements the steps described in the foregoing method embodiments, for example, obtaining asset data of a target service, where the asset data is obtained by a custom resource technology of the Kubernetes system; acquiring a dynamic ontology based on the asset data and a historical asset relationship graph of the target service, wherein the dynamic ontology is determined based on a change asset of the target service and comprises one of the service, a software asset and a hardware asset; and reconstructing the historical asset relationship graph by taking the dynamic ontology as a root node to obtain an updated asset relationship graph of the target business. The specific implementation of each step is not repeated here.

It should be noted that examples of the computer readable storage medium may also include, but are not limited to, a phase change memory (PRAM), a Static Random Access Memory (SRAM), a Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), a Read Only Memory (ROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), a flash memory, or other optical or magnetic storage medium, which will not be described in detail herein.

The asset data processing device 70 in the embodiment of the present application is described above from the viewpoint of a modularized functional entity, and the server and the terminal device for executing the asset data processing method in the embodiment of the present application are described below from the viewpoint of hardware processing, respectively.

It should be noted that, in the embodiment of the asset data processing apparatus of the present application, the entity device corresponding to the input/output module 701 shown in fig. 7 may be an input/output unit, a transceiver, a radio frequency circuit, a communication module, an input/output (I/O) interface, etc., and the entity device corresponding to the processing module 702 may be a processor. The asset data processing device 70 shown in fig. 7 may have a structure as shown in fig. 8, and when the asset data processing device 70 shown in fig. 7 has a structure as shown in fig. 8, the processor and transceiver in fig. 8 can implement the same or similar functions as the processing module 702 and the input-output module 701 provided in the device embodiment of the device described above, and the memory in fig. 8 stores a computer program to be called when the processor performs the above-described asset data processing method.

Fig. 9 is a schematic diagram of a server structure provided in an embodiment of the present application, where the server 1100 may vary considerably in configuration or performance, and may include one or more central processing units (central processing units, CPU) 1122 (e.g., one or more processors) and memory 1132, one or more storage media 1130 (e.g., one or more mass storage devices) storing applications 1142 or data 1144. Wherein the memory 1132 and the storage medium 1130 may be transitory or persistent. The program stored on the storage medium 1130 may include one or more modules (not shown), each of which may include a series of instruction operations on a server. Still further, the central processor 1122 may be provided in communication with a storage medium 1130, executing a series of instruction operations in the storage medium 1130 on the server 1100.

The Server 1100 may also include one or more power supplies 1126, one or more wired or wireless network interfaces 1170, one or more input output interfaces 1158, and/or one or more operating systems 1141, such as Windows Server, mac OS X, unix, linux, freeBSD, and the like.

The steps performed by the server in the above embodiments may be based on the structure of the server 1100 shown in fig. 9. For example, the steps performed by the asset data processing device 60 shown in FIG. 9 in the above-described embodiments may be based on the server structure shown in FIG. 9. For example, the CPU 1122 may perform the following operations by calling instructions in the memory 1132:

asset data for the target business is obtained through the input output interface 1158; the asset data is obtained through a user-defined resource technology of a Kubernetes system;

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and for parts of one embodiment that are not described in detail, reference may be made to related descriptions of other embodiments.

It will be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working processes of the systems, apparatuses and modules described above may refer to the corresponding processes in the foregoing method embodiments, which are not repeated herein.

In the several embodiments provided in the embodiments of the present application, it should be understood that the disclosed systems, apparatuses, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, and for example, the division of the modules is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple modules or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or modules, which may be in electrical, mechanical, or other forms.

The modules described as separate components may or may not be physically separate, and components shown as modules may or may not be physical modules, i.e., may be located in one place, or may be distributed over a plurality of network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist alone physically, or two or more modules may be integrated into one module. The integrated modules may be implemented in hardware or in software functional modules. The integrated modules, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable storage medium.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product.

The computer program product includes one or more computer instructions. When the computer program is loaded and executed on a computer, the flow or functions described in accordance with embodiments of the present application are fully or partially produced. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be stored by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), etc.

The foregoing describes in detail the technical solution provided by the embodiments of the present application, in which specific examples are applied to illustrate the principles and implementations of the embodiments of the present application, where the foregoing description of the embodiments is only used to help understand the methods and core ideas of the embodiments of the present application; meanwhile, as those skilled in the art will have variations in the specific embodiments and application scope according to the ideas of the embodiments of the present application, the present disclosure should not be construed as limiting the embodiments of the present application in view of the above.

Claims

1. An asset data processing method, wherein the method is applied to a server device, and the server device runs a Kubernetes system, and the method comprises:

acquiring a dynamic ontology based on the asset data and a historical asset relationship graph of the target business; the dynamic ontology is determined based on the changed assets of the target business, and the dynamic ontology comprises one of business, software assets and hardware assets;

And reconstructing the historical asset relationship graph by taking the dynamic body as a root node to obtain an updated asset relationship graph of the target service.

2. The method of claim 1, wherein the obtaining a dynamic ontology based on the asset data and the historical asset relationship map of the target business comprises:

extracting an asset to be processed of the target business from the asset data;

selecting a change asset which is different from the history asset from the assets to be processed based on the history asset in the history asset relationship map;

converting the variant assets into the dynamic ontology through an ontology mapping model; the ontology mapping model is used for converting the variant assets from an original data format to a storage format in an asset relationship graph.

3. The method of claim 2, wherein said inputting the variant asset into an ontology mapping model, outputting the dynamic ontology from the ontology mapping model, comprises:

acquiring an attribute field of the change asset from the asset data;

invoking an ontology mapping model matched with the attribute field in a Kubernetes system; the ontology mapping model is pre-established by a cloud native service in a Kubernetes system;

Inputting the change assets into the ontology mapping model, and constructing the dynamic ontology through the ontology mapping model;

wherein the dynamic body comprises at least one of: asset identification, asset attributes, and asset associations of the variant asset.

4. A method according to claim 2 or 3, wherein prior to said acquiring a dynamic ontology based on said asset data and said historical asset relationship map of the target business, said method further comprises:

obtaining the similarity among a plurality of assets to be processed in the target business;

clustering the plurality of assets according to the similarity among the plurality of assets to be processed to obtain a clustering result; and the similar to-be-processed assets in the clustering result correspond to the same ontology mapping model.

5. A method according to any one of claims 1 to 3, wherein after the acquiring a dynamic ontology based on the asset data and the historical asset relationship map of the target business, the method further comprises:

acquiring the access frequency of the change assets in the history asset relationship graph through a user-defined resource technology;

and setting the hierarchy of the dynamic ontology in the updated asset relationship graph according to the access frequency, wherein the hierarchy of the dynamic ontology is inversely related to the access frequency of the variable asset constructing the dynamic ontology.

6. A method according to any one of claims 1 to 3, wherein reconstructing the historical asset relationship graph with the dynamic ontology as a root node to obtain an updated asset relationship graph of the target service comprises:

acquiring a cloud primary data stream of the target service;

determining asset association relationships of the change assets in the target business based on the cloud primary data stream;

and taking the dynamic ontology as a root node, and connecting the data flow relation between the dynamic ontology and other level nodes in the historical asset relation map based on the asset association relation to obtain the updated asset relation map.

7. A method according to any one of claims 1 to 3, wherein, after the reconstructing the historical asset relationship graph with the dynamic ontology as a root node to obtain the updated asset relationship graph of the target service, the method further comprises:

acquiring the historical asset change condition of the target service from the historical asset relationship graph; the historical asset transition condition includes at least one of: the change time, the change quantity and the change type of the history assets in the target business;

Predicting future asset change conditions of the updated asset relationship graph according to the asset data and the historical asset change conditions;

generating asset early warning information of the target service in the updated asset relationship graph based on the future asset change condition; the asset early warning information is used for indicating the change probability, change time or change quantity of various assets in the updated asset relationship graph.

8. An asset data processing device, the device being applied to a server-side appliance, the server-side appliance operating with a Kubernetes system, the device comprising:

the processing module is configured to acquire a dynamic ontology based on the asset data and a historical asset relationship graph of the target service; the dynamic ontology is determined based on the changed assets of the target business, and the dynamic ontology comprises one of business, software assets and hardware assets; and reconstructing the historical asset relationship graph by taking the dynamic body as a root node to obtain an updated asset relationship graph of the target service.

9. A computing device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any of claims 1-7 when the computer program is executed.

10. A computer readable storage medium comprising instructions which, when run on a computer, cause the computer to perform the method of any of claims 1-7.