一种数据更新方法、装置、电子设备及计算机可读介质

技术领域

本申请涉及大数据数据处理技术领域，尤其涉及一种数据更新方法、装置、电子设备及计算机可读介质。

背景技术

目前，企业在长时间发展过程中，新系统不断开发，老系统也长期存在，系统既有敏态的，也有稳定态的，应用架构往往难以兼顾两种形态。如果全部按敏态管理，会给老系统带来风险，如果全部按稳态管理，采用瀑布模型开发及发布，又失去了敏态优势，使得相关数据更新不准确。

发明内容

有鉴于此，本申请实施例提供一种数据更新方法、装置、电子设备及计算机可读介质，能够解决现有的多系统共存时的数据更新不准确或者数据更新风险大的问题。

为实现上述目的，根据本申请实施例的一个方面，提供了一种数据更新方法，包括：

接收数据更新请求，获取对应的第一系统标识和第二系统标识；

获取第一系统标识和第二系统标识对应的系统组件定义数据；

基于系统组件定义数据，确定对应的系统组件与预设共识层的相似度；

根据相似度和预设共识层，对系统组件进行分层，以得到各个系统组件层；

确定各个系统组件层对应的更新策略，进而根据更新策略对所对应的系统组件层的系统组件数据进行更新。

可选地，确定对应的系统组件与预设共识层的相似度，包括：

将系统组件定义数据基于词嵌入的方式转换为系统组件定义数据向量；

将系统组件定义数据向量与预设共识层对应的预设维度共识向量进行相似度计算，以得到各个相似度。

可选地，根据相似度和预设共识层，对系统组件进行分层，以得到各个系统组件层，包括：

根据相似度将对应的系统组件分配至对应的预设共识层，以得到对应的系统组件层。

可选地，根据相似度将对应的系统组件分配至对应的预设共识层，以得到对应的系统组件层，包括：

将相似度大于预设阈值的系统组件分配至对应的预设维度共识向量对应的预设共识层，以得到对应的系统组件层。

可选地，确定各个系统组件层对应的更新策略，包括：

获取预设共识层对应的预设共识度，基于预设共识度确定各个系统组件层对应的更新策略。

可选地，基于预设共识度确定各个系统组件层对应的更新策略，包括：

响应于预设共识度大于共识度阈值，确定对应的系统组件层对应的更新策略为稳定迭代更新策略；

响应于预设共识度小于共识度阈值，确定对应的系统组件层对应的更新策略为敏捷快速迭代更新策略。

可选地，稳定迭代更新策略，包括：

按周更新并按月更新、按周更新、按月更新中的一种或几种；

敏捷快速迭代更新策略，包括：

按小时更新并按天更新、按小时更新、按天更新中的一种或几种。

另外，本申请还提供了一种数据更新装置，包括：

接收单元，被配置成接收数据更新请求，获取对应的第一系统标识和第二系统标识；

获取单元，被配置成获取第一系统标识和第二系统标识对应的系统组件定义数据；

相似度确定单元，被配置成基于系统组件定义数据，确定对应的系统组件与预设共识层的相似度；

分层单元，被配置成根据相似度和预设共识层，对系统组件进行分层，以得到各个系统组件层；

更新单元，被配置成确定各个系统组件层对应的更新策略，进而根据更新策略对所对应的系统组件层的系统组件数据进行更新。

可选地，相似度确定单元进一步被配置成：

将系统组件定义数据基于词嵌入的方式转换为系统组件定义数据向量；

将系统组件定义数据向量与预设共识层对应的预设维度共识向量进行相似度计算，以得到各个相似度。

可选地，分层单元进一步被配置成：

根据相似度将对应的系统组件分配至对应的预设共识层，以得到对应的系统组件层。

可选地，分层单元进一步被配置成：

将相似度大于预设阈值的系统组件分配至对应的预设维度共识向量对应的预设共识层，以得到对应的系统组件层。

可选地，更新单元进一步被配置成：

获取预设共识层对应的预设共识度，基于预设共识度确定各个系统组件层对应的更新策略。

可选地，更新单元进一步被配置成：

