产品信息集成处理方法、装置、计算机设备和存储介质

摘要

本申请涉及一种产品信息集成处理方法、装置、计算机设备和存储介质。其中方法通过ETL工具从多个源系统中抽取产品关联数据，并对抽取的产品关联数据进行清洗及整合处理，以形成统一的标准产品关联数据，进而根据设定的产品应用模式，并采用ETL调度工具对标准产品关联数据进行归类，得到标准产品信息，从而实现对标准产品信息进行集中管理，且并不需要在各个源系统中开发对外开放的统一API接口，也无需对涉及交互的关联系统的硬件、软件以及网络进行升级改造，从而极大的节约了成本。

权利要求

1.一种产品信息集成处理方法，其特征在于，所述方法包括：

通过ETL工具从多个源系统中抽取产品关联数据，所述源系统包括记录了相同产品不同阶段数据源以及不同产品多个阶段数据源的多个系统；

根据产品维度对抽取的所述产品关联数据进行清洗及整合处理，以形成统一的标准产品关联数据，所述标准产品关联数据是用于记录各产品的全貌数据；

根据设定的产品应用模式，并采用ETL调度工具识别所述标准产品关联数据中的产品类别字段，以对所述标准产品关联数据进行归类，得到标准产品信息，所述标准产品信息是对所述标准产品关联数据进行归类后得到的具有类别的各产品的全貌数据的信息；

所述产品关联数据中记录了对应的关键业务标识；所述对抽取的所述产品关联数据进行清洗及整合处理，包括：从所述产品关联数据中提取所述关键业务标识，根据所述关键业务标识的权重对提取的所述关键业务标识进行去重处理，得到所述产品关联数据的业务主键标识；通过配置的代码映射关系将所述产品关联数据中的业务代码转换为标准业务代码；根据所述产品关联数据的业务主键标识对转换为标准业务代码的产品关联数据进行整合，获得标准产品关联数据。

2.根据权利要求1所述的方法，其特征在于，所述通过ETL工具从多个源系统中抽取产品关联数据，包括：根据设定的数据采集频率，采用ETL工具从多个源系统中抽取增量数据；

根据所述增量数据对应的数据源对所述增量数据进行标识，以获得产品关联数据，所述数据源包括数据所属的源系统以及数据在所述源系统中的原表名称。

3.根据权利要求2所述的方法，其特征在于，所述增量数据中具有对应的关键业务标识；所述采用ETL工具从多个源系统中抽取增量数据之后，所述方法还包括：根据所述增量数据以及对应的关键业务标识更新存量数据，并记录更新时间。

4.根据权利要求1所述的方法，其特征在于，所述产品关联数据包括对应数据源的标识；所述从所述产品关联数据中提取所述关键业务标识，根据所述关键业务标识的权重对提取的所述关键业务标识进行去重处理，包括：从所述产品关联数据中提取所述关键业务标识；

在所述关键业务标识中拼接与所述产品关联数据对应的数据源的标识，生成新的业务标识；

根据所述关键业务标识的权重对新的业务标识进行去重处理。

5.根据权利要求1所述的方法，其特征在于，所述采用ETL调度工具识别所述标准产品关联数据中的产品类别字段，以对所述标准产品关联数据进行归类，包括：通过ETL调度工具识别所述标准产品关联数据中对应的产品类别字段；

若所述标准产品关联数据对应的产品类别字段中记录了产品类别信息，则将所述标准产品关联数据归为与所述产品类别信息对应的产品类别；

若所述标准产品关联数据对应的产品类别字段为空，则获取所述标准产品关联数据对应的产品名称，根据所述产品名称对所述标准产品关联数据进行归类。

6.根据权利要求5所述的方法，其特征在于，所述根据所述产品名称对所述标准产品关联数据进行归类，包括：识别所述产品名称中是否包含设定的关键字；

若所述产品名称中包含设定的关键字，则将所述标准产品关联数据归为与所述关键字对应的设定产品类别。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述方法还包括：响应于第一账户对所述标准产品信息的备案申请操作，获取对所述备案申请进行审批的第二账户；

向所述第二账户发送所述备案申请，所述备案申请用于指示所述第二账户对所述备案申请进行审批；

接收所述第二账户返回的审批结果。

8.根据权利要求1至6任一项所述的方法，其特征在于，所述标准产品信息中包括第一产品名称；所述得到标准产品信息之后，所述方法还包括：获取产品报备信息，所述产品报备信息中包括第二产品名称；

识别所述第一产品名称与所述第二产品名称之间的相似度；

若所述相似度达到设定阈值，则建立所述第一产品名称对应的标准产品信息和所述第二产品名称对应的产品报备信息之间的关联关系。

9.一种产品信息集成处理装置，其特征在于，所述装置包括：

数据采集模块，用于通过ETL工具从多个源系统中抽取产品关联数据，所述源系统包括记录了相同产品不同阶段数据源以及不同产品多个阶段数据源的多个系统；

数据处理模块，用于根据产品维度对抽取的所述产品关联数据进行清洗及整合处理，以形成统一的标准产品关联数据，所述标准产品关联数据是用于记录各产品的全貌数据；

产品信息标准化模块，用于根据设定的产品应用模式，并采用ETL调度工具识别所述标准产品关联数据中的产品类别字段，以对所述标准产品关联数据进行归类，得到标准产品信息，所述标准产品信息是对所述标准产品关联数据进行归类后得到的具有类别的各产品的全貌数据的信息；

所述产品关联数据中记录了对应的关键业务标识；所述数据处理模块具体用于：从所述产品关联数据中提取所述关键业务标识，根据所述关键业务标识的权重对提取的所述关键业务标识进行去重处理，得到所述产品关联数据的业务主键标识；通过配置的代码映射关系将所述产品关联数据中的业务代码转换为标准业务代码；根据所述产品关联数据的业务主键标识对转换为标准业务代码的产品关联数据进行整合，获得标准产品关联数据。

10.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至8中任一项所述的方法的步骤。

11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至8中任一项所述的方法的步骤。

说明书

产品信息集成处理方法、装置、计算机设备和存储介质

技术领域

[0001] 本申请涉及互联网信息技术领域，特别是涉及一种产品信息集成处理方法、装置、计算机设备和存储介质。

背景技术

[0002] 随着互联网技术的快速发展，保险企业旗下各专业子公司开发销售的保险产品数量越来越多，由于各子公司经营性质的不同，且类型差异较大，从而长期处于各自管理的状态。目前企业对保险产品的管理依赖于人工从各个子公司独立的核心产品系统（该系统管理保险产品基本属性数据）、营销系统（该系统管理保险产品销售数据）、报表系统等中拉取产品关联数据，然后进行产品数据整合及分析，其效率低且容易因人为失误而导致错误。

