CN117151862A - 数据处理方法、装置、系统、设备和存储介质 - Google Patents

Abstract

本申请提供一种数据处理方法、装置、系统、设备和存储介质，可用于分布式领域。方法包括：获取信用卡调额系统的原始数据；根据原始数据的特征，将原始数据进行归类并且完成溯源处理，将原始数据加工成宽表，构建信用卡系统对应的目标数据湖；对目标数据湖中的数据进行特征工程处理，计算出信用卡调额系统中各个用户对应的特征数据，调额系统配置有预设调额模型；响应于预设调额模型的调用请求，根据调用请求中携带的业务要求，确定符合业务要求的目标特征数据；将目标特征数据返回给预设调额模型，以使预设调额模型基于目标特征数据响应用户的调额请求。本申请提高信用卡调额系统的响应速率和准确度，提高用户体验。

Description

数据处理方法、装置、系统、设备和存储介质

技术领域

本申请涉及分布式领域，尤其涉及一种数据处理方法、装置、系统、设备和存储介质。

背景技术

随着近些年传统银行业的数字换转型升级，通过线上的服务就可以完成具体银行业务的办理，在这个过程中就可以体现出一家银行对于用户体验的重视程度。在互联网时代，用户体验可以说已经成为了衡量一家公司产品好用与否的第一观测点，对业务的发展有着重要的意义。

以大型银行信用卡调额业务为例，用户在使用银行信用卡的时候，可以根据自身的实际需要进行本币或者外币或者本外币同时的升额和降额操作，来满足自身的实际用卡需求。比如用户在使用信用卡购物时发现目前的信用卡额度可能不满足自己的实际需要，就会选择进行信用卡额度升额操作，通过后台系统的判断来计算出可以升的额度，以尽量满足客户的实际用卡需求。这就要保证客户在这一阶段的用户体验，因为在实际的付款阶段，客户没有太多的时间来进行等待，如果调额不成功或者调额时间过长，不仅用户体验不好，而且可能会导致客户选择其他金融机构的支付方案，这会导致该银行未来的收入发生损失。因此，在保证符合银行风控要求的前提下，来对客户的调额申请进行实时的计算，是很有必要的。

目前的调额系统大多仍然采用传统的C/S(Client-Server，服务器-客户机)架构，通过若干互相配合的上下游系统，来大量的进行数据库的增删改查操作，以为额度的计算提供数据支持。在这个过程中，极度依赖数据库的IO(Input/Output，输入/输出)和网络带宽，而且无法满足智能调额模型对于特征数据的时效性、准确性和便捷性的需求。

发明内容

本申请提供一种数据处理方法、装置、系统、设备和存储介质，至少可以解决信用卡调额系统中调额模型对于用户特征数据的时效性、准确性和便捷性的需求的问题，提高信用卡调额系统的响应速率和准确度，提高用户体验。

第一方面，本申请提供一种数据处理方法，包括：获取信用卡调额系统的原始数据，所述原始数据包括所述信用卡调额系统的上下游数据、历史数据和新增数据中的一种或多种；根据所述原始数据的特征，将所述原始数据进行归类并且完成溯源处理，将所述原始数据加工成宽表，构建所述信用卡系统对应的目标数据湖；对所述目标数据湖中的数据进行特征工程处理，计算出所述信用卡调额系统中各个用户对应的特征数据，所述调额系统配置有预设调额模型；响应于预设调额模型的调用请求，根据所述调用请求中携带的业务要求，确定符合所述业务要求的目标特征数据；将所述目标特征数据返回给所述预设调额模型，以使所述预设调额模型基于所述目标特征数据响应用户的调额请求。

第二方面，本申请提供一种数据处理装置，包括：

获取模块，用于获取信用卡调额系统的原始数据，所述原始数据包括所述信用卡调额系统的上下游数据、历史数据和新增数据中的一种或多种；

构建模块，用于根据所述原始数据的特征，将所述原始数据进行归类并且完成溯源处理，将所述原始数据加工成宽表，构建所述信用卡系统对应的目标数据湖；

特征处理模块，用于对所述目标数据湖中的数据进行特征工程处理，计算出所述信用卡调额系统中各个用户对应的特征数据；

确定模块，用于响应于预设调额模型的调用请求，根据所述调用请求中携带的业务要求，确定符合所述业务要求的目标特征数据；

返回模块，用于将所述目标特征数据返回给所述预设调额模型，以使所述预设调额模型基于所述目标特征数据响应用户的调额请求。

第三方面，本申请实施例提供一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；

其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述电子设备执行上述任一方面所述的方法。

第四方面，本申请实施例提供一种云设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；

其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述云设备执行上述任一方面所述的方法。

第五方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现上述任一方面所述的方法。

第六方面，本申请实施例提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述任一方面所述的方法。

本申请提供的数据处理方法、装置、系统、设备和存储介质，将原有信用卡调额系统的基于关系型数据库架构的数据底座，下移到实时数据湖中，构建所述信用卡系统对应的目标数据湖，然后配合特征工程对目标数据湖中的数据进行特征计算，得到所述信用卡调额系统中各个用户对应的特征数据，当接收到信用卡调额系统中预设调额模型的调用请求时，根据调用请求中携带的业务需求，实时将符合要求的目标特征数据返回给预设调额模型，以使预设调额模型可以直接基于目标特征数据响应用户的调额请求。如此，信用卡调额系统的上下游数据都采用数据湖的方式存储，满足了信用卡调额所需数据的实时获取，结合特征工程的实时计算，在加快调额的进程的同时可以减少因为数据更新不及时和数据不规范而导致的调额模型的风控失真的情况，提高信用卡调额系统的响应速率和准确度，提高用户体验。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种电子设备的结构示意图；

