CN116383223A - 资产数据处理方法、相关装置及存储介质 - Google Patents

Abstract

本申请实施例涉及数据处理领域，提供一种资产数据处理方法、相关装置及存储介质。该方法应用于服务端设备，该方法包括：获取目标业务的资产数据；资产数据是通过Kubernetes***的自定义资源技术得到的；基于资产数据以及目标业务的历史资产关系图谱，获取动态本体；动态本体基于目标业务的变化资产确定，动态本体包括业务、软件资产和硬件资产中的一种；以动态本体为根节点，重构历史资产关系图谱，得到目标业务的更新资产关系图谱。该方法基于资产数据构建出与变化资产相应的动态本体，进而以动态本体为根节点，重构目标业务的资产关系图谱，实现了资产数据的自动化管理，在资产与业务场景之间形成高效的数据关系形式，有效提高资产数据的维护效率。

Description

资产数据处理方法、相关装置及存储介质

技术领域

本申请实施例涉及数据处理领域，更具体地涉及一种资产数据处理方法、相关装置及存储介质。

背景技术

随着企业的业务发展，企业需要部署与业务配套的各种软硬件资产。其中，软件资产例如是关系型数据库管理***(如MySQL)、远程字典服务(Remote Dictionary Server，Redis)、分布式发布订阅消息***(如Kafka)等各种数据库。硬件资产例如是服务器、交换机、硬盘、中央处理器(Central Processing Unit，CPU)、图形处理器(GraphicsProcessing Unit，GPU)等各种硬件设备。

相关技术中，为了维护各种资产与业务场景之间的数据关系，通常会针对各种业务场景研发与之对应的配置管理***，如配置管理数据库(Configuration ManagementDatabase，CMDB)。在现有管理***中，通常会为每一个资产单独建立对应的数据表，每次资产更新都需要对涉及到的资产的数据表进行结构修改。然而，在一些业务频繁变动的应用场景下，为了及时记录每次业务变动造成的资产变动，均需要人工更改资产的数据表结构，操作繁琐且耗费人力，数据维护效率低。

发明内容

本申请实施例提供一种资产数据处理方法、相关装置及存储介质，能够实现资产数据的自动化管理，提高资产数据的维护效率。

第一方面，本申请实施例提供一种资产数据处理方法，该方法应用于服务端设备，该服务端设备运行有Kubernetes***，该方法包括：

获取目标业务的资产数据；该资产数据是通过Kubernetes***的自定义资源技术得到的；

基于该资产数据以及目标业务的历史资产关系图谱，获取动态本体；该动态本体基于目标业务的变化资产确定，动态本体包括业务、软件资产和硬件资产中的一种；

以动态本体为根节点，重构历史资产关系图谱，得到目标业务的更新资产关系图谱。

第二方面，本申请实施例提供一种资产数据处理装置，具有实现对应于上述第一方面提供的资产数据处理方法的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。

在一个实施方式中，该装置应用于服务端设备，该服务端设备运行有Kubernetes***，该装置包括：

输入输出模块，被配置为获取目标业务的资产数据；该资产数据是通过Kubernetes***的自定义资源技术得到的；

处理模块，被配置为基于该资产数据以及目标业务的历史资产关系图谱，获取动态本体；该动态本体基于目标业务的变化资产确定，动态本体包括业务、软件资产和硬件资产中的一种；以动态本体为根节点，重构历史资产关系图谱，得到目标业务的更新资产关系图谱。

第三方面，本申请实施例提供一种计算设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现第一方面中所述的资产数据处理方法。

第四方面，本申请实施例提供一种计算机可读存储介质，其包括指令，当其在计算机上运行时，使得计算机执行第一方面中所述的资产数据处理方法。

相较于现有技术，本申请实施例中，获取目标业务的资产数据。该资产数据可以通过Kubernetes***的自定义资源技术得到，由于Kubernetes***能够对云原生环境下目标业务的各类资产进行自动化监测，因而，可以为目标业务的自动化资产管理提供数据基础。进而，基于目标业务的资产数据以及目标业务的历史资产关系图谱，获取动态本体。该动态本体基于目标业务的变化资产确定，可以是业务、软件资产和硬件资产中的任意一种，从而通过动态本体能够表示目标业务的业务变化情况或资产变化情况。最终，以动态本体为根节点，重构历史资产关系图谱，得到目标业务的更新资产关系图谱，该更新资产关系图谱能够可视化展示变化资产与目标业务之间的数据关系。本申请实施例中提供了一种全新的资产数据管理方式，相比于现有技术中每次业务变动造成的资产变动，都需要人工更改资产的数据结构表的数据管理方式，本申请实施例中可以基于资产数据构建出与变化资产相应的动态本体，进而以动态本体为根节点重构目标业务的资产关系图谱，实现了资产数据的自动化管理，在资产与业务场景之间形成了高效的数据关系形式，极大程度降低了管理资产数据的难度，提高了资产数据的维护效率。

附图说明

通过参考附图阅读本申请实施例的详细描述，本申请实施例的目的、特征和优点将变得易于理解。其中：

图1为本申请实施例中资产数据处理***的一种示意图；

图2为本申请实施例中资产数据处理方法的一种流程示意图；

图3为本申请实施例中资产数据处理方法的一种原理示意图；

图4为本申请实施例中资产关系图谱的一种示意图；

图5为本申请实施例中资产关系图谱的另一种示意图；

图6为本申请实施例中资产关系图谱构建流程的一种示意图；

图7为本申请实施例中资产数据处理装置的一种结构示意图；

图8为本申请实施例中计算设备的一种结构示意图；

图9为本申请实施例中服务器的一种结构示意图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

本申请实施例的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块，本申请实施例中所出现的模块的划分，仅仅是一种逻辑上的划分，实际应用中实现时可以有另外的划分方式，例如多个模块可以结合成或集成在另一个***中，或一些特征可以忽略，或不执行。另外，所显示的或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，模块之间的间接耦合，通信连接可以是电性或其他类似的形式，本申请实施例中均不作限定。并且，作为分离部件说明的模块或子模块可以是也可以不是物理上的分离，可以是也可以不是物理模块，或者可以分布到多个电路模块中，可以根据实际的需要选择其中的部分或全部模块来实现本申请实施例方案的目的。