[0003] 相关技术中，也可以通过在各个子公司独立的核心产品系统、营销系统、报表系统等中开发对外开放的统一API（Application Programming Interface，应用程序接口）接口，通过逐个对接API接口获取需要的产品关联数据以进行产品数据整合。然而，通过在各个子公司独立的核心产品系统、营销系统、报表系统等中开发对外开放的统一API接口，其成本较高，且对涉及交互的关联系统的硬件、软件以及网络等要求也较高。

发明内容

[0004] 基于此，有必要针对上述开发对外开放的统一API接口，其成本较高的问题，提供一种产品信息集成处理方法、装置、计算机设备和存储介质。

[0005] 一种产品信息集成处理方法，所述方法包括：

[0006] 通过ETL（Extract-Transform-Load，数据仓库技术）工具从多个源系统中抽取产品关联数据，其中，源系统包括记录了相同产品不同阶段数据源以及不同产品多个阶段数据源的多个系统；

[0007] 根据产品维度对抽取的所述产品关联数据进行清洗及整合处理，以形成统一的标准产品关联数据，其中，标准产品关联数据是用于记录各产品的全貌数据；

[0008] 根据设定的产品应用模式，并采用ETL调度工具识别标准产品关联数据中的产品类别字段，以对标准产品关联数据进行归类，得到标准产品信息，其中，标准产品信息是对标准产品关联数据进行归类后得到的具有类别的各产品的全貌数据的信息。

[0009] 在其中一个实施例中，通过ETL工具从多个源系统中抽取产品关联数据，包括：根据设定的数据采集频率，采用ETL工具从多个源系统中抽取增量数据；根据增量数据对应的数据源对增量数据进行标识，以获得产品关联数据，其中，数据源包括数据所属的源系统以及数据在源系统中的原表名称。

[0010] 在其中一个实施例中，增量数据中具有对应的关键业务标识；则采用ETL工具从多个源系统中抽取增量数据之后，所述方法还包括：根据增量数据以及对应的关键业务标识更新存量数据，并记录更新时间。

[0011] 在其中一个实施例中，产品关联数据中记录了对应的关键业务标识；所述对抽取的产品关联数据进行清洗及整合处理，包括：从产品关联数据中提取关键业务标识，根据关键业务标识的权重对提取的关键业务标识进行去重处理，得到产品关联数据的业务主键标识；通过配置的代码映射关系将产品关联数据中的业务代码转换为标准业务代码；根据产品关联数据的业务主键标识对转换为标准业务代码的产品关联数据进行整合，获得标准产品关联数据。

[0012] 在其中一个实施例中，产品关联数据包括对应数据源的标识；所述从产品关联数据中提取关键业务标识，根据关键业务标识的权重对提取的关键业务标识进行去重处理，包括：从产品关联数据中提取关键业务标识；在关键业务标识中拼接与产品关联数据对应的数据源的标识，生成新的业务标识；根据关键业务标识的权重对新的业务标识进行去重处理。

[0013] 在其中一个实施例中，所述采用ETL调度工具识别标准产品关联数据中的产品类别字段，以对标准产品关联数据进行归类，包括：通过ETL调度工具识别标准产品关联数据中对应的产品类别字段；若标准产品关联数据对应的产品类别字段中记录了产品类别信息，则将标准产品关联数据归为与产品类别信息对应的产品类别；若标准产品关联数据对应的产品类别字段为空，则获取标准产品关联数据对应的产品名称，根据产品名称对标准产品关联数据进行归类。

[0014] 在其中一个实施例中，根据产品名称对标准产品关联数据进行归类，包括：识别产品名称中是否包含设定的关键字；若产品名称中包含设定的关键字，则将标准产品关联数据归为与关键字对应的设定产品类别。

[0015] 在其中一个实施例中，所述方法还包括：响应于第一账户对标准产品信息的备案申请操作，获取对备案申请进行审批的第二账户；向第二账户发送备案申请，其中，备案申请用于指示第二账户对备案申请进行审批；接收第二账户返回的审批结果。

[0016] 在其中一个实施例中，标准产品信息中包括第一产品名称；所述得到标准产品信息之后，所述方法还包括：获取产品报备信息，其中，产品报备信息中包括第二产品名称；识别第一产品名称与所述第二产品名称之间的相似度；若相似度达到设定阈值，则建立第一产品名称对应的标准产品信息和第二产品名称对应的产品报备信息之间的关联关系。

[0017] 一种产品信息集成处理装置，所述装置包括：

[0018] 数据采集模块，用于通过ETL工具从多个源系统中抽取产品关联数据，所述源系统包括记录了相同产品不同阶段数据源以及不同产品多个阶段数据源的多个系统；

[0019] 数据处理模块，用于根据产品维度对抽取的产品关联数据进行清洗及整合处理，以形成统一的标准产品关联数据，标准产品关联数据是用于记录各产品的全貌数据；

[0020] 产品信息标准化模块，用于根据设定的产品应用模式，并采用ETL调度工具识别标准产品关联数据中的产品类别字段，以对标准产品关联数据进行归类，得到标准产品信息，其中，标准产品信息是对标准产品关联数据进行归类后得到的具有类别的各产品的全貌数据的信息。

[0021] 一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如上所述方法的步骤。

[0022] 一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述方法的步骤。

[0023] 上述产品信息集成处理方法、装置、计算机设备和存储介质，通过ETL工具从多个源系统中抽取产品关联数据，并对抽取的产品关联数据进行清洗及整合处理，以形成统一的标准产品关联数据，进而根据设定的产品应用模式，并采用ETL调度工具对标准产品关联数据进行归类，得到标准产品信息，从而实现对标准产品信息进行集中管理，且并不需要在各个源系统中开发对外开放的统一API接口，也无需对涉及交互的关联系统的硬件、软件以及网络进行升级改造，从而极大的节约了成本。

附图说明

[0024] 图1为一个实施例中产品信息集成处理方法的应用环境图；

[0025] 图2为一个实施例中产品信息集成处理方法的流程示意图；

[0026] 图3为一个实施例中抽取产品关联数据步骤的流程示意图；

[0027] 图4为一个实施例中进行数据清洗及整合步骤的流程示意图；

[0028] 图5为一个实施例中进行标准化步骤的流程示意图；

[0029] 图6为另一个实施例中产品信息集成处理方法的流程示意图；

[0030] 图7为再一个实施例中产品信息集成处理方法的流程示意图；

[0031] 图8为一个实施例中产品信息集成处理装置的结构框图；