图2为本申请实施例提供的一种数据处理方案的应用场景示意图；

图3为本申请实施例提供的一种数据处理系统的架构示意图；

图4为本申请实施例提供的一种数据处理方法的流程示意图；

图5为本申请实施例提供的一种数据处理装置的结构示意图；

图6为本申请实施例提供的一种云设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

本文中术语“和/或”，用于描述关联对象的关联关系，具体表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

需要说明的是，本申请数据处理方法、装置、系统、设备和存储介质可用于分布式领域，也可用于除分布式领域之外的任意领域，本申请数据处理方法、装置、系统、设备和存储介质的应用领域不做限定。

为了清楚地描述本申请实施例的技术方案，首先对本申请所涉及的名词进行释义：

C/S：Client-Server，服务器-客户机。

MySQL：是一个关系型数据库管理系统。

HDFS：Hadoop Distributed File System，分布式文件系统。

Hudi：Hadoop Updates and Incrementals，Hadoop的插入更新和增量拉取，是一种基于Hadoop的数据湖存储架构。一次Commit表示将一批数据原子性地写入一个表。

Flink：一个分布式计算框架。

Kafka：是一种高吞吐量的分布式发布订阅消息系统。

Spark：是一种通用内存并行计算框架，用于构建大型的、低延迟的数据分析应用程序。

Redis：Remote Dictionary Server，远程字典服务，是一种数据缓存装置。

TF-IDF：term frequency–inverse document frequency，是一种用于信息检索与数据挖掘的常用加权技术。

Bellman-Ford：贝尔曼-福特算法，一种求解单源最短路径问题的算法。

CDC：Change Data Capture，一种用于捕获数据库中数据变更的技术。

ETL：Extract-Transform-Load，用来描述将数据从来源端经过抽取、转换、加载至目的端的过程。

FeatHub：流批一体的实时特征工程平台。

ExpressionTransform：支持声明式的计算表达式，用户可以对特征进行加减乘除等操作。

JoinTransform：支持拼接不同Table Descriptor(表描述符)的特征，用户可以指定样本数据表和维表，以获得训练样本。

PythonUDFTransform：支持用户在FeatHub SDK(Software Development Kit，软件开发工具包)中自定义和调用Python(一种计算机语言)函数，方便熟悉Python的数据科学家进行特征开发。

SlidingWindowTransform：支持基于滑动窗口的集合计算，可以随着时间变化输出新的实时特征数据。

CPU：Central Processing Unit，中央处理器。

如图1所示，本实施例提供一种电子设备1，包括：至少一个处理器11和存储器12，图1中以一个处理器为例。处理器11和存储器12通过总线10连接。存储器12存储有可被处理器11执行的指令，指令被处理器11执行，以使电子设备1可执行下述的实施例中方法的全部或部分流程，以解决信用卡调额系统中调额模型对于用户特征数据的时效性、准确性和便捷性的需求的问题，提高信用卡调额系统的响应速率和准确度，提高用户体验。

于一实施例中，电子设备1可以是手机、平板电脑、笔记本电脑、台式计算机或者多个计算机组成的大型运算系统。

图2为本申请实施例提供的一种数据处理方案的应用场景系统200的示意图。如图2所示，该系统包括：服务器210和终端220，其中：

服务器210可以是提供金融资产数据交易请求处理服务的数据平台，比如可以是银行的信用卡调额系统的管理平台。实际场景中，一个信用卡调额系统可能有多个服务器210，图2中以1个服务器210为例。

终端220可以是用户登录信用卡调额系统时使用的电脑、手机、平板等设备，终端220也可以有多个，图2中以2个终端220为例进行示意。

终端220与服务器210之间可以通过互联网进行信息传输，以使终端220可以访问服务器210上的数据。上述终端220和/或者服务器210均可以由电子设备1来实现。

本申请实施例的数据处理方式可以应用于任意需要进行分布式数据处理的领域。

以金融系统的分布式系统领域为例，随着官方对于普惠金融政策的支持力度加大和发力发展信用卡业务的实际业务需求，越来越多的大型商业银行业加入了信用卡这个竞争白热化的个人金融领域，在这个领域中不仅要面对众多实力不容小觑的银行同业同样也要面对来势汹汹的互联网金融平台的竞争。因此，在这个竞争的背后，就是比拼特色业务能力、服务水平、优惠政策和用户体验等几个方面所展现出来的综合实力。对于业务能力、服务水平和优惠政策几个方面来说，主要是根据所属银行的具体特性、专业能力和资金倾斜角度来谈。随着近些年传统银行业的数字换转型升级，通过线上的服务就可以完成具体银行业务的办理，在这个过程中就可以体现出一家银行对于用户体验的重视程度。在互联网时代，用户体验可以说已经成为了衡量一家公司产品好用与否的第一观测点，对业务的发展有着重要的意义。

以大型银行信用卡调额业务为例，信用卡调额业务就是一个影响用户体验的重要窗口，用户在使用银行信用卡的时候，可以根据自身的实际需要进行本币或者外币或者本外币同时的升额和降额操作，来满足自身的实际用卡需求。比如用户在使用信用卡购物时，发现目前的信用卡额度可能不满足自己的实际需要，就会选择进行信用卡额度升额操作，银行通过后台信用卡调额系统的来计算出该用户可以升的额度，以尽量满足用户的实际用卡需求。这就要保证用户在这一阶段的用户体验。实际的信用卡支付场景中，用户一般没有太多的时间来进行等待，如果调额系统调额不成功或者调额响应时间过长，可能会导致用户选择其他金融平台的支付方案，从而失去用户流。因此，在保证符合银行风控要求的前提下，来对用户的调额申请进行实时的计算，及时响应是很有必要的。