本申请实施例提供一种资产数据处理方法，可应用于资产管理场景，涉及至少一服务设备，至少一服务设备包括至少一个资产数据处理装置。例如，一个服务设备包括一个资产数据处理装置，用于执行资产数据处理中不同阶段的步骤。例如，资产数据处理装置用于获取目标业务的资产数据，并基于该资产数据以及目标业务的历史资产关系图谱获取动态本体，从而以动态本体为根节点重构历史资产关系图谱。重构后得到的更新资产关系图谱能够可视化展示变化资产与目标业务之间的数据关系，使得资产数据能够被自动化管理，极大程度降低了管理资产数据的难度，提高了资产数据的维护效率。其中，资产数据处理装置可为获取目标业务的资产数据，并基于该资产数据以及目标业务的历史资产关系图谱获取动态本体，从而以动态本体为根节点重构历史资产关系图谱的应用程序，或为安装了获取目标业务的资产数据，并基于该资产数据以及目标业务的历史资产关系图谱获取动态本体，从而以动态本体为根节点重构历史资产关系图谱的应用程序的服务器。

本申请实施例提供的方案涉及云服务，具体通过如下实施例进行说明:

其中，云计算(Cloud Computing)是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用***能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。广义云计算，指服务的交付和使用模式，指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关，也可是其他服务。云计算是网格计算(Grid Computing)、分布式计算(Distributed Computing)、并行计算(Parallel Computing)、效用计算(Utility Computing)、网络存储(Network StorageTechnologies)、虚拟化(Virtualization)、负载均衡(Load Balance)等传统计算机和网络技术发展融合的产物。

随着互联网、实时数据流、连接设备多样化的发展，以及搜索服务、社会网络、移动商务和开放协作等需求的推动，云计算迅速发展起来。不同于以往的并行分布式计算，云计算的产生从理念上将推动整个互联网模式、企业管理模式发生革命性的变革。

云原生，是基于分布部署和统一运管的分布式云，以容器、微服务等技术为基础建立的一套云技术产品体系。其中，云原生应用，也就是面向“云”而设计的应用，在使用云原生技术后，开发者无需考虑底层的技术实现，可以充分发挥云平台的弹性和分布式优势，实现快速部署、按需伸缩、不停机交付等。

资产，可以是与业务配套的各种软硬件资产。其中，软件资产例如是关系型数据库管理***(如MySQL)、Redis、分布式发布订阅消息***(如Kafka)等各种数据库。硬件资产例如是服务器、交换机、硬盘、CPU、GPU等各种硬件设备。

相关技术中的资产管理场景下，随着企业的业务发展，企业需要部署与业务配套的各种软硬件资产。

为了维护各种资产与业务场景之间的数据关系，通常会针对各种业务场景研发与之对应的配置管理***，如配置管理数据库。在现有管理***中，通常会为每一个资产单独建立对应的数据表，每次资产更新都需要对涉及到的资产的数据表进行结构修改。然而，在一些业务频繁变动的应用场景下，为了及时记录每次业务变动造成的资产变动，均需要人工更改资产的数据表结构，操作繁琐且耗费人力，数据维护效率低。

相比于现有技术中每次业务变动造成的资产变动，都需要人工更改资产的数据结构表的数据管理方式，本申请实施例中可以基于资产数据构建出与变化资产相应的动态本体，进而以动态本体为根节点重构目标业务的资产关系图谱，实现了资产数据的自动化管理，在资产与业务场景之间形成了高效的数据关系形式，极大程度降低了管理资产数据的难度，提高了资产数据的维护效率。

一些实施方式中，资产数据处理装置是一个，也可以是多个。多个资产数据处理装置可以采用分布式部署，也可以采用集中式部署，参照图1，本申请实施例提供的资产数据处理方法可基于图1所示的一种资产数据处理***实现。在图1中，资产数据处理装置a、b、c分别用于处理数据中心所存储的不同业务的资产数据，即业务A的资产数据、业务B的资产数据、业务C的资产数据。实际应用中，一个资产数据处理装置也可用于处理多个业务的资产数据，本申请实施例并不限制。其中，资产数据处理装置可以是应用程序或服务器。

需要说明的是，本申请实施例涉及的服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

参照图2，图2为本申请实施例提供的一种资产数据处理方法的流程示意图。该方法可应用于资产管理场景下的资产数据处理装置，由资产数据处理装置执行，获取目标业务的资产数据，并基于资产数据构建出与变化资产相应的动态本体，从而以动态本体为根节点重构目标业务的资产关系图谱的具体步骤。所述资产数据处理方法包括步骤201-203：

步骤201，获取目标业务的资产数据。

在本申请实施例中，目标业务是指需要进行资产管理的业务。比如，AI产品业务、云服务产品业务、售后监控业务。

资产数据，主要用于描述目标业务所需调用的资产信息，例如，资产名称、资产分类、资产数量、资产使用情况、资产性能、资产权限、资产安全等级，等等。可以理解的是，实际应用中，所述资产数据包括但不限于：目标业务所涉及的硬件资产数据、和/或软件资产数据。对于不同类型的资产，所需关注的资产数据类型有所区别。具体区别可参见下文对资产属性信息的相关介绍，此处暂不展开。这样，通过资产数据可以反映目标业务所涉及的资产使用情况，例如资产本身属性以及实际运营情况，从而为后续对目标业务服务架构的管理提供基础。进一步可选地，资产的运营情况的方式可以是，监控资产的多种指标数据，如运行时长、设备温度、数据吞吐量等，进而根据上述一种或多种指标数据分析获得资产的运营情况。