响应于预设共识度大于共识度阈值，确定对应的系统组件层对应的更新策略为稳定迭代更新策略；

响应于预设共识度小于共识度阈值，确定对应的系统组件层对应的更新策略为敏捷快速迭代更新策略。

可选地，稳定迭代更新策略，包括：

按周更新并按月更新、按周更新、按月更新中的一种或几种；

敏捷快速迭代更新策略，包括：

按小时更新并按天更新、按小时更新、按天更新中的一种或几种。

另外，本申请还提供了一种数据更新电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如上述的数据更新方法。

另外，本申请还提供了一种计算机可读介质，其上存储有计算机程序，程序被处理器执行时实现如上述的数据更新方法。

为实现上述目的，根据本申请实施例的又一个方面，提供了一种计算机程序产品。

本申请实施例的一种计算机程序产品，包括计算机程序，程序被处理器执行时实现本申请实施例提供的数据更新方法。

上述发明中的一个实施例具有如下优点或有益效果：本申请通过接收数据更新请求，获取对应的第一系统标识和第二系统标识；获取第一系统标识和第二系统标识对应的系统组件定义数据；基于系统组件定义数据，确定对应的系统组件与预设共识层的相似度；根据相似度和预设共识层，对系统组件进行分层，以得到各个系统组件层；确定各个系统组件层对应的更新策略，进而根据更新策略对所对应的系统组件层的系统组件数据进行更新。从而提高多系统共存时的数据更新准确率和数据更新效率，以及降低在多系统共存场景下的数据更新风险。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本申请，不构成对本申请的不当限定。其中：

图1是根据本申请一个实施例的数据更新方法的主要流程的示意图；

图2是根据本申请一个实施例的数据更新方法的主要流程的示意图；

图3是根据本申请一个实施例的数据更新方法的步进式分层示意图；

图4是根据本申请一个实施例的数据更新方法的双态协同示意图；

图5是根据本申请实施例的数据更新装置的主要单元的示意图；

图6是本申请实施例可以应用于其中的示例性系统架构图；

图7是适于用来实现本申请实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。需要说明的是，本申请的技术方案中，所涉及的用户个人信息的采集、分析、使用、传输、存储等方面，均符合相关法律法规的规定，被用于合法且合理的用途，不在这些合法使用等方面之外共享、泄露或出售，并且接受监管部门的监督管理。应当对用户个人信息采取必要措施，以防止对此类个人信息数据的非法访问，确保有权访问个人信息数据的人员遵守相关法律法规的规定，确保用户个人信息安全。一旦不再需要这些用户个人信息数据，应当通过限制甚至禁止数据收集和/或删除数据的方式将风险降至最低。

当使用时，包括在某些相关应用程序中，通过对数据去标识来保护用户隐私，例如在使用时通过移除特定标识符、控制所存储数据的量或特异性、控制数据如何被存储、和/或其他方法去标识。

图1是根据本申请一个实施例的数据更新方法的主要流程的示意图，如图1所示，数据更新方法包括：

步骤S101，接收数据更新请求，获取对应的第一系统标识和第二系统标识。

本实施例中，数据更新方法的执行主体（例如，可以是服务器）可以通过有线连接或无线连接的方式，接收数据更新请求。具体地，数据更新请求可以是对企业中各种系统进行数据更新的请求。其中，企业中的各种系统可以包括会计系统、账务核心系统等，本申请对企业中的各种系统的类型不做具体限定。企业中的各种系统更新周期可能不统一，系统颗粒度可能不一致。

步骤S102，获取第一系统标识和第二系统标识对应的系统组件定义数据。

本申请实施例中，第一系统标识可以是新系统对应的编号或名称，第二系统标识可以是老系统对应的编号或名称，本申请实施例对第一系统标识对应的系统的类型不做具体限定，对第二系统标识对应的系统的类型不做具体限定。

组件定义数据，例如可以是组件的应用场景数据、组件的性能数据、组件的空间占用率数据等，本申请实施例对组件定义数据不做具体限定。

执行主体可以汇总第一系统标识对应的各个组件的组件定义数据，以及汇总第二系统标识对应的各个组件的组件定义数据。