目前的调额系统大多仍然采用传统的C/S架构，通过若干互相配合的上下游系统来大量的进行数据库的增删改查操作，以为额度的计算提供数据支持。在这个过程中，极度依赖数据库的IO和网络带宽，同时不满足智能调额模型对于特征数据的时效性、准确性和便捷性的需求。

针对上述问题，在相关技术中，为了满足不同的业务需求，在向调额系统提供数据之前，对于数据的处理可以分为时效性高的数据链路和时效性低的数据链路，对于时效性较高的链路而言使用的是Kafka+Flink的策略，对于时效性较低的链路而言使用的是Spark离线策略。时效性高的数据会通过Kafka+Flink进行流式计算。时效性低的数据通过Spark+HDFS进行批计算，最后出仓到MySQL、Redis或Kafka等的介质中。然而，在相关信用卡调额系统中所使用的数据主要来自于经过低失效性链路导入到MySQL中的数据。对于上述的数加工和使用的策略，存在一些根本的问题。问题如下：

1)信用卡调额系统所使用的是低时效数据，离线批量计算的时间频率通常为天、周或月等。无法满足实时的调额模型和风控希望达到的秒级或者分钟级的计算要求。为了满足实时计算的要求，相关技术中，有些业务流程可以在原有的数据仓库上来新增实时链路。

2)但是新增的实时链路通常观测性较弱，由于Kafka的查数不便性，因此需要将数据迁移到其他的存储介质中来进行查询，就会造成很大的时间延迟和不便性。实时数据链路普遍不容易和业务时间对齐，难以准确定位到需要重跑的起点。如果数据出现异常，业务一般不会选择在实时流上进行重跑，而是进行离线链路的T-1(第二天)修复。

3)对于实时和离线两条数据链路而言，会增加数据口径统一和运维的相关成本。

4)由于批流一体的数据底座，数据处理的主要任务还是会落在批量上面，因此在业务非高峰期，比如凌晨的时候会出现计算资源的高峰，会存在任务排队现象，在这个过程中会对实时的任务产生一些不良影响。

为了解决上述问题，本申请实施例提供一种数据处理方案，将原有信用卡调额系统的基于关系型数据库架构的数据底座，下移到实时数据湖中，构建信用卡系统对应的目标数据湖，然后配合特征工程对目标数据湖中的数据进行特征计算，得到信用卡调额系统中各个用户对应的特征数据，当接收到信用卡调额系统中预设调额模型的调用请求时，根据调用请求中携带的业务需求，实时将符合要求的目标特征数据返回给预设调额模型，以使预设调额模型可以直接基于目标特征数据响应用户的调额请求。如此，信用卡调额系统的上下游数据都采用数据湖的方式存储，满足了信用卡调额所需数据的实时获取，结合特征工程的实时计算，在加快调额的进程的同时可以减少因为数据更新不及时和数据不规范而导致的调额模型的风控失真的情况，提高信用卡调额系统的响应速率和准确度，提高用户体验。

以原有基于MySQL等关系型数据库架构的信用卡调额系统为例，本申请实施例提供一种基于Flink和Hudi的大型银行信用卡调额实时数据湖与特征工程系统，将原有系统的基于MySQL等关系型数据库架构的数据底座，下移到实时数据湖中，同时配合实时计算特征工程，从而满足信用卡调额所需数据的实时获取与特征工程的实时计算，在加快调额的进程的同时可以减少因为数据更新不及时和数据不规范而导致的调额计算模型的风控失真的情况。

本申请实施例的系统可以提升大型银行对于信用卡调额业务的数据更新速度、响应速度和调额风控的有效性，可以突破原有C/S架构下，众多上下游系统使用MySQL等传统数据库所带来的业务高峰期的性能瓶颈、数据存在不一致和数据存在滞后性的现象。在这样的数据密集型的实时应用场景中，特别是涉及复杂的上下游系统同时运算的系统，业务不仅要计算数据结果，而且要保障数据时效性。

如图3所示，为本申请实施例提供的一种数据处理系统300的架构示意图，该系统300可以包括：数据湖、特征工程系统和调额系统，以信用卡调额业务场景为例，其中：

数据湖，用于将行信用卡调额业务需要的原有上下游系统的原始数据进行入湖处理，并实时存储信用卡调额业务需要的用户数据和更新数据。

特征工程模块，用于根据数据湖中的数据，实时计算信用卡调额业务所需要的用户特征数据。

调额系统，可以是信用卡调额系统，可以配置有智能的信用卡调额模型，当接收到某个用户的调额请求时，调额模型可以向特征工程模块直接调用本次调额操作所需要的用户特征数据，以及时响应用户的调额请求。

于一实施例中，调额系统还可以包括风控模型，风控模型可以调用特征模型模块的用户数据，用于对本次调额操作进行风险评估与控制，以保证调额交易的安全性。

下面以一种基于Flink和Hudi的大型银行信用卡调额实时数据湖与特征工程系统的设计和实现为例进行说明：