在一可选设计中，资产数据可以通过容器编排引擎(Kubernetes，K8s)***的自定义资源技术(Custom Resource Definition，CRD)得到。Kubernetes***，是一个容器编排引擎，支持自动化部署、大规模可伸缩、应用容器化管理。在Kubernetes***的生产环境中部署一个应用程序时，可以部署该应用的多个实例，以便对应用请求进行负载均衡。通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件***，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件***解耦的，因而容器能够在不同云、不同版本操作***间进行迁移。容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器为应用创建容器镜像，因而，每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更“透明”，这更便于监控和管理。

具体来说，目标业务相关的资产数据可由Kubernetes***根据实际应用需求自定义设置的。例如，目标业务的资产数据可以是由用户在目标任务建立界面中自定义设置的。或者，目标业务的资产数据也可以是在资产管理***的设置下实现自动化配置的。示例性地，在资产管理***中可建立目标业务的管理任务，并生成对应管理任务的引导信息，该引导信息指示所需设置的资产数据类型，基于引导信息的提示以及实际业务需求自动配置资产数据。可以理解的是，自定义设置的资产数据类型，可以是目标业务所涉及的各种业务信息，也可以是为目标业务所部署的各种软硬件资产，以及软硬件资产的相关信息。软硬件资产的相关信息包括但不限于资产属性、资产数量、资产运行环境信息。

进一步可选地，可以应用自定义资源技术来监测目标业务中各项资产的指标数据，比如，各项硬件资产的运行时长、设备温度、数据吞吐量等，各项软件资产的属性、版本、功能等。例如，在Kubernetes***中创建一个用于监测目标指标数据的自定义资产对象，并配置对应的控制器(Controller)，以启动Controller的监测(watch)机制。通过编辑自定义资产对象中的自定义字段，可以配置需要监测的指标数据类型、指标数据处理条件、处理流程等。从而，在watch机制下，Controller若监测到自定义资产对象发生变化，则将监测到的自定义资产对象的变化情况更新到对应业务的资产数据中，比如将当前的指标数据值存储为对应业务的资产数据。若Controller监测自定义资产对象达到预设的处理条件，则执行自定义资产对象对应的处理流程。比如监测到某硬件设备的运行时长(即自定义资产对象)达到设定待机时长后，触发针对某设备的运行超时警告，以便管理端及时切换这一设备的运行状态。或者，监测到某硬件设备的设备类型发生变更，则在资产关系图谱中更新对应的设备属性信息，以记录设备类型的变更情况。在一个示例中，假设需要对业务A的资产数据进行监测，假设业务A的资产包括服务器a，那么，通过watch机制监测服务器a的设备类型、运行时长、运行温度、数据吞吐量等指标数据，若上述指标数据中的一个或多个发生变化，则将其变化值更新到对应的资产数据中，用以作为后续更新动态本体的数据基础。

除了上述依据watch机制实现资产数据的监测功能之外，资产数据的监测功能还可以依靠部署在硬件设备中的传感器或其他信息采集模块来实现。例如，采用硬件设备中的温度传感器监测运行温度，作为该硬件设备的资产数据之一。

另一可选设计中，也可以通过云原生服务接口获取目标业务的资产数据。示例性地，调用云原生服务接口，从云服务端中获取目标业务的配置数据，以从配置数据中提取资产数据。

步骤202，基于所述资产数据以及所述目标业务的历史资产关系图谱，获取动态本体。

在本申请实施例中，资产关系图谱用于可视化展示所述目标业务的服务架构。本申请中，为便于描述，将已经构建完成的资产关系图谱称为历史资产关系图谱，将本实施例中重新构建的资产关系图谱称为更新资产关系图谱。无论是何种资产关系图谱中，均包括目标业务涉及的各种资产数据，这些资产数据被记录在动态本体中。

在本申请实施例中，所述动态本体基于所述目标业务的变化资产确定。简单来说，就是动态本体能够根据Kubernetes***的自定义资源技术监测到的最新资产数据进行实时更新(当然，除了实时更新之外，实际应用中也可以设置动态本体的更新周期)，因而，通过引入动态本体能够为资产数据的自动化管理提供实现基础。

在本申请实施例中，所述动态本体包括业务、软件资产和硬件资产中的一种。例如，软件资产可以是目标业务所使用到的软件算法、实现目标业务功能的各种应用程序。硬件资产可以是服务器、交换机、硬盘、内存、中央处理器、图形处理器。除了实体设备之外，资产还可以是云服务设备中部署的虚拟资源，例如虚拟机、云服务器、容器、容器引擎。本申请实施例中并不限定资产的类型以及数量，可根据实际应用需求进行配置。

可以理解的是，所述各个资产对应的属性信息包括但不限于以下信息中的一种或多种：资产数量、资产分类、资产所属的业务信息、资产安全等级、资产权限信息。通过各个资产对应的属性信息，能够从不同维度反映各个资产的实际使用情况，为后续目标业务服务架构的管理提供数据基础。例如，通过资产数量可以了解到目前可调用的资产数量，通过资产类型可以了解到目前可调用的资产类型，通过资产安全等级可以监控目前各个资产是否存在安全风险，等等。

值得注意的是，对不同类型的业务，还可以获取不同类型资产的属性信息，以便提高资产对目标业务的适应性，提升资产的管理效率。

针对为所述目标业务部署的软件资产，除了上文介绍的属性信息之外，所述软件资产的属性信息还包括以下至少一个信息：数据库名称、数据库地址、算法名称、算法版本、算法镜像、算法镜像地址。

针对为所述目标业务部署的硬件资产，除了上文介绍的属性信息之外，所述硬件资产的属性信息还包括以下至少一个信息：服务器信息、交换机信息、硬盘信息、内存信息、中央处理器信息、图形处理器信息。

无论是上述介绍的基础属性信息，还是上述介绍的软件资产的属性信息，亦或是上述介绍的硬件资产的属性信息，均可以根据目标业务需求自动配置。在一种可选设计中，步骤202的一种实现方式可以具体是：从资产数据中提取目标业务的待处理资产；基于历史资产关系图谱中的历史资产，从待处理资产中选取与历史资产存在差异的变化资产；通过本体映射模型将变化资产转换为动态本体。

