CN114036159A - 银行业务信息更新方法和系统 - Google Patents

Abstract

本申请涉及一种银行业务信息更新方法和系统。所述方法包括：采集用户基于交互平台触发的用户行为数据；对用户行为数据进行数据清洗并整合，得到用户事件数据；根据用户事件数据，更新当前用户信息以及当前营销模型。采用本方法能够不仅满足原有SOA架构的系统中，通过较为刚性的接口连接的系统架构，仅传输预设接口对应的交易数据等，还能够对用户基于交互平台产程的不同用户行为数据实时的更新，以便实时更新用户信息，避免了银行业务系统的数据之间是相对独立的，每个业务系统拥有单独的功能组件和数据集市，系统间的彼此隔离。满足不同业务场景中系统间的信息交互的需求。避免数据积累出现孤岛化、无序化。

Description

银行业务信息更新方法和系统

技术领域

本申请涉及金融技术领域，特别是涉及一种银行业务信息更新方法和系统。

背景技术

随着金融领域技术的发展，越来越多的银行业务可以基于银行业务信息系统完成。银行业务信息系统主流设计是面向服务架构(Service-Oriented Architecture，SOA)。

在SOA架构中，所有银行的业务功能、基础功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成银行业务流程，对客户提供金融服务。

然而，目前的银行业务信息系统，存在无法实时根据用户行为数据更新用户信息并提供相应营销策略的问题。

发明内容

基于此，有必要针对上述技术问题，提供一种能够根据用户行为数据更新用户信息并提供相应营销策略的银行业务信息更新方法和系统。

第一方面，本申请提供了一种银行业务信息更新方法。该方法包括：

采集用户基于交互平台触发的用户行为数据；

对用户行为数据进行数据清洗并整合，得到用户事件数据；

根据用户事件数据，更新当前用户信息以及当前营销模型。

在其中一个实施例中，根据用户事件数据，更新当前的用户信息以及当前营销模型，包括：

根据用户事件数据，生成事件订阅信息；

根据事件订阅信息，更新当前的用户信息以及当前营销模型。

在其中一个实施例中，用户信息包括：用户标签；根据事件订阅信息，更新当前用户信息以及当前营销模型，包括：

将事件订阅信息输入至当前营销模型中进行迭代更新，直到达到预设迭代次数，确定目标营销模型；

根据事件订阅信息中的用户标签更新用户信息中的用户标签。

在其中一个实施例中，该方法还包括：

将事件订阅信息输入至目标营销模型中，得到营销服务信息并发送至用户设备。

在其中一个实施例中，用户行为数据包括：用户下单事件数据；方法还包括：

对用户下单事件数据进行统计和处理，生成多维营销数据信息，并将多维营销数据信息传输至企业管理设备。

第二方面，本申请提供了一种银行业务信息更新系统，该系统包括：交互层、中枢层、基础层；

交互层，用于采集用户基于交互平台触发的用户行为数据并将用户行为数据传输至基础层中；

基础层，用于对用户行为数据进行数据清洗并整合，得到用户事件数据，根据用户事件数据生成事件订阅信息，并发布事件订阅信息至中枢层；

中枢层，用于根据事件订阅信息，更新当前的用户信息以及当前营销模型。

在其中一个实施例中，基础层包括：金融核心平台和数据平台；

金融核心平台，用于获取用户行为数据生成用户事件数据，并将用户事件数据传输至事件平台；

数据平台，用于根据用户事件数据进行数据清洗并整合，发布事件订阅信息至中枢层。

在其中一个实施例中，用户信息包括用户标签；中枢层包括：数据中台；

数据中台，用于根据事件订阅信息对当前营销模型进行迭代更新，直到达到预设迭代次数，确定目标营销模型；

数据中台，还用于根据事件订阅信息中的用户标签更新用户信息中的用户标签，并将更新后的用户标签传输至数据平台。

在其中一个实施例中，中枢层，还包括：业务中台；

业务中台，用于将数据平台发送的事件订阅信息输入至数据中台部署的目标营销模型中，得到营销服务信息，并将营销服务信息发送至用户设备。

在其中一个实施例中，中枢层还包括：智能服务中台和用户体验中台；

数据平台，还用于将更新后的用户标签更新至用户体验中台；

智能服务中台，用于获取用户生物特征信息，根据用户生物特征信息对用户进行身份识别，并在身份识别成功时，调用业务中台根据用户体验中台中的更新后的用户标签，生成目标展示页面。

在其中一个实施例中，用户行为数据包括：用户下单事件数据；系统还包括：企业管理层；

业务中台，还用于对用户下单事件数据进行统计和处理，生成多维营销数据信息，并将多维营销数据信息传输至企业管理设备。

上述银行业务信息更新方法和系统，通过采集用户基于交互平台触发的用户行为数据，对用户行为数据进行数据清洗并整合，得到用户事件数据，根据用户事件数据，更新当前用户信息以及当前营销模型。能够不仅满足原有SOA架构的系统中，通过较为刚性的接口连接的系统架构，仅传输预设接口对应的交易数据等，还能够对用户基于交互平台产程的不同用户行为数据实时的更新，以便实时更新用户信息，避免了银行业务系统的数据之间是相对独立的，每个业务系统拥有单独的功能组件和数据集市，系统间的彼此隔离。满足不同业务场景中系统间的信息交互的需求。避免数据积累出现孤岛化、无序化。

附图说明

图1为一个实施例中银行业务信息更新方法的应用环境图；

图2为一个实施例中银行业务信息更新方法的流程示意图；

图3为一个实施例中用户事件分类示意图；

图4为另一个实施例中行业务信息更新方法的流程示意图；

图5为另一个实施例中行业务信息更新方法的流程示意图；

图6为另一个实施例中行业务信息更新方法的流程示意图；

图7为一个实施例中银行业务信息更新系统结构框图；

图8为另一个实施例中银行业务信息更新系统结构框图；

图9为一个实施例中时间属性定义示意图；

图10为一个实施例中数据平台总体架构示意图；

图11为一个实施例中事件平台的主要交互关系示意图；

图12为一个实施例中事件平台中的消息模式示意图；

图13为一个实施例中消息的顺序流向图；

图14为另一个实施例中消息的顺序流向图；

图15为一个实施例中半事务消息机制示意图；

图16为一个实施例中事件平台中的发布订阅模式示意图；

图17为另一个实施例中银行业务信息更新系统结构框图；

图18为一个实施例中数据中台的应用架构示意图；

图19为一个实施例中数据中台的总体架构示意图；

图20为另一个实施例中银行业务信息更新系统结构框图；

图21为一个实施例中业务中台的应用分群建议示意图；

图22为另一个实施例中银行业务信息更新系统结构框图；

图23为一个实施例中用户体验中台的总体架构示意图；

图24为一个实施例中用户体验中台的应用架构示意图；

图25为一个实施例中智能服务中台的功能分群示意图；

图26为另一个实施例中银行业务信息更新系统结构框图；

图27为一个实施例中行业务信息更新装置的结构框图；

图28为一个实施例中计算机设备的内部结构图。

具体实施方式

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