数据处理系统300可以是基于Flink和Hudi的信用卡调额实时数据湖与特征工程系统，可以应用于大型银行的信用卡调额业务，其核心设计是实现实时数据湖的构建以及对其的应用，以便提升信用卡调额的实时性从而提高用户体验。在构建的过程中，需要将信用卡调额上下游系统所用到的所有数据入湖并进行实时的更新和增量追加，从而更好的为调额数据业务应用场景服务。为了实现基于Flink和Hudi的大型银行信用卡调额实时数据湖与特征工程系统，技术人员需要对于之前原有的数据底座有一定的了解，以及对Flink和Hudi如何构建实时数据湖和原有系统上下游流程有一定的了解。综合上文，可以将本次的系统主要分为三大类，分为数据库数据入湖、实时数据特征计算和实时数据应用部分。以大型商业银行的信用卡调额业务为例，在使用本系统之前需要进行如下操作：

1)大型商业银行的信用卡调额专用实时数据湖的创建。

2)大型商业银行的信用卡调额专用实时特征工程系统的创建。

然后进行如下过程：

3)使用实时入湖存储。

4)使用实时数据特征计算。

5)使用实时的数据应用。

下面结合附图，对本申请的一些实施方式作详细说明。在各实施例之间不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

请参看图4，其为本申请一实施例的数据处理方法，该方法可由图1所示的电子设备1来执行，并可以应用于图2至图3中所示的数据处理的应用场景中，以解决信用卡调额系统中调额模型对于用户特征数据的时效性、准确性和便捷性的需求的问题，提高信用卡调额系统的响应速率和准确度，提高用户体验。本实施例以图2中所示的服务器为执行端为例，该方法包括如下步骤：

步骤401：获取信用卡调额系统的原始数据，原始数据包括信用卡调额系统的上下游数据、历史数据和新增数据中的一种或多种。

在本步骤中，原始数据是指信用卡调额业务所需的数据，可以包括信用卡调额系统的上下游数据、历史数据和新增数据中的一种或多种。以信用卡调额业务为例，原始数据的内容具体可以包括信用卡发卡数据、信用卡审批数据、银行征信报告数据、社保数据、公积金数据、税务数据、法律相关数据、持牌负面数据等。

步骤402：根据原始数据的特征，将原始数据进行归类并且完成溯源处理，将原始数据加工成宽表，构建信用卡系统对应的目标数据湖。

在本步骤中，使用实时入湖存储，根据数据库数据的特征进行归类并且完成溯源处理，根据数据供应方提供的原始数据加工成宽表，并且可以使用Flink CDC将历史数据和新增数据追加到Hudi中构建成数据湖。对于信用卡调额系统而言，原始数据大都存放在MySQL或Oracle数据库中，需要将原始数据整体迁移到数据湖中，在这个过程中会产生大量的名称不一致但是功能相近的表，首先要对这些表进行溯源处理，来实现数据宽表处理，并做实时的追增处理。以前述图3中基于Flink和Hudi的大型银行信用卡调额实时数据湖与特征工程系统的设计和实现场景为例，首先使数据库数据入湖：可以使用Flink、Hudi和FeatHub三者的特点来将企业原始的数据底座进行实时化改造，根据信用卡调额业务中需要的原始数据的特征，将原始数据进行归类并且完成溯源处理，将原始数据加工成宽表，构建信用卡系统对应的目标数据湖。通过将原有的以天或周或月为粒度的数据转为秒级和分钟级数据更新频率，来实现实时的计算。从而实现信用卡调额实时业务的用户体验提升。

于一实施例中，步骤402具体可以包括：抽取原始数据中各个数据表的关键信息。根据关键信息在各个数据表中进行全文匹配，筛选出与关键信息匹配度超过预设阈值的目标数据表。对目标数据表进行溯源处理，得到信用卡调额系统的上游数据仓库的数据传播链路。根据数据传播链路对应的规范信息和上游数据仓库的层确定对应的数据接口，得到原始数据的宽表，构建信用卡系统对应的目标数据湖。

在本实施例中，以前述图3中基于Flink和Hudi的信用卡调额实时数据湖与特征工程系统的场景为例，对于步骤402这部分的实现主要可以分为三步：

第一步：为关键信息的抽取，就是利用数据库中的数据的元数据，提取每个数据表所对应的关键词，具体的，可以将需要使用到表名按照一定格式进行分割、使用TF-IDF方法进行表名关键词的提取，经过分割和TF-IDF方法处理之后，会得到每个数表的关键信息。

第二步：筛选，通过将提取出来的关键信息存放到ElasticSearch(搜索服务器)中，来在各个数据表中进行全文匹配，将关键信息匹配度高于预设阈值的目标数据表，此处预设阈值可以基于实际需求设定，目标数据表可以为一个或多个。

第三步，溯源处理，将筛选出来的目标数据表进行溯源，可以使用Bellman-Ford算法来获取上游数据仓库中的数据传播链路。

于一实施例中，对目标数据表进行溯源处理，得到信用卡调额系统的上游数据仓库的数据传播链路，具体可以包括：从上游数据仓库的贴源层到汇总层，比较不同数据节点之间的距离向量，确定上游数据仓库中存在最小路径集合。对最小路径集合进行筛选，将最小路径集合中包含的数据节点数小于或等于预设数量的第一链路剔除。将最小路径集合中包含的数据节点数大于预设数量的第二链路之间进行比较，将第二链路中重复的链路从最小路径集合中去重剔除。如果第二链路中存在具备包含关系的第一子链路和第二子链路，其中第一子链路为包含第二子链路的分叉链路，将第一子链路拆分成单线链路，单线链路进行去重处理，得到最终的数据传播链路。