以图3示出的转换场景为例，假设服务器a部署有业务A(即目标业务)。为满足业务A的数据吞吐量监控需求，需要对服务器a的数据吞吐量进行监控，基于此，在图3中，通过Kubernetes***的自定义资源技术获取服务器a在多个时刻的数据吞吐量集合(即目标业务的待处理资产)。

进一步地，在图3中，假设数据吞吐量集合为{[t1，m1]，[t2，m2]，[t3，m3]，[t4，m4]，[t5，m5]，[t6，m6]}，其中，t1、t2、t3、t4、t5、t6为上述多个时刻，m1、m2、m3、m4、m5、m6为上述多个时刻各自对应的服务器a的数据吞吐量。基于上述假设，根据历史资产图谱中的历史资产，即t1至t4时刻下服务器a的数据吞吐量{[t1，m1]，[t2，m2]，[t3，m3]，[t4，m4]}，从数据吞吐量集合中筛选出与上述历史资产存在差异的变化资产，即t5和t6时刻下服务器a的数据吞吐量{[t5，m5]，[t6，m6]}。进而，通过本体映射模型处理变化资产{[t5，m5]，[t6，m6]}，得到更新资产关系图谱中的动态本体。

进一步可选地，本体映射模型可以是通过Kubernetes***的云原生服务接口预先构建的。本申请实施例中，本体映射模型用于将变化资产从原始数据格式转换为资产关系图谱中的存储格式，以实现变化资产的自动化录入，提高资产数据管理效率。具体来说，针对所要监测的资产，可以建立与资产属性相匹配的本体映射模型，从而，在建立有资产的属性信息与本体映射模型一一对应的映射关系的基础上，通过资产的属性信息(如属性字段)可以查找对应的本体映射模型，便于实现资产与动态本体之间的转换，进一步提高资产数据管理效率。

具体来说，考虑到资产数据管理的便捷性，为提高资产数据管理效率，在一种可选设计中，通过本体映射模型将变化资产转换为动态本体，可以具体实现为：首先，从资产数据中获取变化资产的属性字段。例如，可以采用Kubernetes***中认证接口(client)的方式，获取目标业务相关服务的属性信息及属性字段，例如自定义资源类型的属性字段。进而，调用Kubernetes***中与属性字段匹配的本体映射模型，该本体映射模型由Kubernetes***中的云原生服务预先建立。最终，将变化资产输入到本体映射模型中，通过本体映射模型构建出动态本体。其中，动态本体包括至少包括以下项之一：变化资产的资产标识、资产属性、资产关联关系。

从而，通过步骤202中引入适用于云原生环境下的本体映射模型能够实现动态本体的自动构建，从而，大大提高资产数据的处理效率，便于资产数据的实时更新、实时监控，为资产数据的自动化管理提供基础。

作为一种可选设计中，步骤202之前，还可以获取目标业务中多个待处理资产之间的相似度；根据多个待处理资产之间的相似度对多个资产进行聚类处理，得到聚类结果。实际应用中，聚类依据包括但不限于资产属性(如设备属性、软件版本)、资产部署信息(如资产所属业务、所属部门、所属产品、所属业务线)、资产存储信息(如镜像仓库、数据库、镜像地址、硬件存储空间、云存储空间)；聚类依据根据实际情况配置此处并不限定。可以理解的是，通过聚类处理将目标业务所关联的多个资产归纳到对应类别中，从而，对于同一类待处理资产可以应用同一个本体映射模型进行处理，进一步提高资产数据的处理效率，有效降低本体映射模型的维护难度。

作为一种可选设计中，步骤202之后，还可以通过自定义资源技术获取历史资产关系图谱中变化资产的访问频率。进而，根据该访问频率设置动态本体在更新资产关系图谱中所处的层级。其中，动态本体的层级与构建该动态本体的变化资产的访问频率呈负相关。这样，将访问频率更高的动态本体设置在更浅的层级中，能够进一步缩短动态本体的访问时间，提高动态本体的访问效率，提升资产数据管理的便捷性。例如，对于AI产品相关的动态本体而言，若检测到服务器的网卡、硬盘、内存等资产中网卡的访问频率最高，可以将网卡对应的动态本体设置最浅的层级中，以便进入AI产品相关的资产关系图谱之后可以快速调取所需访问的资产，降低资产关系图谱的维护复杂度。

步骤203，以所述动态本体为根节点，重构所述历史资产关系图谱，得到所述目标业务的更新资产关系图谱。

在本申请实施例中，资产关系图谱用于可视化展示所述目标业务的服务架构。参见上文，本申请中将已经构建完成的资产关系图谱称为历史资产关系图谱，将本实施例中重新构建的资产关系图谱称为更新资产关系图谱。

具体来说，在一可选设计中，为了更清楚地反映出各个资产的实际运行中的数据变化情况，以及资产之间的数据关系，资产关系图谱包括但不限于：基于目标业务资产构建的动态本体、以及动态本体之间的连接关系。其中，动态本体，用于存储并可视化展示目标业务资产以及其属性信息，这样通过动态本体可以直接监控到资产实际运行中的数据变化情况。动态本体之间的连接关系，用于反映不同资产之间的数据流关系，这样通过动态本体之间的连接关系可以直接获取不同资产之间的数据流关系的变化情况。

举例来说，资产关系图谱可以实现为图4所示的树形结构。在图4所示的资产关系图谱中，资产之间的数据关系通过资产的动态本体之间的连接关系来描述，比如，服务器从属于人工智能(Artificial Intelligence，AI)产品业务组，由此可以创建一个“服务器”模型，以及与之对应的“AI产品”(即AI产品业务组)模型，通过创建动态本体、以及动态本体之间的连接关系，可以描述出服务器与AI产品业务组之间的数据关系。其中，AI技术是一门综合学科，涉及领域广泛，既有硬件层面的技术也有软件层面的技术。人工智能基础技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理技术、操作/交互***、机电一体化等技术。人工智能软件技术主要包括计算机视觉技术、语音处理技术、自然语言处理技术以及机器学习/深度学习等方向。AI产品可以是应用上述技术实现的软件产品和/或硬件产品。