SOA架构是一种在计算环境中设计、开发、部署和管理离散逻辑单元(服务)模型的方法，它本质上是服务的集合以及服务之间的彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。银行业务领域信息系统主流设计是SOA架构。在这种架构中，所有银行的业务功能、基础功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成银行业务流程，对客户提供金融服务。

银行业务领域信息系统的SOA架构主要从系统解构的角度入手，它侧重于将整个应用分解为一系列独立的服务，并指定各种标准和基础设施来使得这些服务易于重用，能够很容易地被银行其他业务系统上的应用来使用。但是在服务实际业务时出现了一些问题，因为SOA更多地是关注静态的信息，服务彼此之间的数据是相互隔离和非实时流动的。所以不能很好地与动态业务匹配，更无法根据实时产生的客户浏览行为数据、交易行为数据、账务行为数据等，实时动态判断识别客户意图，做出迅速响应，并根据客户反馈，对响应策略进行实时动态调整，从而无法用实时的“热”数据来驱动业务功能和流程自动化及智能化，无法快速响应移动互联网时代的市场快速变化和客户极致体验的要求。例如在一个典型的银行业务模型中，一般有很完善的前端渠道系统、业务产品系统、账务核心系统、营销管理系统、运营决策系统等，当一个客户完成一笔工资代发，目前银行SOA架构会碰到一些问题，谁来负责触发这样的一个事件？哪些系统需要实时获得此事件的通知并做出实时响应和处理？各系统分别需要哪些具体的交易、业务、客户的信息，各个系统如何得到通知？如何保证各个系统对此事件的含义的理解一致并对后续行动的协同？如何使静态的数据变为“热”数据流动起来，形成数据驱动的原动力。由于SOA架构关注的是功能实现的静态信息，而且不关注动态数据引发和驱动的后续行为，因此它并不能很好地解决上述问题，而这些问题往往往往又是提升客户体验和客户经营非常需要的特性，也是实现“热”数据驱动架构的关键设计，影响数据驱动的银行数字化转型的实现。

为解决上述问题，本申请通过引入面向事件机制，使得系统具备了感知和快速响应业务事件的能力。这样银行的信息系统就可以简化为同步服务交互加上异步事件消息感知，其中SOA完成功能组件化的服务调用，EDA更多地强调和实现异步业务事件消息的感知和响应。我们称此融合的架构设计方法为事件驱动的面向服务架构(Event-Driven SOA)，其主要内容为：事件驱动的面向服务架构设计中包含了全新、高效、智能、闭环的功能(SOA)和数据(EDA)的二维平面，作为该融合架构设计的关键点。

本申请实施例提供的银行业务信息更新方法方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络与服务器104进行通信。数据存储系统可以存储服务器104需要处理的数据。数据存储系统可以集成在服务器104上，也可以放在云上或其他网络服务器上。用户通过用户终端的交互平台进行交易、浏览等操作产生相关的用户行为数据，服务器可采集用户基于交互平台触发的用户行为数据，并对产生的用户行为数据进行分析整合等操作，以便更新用户的相关喜好、操作信息，并更新营销模型，以便为用户提供更符合用户喜好的营销产品。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑、物联网设备和便携式可穿戴设备，物联网设备可为智能音箱、智能电视、智能空调、智能车载设备等。便携式可穿戴设备可为智能手表、智能手环、头戴设备等。服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种银行业务信息更新方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：

S202，采集用户基于交互平台触发的用户行为数据。

具体地，用户可以通过交互平台基于不同的业务场景触发对一系列的业务操作，在此同时，会同时产生一系列的用户行为数据。服务器就可以采集到用户行为数据。其中，交互平台可以包括：个人银行、手机银行、微信银行等交互平台，在此不加以限制。其中，业务场景可以包括：银行零售线上营销、线上交易、订阅通知、流量消峰、消息通知、参数同步、同步交易解耦等场景，在此不加以限制。其中，用户行为数据可以包括，用户浏览数据、用户交易数据、用户个人信息修改数据等等，在此不加以限制。

可选地，该银行业务信息更新方法可以应用于融合了SOA和EDA的ED SOA系统架构的银行业务信息更新系统中。

S204，对用户行为数据进行数据清洗并整合，得到用户事件数据。

具体地，当获取到用户行为数据，可以采用预设的数据清洗算法，对用户行为数据进行清洗并整合，得到不同分类的用户事件数据。其中，用户事件也即客户事件，可以如图3所示。其中，用户事件数据，即为不同用户事件产生的数据。

S206，根据用户事件数据，更新当前用户信息以及当前营销模型。

具体地，可以将用户事件数据生成事件订阅信息，根据事件订阅信息，更新数据库中存储的用户信息，并采用该用户事件数据作为样本数据，对预先设置的营销模型进行迭代训练，以得到基于用户数据信息更新后的营销模型。

上述银行业务信息更新方法中，通过采集用户基于交互平台触发的用户行为数据，对用户行为数据进行数据清洗并整合，得到用户事件数据，根据用户事件数据，更新当前用户信息以及当前营销模型。能够不仅满足原有SOA架构的系统中，通过较为刚性的接口连接的系统架构，仅传输预设接口对应的交易数据等，还能够对用户基于交互平台产程的不同用户行为数据实时的更新，以便实时更新用户信息，避免了银行业务系统的数据之间是相对独立的，每个业务系统拥有单独的功能组件和数据集市，系统间的彼此隔离。满足不同业务场景中系统间的信息交互的需求。避免数据积累出现孤岛化、无序化。

上述实施例对，银行业务信息更新系统进行了说明，现以一个实施例对如何更新当前的用户信息以及当前营销模型进行说明。在一个实施例中，如图4所示，根据用户事件数据，更新当前的用户信息以及当前营销模型，包括：

S402，根据用户事件数据，生成事件订阅信息。

具体地，当得到了用户事件数据后，可以根据用户事件数据，生成对应的事件订阅信息，并将该信息进行发布。其中，事件订阅信息可以包括：用户足迹事件订阅、用户理财事件订阅、客户标签更新事件、客户代发事件订阅、客户理财事件订阅等等。

S404，根据事件订阅信息，更新当前的用户信息以及当前营销模型。

具体地，当得到了事件订阅信息后，可以将事件订阅信息中的用户标签直接更新数据库中存储的用户标签。同时将将事件订阅信息中的用户标签输入至当前营销模型中进行迭代训练，得到目标营销模型。

进一步地，用户信息包括：用户标签；根据事件订阅信息，更新当前用户信息以及当前营销模型，包括：将事件订阅信息输入至当前营销模型中进行迭代更新，直到达到预设迭代次数，确定目标营销模型。根据事件订阅信息中的用户标签更新用户信息中的用户标签。

本实施例中，通过根据用户事件数据，生成事件订阅信息，根据事件订阅信息，更新当前的用户信息以及当前营销模型。能够实现根据用户事件数据，实时进行更新当前的用户信息，并更新营销模型，一边为用户提供更好的营销产品，满足用户的需求，提高用户的体验。

上述实施例对银行业务信息更新方法进行了说明，在更新了用户信息和营销模型后，可以根据用户信息以及营销模型对用户进行一些营销推荐，现以一个实施例进行说明。在一个实施例中，银行业务信息更新方法，在完成了用户信息和营销模型的更新后，还可以将事件订阅信息输入至目标营销模型中，得到营销服务信息并发送至用户设备。