本实施例中，对于一个真实存在的数据传播链路，其是有一定的存在规律的，可以从数据仓库的贴源层到汇总层使用Bellman-Ford算法。也就是通过比较不同数据节点之间的距离向量来进行判断，因为在数据仓库中有相应血缘关系的数据表在前后是存在一定的关系的，也就表现在经过向量化之后的相应表会存在一定数字上的关系，可以方便进行两点之间的向量化。使用Bellman-Ford方法可以在形成网状的数据仓库数据表中发现存在的一个或多个最小路径构成的最小路径集合。在得到整个数据仓库数据表网络中的最小路径集合之后，需要进行筛选，如果某个最小路径1中的数据节点数小于等于3，则在最小路径集合中将最小路径1进行剔除。另一方面，数据节点数大于3的第二链路之间需要进行匹配，查看是否存在相同或者是包含的关系，如果两个存在两个链路相同，说明重复了，则进行去重，将重复多余的一个第二链路剔除。如果是存在包含关系，比如第一子链路的节点关系为：第二子链路的节点关系为：A-B-C，可见，第一子链路包含第一子链路的全部节点路径，则按照包含部分，将第一子链路拆分为单线链路，分别为链路1：A-B-C-D和链路2：A-B-C-E，然后将链路1和链路2与其他的最小路径一起进行去重处理，得到最终的数据传播链路。数据传播路径中均为不重复的单线链路。

第四步：溯源处理后，从信用卡调额系统上游数据仓库的贴源层到汇总层可以得到一个个截断的数据传播链路。然后基于数据传播链路和在贴源层到汇总层之前存在的规范，按照上游数据仓库的层来进行接口设计，从而获取到原始数据的宽表，构建信用卡系统对应的目标数据湖。

于一实施例中，步骤402中构建信用卡系统对应的目标数据湖，还包括：为目标数据湖添加预设过滤条件，预设过滤条件用于在响应数据访问时，过滤掉目标数据湖中对应的响应数据。

在本实施例中，在构建目标数据湖时，对于信用卡调额系统已存在的历史数据可以直接使用Flink CDC写入Hudi，对于新增数据同样也使用Flink CDC写入Hudi中，从而满足时效性的诉求。

于一实施例中，由于Hudi的数据实时更新，不具备可重复读的能力。因此无法满足ETL场景。即使使用Hudi"快照读"的能力。虽然可以读取Hudi的历史的Commit，获取一份某一时刻的快照数据。但如果长时间的保留Commit数据，会导致文件过多，会影响访问timeline的性能，进而影响到Hudi的读写性能。此外通过Flink增量写Hudi时，会周期性的产生Commit，无法控制业务时间和Commit对齐。如果昨天和今天的数据落在同一个Commit里，Savepoint会以Commit为最小力度。当访问昨天的Savepoint时，它会包含今天的数据，与用户的预期不符。因此在这一过程中可以使用Hudi Snapshot View(Hudi快照视图)来解决上述问题，在Flink导入Hudi数据方案中是可以加预设的过滤条件，将第二天的数据过滤出去。可以把预设过滤条件逻辑纳入到Hudi快照视图中。在快照视图里将过滤逻辑，做在Hudi底层，存储在Hudi Meta中。在访问快照视图时，系统会吐出过滤后的数据，从而解决快照里存在跨天数据的问题。此外，快照视图同样是存储元数据，通过映射的方式，访问实际的数据文件，不存在数据冗余存储的问题。也同时满足实时和离线场景，实现了流批统一。除此之外，快照视图是独立切出了一个timeline(时间轴)，支持再做Compaction(压实)、Clustering(聚类)等操作来加速查询。这就实现了Flink timeline和Hudi的有机结合，可以实现数据的实时动态追加入湖。

步骤403：对目标数据湖中的数据进行特征工程处理，计算出信用卡调额系统中各个用户对应的特征数据，调额系统配置有预设调额模型。

在本步骤中，使用实时数据特征计算，使用目标数据湖中的实时数据，根据具体的业务要求来使用Flink高效加工出信用卡调额系统中各个用户所需的特征数据，以供预设调额模型和/或风控模型使用。

于一实施例中，对目标数据湖中的数据进行特征工程处理，计算出信用卡调额系统中各个用户对应的特征数据，包括：采用本地计算方式，计算出信用卡调额系统中各个用户对应的特征数据，本地存储特征数据。和/或，采用分布式计算方式，计算出信用卡调额系统中各个用户对应的特征数据，在线存储特征数据。和/或，采用离线计算方式，计算出信用卡调额系统中各个用户对应的特征数据，离线存储特征数据。

在本实施例中，通过步骤402,可以实现使用Flink和Hudi的数据实时入湖操作，在本步骤中，可以使用流批一体的实时特征工程平台实现特征计算，比如可以使用FeatHub来进行特征的实时计算，以供调额和风控模型使用。FeatHub存在三种计算模式，分别为LocalProcessor(本地处理器)、Flink Processor(基于Flink框架的处理器)和Spark Processor(基于Spark框架的处理器)。其中Local Processor支持用户在单机上利用CPU、磁盘等资源计算特征，以方便用户在单机上完成实验。Flink Processor可以将用户的特征定义翻译成Flink作业，在高可用性、分布式的集群环境中进行低延迟、高吞吐的特征计算。SparkProcessor则可以将用户的特征定义翻译成Spark作业，支持用户使用Spark执行高吞吐的离线特征计算。在执行引擎之下是特征的存储，包括离线存储(例如HDFS)、流式存储(例如Kafka)和在线存储(例如Redis)。