在图4所示的资产关系图谱中，支持对各个动态本体的正向查询和反向查询，从任一动态本体处可以查看与之相关的所有动态本体以及相关的连接关系，使得资产关系图谱可以适配于各种资产管理场景，大大提升资产关系图谱的灵活性，扩展资产关系图谱的使用范围。进一步可选地，在实际资产管理场景中，可以将资产关系图谱中任一动态本体作为数据监测接口连接到相应的管理功能中，从而，通过监测这一动态本体的更新情况来触发相应操作。例如，以图4所示的AI产品的服务器的网卡节点作为数据监测接口，为服务器部署的流量预测功能提供流量监测数据，从而在流量数据超过阈值的情况下触发针对服务器的支持功能，以避免服务器因流量过大而出现异常。另一可选示例中，还可以将多个动态本体绑定为一组关联的数据监测接口，从而，在这一组数据监测接口中各个动态本体均达到预设数据监测条件时触发相应操作。

进一步可选地，在图4所示的资产关系图谱中，选取任一个动态本体，可以切换至该动态本体对应的详情介绍界面，在该界面中可修改维护动态本体的属性信息，进一步提升资产关系图谱的便捷性，降低资产关系图谱的维护难度。

此外，本申请实施例中，为保护产品数据的安全性，还会将资产关系图谱中的部分动态本体可以设置为隐藏状态，仅在具有查看权限的用户访问资产关系图谱时展示这些动态本体。仍以图4所示的资产关系图谱为例，为保护AI产品、远程办公桌面、以及办公辅助工具等产品的信息安全性，将涉及到软件功能(如图4中AI产品的功能a1至d、远程办公桌面的功能、办公辅助工具的功能u1至z2)的动态本体、软件部署信息(如图4中远程办公桌面的数据库、远程办公桌面的镜像地址、办公辅助工具的镜像地址)的动态本体设置为隐藏状态，从而得到图5所示的资产关系图谱。

实际应用中，除了图4或图5所示的树形结构之外，资产关系图谱还可以实现为其他图形信息的形式，本申请实施例中并不限定。

在本申请实施例中，资产关系图谱能够可视化展示目标业务的服务架构，各种业务、软件资产信息、硬件资产信息均可以通过云原生数据流的形式组织呈现在资产关系图谱中。为了基于云原生数据流的形式构建资产之间的数据流关系，从而得到能够表示目标业务服务架构的资产关系图谱，在一个可能的设计中，参照图6，资产关系图谱的初始构建过程可以实现为以下步骤601～604：

步骤601，从资产数据中获取目标业务中待创建资产的属性字段。

步骤602，基于待创建资产的属性字段，调用Kubernetes***中与该属性字段匹配的本体映射模型，并将待创建资产输入到该本体映射模型中，通过该本体映射模型构建出该待创建资产的动态本体。

具体来说，在一个可能的设计中，从资产数据中获取待创建资产，以及待创建资产的属性信息。进而，从待创建资产的属性信息中获取待创建资产的属性字段。可选地，可以是通过Kubernetes***中的云原生服务接口获取待创建资产的CRD字段。获取到属性字段之后，查找与该属性字段(如CRD字段)相匹配的本体映射模型，并通过本体映射模型构建出待创建资产的动态本体。实际应用中，该动态本体包括但不限于：待创建资产的标签以及属性节点。

可以理解的是，待创建资产的标签用于标识该待创建资产，待创建资产所关联的属性节点用于可视化展示各个资产的属性特征。

通过上述步骤601至602，可以构建出待创建资产的动态本体。而进一步地，待创建资产之间的数据流需要通过动态本体之间的连接关系反映。故此，下面将介绍如何建立待创建资产之间的连接关系。

步骤603，根据待创建资产之间的云原生数据流关系，建立动态本体之间的连接关系，以创建出资产关系图谱。

在本申请实施例中，资产关系图谱能够可视化展示目标业务的服务架构，例如，目标业务需要使用到的硬件设备、软件服务、以及各种虚拟资源等，上述软硬件资产信息均可以通过云原生数据流的形式组织呈现在资产关系图谱的服务链路中。举例来说，服务链路实现为如图4所示出的资产关系图谱中AI产品相关的服务链路，在这一服务链路中各个动态本体按照数据流关系自上而下分别表示为：AI产品所对接的业务部门(即事业部)、AI产品所属的产品线(即AI产品线)、AI产品所关联的软件资产(即AI产品)、AI产品所需调用的硬件资产(即服务器)。在图4的树形结构中还包括动态本体关联的属性节点，比如，AI产品所关联的软件资产的属性节点包括版本1(Version1)、版本2(Version2)、以及上述两个版本各自对应的功能a1至c1、功能a2至d，AI产品所需调用的硬件资产的属性节点即网卡、硬盘、内存。进一步地，选取网卡、硬盘、内存这些属性节点，可以查看到对应的属性信息。例如，选取网卡节点可查看到各种网卡参数，如网卡名称、网卡类型、网卡性能参数等。

具体来说，在一个可能的设计中，假设所述云原生数据流关系包括所述目标业务涉及的服务链路。基于这一假设，本步骤603中，可以先划分待创建资产所属的服务链路。具体地，可以根据待创建资产所归属的业务来将待创建资产划分到所属业务下设的服务链路中。进而，根据待创建资产的归属关系，依次连接所述服务链路所属的待创建资产的标签，以构建出所述连接关系。

通过步骤601～603可以创建出初始的资产关系图谱(即第一次重构前的历史资产关系图谱)，用以可视化展示目标业务的初始服务架构，实现对各种软硬件资产信息的高效组织形式。