具体地，将事件订阅信息输入至目标营销模型中，得到营销服务信息并发送至用户设备，就是在用户产生用户行为数据后，生成响应的事件订阅信息，将该事件订阅信息输入至目标营销模型中，即可确定为该用户进行推送的营销产品，同时也会得到进行营销推广的合适渠道、时间进行推送。例如，客户发生一笔代发工资的事件之后，该事件通过事件平台实时传递到业务中的营销中心，营销中心触发最新的营销模型进行预测，得到合适的渠道、合适的时间段，发生合适的营销活动或产品至客户设备。其中，推送的方式可以包括：语音、短信、链接等，在此不加以限制。

在本实施例中，通过将事件订阅信息输入至目标营销模型中，得到营销服务信息并发送至用户设备。能够事实根据不同的用户动作，产生用户可能感兴趣的营销活动或者产品，以提高了用户体验感受。

上述银行业务信息更新方法，在完成了用户信息和营销模型的更新后，还可以在用户下次进行浏览时，根据更新后的信息生成针对各个用户的展示页面，在一个实施例中，如图5所示，银行业务信息更新方法还包括：

S502，获取用户生物特征信息，根据用户生物特征信息对用户进行身份识别；

S504，在身份识别成功时，根据更新后的用户标签，生成目标展示页面。

具体地，当用户登录银行系统时或者点击了营销产品的链接时，可以首先通过智能交互模块，获取用户的生物特征信息，对用户的身份进行验证，当验证通过时，允许访问，并基于上一次或者用户浏览的信息更新的用户标签，重新组织访问页面，提供和用户标签相关的内容。例如，当客户收到并点击营销短信链接后，进行了H5页面的展示，此时渠道调用了智能服务中台完成了生物识别和智能化交互之后，渠道从用户体验核心拿到最新的客户标签数据，然后调用业务中台的营销中心组织形成该客户最新的适合于该客户特点的个性化展示页面，形成了千人千面的效果。

在本实施例中，通过获取用户生物特征信息，根据用户生物特征信息对用户进行身份识别；在身份识别成功时，根据更新后的用户标签，生成目标展示页面。能够针对不同的用户生成不同的用户展示界面，形成千人千面的效果。

上述实施例对银行业务信息更新方法进行了说明，当产生用户行为数据后，还需要将相关的信息进行统计处理，以使企业管理人员能够根据这些信息及时对一些营销策略进行一定的调整。现以一个实施例对进一步说明，在一个实施例中，用户行为数据包括：用户下单事件数据；方法还包括：

对用户下单事件数据进行统计和处理，生成多维营销数据信息，并将多维营销数据信息传输至企业管理设备。

具体地，当用户进行一些购买、订阅、下单的事件后，会产生用户下单时间数据。得到该数据后，会对用户下单事件数据进行统计和处理，生成多维营销数据信息，并将多维营销数据信息传输至企业管理设备。例如，当客户浏览H5页面中推送的营销产品后，形成下单事件，该事件实时获取到并通过事件平台，传递到数据中台，进行实时数据的加工和统计，并形成营销多维度数据，下发给业务中心的营销中心，营销中心形成营销数据大屏，供管理人员进行后续营销效果的评估和营销策略的调整。

在本实施例中，通过对用户下单事件数据进行统计和处理，生成多维营销数据信息，并将多维营销数据信息传输至企业管理设备。能够针对用户下单数据，进行分析，以供企业营销人员进行实时监测，并调整营销策略。

为了便于本领域技术人员的理解，现以一个实施例对银行业务信息更新方法进一步说明，在一个实施例中，如图6所示，银行业务信息更新方法，包括：

S601，采集用户基于交互平台触发的用户行为数据。

S602，对用户行为数据进行数据清洗并整合，得到用户事件数据。

S603，根据用户事件数据，生成事件订阅信息。

S604，将事件订阅信息输入至当前营销模型中进行迭代更新，直到达到预设迭代次数，确定目标营销模型。

S605，根据事件订阅信息中的用户标签更新用户信息中的用户标签。

S606，将事件订阅信息输入至目标营销模型中，得到营销服务信息并发送至用户设备。

S607，获取用户生物特征信息，根据用户生物特征信息对用户进行身份识别。

S608，在身份识别成功时，根据更新后的用户标签，生成目标展示页面。

S609，对用户下单事件数据进行统计和处理，生成多维营销数据信息，并将多维营销数据信息传输至企业管理设备。

本实施例中，通过采集用户基于交互平台触发的用户行为数据，对用户行为数据进行数据清洗并整合，得到用户事件数据，根据用户事件数据，更新当前用户信息以及当前营销模型。能够不仅满足原有SOA架构的系统中，通过较为刚性的接口连接的系统架构，仅传输预设接口对应的交易数据等，还能够对用户基于交互平台产程的不同用户行为数据实时的更新，以便实时更新用户信息，避免了银行业务系统的数据之间是相对独立的，每个业务系统拥有单独的功能组件和数据集市，系统间的彼此隔离。满足不同业务场景中系统间的信息交互的需求。避免数据积累出现孤岛化、无序化。

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

上述实施例对银行业务信息更新方法进行说明，该银行业务信息更新方法可以应用于银行业务信息更新系统中，现以一个实施例对银行业务信息更新系统进行说明，在一个实施例中，如图7所示，银行业务信息更新系统，包括：交互层701、中枢层702、基础层703；

交互层701，用于采集用户基于交互平台触发的用户行为数据并将用户行为数据传输至基础层702中；

基础层702，用于对用户行为数据进行数据清洗并整合，得到用户事件数据，根据用户事件数据生成事件订阅信息，并发布事件订阅信息至中枢层703；

中枢层703，用于根据事件订阅信息，更新当前的用户信息以及当前营销模型。

具体地，交互层采集用户基于交互平台触发的用户行为数据并将用户行为数据传输至基础层中。其中可以采用传统的数据沉淀和数据回流的方式，将数据落入至基础层中的数据库、大数据平台。基础层在对用户行为数据进行数据清洗并整合，得到用户事件数据，根据用户事件数据生成事件订阅信息，通过异步事件同步机制，发布事件订阅信息至中枢层，准实时落地中枢层。中枢层，根据事件订阅信息，更新当前的用户信息以及当前营销模型，可以通过将基础层传输的“冷”“热”数据在中枢层进行实时整合、加工形成知识，进行模型算法的实时/批量计算形成智慧并驱动业务能力快速达成。其中，冷数据，即为用户交易相关的信息，热数据可以包括时间订阅信息。

可选地，该银行业务信息更新系统，为融合SOA和EDA系统架构的ED SOA系统架构。