于一实施例中，可以使用Flink Processor来实现特征的实时计算，同时将计算出的特征数据结果存储到在线存储Redis中。之后编写声明式的特征定义，指定特征的数据源和目标存储位置，以及特征计算逻辑。在实际的特征计算逻辑中，可以使用ExpressionTransform、JoinTransform和SlidingWindowTransform来对存储在Hudi中的数据表进行数据的操作，从而得到可以满足特征计算的数据要求，最后通过PythonUDFTransform来完成不同业务规则的特征实现，存储到redis中来供调额模型和/或风控模型的使用。

于一实施例中，在步骤403之后还可以包括：根据目标数据湖和业务需求配置信用卡调额系统的数据接口，以使信用卡调额系统的数据源配适目标数据湖中的宽表。

在本实施例中，对于所有涉及到数据库操作的信用卡调额系统而言，需要将原有的数据源进行替换处理，通过根据实际的业务逻辑所使用到的原有数据表，来重新设计接口，以配适使用存储在Hudi中的宽表。使用实时的数据应用，将存在Hudi中的数据进行使用，在这个过程之前对系统进行改造，创建不同分系统特有的数据接口，从而以使整个信用卡调额业务上下游共用一套数据来源，方便维护和问题排查。

于一实施例中，在构建了目标数据湖之后，还可以包括：接收信用卡调额系统的更新数据，根据更新数据，更新目标数据湖。

在本实施例中，可以使用Flink CDC来与上游供数的数据平台来对接，通过实时的数据接收并更新到Hudi中，来实时同步整个应用上下游的数据供应，从而保证全局数据的一致性，排除了因为前后系统的数据不一致，或者数据表结构设计不一致而导致的系统故障，最重要的一点是实时的更新数据，并且所有系统直接从Hudi中实时取数，会节省全流程很多的数据库IO操作，从而可以节省时间来提升系统的响应速率。

步骤404：响应于预设调额模型的调用请求，根据调用请求中携带的业务要求，确定符合业务要求的目标特征数据。

在本步骤中，当用户在调额系统提交信用卡调额请求时，调额系统中的预设调额模型可以根据业务需求直接调用步骤403中计算出来的特征数据，系统在接收到调用请求时，响应于该调用请求，根据调用请求中携带的业务要求，确定符合业务要求的目标特征数据，不需要调额模型自己计算特征数据，可以将整体的调额流程时间缩短提升用户体验。

在可选实施例中，调用请求也可以是风控模型发出的。

步骤405：将目标特征数据返回给预设调额模型，以使预设调额模型基于目标特征数据响应用户的调额请求。

在本步骤中，系统将符合业务要求的目标特征数据返回给预设调额模型，以便于调额模型根据目标特征数据进行计算，并响应用户的调额请求。如果调用请求是风控模型发出的，则将目标特征数据返回给对应的风控模型，以使风控模型根据目标特征数据对本次用户的调额请求进行风险评估。

对于调额模型和/或风控模型，可以将步骤403计算出来的对应特征数据直接提取出来，导入到对应的模型中进行计算，节省了从头到尾加工数据计算数据的过程。并且实时的特征数据，可以更好地的反应出数据的真实性，可以更好的提供真实的信息，此外特征数据单独存储在Redis中，可以提供很好的性能，按照一定的时间粒度来进行更新，可以会更好的为信用卡调额系统服务。

上述数据处理方法，提出了通过使用基于大型银行信用卡调额的实时数据湖的解决方案，主要包含三个模块，分别为数据库数据入湖、实时数据特征计算和实时数据应用部分。这三个模块串行工作，数据库数据入湖实现数据的实时入湖存储，实时数据特征计算通过模型的设计来实时计算出特征信息，实时数据应用将实时的数据应用到调额系统中去。

通过使用Flink+Hudi来实现增量数据以及相应的增量计算数据结果存储在Hudi中，可以支持秒级和分钟级的数据计算。再根据Hudi的流表二象性，在可以满足实时的数据流式增量消费的同时也可以作为表来直接进行查询。同样，可以满足批量的要求，也就是同时满足实时和离线的计算要求，使用一个数据底座完成了两套功能。通过既有的增量计算的能力，将原本在非业务高峰所进行的可以影响实时计算的批量任务可以被在分配数据资源的时候进行细分，分摊到全天来进行，实现错峰的计算资源使用。通过使用Hudi表的排序、索引和物化等的功能，可以直接查询Hudi表中的数据，从而达到数据不出仓的效果。因此在之后使用计算调额特征的时候可以直接通过Hudi提取数据来达到实时的效果来满足实时调额和风控模型的需求。

将现有的应用系统进行改造，将涉及信用卡调额的全部上下游系统的数据接口从之前的MySQL或Oracle(Oracle Database，Oracle数据库)替换到Hudi上面，进行相应的数据迁移之后，实时接入Hudi，从而可以真正实现秒级的数据应用需要，同时也可以真正发挥调额和实时风控的作用。实现信用卡调额系统全流程的数据实时存储和计算和应用，来降低系统的运行时间提高系统的响应效率，增强客户体验。

具体地，本申请实施例提出的基于Flink和Hudi的大型银行信用卡调额实时数据湖与特征工程系统，至少具备如下优点：

1)减轻企业做整体数据架构的成本：该方案可以将原本的批流一体的架构整体平移到流式架构中，使用一套环境实现之前多套环境才能完成的计算任务。可以帮助企业节省硬件资源和运维成本。同时应用系统直连可以节省大量的系统数据库应用需求，为企业的达到降本增效的效果。