可以理解的是，本申请实施例中重构历史资产关系图谱时，主要需要重新构建的是：基于目标业务中变化资产构建的动态本体，以及该动态本体相关的连接关系。具体而言，为了重新构建资产关系图谱，步骤203的一种可选实现方式为：获取目标业务的云原生数据流；基于云原生数据流确定变化资产在目标业务中的资产关联关系；以动态本体为根节点，基于资产关联关系连接动态本体与历史资产关系图谱中其他层级节点之间的数据流关系，得到更新资产关系图谱。具体重构方式与上文创建初始资产关系图谱的方式类似，此处不再展开介绍。通过这一方式，能够实现对资产关系图谱的重构，从而实现资产数据的自动化管理，提高资产数据的处理效率，便于资产数据的实时更新、实时监控。

实际应用中，目标业务中各项资产的变化情况，随着目标业务类型存在一定规律。例如，目标业务为旅游出行票务业务，那么，临近公共假期时业务的数据处理量会大大增加，此情况下需要为业务预先扩容，部署更多的硬件设备(即硬件资产)或者更新相应的补丁(即软件资产)，以避免业务***崩溃。例如，目标业务为购物平台的AI客服产品，那么，促销期之前，同样也需要为业务预先扩容来避免业务***崩溃。

针对上述情况，在一种可选设计中，在步骤203之后，还可以从历史资产关系图谱中获取目标业务的历史资产变化情况。本申请实施例中，历史资产变化情况包括目标业务中历史资产的变化时间、变化数量、变化类型中的至少一个。进而，根据资产数据以及历史资产变化情况，预测更新资产关系图谱的未来资产变化情况。不难理解，此处历史资产的变化情况可以是与目标业务类型相关，例如，在上述示例中，旅游出行票务业务中的硬件设备的数量、带宽、设备类型均与公共假期的人流出行情况相关，因而，根据旅游出行票务业务中的历史资产变化情况，可以预测出未来旅游出行票务业务的数据处理量，从而得出适应于这一数据处理量的硬件设备信息(即未来资产变化情况)。最终，基于未来资产变化情况，在更新资产关系图谱中生成目标业务的资产预警信息。该资产预警信息用于指示更新资产关系图谱中各类资产的变化概率、变化时间或变化数量。继续以旅游出行票务业务为例，基于未来所需的硬件设备信息，在资产关系图谱中生成与该硬件设备信息匹配的动态本体作为预警实体，从而通过预警实体指示所需更新的硬件设备信息(比如设备类型、数量等)。当然，实际应用中，这一预警实体的外观可以区别于已经部署的硬件设备对应的动态本体的外观，例如，预警实体的区别外观可体现为以下之一：亮度、色彩、形状、边框线条。

当然，除了预警实体之外，也可以将资产预警信息以文字或图像的形式更新在资产关系图谱中。例如，高亮显示具有更新概率达到设定条件的资产对应的动态本体，以引导用户选取这一资产对应的动态本体，并响应于选取指令展示这一动态本体的变化趋势介绍(包括但不限于变化概率、变化时间、变化数量等)。变化趋势介绍可以是图表形式，也可以是文字形式，这里并不限定。

由此，通过上述步骤生成资产预警信息可以在更新资产关系图谱中体现未来的资产变化趋势，以便及时调整目标业务的资产部署方式，有助于实现目标业务的自动化运行管理。

在上文介绍的资产关系图谱的基础上，为了进一步保护目标业务的资产数据安全，与前文示例中介绍的隐藏状态类似，本申请实施例中，还可在资产关系图谱中隐藏部分涉及到信息安全的动态本体，例如，用于表示设备属性信息的动态本体。

在接收到对目标动态本体的查看请求之后，验证用户的查看操作权限，仅对符合查看条件的用户开放查看权限。具体地，若查看操作权限满足预设的查看条件，则在资产关系图谱中显示目标动态本体。这样，通过动态本体的查看条件可以保护资产的属性信息安全，防止查看或篡改属性信息带来的安全风险。

可以理解的是，动态本体的查看条件可以是预先配置的。例如，在创建目标业务时可以设置对应的管理员，由此，查看条件可以设置为：具有管理员身份的用户可查看各个动态本体包含的动态本体。进一步可选地，可以将目标业务所属对接部门的身份自动设置为管理员。

为了进一步保护目标业务的资产数据安全，本申请实施例中可选地，在构建资产关系图谱之后，还可接收对所述资产关系图谱中目标动态本体的维护操作请求，并验证用户的维护操作权限，仅对符合维护条件的用户开放维护权限。具体地，若所述维护操作权限满足预设的维护条件，则对所述目标动态本体执行对应的维护操作。这样，通过目标动态本体的维护条件可以限制对目标动态本体执行维护操作的用户身份，从而避免非法用户对目标动态本体执行违规操作，保护资产的信息安全，降低资产数据的安全风险。

可以理解的是，与动态本体的查看条件类似，目标动态本体的维护条件也可以是预先配置的。例如，在创建目标业务时可以设置对应的管理员，由此，目标动态本体的维护条件可以设置为：具有管理员身份的用户可维护各个动态本体。同样地，也可以直接将目标业务所属对接部门的身份自动设置为管理员。进一步地，根据不同维护操作的安全风险，还可以将管理员设置为多个级别，分别为不同级别的管理员开放不同的维护操作权限。

本申请实施例中，提供了一种全新的资产数据管理方式，相比于现有技术中每次业务变动造成的资产变动，都需要人工更改资产的数据结构表的数据管理方式，本申请实施例中可以基于资产数据构建出与变化资产相应的动态本体，进而以动态本体为根节点重构目标业务的资产关系图谱，实现了资产数据的自动化管理，在资产与业务场景之间形成了高效的数据关系形式，极大程度降低了管理资产数据的难度，提高了资产数据的维护效率。

在介绍了本申请实施例的方法之后，接下来，参考图7对本申请实施例的资产数据处理装置进行介绍。

本申请实施例中的资产数据处理装置70能够实现对应于上述图2所对应的实施例中资产数据处理方法的步骤。资产数据处理装置70实现的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。所述资产数据处理装置70应用于服务端设备，所述服务端设备运行有Kubernetes***。所述资产数据处理装置70可包括输入输出模块701、处理模块702，所述处理模块702、所述输入输出模块701的功能实现可参考图2所对应的实施例中所执行的操作，此处不作赘述。例如，所述处理模块702可用于控制所述输入输出模块701的数据收发操作。