在本实施例中，银行业务信息更新系统，包括：交互层、中枢层、基础层；交互层采集用户基于交互平台触发的用户行为数据并将用户行为数据传输至基础层中；基础层对用户行为数据进行数据清洗并整合，得到用户事件数据，根据用户事件数据生成事件订阅信息，并发布事件订阅信息至中枢层；中枢层根据事件订阅信息，更新当前的用户信息以及当前营销模型。能够把银行现有业务系统应用功能通过接口集成的刚性架构，逐步向通过实时数据驱动功能流程的柔性架构过渡，再向具有实时智能的认知型架构过渡。对所有业务场景中利用智能端感知的“热”数据，进行自动化实时采集、实时加工、实时整合存储；提升实时分析计算能力，结合离线计算和分布式计算，构建高时效的计算引擎；提供流处理、批处理、批流结合的混合计算方式，以更快速的反应能力响应市场变化和客户体验要求。通过标准化接口和智能算法，实现OLTP(On-Line Transaction Processing,联机事务处理过程)与OLAP(On-line Analytical Processing,联机分析处理)系统层面的对接、数据平面与前台业务层的对接、分析需求和交易需求的对接，建立数据平面与业务平面的实时数据传输通道，摒弃孤立条线资源不共享、缺乏合力的弊端；将高质量的资产化数据，通过AI模型和算法，驱动业务功能和流程，适时为用户提供个性化、智能化体验，为用户经营及业务决策提供智能支撑。在此基础上，进一步形成两维平面的闭环，业务场景新产生的“热数据”回流数据平面，对模型、算法进行迭代，持续升级业务功能和优化流程。

上述实施例对银行业务信息系统进行了说明，由于在上述系统中，正式由于融合了EDA数据平台，才能实现对用户行为数据等信息数据进行一定的处理，现以一个实施例对数据平台进行说明，在一个实施例中，如图8所示，基础层702包括：金融核心平台7021和数据平台7022；

金融核心平台7021，用于获取用户行为数据生成用户事件数据，并将用户事件数据传输至事件平台；

数据平台7022，用于根据用户事件数据进行数据清洗并整合，发布事件订阅信息至中枢层。

具体地，数据平台可以包括企业级事件驱动架构(EDA)，能够将所有用户全维度数据进行准实时感知和沉淀，是全新数据平面构建和实现数据驱动实现的基础。首先，金融核心平台获取用户行为数据生成用户事件数据，并将用户事件数据传输至事件平台；数据平台根据用户事件数据进行数据清洗并整合，发布事件订阅信息至中枢层。

事件平台为异步事件机制，是构建全新数据平面和实现数据驱动的基础和前提。可以实现订阅通知、流量消峰、消息通知、参数同步、同步交易解耦等场景。主要实现事件管理、事件处理引擎、事件传输组件等功能。其中，事件定义为行为主体在业务场景中发生行为的最小单元。事件的分类可以参照图3。事件属性定义可以参见图9。

可选地，事件平台可以包括：事件消息队列服务层、事件消息加工服务层、事件管理服务层。其中，事件消息队列服务层，包括：事件API、事件队列。时间API，用于向事件产生端和事件消费端提供的标准化的事件发生和事件订阅接口，减少对其侵入性。事件队列，用于实现事件的异步消息队列机制、路由转发。事件消息加工服务层包括：公共事件处理、主题事件处理。公共事件处理，用于负责公共的报文格式转换、过滤、条件、丰富、去重等事件处理动作，并供给下游的主题引擎或事件应用端使用。主题事件处理，用于负责解决某个主题的复杂事件的处理，一般主题引擎和管理分析类应用靠得更近，例如：反欺诈、营销管理、客户信息、会计核算。事件管理服务层，包括：事件注册管理、事件监控管理、事件配置发布、事件异常处理、事件多维度实时分析、事件持久化。事件注册管理，用于按业务场景、应用系统(或组件)、联机服务、事件等多个维度来抽象定义、注册每一个发布/订阅事件。事件监控管理，用于依据事件注册定义，在运行态基于收集的事件动态流转信息来监控、管理异步事件驱动的SLA/QoS。事件配置发布，用于允许将事件注册管理信息同步到事件产生/消费端、事件处理引擎、事件传输通道，进而支持以上事件处理环节对事件的检查等处理。事件异常处理，用于实现事件的异常抛出、异常排查、异常处理机制。事件多维度实时分析，用于基于事件消息，进行多维度指标的分析的实时加工、统计。事件持久化，用于实现事件的缓存和落盘持久化、落库。可选地，数据平台的总体架构如图10所示。

可选地，事件平台内部的信息传输可以通过事件处理引擎监听订阅事件是，事件产生端产生待发布事件；调用事件管理API进行事件发送前检查，时间管理API检查正常发送事件至事件传输通道，事件传输通道进行路由转发至事件处理引擎，事件处理引擎进行时间加工整合，产生新事件，调用事件管理API，进行事件发送前检查，事件管理API发送事件；事件传输通道进行路由转发，想事件消费端发送事件。事件平台的主要交互关系可参见图11。

在事件平台中的消息模式，可以包括如图12所示的点对点模式(P2P)：P2P模式包含三个角色：消息队列(Queue)，发送者(Sender)，接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。每个消息只有一个消费者(Consumer)(即一旦被消费，消息就不再在消息队列中)，发送者和接收者之间在时间上没有依赖性。也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列，接收者在成功接收消息之后需向队列应答成功，Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

其中，事件消费可以包括：同步(PULL)订阅者或接收者通过receive方法来接收消息，receive方法在接收到消息之前(或超时之前)将一直阻塞；异步(PUSH)订阅者或接收者可以注册为一个消息监听器。当消息到达之后，系统自动调用监听器的onMessage方法。

消息的顺序可以参照图13和14所示，分区顺序消息，对于指定的一个Topic，所有消息根据shardKey进行区块分区。同一个分区内的消息按照严格的FIFO顺序进行发布和消费。适用于对性能要求高，非全局性有序，可以拆分出最小有序单元的系统，如：电商系统，一个完整的订单处理流程为最小有序单元，以订单ID作为shardKey，同一个订单相关的创建订单消息、订单支付消息、订单退款消息、订单物流消息都会按照先后顺序来发布和订阅。全局顺序消息，对于指定的一个Topic，可以给消息加上全局编号，来表示消息的前后顺序。所有消息按照严格的FIFO的顺序进行发布和消费。适用于对于性能要求不高的全局性业务场景。

消费定时/延时：生产者将消息发送到消息队列服务端，但并不期望这条消息立马投递，而是推迟到当前时间点之后的某个时间或延迟一定时间后投递到消费者进行消费，该消息即定时消息。例如，在创建订单时会发送一条消息，这条消息将在30分钟以后投递给消费者，消费者收到此消息后需要判断对应的订单是否已经完成支付，如支付未完成，则关闭订单。

消息事务：半事务消息机制，如图15所示，将消息发送方向消息队列服务端的消息投送作为整个异步消息过程中的部分事务过程，确保发送方的本地事务和消息投递动作的事务一致性。主要的流程包括：发送方发送半事务消息：发送方已经将消息发送到了服务端，但是服务端未收到生产者对该消息的二次确认，处于该状态下的消息暂时不会被投递。发送方执行本地事务：发送方半事务消息发送成功后，开始执行本地事务，并根据本地事务执行情况，进行消息的二次确认，Commit或Rollback。消息回查确认：消息队列服务端会扫描消息状态，若发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态，以决定消息是否要投递或删除。

现有的一些主流开源产品比较可参见表1：

表1

此处可基于以下实施策略建议，构建数据平台：

1、第一阶段，建议结合用户中心建设，构建事件平台，同时推进相关系统(如客户资产类产品系统、用户体系、渠道系统、客户足迹系统等)进行异步事件改造。