[0032] 图9为一个实施例中产品信息集成处理装置对应的架构分层结构图；

[0033] 图10为一个实施例中数据抽取及加工的实现原理图；

[0034] 图11为一个实施例中产品信息集成处理的调度实现原理图；

[0035] 图12为一个实施例中计算机设备的内部结构图。

具体实施方式

[0036] 为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

[0037] 本申请提供的产品信息集成处理方法，可以应用于如图1所示的应用环境中。其中，产品数据库102（包括各个独立的数据库1、数据库2、……数据库n）通过网络与服务器104进行通信。服务器104通过ETL工具从多个源系统（即数据库102）中抽取产品关联数据，所述源系统包括记录了相同产品不同阶段数据源的多个系统以及不同产品多个阶段数据源的多个系统（如图1中的数据库1、数据库2、……、数据库n），并对抽取的产品关联数据进行清洗及整合处理，以形成统一的标准产品关联数据，从而根据设定的产品应用模式，并采用ETL调度工具对标准产品关联数据进行归类，得到标准产品信息。其中，数据库102是按照数据结构来组织、存储和管理数据的仓库，可以但不限于是各种本地数据库、云数据库等，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

[0038] 在一个实施例中，如图2所示，提供了一种产品信息集成处理方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：

[0039] 步骤210，通过ETL工具从多个源系统中抽取产品关联数据。

[0040] 其中，ETL（Extract-Transform-Load，数据仓库技术）用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至数据仓库的过程。源系统包括记录了产品不同阶段数据源的多个系统，例如，包括各个子公司独立的核心产品系统（该系统管理保险产品基本属性数据）、营销系统（该系统管理保险产品销售数据）、报表系统等，可以理解的是，同一子公司独立的核心产品系统、营销系统以及报表系统等记录的是相同产品不同阶段的数据源；而对于不同的子公司来说，由于其经营性质的不同，其对应的产品也不同，因此，各个子公司的源系统中记录的是不同产品多个阶段的数据源。产品关联数据则是指与产品相关的分散在不同源系统中的数据，如产品基本属性数据在核心产品系统中，产品销售数据在营销系统中等。由于产品相关的数据分散在不同的源系统中，从而无法查看所有的产品关联数据，也就没法看到产品的全貌，同时也无法做到产品的全生命周期管理。基于此，在本实施例中，通过利用ETL的抽取工具，从分散在各个子公司并相互独立的源系统（包括但不限于各子公司的核心产品系统、营销系统、报表系统等）中抽取产品关联数据，进而通过后续步骤对抽取的数据进行加工、整合，从而得到产品的所有关联数据，并形成具有产品全貌的标准产品信息，以对标准产品信息进行集中管理。

[0041] 步骤220，对抽取的产品关联数据进行清洗及整合处理，以形成统一的标准产品关联数据。

[0042] 其中，标准产品关联数据是将从不同源系统中抽取的与产品相关的不同阶段的产品关联数据进行清洗及整合后形成的能够反应产品全貌的数据，即从产品开发形成、上市销售等全过程中的相关数据。具体的，清洗是对数据进行重新审查和校验的过程，目的在于删除重复信息、纠正存在的错误，并提供数据一致性。整合则是将在不同数据源的数据收集、整理、清洗，以及转换后加载到一个新的数据源，以产品维度为数据消费者提供统一数据视图的数据集成方式。在本实施例中，通过产品维度将从多个源系统中抽取的产品关联数据进行清洗及整合处理，从而形成统一用于记录产品全貌的标准产品关联数据。

[0043] 步骤230，根据设定的产品应用模式，并采用ETL调度工具对标准产品关联数据进行归类，得到标准产品信息。

[0044] 其中，设定的产品应用模式是指预先设定的符合产品应用规则的样式，如产品展示的格式、内容等。归类是指以产品维度对标准产品关联数据按照一定的种类、等级或性质置于一定的地方或系列中。标准产品信息则是对标准产品关联数据进行归类后得到的具有类别的产品全貌信息。在本实施例中，根据设定的产品应用模式，并采用ETL调度工具识别标准产品关联数据中的产品类别字段，以对标准产品关联数据进行归类，从而得到标准产品信息，具体地，标准产品信息是对标准产品关联数据进行归类后得到的具有类别的各产品的全貌数据的信息。

[0045] 上述产品信息集成处理方法中，通过ETL工具从多个源系统中抽取产品关联数据，并对抽取的产品关联数据进行清洗及整合处理，以形成统一的标准产品关联数据，进而根据设定的产品应用模式，并采用ETL调度工具对标准产品关联数据进行归类，得到标准产品信息，从而实现对标准产品信息进行集中管理，且并不需要在各个源系统中开发对外开放的统一API接口，也无需对涉及交互的关联系统的硬件、软件以及网络进行升级改造，从而极大的节约了成本。

[0046] 在一个实施例中，如图3所示，步骤210，通过ETL工具从多个源系统中抽取产品关联数据，具体包括：

[0047] 步骤211，根据设定的数据采集频率，采用ETL工具从多个源系统中抽取增量数据。

[0048] 其中，增量数据是指当前根据数据采集频率从各个源系统中抽取的源数据。其中，数据采集频率可以是一天，也可以是一个月，即当天采集前一天的数据，或当月采集前一个月的数据，具体可以根据实际需要设定采集频率。具体的，根据设定的数据采集频率，采用ETL工具从多个源系统中抽取增量数据。

[0049] 进一步的，增量数据中具有对应的关键业务标识，则在抽取增量数据之后，还可以根据增量数据以及对应的关键业务标识更新存量数据，并记录更新时间。其中，关键业务标识是指用于关联不同源系统中源数据的关键字，例如，可以是保单号、赔案号、保全批单号或收付号等。存量数据则是指在当前采集之前所有已采集的源数据。具体的，当每次采集到新的源数据（也即增量数据）后，根据对应的关键业务标识对存量数据进行更新，从而得到当前时刻的全量数据，并记录更新时间，从而当更新异常时，可以根据更新时间以及对应的增量数据进行修复。

[0050] 步骤212，根据增量数据对应的数据源对增量数据进行标识，以获得产品关联数据。

[0051] 其中，数据源包括数据所属的源系统以及数据在源系统中的原表名称。在本实施例中，根据增量数据对应的数据源对增量数据进行标识，具体的，可以在增量数据中增加该增量数据所属的源系统标识（例如可以是源系统的唯一识别码）以及原表名称，从而形成产品关联数据。

[0052] 在一个实施例中，产品关联数据中记录了对应的关键业务标识，如图4所示，步骤220，对抽取的产品关联数据进行清洗及整合处理，具体包括：