一些实施方式中，所述输入输出模块701，还被配置为获取目标业务的资产数据；所述资产数据是通过Kubernetes***的自定义资源技术得到的；

所述处理模块702，还被配置为基于所述资产数据以及所述目标业务的历史资产关系图谱，获取动态本体；所述动态本体基于所述目标业务的变化资产确定，所述动态本体包括业务、软件资产和硬件资产中的一种；以所述动态本体为根节点，重构所述历史资产关系图谱，得到所述目标业务的更新资产关系图谱。

一些实施方式中，所述处理模块702，基于所述资产数据以及所述目标业务的历史资产关系图谱，获取动态本体时，被配置为：

从所述资产数据中提取所述目标业务的待处理资产；基于所述历史资产关系图谱中的历史资产，从所述待处理资产中选取与所述历史资产存在差异的变化资产；通过本体映射模型将所述变化资产转换为所述动态本体；所述本体映射模型用于将所述变化资产从原始数据格式转换为资产关系图谱中的存储格式。

一些实施方式中，所述处理模块702，将所述变化资产输入本体映射模型，由所述本体映射模型输出所述动态本体时，被配置为：

从所述资产数据中获取所述变化资产的属性字段；调用Kubernetes***中与所述属性字段匹配的本体映射模型；所述本体映射模型由Kubernetes***中的云原生服务预先建立；将所述变化资产输入到所述本体映射模型中，通过所述本体映射模型构建出所述动态本体；其中，所述动态本体至少包括以下项之一：所述变化资产的资产标识、资产属性以及资产关联关系。

一些实施方式中，所述处理模块702，还被配置为：

在基于所述资产数据以及所述目标业务的历史资产关系图谱，获取动态本体之前，获取所述目标业务中多个待处理资产之间的相似度；根据多个待处理资产之间的相似度对所述多个资产进行聚类处理，得到聚类结果；所述聚类结果中同类待处理资产对应同一个本体映射模型。

一些实施方式中，所述处理模块702，还被配置为：

在基于所述资产数据以及所述目标业务的历史资产关系图谱，获取动态本体之后，通过自定义资源技术，获取在所述历史资产关系图谱中的所述变化资产的访问频率；根据所述访问频率设置所述动态本体在所述更新资产关系图谱中所处的层级，其中，动态本体的层级与构建该动态本体的变化资产的访问频率呈负相关。

一些实施方式中，所述处理模块702，以所述动态本体为根节点，重构所述历史资产关系图谱，得到所述目标业务的更新资产关系图谱时，被配置为：

获取所述目标业务的云原生数据流；基于所述云原生数据流确定所述变化资产在所述目标业务中的资产关联关系；以所述动态本体为根节点，基于所述资产关联关系连接所述动态本体与所述历史资产关系图谱中其他层级节点之间的数据流关系，得到所述更新资产关系图谱。

一些实施方式中，所述处理模块702，还被配置为：

在以所述动态本体为根节点，重构所述历史资产关系图谱，得到所述目标业务的更新资产关系图谱之后，从所述历史资产关系图谱中获取所述目标业务的历史资产变化情况；所述历史资产变化情况至少包括以下项之一：所述目标业务中历史资产的变化时间、变化数量、变化类型；根据所述资产数据以及所述历史资产变化情况，预测所述更新资产关系图谱的未来资产变化情况；基于所述未来资产变化情况，在所述更新资产关系图谱中生成所述目标业务的资产预警信息；所述资产预警信息用于指示所述更新资产关系图谱中各类资产的变化概率、变化时间或变化数量。

本申请实施例中，资产数据处理装置可以基于资产数据构建出与变化资产相应的动态本体，进而以动态本体为根节点重构目标业务的资产关系图谱，实现了资产数据的自动化管理，在资产与业务场景之间形成了高效的数据关系形式，极大程度降低了管理资产数据的难度，提高了资产数据的维护效率。

在介绍了本申请实施例的方法和装置之后，接下来，对本申请实施例的计算机可读存储介质进行说明，计算机可读存储介质可为光盘，其上存储有计算机程序(即程序产品)，所述计算机程序在被处理器运行时，会实现上述方法实施方式中所记载的各步骤，例如，获取目标业务的资产数据，该资产数据是通过Kubernetes***的自定义资源技术得到的；基于该资产数据以及目标业务的历史资产关系图谱，获取动态本体，该动态本体基于目标业务的变化资产确定，动态本体包括业务、软件资产和硬件资产中的一种；以动态本体为根节点，重构历史资产关系图谱，得到目标业务的更新资产关系图谱。各步骤的具体实现方式在此不再重复说明。

需要说明的是，所述计算机可读存储介质的例子还可以包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他光学、磁性存储介质，在此不再一一赘述。

上面从模块化功能实体的角度对本申请实施例中的资产数据处理装置70进行了描述，下面从硬件处理的角度分别对本申请实施例中的执行资产数据处理方法的服务器、终端设备进行描述。

需要说明的是，在本申请资产数据处理装置实施例的图7所示的输入输出模块701对应的实体设备可以为输入/输出单元、收发器、射频电路、通信模块和输入/输出(I/O)接口等，处理模块702对应的实体设备可以为处理器。图7所示的资产数据处理装置70可以具有如图8所示的结构，当图7所示的资产数据处理装置70具有如图8所示的结构时，图8中的处理器和收发器能够实现前述对应该装置的装置实施例提供的处理模块702和输入输出模块701相同或相似的功能，图8中的存储器存储处理器执行上述资产数据处理方法时需要调用的计算机程序。