2、第二阶段，建议根据第一阶段实施情况和效果，对事件平台功能进行进一步优化，并着手制定、发布事件管理要求、接入规范及事件流水结构体规范。

3、第三阶段，按照系统类型、重要程度，对现有系统进行分批推广、改造，优先考虑用户相关的足迹类、资产类、签约类、动账类系统。

事件平台中的发布订阅模式可以包括三个角色主题(Topic)，发布者(Publisher)，订阅者(Subscriber)，如图16所示。多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。每个消息可以有多个消费者，发布者和订阅者之间有时间上的依赖性。针对某个主题(Topic)的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。为了消费消息，订阅者必须保持运行的状态。发布订阅模式下，当发布者消息量很大时，显然单个订阅者的处理能力是不足的。实际上现实场景中是多个订阅者节点组成一个订阅组负载均衡消费topic消息即分组订阅，这样订阅者很容易实现消费能力线性扩展。

在本实施例中，由于基础层包括：金融核心平台和数据平台；金融核心平台获取用户行为数据生成用户事件数据，并将用户事件数据传输至事件平台；数据平台根据用户事件数据进行数据清洗并整合，发布事件订阅信息至中枢层。能够对用户行为数据进行初步的清洗和整合。

上述实施例对银行业务信息系统中的基础层进行了说明，现一个实施例对中枢层进一步说明，在一个实施例中，如图17所示，用户信息包括用户标签；中枢层包括：数据中台7031；

数据中台7031，用于根据事件订阅信息对当前营销模型进行迭代更新，直到达到预设迭代次数，确定目标营销模型；

数据中台7031，还用于根据事件订阅信息中的用户标签更新用户信息中的用户标签，并将更新后的用户标签传输至数据平台。

具体地，数据中台能够在接收到事件订阅信息后，对当前影响模型进行迭代更新，直到达到预设迭代次数，则可以确定基于该事件的目标营销模型。并且，在可以获取事件订阅信息中的用户标签，更新数据中台中的用户信息中的用户标签，并将更新后的用户标签传输至数据平台。

数据中台为面向行内各应用系统、业务场景以及相关科技与业务人员，提供统一的、体系化、产品化、标准化、规模化的数据服务，其中包括：

1.多品类的数据产品服务。结合银行业经营特点与我行数字生态建设要求，构建高效、全面的数据产品服务体系，提供包括知识图谱服务、模型服务、数据标签体系、业务统计指标、业务报表、可视化分析与数字大屏等多维度的数据产品服务，有效提升行内业务的数字化、智能化服务。2.灵活的服务调用模式。精简数据服务流程，提供高效、灵活的数据服务对接机制和共享机制，服务调用模式包括订阅、双向调用、推送以及组合等多个类型。3.开放的数据分析能力。提供简单易用的在线分析、实时查询、多维分析、可视化分析的能力。

数据中台的应用架构可以参见图18所示，具备的功能包括：1、结合银行业经营特点与我行数字生态建设要求，构建高效、全面的数据产品服务体系，提供包括知识图谱服务、模型服务、数据标签体系、业务统计指标、业务报表等多维度的数据产品服务。2、精简数据服务流程，提供高效、灵活的数据服务对接机制和共享机制，服务调用模式包括订阅、双向调用、推送以及组合等多个类型。3、提供精简的数据服务使用流程，实现服务申请、服务封装、服务评估、服务监控的全面管理。

数据中台的总体架构可参见图19所示。数据中台作为数据类应用能力的集合，涵盖了数据存储与加工整合能力的大数据服务平台，数据仓库以及数据作业调度系统，在此之上，数据科学工作平台中的模型服务与管理平台、报表服务平台、图数据分析服务平台具备跨底层数据平台的整合加工能力、数据建模能力，数据资产管理系统对行内的数据资产进行统一的维护和评定，提供数据资产治理和运行的能力。最终数据中台的数据资产通过数据服务平台提供对外服务。

在数据中台内部，数据服务平台对接模型管理及服务平台，报表服务平台，图数据分析服务平台，数据资产管理系统以及企业数据平台的大数据服务平台和数据仓库等系统。其对数据中台内部系统的各项数据服务功能进行整合包装，形成品类全面的数据服务目录；根据需求将各类服务进行数据流程编排，提供灵活高效的服务调用模式，简化上游业务系统对数据服务进行串联的要求；简化服务领用到上线运行的流程，提供一站式的数据服务管理能力。

数据中台对外主要通过企业级微服务平台，事件平台，以及企业数据交换平台对各类应用系统提供包括知识图谱服务、模型服务、数据标签体系、业务统计指标、业务报表等多维度的数据产品服务，有效提升行内业务的数字化智能化提升。

数据中台中的主要交互关系包括：数据中台，底层存储和计算能力依托于数据仓库和大数据服务平台，应用服务能力整合了主要的数据应用类系统，如模型管理及服务平台，报表平台，知识图谱分析管理平台，通过ESF，对各类应用系统暴露联机服务，通过数据交换平台，对外提供批量数据传输服务。

未来，依托事件平台的建设，实时或准实时的获取各类高时效数据信息，基于各类业务需求，将实时信息同历史信息进行加工整合，指标计算，再通过同步服务或异步推送的方式，为各业务类应用进行赋能。

数据中台的相关系统改造要求可以包括：数据服务平台包装已经成型的服务，形成通用的数据产品，支持多业务场景重复调用；提供多类型灵活性高的服务模式，包括但不限于订阅、调用、推送以及其他组合形式；建立线上数据申请、审批、加工、交付一站式工作流程，具备订单式数据需求管理和交付能力；数据资产管理系统形成全面的数据服务目录，涵盖数据标签、知识图谱、业务统计指标、数据模型等多个门类；强化业务系统元数据的管控能力；建立完善的数据质量管理体系，实现数据成本核算，对数据的投入产出进行有效核算，提升数据的使用效率；对各系统间数据流的血缘分析可视化，能够及时发现元数据调整对上下游的影响，避免出现数据不一致性；数据仓库和大数据服务平台增强数据基础数据服务能力，提高数据加工服务时效性和完整性；增强流式计算能力，提高流式计算可靠性；基于事件平台的建设，优化现有数据跑批和流式计算架构；根据不同场景SLA的要求，提供不同时效性的数据服务。

构建数据中台的关键实施要点包括：高并发低延时的联机访问能力；高性能和高可靠性的流式数据处理能力；实时数据同历史数据的混合查询服务的能力增强；增强批流结合的能力，优化现有流式数据服务和批量数据服务整体架构模型服务能力的增强；强化数据资产管理能力。

数据中台的构建可以基于以下策略：第一阶段，结合异步事件架构的构建，数据获取方式由批量逐步转为批流结合，并逐步加大实时计算的比重，需要根据此趋势，增强现有流式数据计算和服务能力和提升批量数据服务时效性；同时，构建高实效性的各类数据产品(标签、模型实时预测、计算结果数据)的实时服务调用能力；第二阶段，根据第一阶段实施情况和效果，对大数据服务平台和数据仓库部份的批量作业进行实时化探索，构建实时数仓；第三阶段，基于前两阶段的实施中遇到的问题，进行痛点分析，提升各类数据应用系统的实时处理能力，同时也对前台业务类系统提出明确的实时数据SLA要求；第四阶段，形成全面的数据服务目录，涵盖数据标签、知识图谱、业务统计指标、数据模型等多个门类，打造完整的数据产品。