[0053] 步骤221，从产品关联数据中提取关键业务标识，根据关键业务标识的权重对提取的关键业务标识进行去重处理，得到产品关联数据的业务主键标识。

[0054] 其中，关键业务标识是指用于关联不同源系统中源数据的关键字，由于关键业务标识可能存在多个，所以在对数据整合时容易造成混乱，因此，在本实施例中，根据关键业务标识的权重对提取的关键业务标识进行去重处理，从而得到产品关联数据的业务主键标识，进而通过该业务主键标识对数据进行整合，以实现对数据的集中管理。

[0055] 进一步的，为了避免整合不同的源系统的业务主键标识时出现撞号问题，在本实施例中，产品关联数据中还包括对应数据源的标识，因此，从产品关联数据中提取关键业务标识后，还可以在该关键业务标识中拼接与产品关联数据对应的数据源的标识，从而生成新的业务标识，进而根据关键业务标识的权重对新的业务标识进行去重处理。其中，数据源的标识可以是对应产品关联数据所属的源系统标识。

[0056] 步骤222，通过配置的代码映射关系将产品关联数据中的业务代码转换为标准业务代码。

[0057] 其中，业务代码是指产品关联数据中的数据项所对应的编码。标准业务代码则是对产品关联数据中的数据项所对应的标准编码。代码映射关系则是指同一数据项的业务代码与标准业务代码之间的转换关系。例如，若某一源系统中产品关联数据中的数据项“性别男”对应的编码为“0”，“性别女”对应的编码为“1”，而另一源系统中产品关联数据中的数据项“性别男”对应的编码为“a”，“性别女”对应的编码为“b”，若行业标准中对于数据项“性别男”的标准编码为“bz01”，对于数据项“性别女”的标准编码为“bz02”，则可以基于行业标准对上述两个源系统中产品关联数据中的数据项“性别男”和“性别女”的业务代码进行转换，从而将其转换为行业标准中的标准编码方式。具体的，可以通过在对应的表结构上增加字段实现，例如，源表：表A，性别sex；数据标准化层：表A，原性别sex_ocd，性别sex_cd；其中，原性别 sex_ocd：直接映射源表；性别sex_cd：为通过配置表转换后的结果。

[0058] 步骤223，根据产品关联数据的业务主键标识对转换为标准业务代码的产品关联数据进行整合，获得标准产品关联数据。

[0059] 具体的，通过上述步骤对从各个源系统中抽取的产品关联数据进行标准化处理之后，进而根据产品关联数据的业务主键标识对各个源系统中标准化后的产品关联数据进行整合，从而获得标准产品关联数据。

[0060] 在一个实施例中，标准产品关联数据中包括对应的产品类别字段，如图5所示，步骤230，采用ETL调度工具对标准产品关联数据进行归类，具体包括：

[0061] 步骤231，通过ETL调度工具识别标准产品关联数据对应的产品类别字段。

[0062] 其中，产品类别字段是用于记录产品类别信息的字段。通常，若源数据中存在产品类别信息，则会被记录到标准产品关联数据对应的产品类别字段中，若源数据中不存在产品类别信息，则标准产品关联数据对应的产品类别字段中记录的信息为空。在本实施例中，通过ETL调度工具识别标准产品关联数据中对应的产品类别字段是否记录了产品类别信息。

[0063] 步骤232，判断产品类别字段中是否记录了产品类别信息。

[0064] 若是，则执行步骤233，否则执行步骤234。

[0065] 步骤233，将标准产品关联数据归为与产品类别信息对应的产品类别。

[0066] 具体的，若标准产品关联数据对应的产品类别字段中记录了产品类别信息，则将标准产品关联数据归为与记录的产品类别信息对应的产品类别。

[0067] 步骤234，获取标准产品关联数据对应的产品名称，根据产品名称对标准产品关联数据进行归类。

[0068] 具体的，若标准产品关联数据对应的产品类别字段为空，则获取标准产品关联数据对应的产品名称，进而根据产品名称对标准产品关联数据进行归类。

[0069] 进一步的，根据产品名称对标准产品关联数据进行归类具体包括：识别产品名称中是否包含设定的关键字，若产品名称中包含设定的关键字，则将标准产品关联数据归为与该关键字对应的设定产品类别。其中，设定的关键字是指根据特有业务要求而事先规定的关键字，设定产品类别则是事先为设定的关键字而制定好的类别。举例来说，如设定的关键字为“癌”、“肿瘤”等，且事先为其设定了相关类别，若识别到标准产品关联数据的产品名称中包含了“癌”或“肿瘤”等关键字，则将该标准产品关联数据归为与设定的关键字对应的设定产品类别。需要说明的是，对于无法自动归类的标准产品关联数据（即对应的产品类别字段为空，且产品名称中并未包含设定的关键字），则可进行手动归类。

[0070] 在一个实施例中，如图6所示，上述方法还包括如下步骤：

[0071] 步骤610，响应于第一账户对标准产品信息的备案申请操作，获取对备案申请进行审批的第二账户。

[0072] 由于产品的固有特性，例如，对于保险产品来说，在上市前需要至相关监管机构进行备案，且备案通过后方可上市。而本实施例中的备案申请是指报送相关监管机构进行备案前，企业内部对备案产品的审批流程，只有当企业内部的备案审批通过后，方可报送至相关监管机构进行备案，以提高备案的通过率。由于传统技术中各子公司的源系统相互独立，导致传统的线下备案申请模式无章可循，更难以获取其历史审批轨迹，从而在出现问题时无可追溯。基于此，本实施例可以通过服务器开放的备案申请入口，以提交第一账户对标准产品信息的备案申请操作，并获取对备案申请进行审批的第二账户。其中，第一账户和第二账户分别为具有不同用户属性的用户账户，例如，第一账户可以是进行产品开发的员工，第二账户可以是该员工的上级领导；或者第一账户是子公司的产品负责人，第二账户则可以是企业的领导。

[0073] 步骤620，向第二账户发送备案申请。

[0074] 其中，该备案申请用于指示第二账户对备案申请进行审批。具体的，服务器根据获取的对备案申请进行审批的第二账户，自动向该第二账户发送该备案申请，以提醒该第二账户对备案申请进行审批，从而给出审批通过或审批不通过的审批结果。

[0075] 步骤630，接收第二账户返回的审批结果。

[0076] 服务器还可以接收第二账户返回的审批结果，并向第一账户展示该审批结果。具体的，在向第一账户展示该审批结果的同时，还可以通过邮件或即时通信的方式以向第一账户进行提醒。可以理解的是，在向第二账户发送备案申请的同时，也可以通过邮件或即时通信的方式以向第二账户进行提醒，从而提高备案申请审批的效率。