2)降低业务开发的成本：该方案，将涉及到信用卡调额的上下游系统使用同一个数据湖中的数据，可以减少各自使用原有数据库时所产生的数据口径不统一的问题，从根本上解决了数据表因为业务逻辑的调整而导致整个信用卡调额上下游系统均需要修改的问题。因此减少了业务开发过程中重复造轮子的人力和资源。

3)提高系统响应敏捷度：该方案可以提高系统响应敏捷度，也就是提高数据的实时响应能力，可以减少使用数据的时间、可以提高数据的实时性和提高模型的特征工程的实时性。

请参看图5，其为本申请一实施例的数据处理装置，该装置可应用于图1所示的电子设备1。并可以应用于图2至图3中所示的数据处理的应用场景中，以解决信用卡调额系统中调额模型对于用户特征数据的时效性、准确性和便捷性的需求的问题，提高信用卡调额系统的响应速率和准确度，提高用户体验。该装置包括：获取模块、构建模块、特征处理模块、确定模块和返回模块，各个模块的功能原理如下：

获取模块，用于获取信用卡调额系统的原始数据，原始数据包括信用卡调额系统的上下游数据、历史数据和新增数据中的一种或多种。

构建模块，用于根据原始数据的特征，将原始数据进行归类并且完成溯源处理，将原始数据加工成宽表，构建信用卡系统对应的目标数据湖。

特征处理模块，用于对目标数据湖中的数据进行特征工程处理，计算出信用卡调额系统中各个用户对应的特征数据。

确定模块，用于响应于预设调额模型的调用请求，根据调用请求中携带的业务要求，确定符合业务要求的目标特征数据。

返回模块，用于将目标特征数据返回给预设调额模型，以使预设调额模型基于目标特征数据响应用户的调额请求。

于一实施例中，构建模块，具体用于抽取原始数据中各个数据表的关键信息。根据关键信息在各个数据表中进行全文匹配，筛选出与关键信息匹配度超过预设阈值的目标数据表。对目标数据表进行溯源处理，得到信用卡调额系统的上游数据仓库的数据传播链路。根据数据传播链路对应的规范信息和上游数据仓库的层确定对应的数据接口，得到原始数据的宽表，构建信用卡系统对应的目标数据湖。

于一实施例中，构建模块，具体用于从上游数据仓库的贴源层到汇总层，比较不同数据节点之间的距离向量，确定上游数据仓库中存在最小路径集合。对最小路径集合进行筛选，将最小路径集合中包含的数据节点数小于或等于预设数量的第一链路剔除。将最小路径集合中包含的数据节点数大于预设数量的第二链路之间进行比较，将第二链路中重复的链路从最小路径集合中去重剔除。如果第二链路中存在具备包含关系的第一子链路和第二子链路，其中第一子链路为包含第二子链路的分叉链路，将第一子链路拆分成单线链路，单线链路进行去重处理，得到最终的数据传播链路。

于一实施例中，构建模块，还用于为目标数据湖添加预设过滤条件，预设过滤条件用于在响应数据访问时，过滤掉目标数据湖中对应的响应数据。

于一实施例中，特征处理模块，用于对目标数据湖中的数据进行特征工程处理，计算出信用卡调额系统中各个用户对应的特征数据，包括：采用本地计算方式，计算出信用卡调额系统中各个用户对应的特征数据，本地存储特征数据。和/或，采用分布式计算方式，计算出信用卡调额系统中各个用户对应的特征数据，在线存储特征数据。和/或，采用离线计算方式，计算出信用卡调额系统中各个用户对应的特征数据，离线存储特征数据。

于一实施例中，还包括：配置模块，用于在对目标数据湖中的数据进行特征工程处理，计算出信用卡调额系统中各个用户对应的特征数据之后，根据目标数据湖和业务需求配置信用卡调额系统的数据接口，以使信用卡调额系统的数据源配适目标数据湖中的宽表。

于一实施例中，还包括：更新模块，用于接收信用卡调额系统的更新数据，根据更新数据，更新目标数据湖。

上述数据处理装置的详细描述，请参见上述实施例中相关方法步骤的描述，其实现原理和技术效果类似，本实施例此处不再赘述。

图6为本申请示例性实施例提供的一种云设备60的结构示意图。该云设备60可以用于运行上述任一实施例所提供的方法。如图6所示，该云设备60可以包括：存储器604和至少一个处理器605，图6中以一个处理器为例。

存储器604，用于存储计算机程序，并可被配置为存储其它各种数据以支持在云设备60上的操作。该存储器604可以是对象存储(Object Storage Service，OSS)。

存储器604可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器605，与存储器604耦合，用于执行存储器604中的计算机程序，以用于实现上述任一方法实施例所提供的方案，具体功能和所能实现的技术效果此处不再赘述。

进一步地，如图6，该云设备还包括：防火墙601、负载均衡器602、通信组件606、电源组件603等其它组件。图6中仅示意性给出部分组件，并不意味着云设备只包括图6所示组件。