步骤S103，基于系统组件定义数据，确定对应的系统组件与预设共识层的相似度。

将汇总的组件定义数据对应的系统组件分别与预设共识层进行相似度匹配，以得到对应的相似度。具体地，执行主体可以确定出汇总的各个组件定义数据对应的组件的类型，根据组件的类型与预设共识层进行相似度匹配，以得到各个相似度。

例如，执行主体可以预设好每一个预设共识层对应的组件类型，并将本申请实施例的组件定义数据对应的系统组件的类型分别与预设好的每一个预设共识层对应的组件类型进行相似度匹配，以得到匹配好的每一个预设共识层对应的系统组件。

步骤S104，根据相似度和预设共识层，对系统组件进行分层，以得到各个系统组件层。

在根据得到的相似度确定出每一个系统组件所应处的预设共识层后，对系统组件进行分层处理，以将系统组件归属于所应处于的预设共识层，得到各个系统组件层。

步骤S105，确定各个系统组件层对应的更新策略，进而根据更新策略对所对应的系统组件层的系统组件数据进行更新。

每一个系统组件层的敏态稳态程度都不同，根据每一个系统组件层的敏态稳态程度，确定每一个系统组件层的更新策略。敏态程度越高，系统组件层对应的更新策略对应的更新频率越高，稳态程度越高，系统组件层对应的更新策略对应的更新频率越低。根据确定出的每一个系统组件层对应的更新策略更新该系统组件层的系统组件中的系统组件数据。从而实现对稳态及敏态对应的系统组件层的系统组件数据进行有序管理，缩小系统发布节奏跨度。

本实施例通过接收数据更新请求，获取对应的第一系统标识和第二系统标识；获取第一系统标识和第二系统标识对应的系统组件定义数据；基于系统组件定义数据，确定对应的系统组件与预设共识层的相似度；根据相似度和预设共识层，对系统组件进行分层，以得到各个系统组件层；确定各个系统组件层对应的更新策略，进而根据更新策略对所对应的系统组件层的系统组件数据进行更新。从而提高多系统共存时的数据更新准确率和数据更新效率，以及降低在多系统共存场景下的数据更新风险。

图2是根据本申请一个实施例的数据更新方法的主要流程示意图，如图2所示，数据更新方法包括：

步骤S201，接收数据更新请求，获取对应的第一系统标识和第二系统标识。

第一系统标识与第二系统标识也可以是上下游系统对应的标识，例如第一系统标识可以是上游系统对应的编号或名称等，第二系统标识可以是下游系统对应的编号或名称等，本申请实施例对第一系统标识和第二系统标识对应的系统的类型和名称不做具体限定。

步骤S202，获取第一系统标识和第二系统标识对应的系统组件定义数据。

第一系统标识和第二系统标识对应的系统组件定义数据可以是第一系统标识对应的第一系统产生的第一业务数据，以及第二系统标识对应的第二系统产生的第二业务数据。其中，第一业务数据可以用于第二系统中用于生产第二业务数据。

步骤S203，将系统组件定义数据基于词嵌入的方式转换为系统组件定义数据向量。

通过将数据转化为数据向量可以便于进行后续数据相似度的计算，以助于有效且准确地进行数据聚类。

步骤S204，将系统组件定义数据向量与预设共识层对应的预设维度共识向量进行相似度计算，以得到各个相似度。

具体地，可计算系统组件定义数据向量与预设共识层对应的预设维度共识向量之间的余弦相似度。

步骤S205，根据相似度和预设共识层，对系统组件进行分层，以得到各个系统组件层。

通过与每一个预设共识层的余弦相似度，执行主体可以将对应的系统组件定义数据对应的系统组件分配到对应的预设共识层，以得到各个系统组件层。

具体地，根据相似度和预设共识层，对系统组件进行分层，以得到各个系统组件层，包括：根据相似度将对应的系统组件分配至对应的预设共识层，以得到对应的系统组件层。

对于每一个预设共识层，将与该预设共识层的余弦相似度大于预设阈值时对应的系统组件分配至该预设共识层，以得到与该预设共识层对应的系统组件层。