[0077] 进一步的，当审批结果为审批通过时，则对应的标准产品信息中的备案状态被标记为“审批通过”，当第二账户给出的审批结果为审批不通过时，其对应的备案状态被标记为“备案暂存”，且备案申请流程被退回至第一账户，以供第一账户对该备案申请进行修改或调整。

[0078] 在一个实施例中，标准产品信息中包括第一产品名称，如图7所示，上述方法还包括如下步骤：

[0079] 步骤710，获取产品报备信息。

[0080] 其中，产品报备信息是指在相关监管机构进行备案且备案通过的相关信息，具体的，标准产品信息和产品报备信息中都包括对应的产品名称，本实施例中为了方便说明，将标准产品信息中的产品名称定义为第一产品名称，将产品报备信息中的产品名称定义为第二产品名称。在本实施例中，通过获取产品报备信息，并识别产品报备信息中的第二产品名称。其中，获取产品报备信息可以是获取向服务器导入的产品报备信息。

[0081] 步骤720，识别第一产品名称与第二产品名称之间的相似度。

[0082] 其中，相似度是表征第一产品名称与第二产品名称之间相似性的度量。具体的，可以通过相似度算法计算两者的特征之间的距离，如果距离小，则表示相似度大，如果距离大则相似度小。

[0083] 步骤730，若相似度达到设定阈值，则建立第一产品名称对应的标准产品信息和第二产品名称对应的产品报备信息之间的关联关系。

[0084] 其中，设定阈值是指两者之间可以建立关联关系所需要达到的最小相似度大小。具体的，若两者的相似度达到设定阈值，则自动建立第一产品名称对应的标准产品信息和第二产品名称对应的产品报备信息之间的关联关系；若两者的相似度没有达到设定阈值，则可以通过人工判别并进行手动关联。

[0085] 应该理解的是，虽然图1-7的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1-7中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

[0086] 在一个实施例中，如图8所示，提供了一种产品信息集成处理装置，包括：数据采集模块801、数据处理模块802和产品信息标准化模块803，其中：

[0087] 数据采集模块801，用于通过ETL工具从多个源系统中抽取产品关联数据，其中，源系统包括记录了相同产品不同阶段数据源以及不同产品多个阶段数据源的多个系统；

[0088] 数据处理模块802，用于根据产品维度对抽取的产品关联数据进行清洗及整合处理，以形成统一的标准产品关联数据，其中，标准产品关联数据是用于记录各产品的全貌数据；

[0089] 产品信息标准化模块803，用于根据设定的产品应用模式，并采用ETL调度工具识别标准产品关联数据中的产品类别字段，以对标准产品关联数据进行归类，得到标准产品信息，其中，标准产品信息是对标准产品关联数据进行归类后得到的具有类别的各产品的全貌数据的信息。

[0090] 在一个实施例中，数据采集模块801具体用于：根据设定的数据采集频率，采用ETL工具从多个源系统中抽取增量数据；根据所述增量数据对应的数据源对所述增量数据进行标识，以获得产品关联数据，所述数据源包括数据所属的源系统以及数据在所述源系统中的原表名称。

[0091] 在一个实施例中，增量数据中具有对应的关键业务标识；则数据采集模块801还用于：根据增量数据以及对应的关键业务标识更新存量数据，并记录更新时间。

[0092] 在一个实施例中，产品关联数据中记录了对应的关键业务标识；则数据处理模块802具体用于：从产品关联数据中提取关键业务标识，根据关键业务标识的权重对提取的关键业务标识进行去重处理，得到产品关联数据的业务主键标识；通过配置的代码映射关系将产品关联数据中的业务代码转换为标准业务代码；根据产品关联数据的业务主键标识对转换为标准业务代码的产品关联数据进行整合，获得标准产品关联数据。

[0093] 在一个实施例中，产品关联数据包括对应数据源的标识；数据处理模块802还用于：从产品关联数据中提取关键业务标识；在关键业务标识中拼接与产品关联数据对应的数据源的标识，生成新的业务标识；根据关键业务标识的权重对新的业务标识进行去重处理。

[0094] 在一个实施例中，标准产品关联数据中包括对应的产品类别字段；则产品信息标准化模块803用于：通过ETL调度工具识别标准产品关联数据对应的产品类别字段；若标准产品关联数据对应的产品类别字段中记录了产品类别信息，则将标准产品关联数据归为与产品类别信息对应的产品类别；若标准产品关联数据对应的产品类别字段为空，则获取标准产品关联数据对应的产品名称，根据产品名称对标准产品关联数据进行归类。

[0095] 在一个实施例中，产品信息标准化模块803还用于：识别产品名称中是否包含设定的关键字；若产品名称中包含设定的关键字，则将标准产品关联数据归为与关键字对应的设定产品类别。

[0096] 在一个实施例中，上述装置还包括备案申请审批模块，用于响应于第一账户对标准产品信息的备案申请操作，获取对备案申请进行审批的第二账户；向第二账户发送备案申请，其中，备案申请用于指示第二账户对备案申请进行审批；接收第二账户返回的审批结果。

[0097] 在一个实施例中，标准产品信息中包括第一产品名称；则上述装置还包括产品关联模块，用于获取产品报备信息，其中，产品报备信息中包括第二产品名称；识别第一产品名称与第二产品名称之间的相似度；若相似度达到设定阈值，则建立第一产品名称对应的标准产品信息和第二产品名称对应的产品报备信息之间的关联关系。

[0098] 关于产品信息集成处理装置的具体限定可以参见上文中对于产品信息集成处理方法的限定，在此不再赘述。上述产品信息集成处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

[0099] 在一个实施例中，以下结合具体的应用场景进一步对本申请进行说明，具体的，本实施例以保险领域的保险产品为例进行说明，其中，保险产品包括境内保险产品和境外保险产品，且包括但不限于寿险、健康险、意外险、年金险、委托管理类、车险、水险、企业工程险、家财险、健康险、责任信用保证险、特险、农险以及其他险等。涉及的保险信息（即产品关联数据）包括产品基本信息、保监报备信息、产品责任信息、产品获奖信息、产品销售信息等。涵盖的产品包括境内保险产品和境外保险产品。

[0100] 图9为本申请的产品信息集成处理装置对应的架构分层结构，整体可包括源系统层、企业统一数据平台层（也就是企业产品信息管理系统数据仓库）、企业产品信息管理系统层以及终端展示层。