于一实施例中，上述图6中的通信组件606被配置为便于通信组件606所在设备和其他设备之间有线或无线方式的通信。通信组件606所在设备可以接入基于通信标准的无线网络，如WiFi，2G、3G、4G、LTE(Long Term Evolution，长期演进，简称LTE)、5G等移动通信网络，或它们的组合。在一个示例性实施例中，通信组件606经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件606还包括近场通信(Near Field Communication，简称NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(Radio Frequency Identification，简称RFID)技术，红外数据协会(InfraredData Association，简称IrDA)技术，超宽带(Ultra Wide Band，简称UWB)技术，蓝牙(bluetooth，简称BT)技术和其他技术来实现。

于一实施例中，上述图6的电源组件603，为电源组件603所在设备的各种组件提供电力。电源组件603可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当处理器执行计算机执行指令时，实现前述任一实施例的方法。

本申请实施例还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现前述任一实施例的方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例方法的部分步骤。

应理解，上述处理器可以是中央处理单元(Central Processing Unit，简称CPU)，还可以是其它通用处理器、数字信号处理器(Digital Signal Processor，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。存储器可能包含高速RAM(Random Access Memory，随机存取存储器)存储器，也可能还包括非易失性存储NVM(Nonvolatile memory，简称NVM)，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(Static Random-Access Memory，简称SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable read only memory，简称EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，可编程只读存储器(Programmable read-only memory，简称PROM)，只读存储器(Read-OnlyMemory，简称ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例的方法。

本申请的技术方案中，所涉及的用户数据等信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (10)

1.一种数据处理方法，其特征在于，包括：

获取信用卡调额系统的原始数据，所述原始数据包括所述信用卡调额系统的上下游数据、历史数据和新增数据中的一种或多种；

根据所述原始数据的特征，将所述原始数据进行归类并且完成溯源处理，将所述原始数据加工成宽表，构建所述信用卡系统对应的目标数据湖；

对所述目标数据湖中的数据进行特征工程处理，计算出所述信用卡调额系统中各个用户对应的特征数据，所述调额系统配置有预设调额模型；

响应于预设调额模型的调用请求，根据所述调用请求中携带的业务要求，确定符合所述业务要求的目标特征数据；

将所述目标特征数据返回给所述预设调额模型，以使所述预设调额模型基于所述目标特征数据响应用户的调额请求。

2.根据权利要求1所述的方法，其特征在于，所述根据所述原始数据的特征，将所述原始数据进行归类并且完成溯源处理，将所述原始数据加工成宽表，构建所述信用卡系统对应的目标数据湖，包括：

抽取所述原始数据中各个数据表的关键信息；

根据所述关键信息在所述各个数据表中进行全文匹配，筛选出与所述关键信息匹配度超过预设阈值的目标数据表；

对所述目标数据表进行溯源处理，得到所述信用卡调额系统的上游数据仓库的数据传播链路；

根据所述数据传播链路对应的规范信息和所述上游数据仓库的层确定对应的数据接口，得到所述原始数据的宽表，构建所述信用卡系统对应的目标数据湖。

3.根据权利要求2所述的方法，其特征在于，所述对所述目标数据表进行溯源处理，得到所述信用卡调额系统的上游数据仓库的数据传播链路，包括：

从所述上游数据仓库的贴源层到汇总层，比较不同数据节点之间的距离向量，确定所述上游数据仓库中存在最小路径集合；

对所述最小路径集合进行筛选，将所述最小路径集合中包含的数据节点数小于或等于预设数量的第一链路剔除；

将所述最小路径集合中包含的数据节点数大于所述预设数量的第二链路之间进行比较，将所述第二链路中重复的链路从所述最小路径集合中去重剔除；

如果所述第二链路中存在具备包含关系的第一子链路和第二子链路，其中第一子链路为包含所述第二子链路的分叉链路，将所述第一子链路拆分成单线链路，单线链路进行去重处理，得到最终的所述数据传播链路。

4.根据权利要求1所述的方法，其特征在于，所述构建所述信用卡系统对应的目标数据湖，还包括：

为所述目标数据湖添加预设过滤条件，所述预设过滤条件用于在响应数据访问时，过滤掉所述目标数据湖中对应的响应数据。

5.根据权利要求1所述的方法，其特征在于，所述对所述目标数据湖中的数据进行特征工程处理，计算出所述信用卡调额系统中各个用户对应的特征数据，包括：

采用本地计算方式，计算出所述信用卡调额系统中各个用户对应的特征数据，本地存储所述特征数据；

和/或，采用分布式计算方式，计算出所述信用卡调额系统中各个用户对应的特征数据，在线存储所述特征数据；

和/或，采用离线计算方式，计算出所述信用卡调额系统中各个用户对应的特征数据，离线存储所述特征数据。

6.根据权利要求1所述的方法，其特征在于，在所述对所述目标数据湖中的数据进行特征工程处理，计算出所述信用卡调额系统中各个用户对应的特征数据之后，还包括：

根据所述目标数据湖和业务需求配置所述信用卡调额系统的数据接口，以使所述信用卡调额系统的数据源配适所述目标数据湖中的宽表。

7.根据权利要求1所述的方法，其特征在于，还包括：

接收所述信用卡调额系统的更新数据，根据所述更新数据，更新所述目标数据湖。

8.一种数据处理装置，其特征在于，所述装置包括：

获取模块，用于获取信用卡调额系统的原始数据，所述原始数据包括所述信用卡调额系统的上下游数据、历史数据和新增数据中的一种或多种；

构建模块，用于根据所述原始数据的特征，将所述原始数据进行归类并且完成溯源处理，将所述原始数据加工成宽表，构建所述信用卡系统对应的目标数据湖；

特征处理模块，用于对所述目标数据湖中的数据进行特征工程处理，计算出所述信用卡调额系统中各个用户对应的特征数据；

确定模块，用于响应于预设调额模型的调用请求，根据所述调用请求中携带的业务要求，确定符合所述业务要求的目标特征数据；

返回模块，用于将所述目标特征数据返回给所述预设调额模型，以使所述预设调额模型基于所述目标特征数据响应用户的调额请求。

9.一种电子设备，其特征在于，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1至6任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至6任一项所述的方法。