具体地，根据相似度将对应的系统组件分配至对应的预设共识层，以得到对应的系统组件层，包括：将相似度大于预设阈值的系统组件分配至对应的预设维度共识向量对应的预设共识层，以得到对应的系统组件层。

将与预设维度共识向量的相似度大于预设阈值的系统组件分配至与该预设维度共识向量对应的预设共识层，从而得到填充了系统组件的系统组件层。这里的“填充”可以是空间上的虚拟填充，意为将该系统组件归为该预设共识层，也可以是实际上的位置的转移填充，本申请实施例对填充的含义不做具体限定。

步骤S206，确定各个系统组件层对应的更新策略，进而根据更新策略对所对应的系统组件层的系统组件数据进行更新。

在确定各个系统组件层对应的更新策略时，执行主体还可以实时检测归属于每一个系统组件层的系统组件被访问的频率，并基于该频率实时更新对应的系统组件所需要归属的系统组件层，以更好地服务用户，保证数据的实时准确性。

具体地，确定各个系统组件层对应的更新策略，包括：获取预设共识层对应的预设共识度，基于预设共识度确定各个系统组件层对应的更新策略。

共识度越高的层，需求较稳定，采用更新频率较小的更新策略，共识度越低的层，需求变化较快，采用更新频率较大的更新策略。执行主体可以预设确定好每一个预设共识层对应的预设共识度，从而在对系统组件分配好对应的预设共识层后，可以根据该预设共识层对应的预设共识度确定对应的更新策略。

具体地，基于预设共识度确定各个系统组件层对应的更新策略，包括：响应于预设共识度大于共识度阈值，确定对应的系统组件层对应的更新策略为稳定迭代更新策略；响应于预设共识度小于共识度阈值，确定对应的系统组件层对应的更新策略为敏捷快速迭代更新策略。

本申请实施例对共识度阈值不做具体限定，可以跟随实际需求动态变更，以满足数据更新需要。

具体地，稳定迭代更新策略，包括：按周更新并按月更新、按周更新、按月更新中的一种或几种；敏捷快速迭代更新策略，包括：按小时更新并按天更新、按小时更新、按天更新中的一种或几种。

本申请实施例可以提高多系统共存时的数据更新准确率和数据更新效率，以及降低在多系统共存场景下的数据更新风险。

图3是根据本申请一个实施例的数据更新方法的步进式分层示意图。步进式分层应用架构按系统的共识范围将企业内部系统按行业级共识、公司级共识、部门级共识及场景级共识进行分层。

行业共识层可以将行业中普遍认同的组件/系统纳管，如金融行业的关系人、合约、条件、产品等基础系统/组件纳管，此类组件在金融行业中已经达成设计共识，差异不大。

公司级共识层可以将公司内部特有的流程系统或者数据实体管理系统进行纳管，这类系统/组件实现了企业级内部的资源共享复用，可以降低多个部门独立开发和运维的成本。例如：商机管理、客户画像、财务会计等。

部门级共识层主要纳管公司各个业务条线差异的系统/组件，如存款部门只关心存款系统、信用卡部门只关心信用卡系统。部门级系统主要支撑个业务条线开展不同类型的业务，往往差异较大。

场景级共识主要纳管面客时的定制化较高的系统/组件， 此类组件变化较快，需要快速尝试找到业务方向。有些支撑活动类的组件可能随着营销活动结束生命周期就终止，但是在活期前需要配合广告、营销等，需要快速迭代上线实现快速业务创新。场景级共识系统/组件具有数量庞大、扩展迅速、快速迭代等特点，非常符合以用户为中心的系统建设需求。