[0101] 其中，源系统层也就是产品关联数据的来源系统，通常对于不同的产品，其对应的关联数据的来源系统可能不同。另外还有一个外部加载区，主要是让其他源系统把数据直接推送到该数据区。企业统一数据平台层，也就是企业产品信息管理系统数据仓库，主要包括三个逻辑层，如ODS（operational data store，操作型数据存储）层、EDW（Enterprise Data Warehouse，企业数据仓库）层以及DM（Data Mart，数据集市）层，这些分层的具体定义和功能说明可见如图10所示的部分。企业产品信息管理系统层，包括的功能模块有：产品展示、补录平台、特别关注、审批管理、指标信息、法律法规、报表展示、系统管理。对接的关联应用系统包括：企业身份认证系统、企业邮件系统、企业内网门户等。终端展现层，目前能支持所有的浏览器，包括google Chrome、Firefox、IE浏览器、Apple Safari等。具体的，从源系统层通过ETL工具抽取产品关联数据到企业统一数据平台层后，经过统一数据平台层的数据加工后，数据流入到企业产品信息管理系统层的应用数据库中，最后在终端经过转换显示给用户。其中，图8所示的数据采集模块801和数据处理模块802可以嵌入企业统一数据平台层内，图8所示的产品信息标准化模块803、备案申请审批模块以及产品关联模块可以嵌入企业产品信息管理系统层内。

[0102] 图10为数据抽取及加工的实现原理图，其中，源系统作为企业统一数据平台层的数据源，提供T+1（其中，T为实际发生的事件交易日，其同步频率为1天，即当天同步前一天的数据）或者M+1（M为实际发生的事件交易月，同步频率为1月，即当月同步上个月的数据）的数据；目前包括不同产品分别对应的数据系统、财务系统以及外部加载区的数据。其中，外部加载区可以包括零散的产品（也即没有单独的数据系统进行管理的产品）数据及外部补录的数据等。

[0103] ODS层，多个数据源的数据将集中到一个ODS数据库。其中，ODS层又包括贴源区、数据标准化区以及历史数据区，其中贴源区又分增量层和存量层；数据标准化区又分扩大增量层以及数据标准化层。

[0104] 对于增量层的数据，可以按如下规则进行命名："源系统简称_"+"原表名"，包括贴源区的增量层以及数据标准化区的扩大增量层。表名称应为：SRC_<源系统英文简称>_<表名称>，命名示例为：SRC_AAA_B_CCCCCCC_DDDD。命名中各部分以_为分隔符，说明如下：源系统英文简称应为3 4个字符的大写英文单词，如AAA；表名称为加载数据的原表的名称，一般~为大写英文单词；如果总长度超过数据库命名限制，则在源表表名末尾开始删减并标识删减个数。若源表为B_CCCCCCCCC_DDDDDD_EEEEE，则其超过长度限制，需要后缀去掉6位，即去掉最后的_EEEEE，则有 SRC_AAA_B_CCCCCCCCC_DDDDDD6，并在每张表中加入抽取时间和增量结束日期两个字段。

[0105] 存量层，数据标准化层：可以按如下规则进行命名："源系统简称_"+"原表名"；表名称应为：SRC_<源系统英文简称>_<表名称>，命名示例：SRC_AAA_B_CCCCCCC_DDDD。命名中各部分以_为分隔符，说明如下：源系统英文简称应为3 4个字符的大写英文单词；表名称为~加载数据的表的名称，大写英文单词；如果总长度超过数据库命名限制，则在源表表名后尾开始删减并标识删减个数。

[0106] 对于ODS各层加工规则如下：

[0107] 对于贴源增量层，ETL直连抽取增量数据，包括不同产品分别对应的数据系统的增量数据；检核通过的外部加载区的增量数据，包括不同产品系统的增量数据；增量区表每天清空；具体命名详见上述命名规则；提交增量区的数据必须是完整事务的。ETL直连方式加工的增量表由数据平台ETL来保证；外部加载的增量数据，由数据平台按照一定的检核规则从外部加载区移动到增量区，异常数据不进入增量区，可以进入历史数据区（即存量层）。

[0108] 对于贴源存量层：1.初始化：ETL直连初始化或外部直接推送初始化；2.增量更新：根据增量层的增量数据更新存量层数据，采用按主键先删后插方式进行更新，保留拱数时点源系统的全量最新数据；3.存量层表不做归档，定期做备份，表命名详见上述命名规则；
4.存量表结构跟源系统一致，表尾增加ETL任务名以及加载时间；5.增量更新异常，可根据加载时间先删后根据增量更新进行修复。

[0109] 对于扩大增量层：其按照一定数据规则进行增量扩大，满足后续增量加工业务数据的完整性。具体的，首先从增量层搜集关键业务主键号，再根据业务主键号从存量层加工出相应的扩大增量层，每次跑批前清空。例如关键业务号包括：保单号，赔案号，保全批单号，以及收付号等，通过一张增量主键配置表，把每个增量的表关键业务主键号搜集起来，等整个增量层批处理完成后，最后做去重归集主键号。扩大增量层的表设计跟贴源增量层相类似；在加工取舍关键业务号时以关键业务号的顺序进行选择。例如增量表同时有保单号，赔案号，那么以保单号为业务主键。举例来说，增量区存在： 表A，保单：1 2 3 4 5；表B，保单： 3 4 5 6 7 8，赔案号： a b c；表C，保单： 9 10，收付号： 100 200；表D，赔案号： c d e。则搜集的关键业务主键号包括：保单号：1 2 3 4 5 6 7 8 9 10；赔案号：a b c d e，收付号：100 200。以此去重，得到归集的主键号为：表A，按保单号取：1 2 3 4 5 6 7 8 9 10；表B，按保单号取：1 2 3 4 5 6 7 8 9 10；表C，按保单号取：1 2 3 4 5 6 7 8 9 10；表D，按赔案号取：a b c d e。

[0110] 对于数据标准层，该层为EDW的整合区提供数据服务。其主要进行业务代码的标准化，非法及不规则数据的处理等。其中，业务代码标准化，目前业务存在两个主流方案，一是采用行业标准，各专业子公司都往行业标准转化，优点是符合行业及外部监管要求；缺点是行业标准不一定适用企业各专业子公司，且所有子系统都需要进行标准化处理；二是采用企业产品为参照，制定标准。例如寿险，可以以对应产品代码为标准，将不同产品的代码进行标准化处理；缺点是产品本身的代码制定的缺陷无法屏蔽；优点是能够快速的实现代码统一，减少系统开销和维护成本。例如，可能存在对于某一产品系统，代码 0 男 1 女，而对于另一产品系统，代码 a 男 b 女，而行业标准为bz01 男 bz02 女。如果采用行业标准：则这两个产品系统都要往行业标准转；如果采用企业产品标准：则只要将一个产品系统的代码向另一个产品系统的代码进行转换即可。具体可通过代码映射配置来实现业务代码标准化。其中，代码映射配置表包括源代码与标准代码的对应。在数据标准层进行系统初始化时，通过存量层表以及代码转换配置表实现转换，日增量时，通过扩大增量层表与代码转换配置表实现转换。