本实施例中，由于中枢层包括：数据中台；数据中台根据事件订阅信息对当前营销模型进行迭代更新，直到达到预设迭代次数，确定目标营销模型；数据中台，还用于根据事件订阅信息中的用户标签更新用户信息中的用户标签，并将更新后的用户标签传输至数据平台。能够完成对用户行为数据产生的事件订阅信息对当前营销模型进行更新。实现全量数据融合分析，形成快速迭代的企业级标签库、模型库，打通前中后台的数据链路，实时数据共享。支持多时效性、多种调用方式，将各类数据产品等实现可复用封装，以API服务的形式直接向前台业务应用方输送，形成数据服务(DaaS)能力。是实现业务数字化和数据业务化的关键一环。

上述实施例对中枢层的数据中台进行了说明，在中枢层包括数据中台的情况下，还可以包括业务中台，现以一个实施例对业务中台进行说明。在一个实施例中，如图20所示，中枢层，还包括：业务中台7032；

业务中台7032，用于将数据平台发送的事件订阅信息输入至数据中台部署的目标营销模型中，得到营销服务信息，并将营销服务信息发送至用户设备。

具体地，在数据中台进行用户标签的更新、营销模型的迭代，然后数据中台将最新的用户标签准实时传递给事件平台，事件平台准实时下发给业务中台更新本地的最新的客户标签信息，此时，业务中台将数据平台发送的事件订阅信息输入至数据中台部署的目标营销模型中，得到营销服务信息，并将营销服务信息发送至用户设备。示例地，当客户发生一笔代发工资的事件之后，该事件通过事件平台实时传递到业务中台的营销中心，营销中心触发最新的营销模型进行预测，选择合适的渠道、合适的时间段，发生合适的营销活动或产品至客户。

业务中台是结合业务场景，将统一交互层、中枢层服务板块、金融核心的产品、基础平台的基础功能中具有可重用、公共性、共享性的功能进行抽象化、标准化，以共享服务的方式提供给内部应用调用，满足生态场景的快速构建，为我行未来生活生态、产融生态和同业生态提供高效创新动能。

业务中台的核心是“构建企业级共享服务中心”，通过对未来生态和线上经营场景的研究，将高频调用的公共服务进行组件化提炼和构建，通过内部API的形式实现模块间的功能组合与协同，形成可复用的关键业务能力资产。

业务中台的构建可以解决系统功能重复建设、业务管理分散且流程割裂等问题，通过对关键业务能力的复用和灵活组合，达到业务产品研发降本增效的目的。

业务中台是各类共享服务中心的集合，是能力的枢纽和对能力的共享。业务中台要求对能力进行细粒度分析，识别共享能力，并将共享能力按照不同的领域建设成为各类服务中心。

业务中台构建原则：服务逐步丰富；业务中台中的各类共享服务中心是一个逐步抽象和形成的过程；随着科技人员对业务场景的认知和抽象能力的提升而逐步完善和丰富的过程；可以按照各个业务域进行建模抽象。上层服务沉淀场景侧交互侧的功能，将比较稳定和公共的功能沉淀到业务中台。下层服务抽象后台业务系统、基础平台的功能，将具备共享性的服务抽象到业务中台。

业务中台的应用分群建议可参见图21，目前抽象的业务中台中的业务功能域如图21所示，后续可根据具体抽象的业务功能分布进行调整。

在本实施例中，由于中枢层，还包括：业务中台；业务中台将数据平台发送的事件订阅信息输入至数据中台部署的目标营销模型中，得到营销服务信息，并将营销服务信息发送至用户设备。能够实时确定针对不同用户标签的营销预测结果，并将适用于不同用户的营销服务信息发送至用户设备。建立业务中台，通过对未来生态和线上经营场景的研究，将高频调用的公共服务进行组件化提炼和构建，通过内部API实现模块间的功能组合与协同，形成可复用的关键业务能力资产(BaaS)。是满足生态场景快速构建的关键一步。

上述实施例对中枢层的数据中台和业务中台进行了说明，现以一个实施例对中枢层的智能服务中心和用户体验中心进行说明；在一个实施例中，如图22所示，中枢层还包括：智能服务中台7033和用户体验中台7034；

数据平台7031，还用于将更新后的用户标签更新至用户体验中台7034；

智能服务中7033，用于获取用户生物特征信息，根据用户生物特征信息对用户进行身份识别，并在身份识别成功时，调用业务中台根据用户体验中台中的更新后的用户标签，生成目标展示页面。

具体地，数据中台将最新的用户标签准实时传递给事件平台，事件平台准实时下发给用户体验中台、业务中台更新本地的最新的客户标签信息，数据中台实时下发最新的营销模型给业务中台的营销中心。至此客户标签和营销模型已经根据当日的客户的热数据完成了更新和迭代。并且当客户收到并点击营销服务信息的短信链接后，进行了H5页面的展示，此时渠道调用了智能服务中台获取用户生物特征信息，根据用户生物特征信息对用户进行身份识别，并在身份识别成功时，即完成了生物识别和智能化交互之后，渠道从用户体验中台拿到最新的用户标签数据，然后调用业务中台的营销中心组织形成该客户最新的适合于该客户特点的个性化展示页面，形成了千人千面的效果。

用户体验中台依托数据中台支撑，实现面向场景的用户视角360度银行及生态全景信息视图汇总及数据服务提供，包括产品服务签约信息、足迹信息、金融资产、金融事件日历、全渠道消息信息、账单信息等准实时和历史信息。同时，可支持存放与用户交互相关的用户信息，用以支撑用户的个性化差异服务，包括用户订阅信息、免打扰信息或其它用户主动录入的信息等。用户体验中台的总体架构可以参见图23。用户体验中台的应用架构可参见图24。

用户体验中台的主要业务流程包括：全量数据准实时计算；客户渠道、生态及足迹、金融核心板块的产品系统产生的各类客户事件需要采集，并准实时入事件平台；用户中心订阅事件平台的各类客户事件；用户中心本地滚动形成客户当天准实时的用户数据；用户中心结合本地的全景全量历史数据，整合当天准实时的数据，形成用户360度全景视图。用户中心高实效查询的场景；客户渠道、生态、API通过服务调用的方式实现对用户全景数据的高实效的查询。

用户体验中台的主要交互关系：用户中心主要通过与企业级微服务平台集成，提供联机访问服务为主，批量数据共享场景原则上可通过数据中台经由数据交换平台提供。用户中心可通过数据服务平台提供的服务接口直接调用获取数据中台数据，减少数据冗余。

用户体验中台的实施策略建议，建议分三个大的阶段开展实施，具体如下：第一阶段，用户中心的用户全局视图和用户缓存管理，先做技术可行性验证，优先考虑基于数据中台构建，避免数据搬家和功能烟囱式建设。第二阶段，结合事件平台，优先考虑解决最急迫的用户需求、业务痛点来构建用户中心。第三阶段，结合场景需求，逐步推进系统功能完善。