图9是本申请实施例提供的一种服务器结构示意图，该服务器1100可因配置或性能不同而产生比较大的差异，可以包括一个或一个以***处理器(central processingunits，CPU)1122(例如，一个或一个以上处理器)和存储器1132，一个或一个以上存储应用程序1142或数据1144的存储介质1130(例如一个或一个以上海量存储设备)。其中，存储器1132和存储介质1130可以是短暂存储或持久存储。存储在存储介质1130的程序可以包括一个或一个以上模块(图中未示出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1122可以设置为与存储介质1130通信，在服务器1100上执行存储介质1130中的一系列指令操作。

服务器1100还可以包括一个或一个以上电源1126，一个或一个以上有线或无线网络接口1170，一个或一个以上输入输出接口1158，和/或，一个或一个以上操作***1141，例如Windows Server，Mac OS X，Unix，Linux，FreeBSD等等。

上述实施例中由服务器所执行的步骤可以基于该图9所示的服务器1100的结构。例如，例如上述实施例中由图9所示的资产数据处理装置60所执行的步骤可以基于该图9所示的服务器结构。例如，所述中央处理器1122通过调用存储器1132中的指令，执行以下操作：

通过输入输出接口1158获取目标业务的资产数据；该资产数据是通过Kubernetes***的自定义资源技术得到的；

基于该资产数据以及目标业务的历史资产关系图谱，获取动态本体；该动态本体基于目标业务的变化资产确定，动态本体包括业务、软件资产和硬件资产中的一种；

以动态本体为根节点，重构历史资产关系图谱，得到目标业务的更新资产关系图谱。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***，装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请实施例所提供的几个实施例中，应该理解到，所揭露的***，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本申请实施例各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机计算机程序时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

以上对本申请实施例所提供的技术方案进行了详细介绍，本申请实施例中应用了具体个例对本申请实施例的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请实施例的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请实施例的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请实施例的限制。

Claims (10)

1.一种资产数据处理方法，其特征在于，所述方法应用于服务端设备，所述服务端设备运行有Kubernetes***，所述方法包括：

获取目标业务的资产数据；所述资产数据是通过Kubernetes***的自定义资源技术得到的；

基于所述资产数据以及所述目标业务的历史资产关系图谱，获取动态本体；所述动态本体基于所述目标业务的变化资产确定，所述动态本体包括业务、软件资产和硬件资产中的一种；

以所述动态本体为根节点，重构所述历史资产关系图谱，得到所述目标业务的更新资产关系图谱。

2.如权利要求1所述的方法，其特征在于，所述基于所述资产数据以及所述目标业务的历史资产关系图谱，获取动态本体，包括：

从所述资产数据中提取所述目标业务的待处理资产；

基于所述历史资产关系图谱中的历史资产，从所述待处理资产中选取与所述历史资产存在差异的变化资产；

通过本体映射模型将所述变化资产转换为所述动态本体；所述本体映射模型用于将所述变化资产从原始数据格式转换为资产关系图谱中的存储格式。

3.如权利要求2所述的方法，其特征在于，所述将所述变化资产输入本体映射模型，由所述本体映射模型输出所述动态本体，包括：

从所述资产数据中获取所述变化资产的属性字段；

调用Kubernetes***中与所述属性字段匹配的本体映射模型；所述本体映射模型由Kubernetes***中的云原生服务预先建立；

将所述变化资产输入到所述本体映射模型中，通过所述本体映射模型构建出所述动态本体；

其中，所述动态本体至少包括以下项之一：所述变化资产的资产标识、资产属性以及资产关联关系。

4.如权利要求2或3所述的方法，其特征在于，所述基于所述资产数据以及所述目标业务的历史资产关系图谱，获取动态本体之前，所述方法还包括：

获取所述目标业务中多个待处理资产之间的相似度；

根据多个待处理资产之间的相似度对多个资产进行聚类处理，得到聚类结果；所述聚类结果中同类待处理资产对应同一个本体映射模型。

5.如权利要求1至3任一项所述的方法，其特征在于，所述基于所述资产数据以及所述目标业务的历史资产关系图谱，获取动态本体之后，所述方法还包括：

通过自定义资源技术，获取所述历史资产关系图谱中的所述变化资产的访问频率；

根据所述访问频率设置所述动态本体在所述更新资产关系图谱中所处的层级，其中，动态本体的层级与构建该动态本体的变化资产的访问频率呈负相关。

6.如权利要求1至3任一项所述的方法，其特征在于，所述以所述动态本体为根节点，重构所述历史资产关系图谱，得到所述目标业务的更新资产关系图谱，包括：

获取所述目标业务的云原生数据流；

基于所述云原生数据流确定所述变化资产在所述目标业务中的资产关联关系；

以所述动态本体为根节点，基于所述资产关联关系连接所述动态本体与所述历史资产关系图谱中其他层级节点之间的数据流关系，得到所述更新资产关系图谱。

7.如权利要求1至3任一项所述的方法，其特征在于，所述以所述动态本体为根节点，重构所述历史资产关系图谱，得到所述目标业务的更新资产关系图谱之后，所述方法还包括：

从所述历史资产关系图谱中获取所述目标业务的历史资产变化情况；所述历史资产变化情况至少包括以下项之一：所述目标业务中历史资产的变化时间、变化数量、变化类型；

根据所述资产数据以及所述历史资产变化情况，预测所述更新资产关系图谱的未来资产变化情况；

基于所述未来资产变化情况，在所述更新资产关系图谱中生成所述目标业务的资产预警信息；所述资产预警信息用于指示所述更新资产关系图谱中各类资产的变化概率、变化时间或变化数量。

8.一种资产数据处理装置，其特征在于，所述装置应用于服务端设备，所述服务端设备运行有Kubernetes***，所述装置包括：

输入输出模块，被配置为获取目标业务的资产数据；所述资产数据是通过Kubernetes***的自定义资源技术得到的；

处理模块，被配置为基于所述资产数据以及所述目标业务的历史资产关系图谱，获取动态本体；所述动态本体基于所述目标业务的变化资产确定，所述动态本体包括业务、软件资产和硬件资产中的一种；以所述动态本体为根节点，重构所述历史资产关系图谱，得到所述目标业务的更新资产关系图谱。

9.一种计算设备，其特征在于，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现权利要求1-7中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，其包括指令，当其在计算机上运行时，使得计算机执行如权利要求1-7中任一项所述的方法。

Images