图4是根据本申请一个实施例的数据更新方法的双态协同示意图。本申请实施例的数据更新方法，可以应用于企业系统组件数据更新的场景。如图4所示，步进式分层应用架构：将企业内部应用组件按行业级共识、公司级共识、部门级共识及场景级共识进行分层；双态协同：在分层的基础上进行敏态稳态协同开发部署，稳态的实现按瀑布模型开发部署，例如按月部署，敏态的按敏捷开发模式实现按周、按天、按小时部署；场景灵活扩展：在统一终端实现多场景的应用灵活扩展，快速创新。通过在分层的基础上进行敏态稳态协同开发部署，稳态的实现按瀑布模型开发部署，敏态的按敏捷开发模式实现业务需求，实现快速上线部署。步进式分层架构不严格遵循敏态或者稳态，而是实现从稳态到敏态的无缝过渡。在行业共识层由于是顶层抽象，需求变化不大，更新周期可以按月更新；公司级共识需求较为稳定，可以按周更新；部门级共识层中是部门特色经营的系统/组件，常常有些新需求，需要不断优化流程，可以按天更新；场景级共识主要面客，需要构建场景，发布活动，产品营销往往需要内外部配合，发布特点是开发周期短、时效要求高、生命周期短等特点，需要按小时更新发布。

示例的，步进式分层应用架构按系统的共识范围将企业内部系统按行业级共识、公司级共识、部门级共识及场景级共识进行分层。行业共识层可以将行业中普遍认同的组件/系统纳管，如金融行业的关系人、合约、条件、产品、地点、分类等基础系统/组件纳管，此类组件在金融行业中已经达成设计共识，差异不大。公司级共识层可以将公司内部特有的流程系统或者数据实体管理系统进行纳管，这类系统/组件实现了企业级内部的资源共享复用，可以降低多个部门独立开发和运维的成本。示例的，公司级共识层可以纳管商机管理、客户画像、项目管理、财务会计、产品管理、合约管理等系统/组件。部门级共识层纳管公司各个业务条线差异的系统/组件，如存款部门只关心存款系统、信用卡部门只关心信用卡系统。部门级系统支撑各业务条线开展不同类型的业务，往往差异较大。示例的，部门级共识层可以纳管存款、贷款、信用卡、贸易融资、收单、投资理财等系统/组件。场景级共识纳管面客时的定制化较高的系统/组件，此类组件变化较快，需要快速尝试找到业务方向。有些支撑活动类的组件可能随着营销活动结束生命周期就终止，但是在生命周期终止前需要配合广告、营销等，需要快速迭代上线实现快速业务创新。示例的，场景级共识层可以纳管分期通、钱包、个人养老金、分期甄选、装修分期、购车分期、生活卡、公积金、商超、美食、车生活等系统/组件。

场景级共识系统/组件具有数量庞大、扩展迅速、快速迭代等特点，非常符合以用户为中心的系统建设需求。系统/组件按共识的范围进行分层管理，按共识分层，共识度越高，所处分层越低；共识度越低，适用范围越窄，所处分层越高。从共识度低的分层到高的分层其共识度逐步提高。系统/组件按共识度分层后，采用不同的更新策略，共识度高的层，需求较为稳定，采用稳定迭代更新策略；共识度低的层，范围较小，对企业的影响较小，可以采用敏捷快速的迭代更新策略。从共识度低的分层到高的分层其更新迭代速度逐步提高。本申请实施例解决了企业在长时间发展过程中，新系统不断开发，老系统也长期存在，稳态及敏态混乱无序管理，系统发布节奏跨度大等问题。

图5是根据本申请实施例的数据更新装置的主要单元的示意图。如图5所示，数据更新装置500包括接收单元501、获取单元502、相似度确定单元503、分层单元504和更新单元505。

接收单元501，被配置成接收数据更新请求，获取对应的第一系统标识和第二系统标识。

获取单元502，被配置成获取第一系统标识和第二系统标识对应的系统组件定义数据。

相似度确定单元503，被配置成基于系统组件定义数据，确定对应的系统组件与预设共识层的相似度。

分层单元504，被配置成根据相似度和预设共识层，对系统组件进行分层，以得到各个系统组件层。

更新单元505，被配置成确定各个系统组件层对应的更新策略，进而根据更新策略对所对应的系统组件层的系统组件数据进行更新。

在一些实施例中，相似度确定单元503进一步被配置成：将系统组件定义数据基于词嵌入的方式转换为系统组件定义数据向量；将系统组件定义数据向量与预设共识层对应的预设维度共识向量进行相似度计算，以得到各个相似度。