[0111] 对于整合区，可按子公司条线领域建立主题模型，为企业业务分析提供数据支撑。建模原则如下：EDW层模型建设分两方面，一是整合层模型建设，二是指标标准化区模型建设。其中，整合层模型采用第三范式进行设计，尽量减少数据冗余，即同一数据属性或事实，在整合层保持只有一个位置存储，避免同一属性或事实多份存储，造成不一致现象。具体可以采用面向业务对象的模型建设方法进行建设，主要围绕当事方、产品、机构、渠道、保全、理赔、财务、收付费共8个对象进行建立。其业务对象主要两大类，一是寿险，二是财险；分寿险整合层，财险整合层。其中，寿险整合层又包括不同寿险产品相关的业务主体。财险整合层又包括不同财险产品相关的业务主体。整合层业务主键按各源系统的主键分别设置，防止整合不同的源系统的主键撞号，因此，可以在业务主键号之前拼上各源系统的简称。整合层数据模型建设考虑企业现有数据，尽量保持对象属性、对象类型、对象子类属性、关系事实属性的完整，以增加模型的稳定性，在未来数据源的数据属性增加时，可以不调整原子层数据模型适用变化。对于指标标准化区，则可以按指标的标准进行统一加工及管理。主要包括指标标准化区和养老金指标层，其分层处理原理如下：指标标准区分寿险指标层，财险指标层，养老金指标层。寿险指标层来源于寿险整合层，财险指标层来源于财险整合层。养老金指标层：由于养老金都是基金，业务相对单一，可以直接从ODS的数据标准化层到养老金的指标层。

[0112] 对于集市区，包括产品基本信息分析、产品经营业绩分析、产品赔付情况分析、产品定价信息分析、产品赔付情况分析、投资组合情况分析、其他分析等分析主题的集市。具体主要包含三个层次的需求，一个日频率，一个月频率，还有年频率。其中，日频率集市：如果涉及保单件数，产品件数就需要存放保单以及产品明细指标，如果不涉及件数类指标，可以按产品、机构、渠道进行按日期汇总。月频率集市：系统加工指标按产品、机构、渠道等产品分析维度进行按月累计汇总，导入性指标按导入粒度，报表样式需求可以选择性映射，例如财务指标可以不映射到机构，那么机构置空。年频率集市：系统加工指标按产品、机构、渠道等产品分析维度进行按年累计汇总，导入性指标按导入粒度，报表样式需求选择性映射。例如财务指标不到机构，那么机构置空。

[0113] 公共数据服务区层，主要满足外部系统及部门提数需求而设定的公共数据推送区，可通过开放的接口如OA提交需求申请流程进行对外服务。系统管理层主要对质量管理(如数据校验)、元数据管理以及运行监控等的处理。

[0114] 其具体的调度流程如图11所示，ETL调度采用Informatica工具，任务编排共分为两层，包括工作流1(ODS，EDW层)和工作流2(DM层)。其通过层级之间的加载策略配置相应的任务级依赖关系，即同一工作流之内配置任务依赖，不同工作流之间配置事件级依赖。举例来说，若按任务实现功能进行划分，则其调度任务可以包含如下类型：

[0115] 1、ETL1（ODS贴源区）任务，即从源系统到ODS的数据抽取，加载任务，包括上游推送，数据库直连两种功能任务，以及存量层数据更新任务；

[0116] 2、ETL2（ODS数据标准区）任务，即ODS数据标准区数据加工任务。主要包括扩大增量层，数据标准化层的抽取，转换，加载任务；

[0117] 3、ETL3（EDW整合区）任务，即整合层数据加工任务，包括按整合层各业务主题加工，转换，更新的任务；

[0118] 4、ETL4（EDW指标标准化区）任务，即指标层数据加工任务，包括按寿险指标层，财险指标层，养老金指标的数据加工；

[0119] 5、ETL5（DM集市区）任务，即数据平台到PIMS数据抽取、加载任务，包括数据库连接抽取功能任务；

[0120] 6、ETL8历史任务，即将生成的数据归档到历史数据中。

[0121] 若按任务调度周期进行划分，则其调度任务可以包含如类型：

[0122] 1、全量任务，即系统初始化ETL加载任务；部分存量表数据加载任务（主要是一些主数据小表）；

[0123] 2、增量任务，即增量数据加载任务。

[0124] 若按任务开发工具进行划分，则其调度任务可以包含如下类型：

[0125] 1、存储过程任务，其遵循数据库开发规范，使用存储过程开发的任务，其采用PLSQL（Procedural Language Structured Query Language，面向Oracle数据库的集成开发环境）工具；

[0126] 2、Informatica（数据管理）任务，遵循调度规范，使用脚本语言开发的批处理任务，其采用Informatica工具。

[0127] 基于此，无需使用自身的程序进行产品关联数据整合、转换，所有的产品关联数据的抽取、转换、整合工作都交由已编写好的数据库程序进行定时按已设定条件进行批量处理，从而实现了产品关联数据自动化和智能化的整合，且经过整合后的产品关联数据通过前端互联网系统进行自动化和智能化转换，并可以按照统一的样式和报表等方式进行集中管理和展示，不仅保证了产品数据展示的完整性，且方便根据完整的产品数据进行数据统一加工，形成相关统计信息，极大的提高了统计信息的效率。

[0128] 在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图12所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储产品关联数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种产品信息集成处理方法。

[0129] 本领域技术人员可以理解，图12中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

[0130] 在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：

[0131] 通过ETL工具从多个源系统中抽取产品关联数据，其中，源系统包括记录了相同产品不同阶段数据源以及不同产品多个阶段数据源的多个系统；

[0132] 根据产品维度对抽取的所述产品关联数据进行清洗及整合处理，以形成统一的标准产品关联数据，所述标准产品关联数据是用于记录各产品的全貌数据；

[0133] 根据设定的产品应用模式，并采用ETL调度工具识别标准产品关联数据中的产品类别字段，以对所述标准产品关联数据进行归类，得到标准产品信息，所述标准产品信息是对所述标准产品关联数据进行归类后得到的具有类别的各产品的全貌数据的信息。