人工智能是未来金融科技发展的关键技术，是高质量发展和业务创新的核心动力，要继续开展人工智能技术和应用创新，赋能更多业务场景。一是建设AI即服务(AI as aService)能力，研发计算机视觉、图像识别、语音识别、以及自然语言处理等AI通用解决方案和组件服务，向其他应用输出成熟的图像识别、人脸识别、语音识别、RPA等的通用类AI能力。二是实现模型算法发布和管理可视化、自动化、智能化，支持快速迭代优化，从而降低AI运用门槛，实现规模化应用。三是持续拓展AI应用场景，结合推荐引擎、知识谱图、RPA、物联网等技术，赋能对客服务、业务营销、运营风控。

智能服务中台是数据驱动架构的重要平台，是将数据转换为知识、进而产生智慧的关键引擎。它与数据中台紧密协作，通过离线、近线、在线计算，实现智能模型的训练、调优、反馈的循环迭代，使得模型越来越“聪明”。输出通用共享的智能服务，提升业务服务的智能化水平。提供平台化的特征工程、模型评估、对抗训练、混合训练等支持，为算法模型的开发者、训练者、标注管理者等提供简洁的方便的服务，降低开发智能服务难度，提高开发及部署智能服务的效率。

智能服务中台的板块的划分原则，按照基础平台、对外智能服务，划分为两层。其中智能服务群：感知中枢、认知中枢、交互中枢、流程中枢。这些系统需要改造才能符合平台化、服务化的架构规划目标要求。智能服务中台的功能分群可参见图25。

在本实施例中，由于中枢层还包括：智能服务中台和用户体验中台；数据平台，还用于将更新后的用户标签更新至用户体验中台；智能服务中台，用于获取用户生物特征信息，根据用户生物特征信息对用户进行身份识别，并在身份识别成功时，调用业务中台根据用户体验中台中的更新后的用户标签，生成目标展示页面。能够实时完成用户信息的更新，并依据更新后的用户信息以及营销模型，提供针对不同用户的页面展示，提升用户体验。构建用户体验核心(UEC)，面向场景和生态，构建银行客户、潜客、开放生态用户的体系，实现用户视角的360度银行及生态全景信息视图及数据服务能力；建立用户成长体系，实现用户经营生态；建立行业、客户洞察分析体系及客户体验监测体系，形成客户旅程和用户体验闭环。这些是数据驱动重要体现。建立智能服务中台，形成AI即服务(AIaaS)能力，研发语音识别、计算机视觉以及自然语言处理领域的解决方案和组件服务，向各应用系统输出成熟的图像识别、人脸识别、语音识别、RPA等通用类AI能力形成，为客户感知、智能交互、流程自动化集约化提供支撑，是提升客户极致、智能体验的关键支撑。

在一个实施例中，用户行为数据包括：用户下单事件数据；系统还包括：企业管理层；

业务中台，还用于对用户下单事件数据进行统计和处理，生成多维营销数据信息，并将多维营销数据信息传输至企业管理设备。

具体地，当客户浏览H5页面中推送的营销产品后，形成下单事件，该事件实时获取到并通过事件平台，传递到数据中台，进行实时数据的加工和统计，并形成营销多维度数据，下发给业务中心的营销中心，营销中心形成营销数据大屏，供管理人员进行后续营销效果的评估和营销策略的调整。

在本实施例中，由于系统还包括：企业管理层；业务中台，还用于对用户下单事件数据进行统计和处理，生成多维营销数据信息，并将多维营销数据信息传输至企业管理设备。能够实现营销人员根据不同的营销效果进行更改营销策略。进一步利用了用户行为信息。

为了便于本领域技术人员的理解，现以一个实施例对银行业务信息更新系统进一步说明，在一个实施例中，如图26所示，银行业务信息更新系统，包括：

交互层、中枢层、基础层、企业管理层；其中，基础层包括：金融核心平台和数据平台；中枢层包括：数据中台；业务中台；智能服务中台和用户体验中台；

交互层，用于采集用户基于交互平台触发的用户行为数据并将用户行为数据传输至基础层中；

金融核心平台，用于获取用户行为数据生成用户事件数据，并将用户事件数据传输至事件平台；

数据平台，用于根据用户事件数据进行数据清洗并整合，发布事件订阅信息至中枢层。

数据中台，用于根据事件订阅信息对当前营销模型进行迭代更新，直到达到预设迭代次数，确定目标营销模型；

数据中台，还用于根据事件订阅信息中的用户标签更新用户信息中的用户标签，并将更新后的用户标签传输至数据平台。

业务中台，用于将数据平台发送的事件订阅信息输入至数据中台部署的目标营销模型中，得到营销服务信息，并将营销服务信息发送至用户设备。

数据平台，还用于将更新后的用户标签更新至用户体验中台；

智能服务中台，用于获取用户生物特征信息，根据用户生物特征信息对用户进行身份识别，并在身份识别成功时，调用业务中台根据用户体验中台中的更新后的用户标签，生成目标展示页面。

业务中台，还用于对用户下单事件数据进行统计和处理，生成多维营销数据信息，并将多维营销数据信息传输至企业管理设备。

具体地，银行业务信息更新系统的系统架构可参见图26。以银行零售线上营销的场景的四条动线为例描述事件驱动的面向服务架构的总体架构设计以及各个分层、各个系统、各个组件的功能分工和数据流向。

(1)数据驱动线：客户在各个渠道侧的操作行为和后台的金融类(服务签约、产品下单、账务流水等)事件都实时的感知、实时落地、实时传递给事件平台，事件平台经过初步的数据清洗、整合之后准实时的传递给数据中台，数据中台进行客户标签的更新、营销模型的迭代，然后数据中台将最新的客户标签准实时传递给事件平台，事件平台准实时下发给用户体验核心、业务中台更新本地的最新的客户标签信息，数据中台实时下发最新的营销模型给业务中台的营销中心。至此客户标签和营销模型已经根据当日的客户的热数据完成了更新和迭代。

(2)事件式营销线：当客户发生一笔代发工资的事件之后，该事件通过事件平台实时传递到业务中的营销中心，营销中心触发最新的营销模型进行预测，选择合适的渠道、合适的时间段，发生合适的营销活动或产品至客户。

(3)千人千面线：当客户收到并点击营销短信链接后，进行了H5页面的展示，此时渠道调用了智能服务中台完成了生物识别和智能化交互之后，渠道从用户体验核心拿到最新的客户标签数据，然后调用业务中台的营销中心组织形成该客户最新的适合于该客户特点的个性化展示页面，形成了千人千面的效果。

(4)营销闭环线：当客户浏览H5页面中推送的营销产品后，形成下单事件，该事件实时获取到并通过事件平台，传递到数据中台，进行实时数据的加工和统计，并形成营销多维度数据，下发给业务中心的营销中心，营销中心形成营销数据大屏，供管理人员进行后续营销效果的评估和营销策略的调整。