在一些实施例中，分层单元504进一步被配置成：根据相似度将对应的系统组件分配至对应的预设共识层，以得到对应的系统组件层。

在一些实施例中，分层单元504进一步被配置成：将相似度大于预设阈值的系统组件分配至对应的预设维度共识向量对应的预设共识层，以得到对应的系统组件层。

在一些实施例中，更新单元505进一步被配置成：获取预设共识层对应的预设共识度，基于预设共识度确定各个系统组件层对应的更新策略。

在一些实施例中，更新单元505进一步被配置成：响应于预设共识度大于共识度阈值，确定对应的系统组件层对应的更新策略为稳定迭代更新策略；响应于预设共识度小于共识度阈值，确定对应的系统组件层对应的更新策略为敏捷快速迭代更新策略。

在一些实施例中，稳定迭代更新策略，包括：按周更新并按月更新、按周更新、按月更新中的一种或几种；敏捷快速迭代更新策略，包括：按小时更新并按天更新、按小时更新、按天更新中的一种或几种。

需要说明的是，本申请的数据更新方法和数据更新装置在具体实施内容上具有相应关系，故重复内容不再说明。

图6示出了可以应用本申请实施例的数据更新方法或数据更新装置的示例性系统架构600。

如图6所示，系统架构600可以包括终端设备601、602、603，网络604和服务器605。网络604用以在终端设备601、602、603和服务器605之间提供通信链路的介质。网络604可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备601、602、603通过网络604与服务器605交互，以接收或发送消息等。终端设备601、602、603上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等（仅为示例）。

终端设备601、602、603可以是具有数据更新处理屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器605可以是提供各种服务的服务器，例如对用户利用终端设备601、602、603所提交的数据更新请求提供支持的后台管理服务器（仅为示例）。后台管理服务器可以接收数据更新请求，获取对应的第一系统标识和第二系统标识；获取第一系统标识和第二系统标识对应的系统组件定义数据；基于系统组件定义数据，确定对应的系统组件与预设共识层的相似度；根据相似度和预设共识层，对系统组件进行分层，以得到各个系统组件层；确定各个系统组件层对应的更新策略，进而根据更新策略对所对应的系统组件层的系统组件数据进行更新。从而提高多系统共存时的数据更新准确率和数据更新效率，以及降低在多系统共存场景下的数据更新风险。

需要说明的是，本申请实施例所提供的数据更新方法一般由服务器605执行，相应地，数据更新装置一般设置于服务器605中。

应该理解，图6中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图7，其示出了适于用来实现本申请实施例的终端设备的计算机系统700的结构示意图。图7示出的终端设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图7所示，计算机系统700包括中央处理单元（CPU）701，其可以根据存储在只读存储器（ROM）702中的程序或者从存储部分708加载到随机访问存储器（RAM）703中的程序而执行各种适当的动作和处理。在RAM703中，还存储有计算机系统700操作所需的各种程序和数据。CPU701、ROM702以及RAM703通过总线704彼此相连。输入/输出（I/O）接口705也连接至总线704。

以下部件连接至I/O接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管（CRT）、液晶征信授权查询处理器（LCD）等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

特别地，根据本申请公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元（CPU）701执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑磁盘只读存储器（CD-ROM）、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括接收单元、获取单元、相似度确定单元、分层单元和更新单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备接收数据更新请求，获取对应的第一系统标识和第二系统标识；获取第一系统标识和第二系统标识对应的系统组件定义数据；基于系统组件定义数据，确定对应的系统组件与预设共识层的相似度；根据相似度和预设共识层，对系统组件进行分层，以得到各个系统组件层；确定各个系统组件层对应的更新策略，进而根据更新策略对所对应的系统组件层的系统组件数据进行更新。

本申请的计算机程序产品，包括计算机程序，计算机程序在被处理器执行时实现本申请实施例中的数据更新方法。

根据本申请实施例的技术方案，可以提高多系统共存时的数据更新准确率和数据更新效率，以及降低在多系统共存场景下的数据更新风险。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。