[0134] 在一个实施例中，处理器执行计算机程序时还实现以下步骤：根据设定的数据采集频率，采用ETL工具从多个源系统中抽取增量数据；根据增量数据对应的数据源对增量数据进行标识，以获得产品关联数据，其中，数据源包括数据所属的源系统以及数据在源系统中的原表名称。

[0135] 在一个实施例中，增量数据中具有对应的关键业务标识；则处理器执行计算机程序时还实现以下步骤：在采用ETL工具从多个源系统中抽取增量数据之后，根据增量数据以及对应的关键业务标识更新存量数据，并记录更新时间。

[0136] 在一个实施例中，产品关联数据中记录了对应的关键业务标识；则处理器执行计算机程序时还实现以下步骤：从产品关联数据中提取关键业务标识，根据关键业务标识的权重对提取的关键业务标识进行去重处理，得到产品关联数据的业务主键标识；通过配置的代码映射关系将产品关联数据中的业务代码转换为标准业务代码；根据产品关联数据的业务主键标识对转换为标准业务代码的产品关联数据进行整合，获得标准产品关联数据。

[0137] 在一个实施例中，产品关联数据包括对应数据源的标识；则处理器执行计算机程序时还实现以下步骤：从产品关联数据中提取关键业务标识；在关键业务标识中拼接与产品关联数据对应的数据源的标识，生成新的业务标识；根据关键业务标识的权重对新的业务标识进行去重处理。

[0138] 在一个实施例中，标准产品关联数据中包括对应的产品类别字段；则处理器执行计算机程序时还实现以下步骤：通过ETL调度工具识别标准产品关联数据对应的产品类别字段；若标准产品关联数据对应的产品类别字段中记录了产品类别信息，则将标准产品关联数据归为与产品类别信息对应的产品类别；若标准产品关联数据对应的产品类别字段为空，则获取标准产品关联数据对应的产品名称，根据产品名称对标准产品关联数据进行归类。

[0139] 在一个实施例中，处理器执行计算机程序时还实现以下步骤：识别产品名称中是否包含设定的关键字；若产品名称中包含设定的关键字，则将标准产品关联数据归为与关键字对应的设定产品类别。

[0140] 在一个实施例中，处理器执行计算机程序时还实现以下步骤：响应于第一账户对标准产品信息的备案申请操作，获取对备案申请进行审批的第二账户；向第二账户发送备案申请，其中，备案申请用于指示第二账户对备案申请进行审批；接收第二账户返回的审批结果。

[0141] 在一个实施例中，标准产品信息中包括第一产品名称；处理器执行计算机程序时还实现以下步骤：在得到标准产品信息之后，获取产品报备信息，其中，产品报备信息中包括第二产品名称；识别第一产品名称与所述第二产品名称之间的相似度；若相似度达到设定阈值，则建立第一产品名称对应的标准产品信息和第二产品名称对应的产品报备信息之间的关联关系。

[0142] 在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

[0143] 通过ETL工具从多个源系统中抽取产品关联数据，其中，源系统包括记录了相同产品不同阶段数据源以及不同产品多个阶段数据源的多个系统；

[0144] 根据产品维度对抽取的所述产品关联数据进行清洗及整合处理，以形成统一的标准产品关联数据，所述标准产品关联数据是用于记录各产品的全貌数据；

[0145] 根据设定的产品应用模式，并采用ETL调度工具识别标准产品关联数据中的产品类别字段，以对所述标准产品关联数据进行归类，得到标准产品信息，所述标准产品信息是对所述标准产品关联数据进行归类后得到的具有类别的各产品的全貌数据的信息。

[0146] 在一个实施例中，计算机程序被处理器执行时还实现以下步骤：根据设定的数据采集频率，采用ETL工具从多个源系统中抽取增量数据；根据增量数据对应的数据源对增量数据进行标识，以获得产品关联数据，其中，数据源包括数据所属的源系统以及数据在源系统中的原表名称。

[0147] 在一个实施例中，增量数据中具有对应的关键业务标识；则计算机程序被处理器执行时还实现以下步骤：在采用ETL工具从多个源系统中抽取增量数据之后，根据增量数据以及对应的关键业务标识更新存量数据，并记录更新时间。

[0148] 在一个实施例中，产品关联数据中记录了对应的关键业务标识；则计算机程序被处理器执行时还实现以下步骤：从产品关联数据中提取关键业务标识，根据关键业务标识的权重对提取的关键业务标识进行去重处理，得到产品关联数据的业务主键标识；通过配置的代码映射关系将产品关联数据中的业务代码转换为标准业务代码；根据产品关联数据的业务主键标识对转换为标准业务代码的产品关联数据进行整合，获得标准产品关联数据。

[0149] 在一个实施例中，产品关联数据包括对应数据源的标识；则计算机程序被处理器执行时还实现以下步骤：从产品关联数据中提取关键业务标识；在关键业务标识中拼接与产品关联数据对应的数据源的标识，生成新的业务标识；根据关键业务标识的权重对新的业务标识进行去重处理。

[0150] 在一个实施例中，标准产品关联数据中包括对应的产品类别字段；则计算机程序被处理器执行时还实现以下步骤：通过ETL调度工具识别标准产品关联数据对应的产品类别字段；若标准产品关联数据对应的产品类别字段中记录了产品类别信息，则将标准产品关联数据归为与产品类别信息对应的产品类别；若标准产品关联数据对应的产品类别字段为空，则获取标准产品关联数据对应的产品名称，根据产品名称对标准产品关联数据进行归类。

[0151] 在一个实施例中，计算机程序被处理器执行时还实现以下步骤：识别产品名称中是否包含设定的关键字；若产品名称中包含设定的关键字，则将标准产品关联数据归为与关键字对应的设定产品类别。

[0152] 在一个实施例中，计算机程序被处理器执行时还实现以下步骤：响应于第一账户对标准产品信息的备案申请操作，获取对备案申请进行审批的第二账户；向第二账户发送备案申请，其中，备案申请用于指示第二账户对备案申请进行审批；接收第二账户返回的审批结果。

[0153] 在一个实施例中，标准产品信息中包括第一产品名称；计算机程序被处理器执行时还实现以下步骤：在得到标准产品信息之后，获取产品报备信息，其中，产品报备信息中包括第二产品名称；识别第一产品名称与所述第二产品名称之间的相似度；若相似度达到设定阈值，则建立第一产品名称对应的标准产品信息和第二产品名称对应的产品报备信息之间的关联关系。

[0154] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器（Read-Only Memory，ROM）、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器（Random Access Memory，RAM）或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器（Static Random Access Memory，SRAM）或动态随机存取存储器（Dynamic Random Access Memory，DRAM）等。

[0155] 以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

[0156] 以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。