在本实施例中，通过采集用户基于交互平台触发的用户行为数据，对用户行为数据进行数据清洗并整合，得到用户事件数据，根据用户事件数据，更新当前用户信息以及当前营销模型。能够不仅满足原有SOA架构的系统中，通过较为刚性的接口连接的系统架构，仅传输预设接口对应的交易数据等，还能够对用户基于交互平台产程的不同用户行为数据实时的更新，以便实时更新用户信息，避免了银行业务系统的数据之间是相对独立的，每个业务系统拥有单独的功能组件和数据集市，系统间的彼此隔离。满足不同业务场景中系统间的信息交互的需求。避免数据积累出现孤岛化、无序化。以上的所有功能和数据的传递加工均基于实时的热数据进行，并可以根据需要动态调整获取和传递的内容，以及加工的逻辑，解决了原有SOA架构下数据传递的时效性和灵活性的痛点。

基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的银行业务信息更新方法的银行业务信息更新装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个银行业务信息更新装置实施例中的具体限定可以参见上文中对于银行业务信息更新方法的限定，在此不再赘述。

在一个实施例中，如图27所示，提供了一种银行业务信息更新装置，包括：

采集模块271，用于采集用户基于交互平台触发的用户行为数据；

第一确定模块272，用于对用户行为数据进行数据清洗并整合，得到用户事件数据；

更新模块273，用于根据用户事件数据，更新当前用户信息以及当前营销模型。

在本实施例中，通过采集模块采集用户基于交互平台触发的用户行为数据，第一确定模块对用户行为数据进行数据清洗并整合，得到用户事件数据，更新模块根据用户事件数据，更新当前用户信息以及当前营销模型。能够不仅满足原有SOA架构的系统中，通过较为刚性的接口连接的系统架构，仅传输预设接口对应的交易数据等，还能够对用户基于交互平台产程的不同用户行为数据实时的更新，以便实时更新用户信息，避免了银行业务系统的数据之间是相对独立的，每个业务系统拥有单独的功能组件和数据集市，系统间的彼此隔离。满足不同业务场景中系统间的信息交互的需求。避免数据积累出现孤岛化、无序化。

在一个实施例中，更新模块，包括：

生成单元，用于根据用户事件数据，生成事件订阅信息；

更新单元，用于根据事件订阅信息，更新当前的用户信息以及当前营销模型

在一个实施例中，用户信息包括：用户标签；更新单元，具体用于将事件订阅信息输入至当前营销模型中进行迭代更新，直到达到预设迭代次数，确定目标营销模型；根据事件订阅信息中的用户标签更新用户信息中的用户标签。

在一个实施例中，银行业务信息更新装置，还包括：

第二确定模块，用于将事件订阅信息输入至目标营销模型中，得到营销服务信息并发送至用户设备。

在一个实施例中，银行业务信息更新装置，还包括：

身份识别模块，用于获取用户生物特征信息，根据用户生物特征信息对用户进行身份识别；

页面生成模块，用于在身份识别成功时，根据更新后的用户标签，生成目标展示页面。

在一个实施例中，用户行为数据包括：用户下单事件数据；参见图C所示，银行业务信息更新装置，还包括：

营销数据信息生成模块，用于对用户下单事件数据进行统计和处理，生成多维营销数据信息，并将多维营销数据信息传输至企业管理设备。

上述银行业务信息更新装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

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

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

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory，ROM)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(ReRAM)、磁变存储器(Magnetoresistive Random Access Memory，MRAM)、铁电存储器(Ferroelectric Random Access Memory，FRAM)、相变存储器(Phase Change Memory，PCM)、石墨烯存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic RandomAccess Memory，DRAM)等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。

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

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

Claims (12)

1.一种银行业务信息更新方法，其特征在于，所述方法包括：

采集用户基于交互平台触发的用户行为数据；

对所述用户行为数据进行数据清洗并整合，得到用户事件数据；

根据所述用户事件数据，更新当前用户信息以及当前营销模型。

2.根据权利要求1所述的方法，其特征在于，所述根据所述用户事件数据，更新当前的用户信息以及当前营销模型，包括：

根据所述用户事件数据，生成事件订阅信息；

根据所述事件订阅信息，更新所述当前的用户信息以及所述当前营销模型。

3.根据权利要求2所述的方法，其特征在于，所述用户信息包括：用户标签；所述根据所述事件订阅信息，更新所述当前用户信息以及所述当前营销模型，包括：

将所述事件订阅信息输入至当前营销模型中进行迭代更新，直到达到预设迭代次数，确定目标营销模型；

根据所述事件订阅信息中的用户标签更新所述用户信息中的用户标签。

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

将所述事件订阅信息输入至所述目标营销模型中，得到营销服务信息并发送至用户设备。

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

获取用户生物特征信息，根据所述用户生物特征信息对用户进行身份识别；

在所述身份识别成功时，根据所述更新后的用户标签，生成目标展示页面。

6.根据权利要求1所述的方法，其特征在于，所述用户行为数据包括：用户下单事件数据；所述方法还包括：

对所述用户下单事件数据进行统计和处理，生成多维营销数据信息，并将所述多维营销数据信息传输至企业管理设备。

7.一种银行业务信息更新系统，其特征在于，所述系统包括：交互层、中枢层、基础层；

所述交互层，用于采集用户基于交互平台触发的用户行为数据并将所述用户行为数据传输至所述基础层中；

所述基础层，用于对所述用户行为数据进行数据清洗并整合，得到用户事件数据，根据所述用户事件数据生成事件订阅信息，并发布所述事件订阅信息至所述中枢层；

所述中枢层，用于根据所述事件订阅信息，更新当前的用户信息以及当前营销模型。

8.根据权利要求7所述的系统，其特征在于，所述基础层包括：金融核心平台和数据平台；

所述金融核心平台，用于获取所述用户行为数据生成用户事件数据，并将所述用户事件数据传输至所述事件平台；

所述数据平台，用于根据所述用户事件数据进行数据清洗并整合，发布事件订阅信息至所述中枢层。

9.根据权利要求8所述的系统，其特征在于，所述用户信息包括用户标签；所述中枢层包括：数据中台；

所述数据中台，用于根据所述事件订阅信息对当前营销模型进行迭代更新，直到达到预设迭代次数，确定目标营销模型；

所述数据中台，还用于根据所述事件订阅信息中的用户标签更新所述用户信息中的用户标签，并将更新后的用户标签传输至所述数据平台。

10.根据权利要求9所述的系统，其特征在于，所述中枢层，还包括：业务中台；

所述业务中台，用于将所述数据平台发送的所述事件订阅信息输入至所述数据中台部署的所述目标营销模型中，得到营销服务信息，并将营销服务信息发送至用户设备。

11.根据权利要求10所述的系统，其特征在于，所述中枢层还包括：智能服务中台和用户体验中台；

所述数据平台，还用于将更新后的用户标签更新至所述用户体验中台；

所述智能服务中台，用于获取用户生物特征信息，根据所述用户生物特征信息对用户进行身份识别，并在身份识别成功时，调用所述业务中台根据所述用户体验中台中的所述更新后的用户标签，生成目标展示页面。

12.根据权利要求10所述的系统，其特征在于，所述用户行为数据包括：用户下单事件数据；所述系统还包括：企业管理层；

所述业务中台，还用于对所述用户下单事件数据进行统计和处理，生成多维营销数据信息，并将所述多维营销数据信息传输至企业管理设备。

Images