银行业数据的处理方法、系统、终端设备及计算机存储介质

技术领域

本申请涉及银行业数据处理领域，尤其涉及一种银行业数据的处理方法、系统、终端设备及可读存储介质。

背景技术

随着数据作为新的生产要素得到广泛认识和深入应用，以银行业为代表的商业创新力量，基于数据驱动的业务比重越来越大、业务需求越来越多样、数据规模更是呈现爆炸性增长，因此，需要立足于银行业务，建设一套具备银行专业知识库、业务标签与规则建议的智能建模系统，降低银行数据模型设计的学习门槛、开发成本，并从银行业务角度在模型设计中提供安全合规建议和配套规则管控。

然而，传统数据建模及开发系统，主要提供库表结构的可视化设计、逻辑化设计、代码编写，是一种通用的类数据库开发的方案，不能解决多类型数据库、集群的重复开发问题，导致银行业数据进行处理分析的效率较低以及成本较高。例如，在银行业中，各类数据库及数据引擎普遍仍以SQL(Structured Query Language，结构化查询语言)作为开发语言，但是由于底层存储计算架构的差异、计算模型的差异、数据格式的差异等原因，各种大数据开源软件对SQL的要求和语法都不一样，比如Hive、Apache Spark SQL、GaussDB等。而基于场景考虑，应用系统针对存储计算效率和成本的差异，会同时采用不同的组件部署策略，可能同时使用不同的数据库工具、但其上会存储相同的数据，这导致一套业务需要在不同数据库上建模。而要实现这一目的，需要数据开发掌握多种数据库建模语言，并理解其最佳的设计实践，带来了极大的使用成本和效率瓶颈。

发明内容

本申请的主要目的在于提供一种银行业数据的处理方法、系统、终端设备及可读存储介质，旨在解决对银行业数据进行处理分析的效率低和成本高的技术问题。

为实现上述目的，本申请提供了一种银行业数据的处理方法，所述银行业数据的处理方法包括：

通过统一的语法规范，生成多个不同数据库的数据库建模需求信息；

根据各个所述数据库的数据库建模需求信息，并结合统一的逻辑建模结构，建立银行业专业知识库，其中，所述银行业专业知识库中包括字典、数据项，以及所述数据项对应的码值定义，所述字典包括词根字典和术语字典；

获取待处理的银行业数据，通过所述银行业专业知识库，将所述银行业数据对应的数据逻辑模型，翻译为所述银行业数据对应的数据物理模型；

根据所述数据物理模型，生成适配各个所述数据库的建模语句；

将所述建模语句输入至各个所述数据库对应的数据库环境进行执行，得到综合执行结果，将所述综合执行结果作为对银行业数据进行分析处理的结果。

可选地，所述通过所述银行业专业知识库，将所述银行业数据对应的数据逻辑模型，翻译为所述银行业数据对应的数据物理模型的步骤包括：

通过所述银行业专业知识库，将所述银行业数据对应的数据逻辑模型进行初始化标记，并输出预设的标签引导确认界面；

在接收到响应于所述标签引导确认界面而输入的确认指令后，根据初始化标记后的数据逻辑模型，生成所述银行业数据对应的多个预设目标属性，其中，所述预设目标属性包括业务标签和数据分布形态；

根据所述银行业数据对应的各所述预设目标属性，确定所述银行业数据对应的数据物理模型。

可选地，所述根据所述银行业数据对应的各所述预设目标属性，确定所述银行业数据对应的数据物理模型的步骤包括：

根据所述银行业数据对应的各所述预设目标属性，从所述银行业专业知识库检索得到所述银行业数据匹配的业务合规指标，其中，所述业务合规指标包括所述预设目标属性对应的取值范围信息、安全合规信息和监管要求信息；

根据所述业务合规指标，对所述银行业数据进行多集群的模型布控，得到所述银行业数据对应的数据物理模型。

可选地，所述根据所述数据物理模型，生成适配各个所述数据库的建模语句的步骤包括：

获取各个所述数据库对应的数据库特性，根据各个所述数据库对应的数据库特性，分别对所述数据物理模型进行模型优化和配置补充，得到与各个所述数据库各自适配的目标物理模型；

基于各个所述数据库各自适配的目标物理模型，生成适配各个所述数据库的建模语句；

其中，所述模型优化包括对所述数据物理模型的字段信息、主键与分布键信息的优化，所述配置补充包括对所述数据物理模型的生命周期、存储类型与分片规则的补充。

可选地，所述将所述建模语句输入至各个所述数据库对应的数据库环境进行执行，得到综合执行结果的步骤包括：

将所述建模语句输入至各个所述数据库对应的数据库环境，输出得到各个所述数据库环境对应的模型执行指令信息，其中，所述数据库环境包括数据库类型信息，所述模型执行指令信息为新建模型或者变更模型；

执行各所述模型执行指令信息适配的语句策略，得到综合执行结果。

可选地，在所述将所述银行业数据对应的数据逻辑模型，翻译为所述银行业数据对应的数据物理模型的步骤之前，所述方法还包括：

对所述银行业数据对应的数据逻辑模型进行规范性检查；

在所述银行业数据对应的数据逻辑模型中将所述规范性检查出的非规范信息进行校正更新。

可选地，所述获取待处理的银行业数据的步骤包括：

获取端到端输入的映射源银行业务数据；

通过所述映射源银行业务数据，结合事实模型设计和维度模型设计，筛选分析得到银行业的数仓核心数据；

将所述数仓核心数据，作为待处理的银行业数据。

此外，为实现上述目的，本申请还提供一种银行业数据的处理系统，所述系统包括：

语义定义模块，用于通过统一的语法规范，生成多个不同数据库的数据库建模需求信息；

逻辑设计模块，用于根据各个所述数据库的数据库建模需求信息，并结合统一的逻辑建模结构，建立银行业专业知识库，其中，所述银行业专业知识库中包括字典、数据项，以及所述数据项对应的码值定义，所述字典包括词根字典和术语字典；

物理转换模块，用于获取待处理的银行业数据，通过所述银行业专业知识库，将所述银行业数据对应的数据逻辑模型，翻译为所述银行业数据对应的数据物理模型；

语句生成模块，用于根据所述数据物理模型，生成适配各个所述数据库的建模语句；

语句执行模块，用于将所述建模语句输入至各个所述数据库对应的数据库环境进行执行，得到综合执行结果，将所述综合执行结果作为对银行业数据进行分析处理的结果。

此外，为实现上述目的，本申请还提供一种终端设备，所述终端设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的银行业数据的处理程序，所述银行业数据的处理程序被所述处理器执行时实现如上述的银行业数据的处理方法的步骤。

此外，为实现上述目的，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有银行业数据的处理程序，所述银行业数据的处理程序被处理器执行时实现如上述的银行业数据的处理方法的步骤。

本申请通过统一的语法规范，生成多个不同数据库的数据库建模需求信息，从而定义统一建模的语法规范、逻辑建模结构，并通过根据各个数据库的数据库建模需求信息，并结合统一的逻辑建模结构，建立银行业专业知识库，其中，该银行业专业知识库中包括字典、数据项，以及所述数据项对应的码值定义，所述字典包括词根字典和术语字典，然后获取待处理的银行业数据，通过银行业专业知识库，将银行业数据对应的数据逻辑模型，翻译为银行业数据对应的数据物理模型，从而采用统一语义建立逻辑模型，根据要建模的数据库，将逻辑模型翻译为对应数据库的物理模型，再通过根据数据物理模型，生成适配各个数据库的建模语句，从而实现根据物理模型，系统自动生成不同数据库的建模语句，并将建模语句输入至各个数据库对应的数据库环境进行执行，得到综合执行结果，将综合执行结果作为对银行业数据进行分析处理的结果，从而提供一种统一语义的逻辑化建模方法，本申请的数据开发只需定义一次业务模型、系统自动转换生成多引擎多集群的模型和任务，实现一次开发、多集群部署，大幅提升建模效率以及模型的可迁移性，并且降低数据开发的学习成本。

也即，本申请中银行业数据的处理方法可实现统一语义的数据逻辑化建模，通过统一标准的建模语义，满足各种不同数据库的建模需求，用户无需关心数据库的语法差异，能够使用统一语义完成不同数据库的建模。并且，通过统一语义语法的建模，可实现一次定义、多数据库同时建模，大幅提升建模效率，体现了逻辑建模的可复制性与可迁移性，同时统一语义支持扩展，实现不同数据库的兼容，降低了银行业数据在不同数据库上建模的成本和效率，进而有效解决了对银行业数据进行处理分析的效率低和成本高的技术问题。

附图说明

图1是本申请实施例方案涉及的硬件运行环境的终端设备的结构示意图；

图2为本申请银行业数据的处理方法第一实施例的流程示意图；

图3为本申请银行业数据的处理方法第二实施例的流程示意图；

图4为本申请银行业数据的处理方法第三实施例的流程示意图；

图5为本申请银行业数据的处理方法第四实施例的流程示意图；

图6为本申请银行业数据的处理系统一实施例涉及的功能模块示意图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

参照图1，图1为本申请实施例方案涉及的硬件运行环境的终端设备结构示意图。

需要说明的是，本申请实施例终端设备可以是执行本申请银行业数据的处理方法的设备，该终端设备具体可以是内部包含有银行业数据的处理系统的终端设备。

如图1所示，该终端设备可以包括：处理器1001，例如中央处理器(CentralProcessing Unit，CPU)，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(WIreless-FIdelity，WI-FI)接口)。存储器1005可以是高速的随机存取存储器(RandomAccess Memory，RAM)存储器，也可以是稳定的非易失性存储器(Non-Volatile Memory，NVM)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的结构并不构成对终端设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种存储介质的存储器1005中可以包括操作系统、数据存储模块、网络通信模块、用户接口模块以及银行业数据的处理程序。

在图1所示的终端设备中，网络接口1004主要用于与其他设备进行数据通信；用户接口1003主要用于与用户进行数据交互；本申请终端设备中的处理器1001、存储器1005可以设置在终端设备中，所述终端设备通过处理器1001调用存储器1005中存储的银行业数据的处理程序，并执行以下操作：

通过统一的语法规范，生成多个不同数据库的数据库建模需求信息；

根据各个所述数据库的数据库建模需求信息，并结合统一的逻辑建模结构，建立银行业专业知识库，其中，所述银行业专业知识库中包括字典、数据项，以及所述数据项对应的码值定义；

获取待处理的银行业数据，通过所述银行业专业知识库，将所述银行业数据对应的数据逻辑模型，翻译为所述银行业数据对应的数据物理模型；

根据所述数据物理模型，生成适配各个所述数据库的建模语句；

将所述建模语句输入至各个所述数据库对应的数据库环境进行执行，得到综合执行结果，将所述综合执行结果作为对银行业数据进行分析处理的结果。

进一步地，处理器1001调用存储器1005中存储的银行业数据的处理程序，还执行以下操作：

通过所述银行业专业知识库，将所述银行业数据对应的数据逻辑模型进行初始化标记，并输出预设的标签引导确认界面；

在接收到响应于所述标签引导确认界面而输入的确认指令后，根据初始化标记后的数据逻辑模型，生成所述银行业数据对应的多个预设目标属性，其中，所述预设目标属性包括业务标签和数据分布形态；

根据所述银行业数据对应的各所述预设目标属性，确定所述银行业数据对应的数据物理模型。

进一步地，处理器1001调用存储器1005中存储的银行业数据的处理程序，还执行以下操作：

根据所述银行业数据对应的各所述预设目标属性，从所述银行业专业知识库检索得到所述银行业数据匹配的业务合规指标，其中，所述业务合规指标包括所述预设目标属性对应的取值范围信息、安全合规信息和监管要求信息；

根据所述业务合规指标，对所述银行业数据进行多集群的模型布控，得到所述银行业数据对应的数据物理模型。

进一步地，处理器1001调用存储器1005中存储的银行业数据的处理程序，还执行以下操作：

获取各个所述数据库对应的数据库特性，根据各个所述数据库对应的数据库特性，分别对所述数据物理模型进行模型优化和配置补充，得到与各个所述数据库各自适配的目标物理模型；

基于各个所述数据库各自适配的目标物理模型，生成适配各个所述数据库的建模语句；

其中，所述模型优化包括对所述数据物理模型的字段信息、主键与分布键信息的优化，所述配置补充包括对所述数据物理模型的生命周期、存储类型与分片规则的补充。

进一步地，处理器1001调用存储器1005中存储的银行业数据的处理程序，还执行以下操作：

将所述建模语句输入至各个所述数据库对应的数据库环境，输出得到各个所述数据库环境对应的模型执行指令信息，其中，所述数据库环境包括数据库类型信息，所述模型执行指令信息为新建模型或者变更模型；

执行各所述模型执行指令信息适配的语句策略，得到综合执行结果。

进一步地，处理器1001调用存储器1005中存储的银行业数据的处理程序，还执行以下操作：

对所述银行业数据对应的数据逻辑模型进行规范性检查；

在所述银行业数据对应的数据逻辑模型中将所述规范性检查出的非规范信息进行校正更新。

进一步地，处理器1001调用存储器1005中存储的银行业数据的处理程序，还执行以下操作：

获取端到端输入的映射源银行业务数据；

通过所述映射源银行业务数据，结合事实模型设计和维度模型设计，筛选分析得到银行业的数仓核心数据；

将所述数仓核心数据，作为待处理的银行业数据。

基于上述的终端设备，提供本申请银行业数据的处理方法的整体构思。

目前，传统数据建模及开发系统，主要提供库表结构的可视化设计、逻辑化设计、代码编写，是一种通用的类数据库开发的方案，不能解决多类型数据库、集群的重复开发问题，导致银行业数据进行处理分析的效率较低以及成本较高。例如，在银行业中，各类数据库及数据引擎普遍仍以SQL(Structured Query Language，结构化查询语言)作为开发语言，但是由于底层存储计算架构的差异、计算模型的差异、数据格式的差异等原因，各种大数据开源软件对SQL的要求和语法都不一样，比如Hive、Apache Spark SQL、GaussDB等。而基于场景考虑，应用系统针对存储计算效率和成本的差异，会同时采用不同的组件部署策略，可能同时使用不同的数据库工具、但其上会存储相同的数据，这导致一套业务需要在不同数据库上建模。而要实现这一目的，需要数据开发掌握多种数据库建模语言，并理解其最佳的设计实践，带来了极大的使用成本和效率瓶颈。

具体地，针对应用或数据仓库同时使用Gauss、Hadoop等多种计算存储引擎、每个计算引擎可能又有多个集群的架构，用户的业务场景要求导致一个业务模型需要在不同引擎不同集群上都要单独开发，开发效率低且一致性很难保障。不同数据库及引擎有不同语法和规范要求，学习成本高、使用门槛高。

针对上述现象，本申请提出了一种银行业数据的处理方法，所述银行业数据的处理方法包括：通过统一的语法规范，生成多个不同数据库的数据库建模需求信息；根据各个所述数据库的数据库建模需求信息，并结合统一的逻辑建模结构，建立银行业专业知识库，其中，所述银行业专业知识库中包括字典、数据项，以及所述数据项对应的码值定义；获取待处理的银行业数据，通过所述银行业专业知识库，将所述银行业数据对应的数据逻辑模型，翻译为所述银行业数据对应的数据物理模型；根据所述数据物理模型，生成适配各个所述数据库的建模语句；将所述建模语句输入至各个所述数据库对应的数据库环境进行执行，得到综合执行结果，将所述综合执行结果作为对银行业数据进行分析处理的结果。

如此，本申请实施例中银行业数据的处理方法可实现统一语义的数据逻辑化建模，通过统一标准的建模语义，满足各种不同数据库的建模需求，用户无需关心数据库的语法差异，能够使用统一语义完成不同数据库的建模。并且，通过统一语义语法的建模，可实现一次定义、多数据库同时建模，大幅提升建模效率，体现了逻辑建模的可复制性与可迁移性，同时统一语义支持扩展，实现不同数据库的兼容，降低了银行业数据在不同数据库上建模的成本和效率，进而有效解决了对银行业数据进行处理分析的效率低和成本高的技术问题。

基于上述的终端设备和本申请银行业数据的处理方法的整体构思，进一步提出本申请银行业数据的处理方法的各个实施例。

请参照图2，图2为本申请银行业数据的处理方法第一实施例的流程示意图。

应当理解的是，虽然在流程图中示出了逻辑顺序，但是在某些情况下，本申请银行业数据的处理方法当然也可以以不同于此处的顺序执行所示出或描述的步骤。

如图2所示，在本实施例中，本申请银行业数据的处理方法，可以包括以下步骤：

步骤S10：通过统一的语法规范，生成多个不同数据库的数据库建模需求信息；

在本实施例中，首先定义统一建模的语法规范，例如采用SQL92为基础，对GaussDB、Hadoop等标准语法、关键字、数据类型进行兼容，为用户提供统一的建模语言，从而针对多个不同数据库的特性，结合该定义的统一语法规范，生成多个不同数据库的数据库建模需求信息。

步骤S20：根据各个所述数据库的数据库建模需求信息，并结合统一的逻辑建模结构，建立银行业专业知识库；

其中，所述银行业专业知识库中包括字典、数据项，以及所述数据项对应的码值定义，所述字典包括词根字典和术语字典。

在本实施例中，需要根据各个数据库的数据库建模需求信息，并结合统一的逻辑建模结构，来构建银行业专业知识库，其中，该银行业专业知识库中包括字典、数据项，以及数据项对应的码值定义，所述字典包括词根字典和术语字典。当然，该银行业专业知识库还可包括数据项对应的设计规范、所属主题与业务领域标签，以及分类分级的质量与管理规范、逻辑与物理模型转换规范等。

本实施例通过采用统一语义，建立逻辑模型的设计原则，实现统一语义的逻辑模型设计，便于用户完成逻辑模型设计。

具体地，为了更助于理解，以下进行进一步描述：

在本实施例中，词根字典包括主要业务的词根及中英文定义，如账户、机构、交易、贴现、对公等等，如下的表(一)为词根示例：

(一)

术语字典是根据国家制定的银行行业标准，提取常见约定术语的中文及英文全拼或缩写，相比于词根更具有银行行业通用意义，如下的表(二)为术语字典示例：

(二)

在本实施例中，术语、以及银行业主数据的一些数据项(数据项可根据词根组合翻译)，可能存在一类特定情况，即其内容有约定的备选值，需要在知识库定义其码值。同时每一类数据项，均可以定义其所属主题，属于业务标签的一种，如下的表(三)为码值示例：

(三)

主题可以定义其所属的业务领域，用于业务领域相关的规则处理，如下的表(四)为主题示例：

(四)

需要说明的是，数据项的规则规范(即数据项对应的设计规范)分为业务规范与系统规范：

1、业务规范是指数据项有银行业特定管控或要求的。例如银行业统一标准的PII(Personal Identifiable Information，个人身份信息)信息、对敏感信息的安全级别、加密策略以及访问和扩散控制策略，还有如监管报送数据项的检查规则和口径定义，都属于业务规范。这类规范定义后，用于数据的管控，保障数据的使用和管理合规。

2、系统规范值将逻辑模型转换为物理模型时需考虑的内容，如根据常见的银行业模型数据分布形态，系统应生成不同形态的分区策略与时间戳标记，按照银行业规范要求的数据进行有效期、过期管控以及相关处理策略，系统应当为逻辑模型建立符合要求的多个物理模型，并自动配置其存储策略与数据分割等等。如下的表(五)为数据分布形态、有效期和约定物理字段的示例：

(五)

所述步骤S20之后，执行步骤S30：获取待处理的银行业数据，通过所述银行业专业知识库，将所述银行业数据对应的数据逻辑模型，翻译为所述银行业数据对应的数据物理模型；

本实施例通过根据要建模的数据库，将逻辑模型翻译为对应数据库的物理模型。具体地，例如按照GaussDB的语法进行翻译，将模型属性、字段属性、约束信息等映射到GaussDB的建表或建视图要素上，采用该种方式，将逻辑模型映射为物理模型，还可扩展支持其他多种数据库类型。

示例性地，所述获取待处理的银行业数据的步骤包括：

步骤A10，获取端到端输入的映射源银行业务数据；

步骤A20，通过所述映射源银行业务数据，结合事实模型设计和维度模型设计，筛选分析得到银行业的数仓核心数据；

步骤A30，将所述数仓核心数据，作为待处理的银行业数据。

本实施例通过获取端到端输入的映射源银行业务数据，再通过该映射源银行业务数据，结合事实模型设计和维度模型设计，筛选分析得到银行业的数仓核心数据，再将该数仓核心数据，作为待处理的银行业数据，从而使得本申请实施例在需要获取待处理的银行业数据时，通过端到端映射源数据与事实模型/维度模型，快速建立数仓主数据等核心数据，从而完成源端数据(即映射源银行业务数据)采集的过程，以获得该待处理的银行业数据，进而便于后续将待处理的银行业数据作为种子，通过知识库快速进行初始化标记，引导人工确认，最终完成业务标签和数据分布形态的标记。

进一步地，在所述将所述银行业数据对应的数据逻辑模型，翻译为所述银行业数据对应的数据物理模型的步骤之前，所述方法还包括：

步骤B10，对所述银行业数据对应的数据逻辑模型进行规范性检查；

步骤B20，在所述银行业数据对应的数据逻辑模型中将所述规范性检查出的非规范信息进行校正更新。

本实施例通过对银行业数据对应的数据逻辑模型进行规范性检查，并在银行业数据对应的数据逻辑模型中将规范性检查出的非规范信息进行校正更新，从而使得本申请实施例在建立逻辑模型后和翻译物理模型前，对逻辑模型的规范性进行检查，例如检查是否存在不恰当的命名、非标准的数据类型、过大的字段长度、缺失的必要属性等不规范情况。

所述步骤S30之后，执行步骤S40：根据所述数据物理模型，生成适配各个所述数据库的建模语句；

在本实施例中，系统已获取到所有要建模数据库的物理模型，可根据数据库的语法，结合物理模型的要素组装生成最终要执行的建模语句，每个数据库会生成自己独立的建模语句。

步骤S50：将所述建模语句输入至各个所述数据库对应的数据库环境进行执行，得到综合执行结果，将所述综合执行结果作为对银行业数据进行分析处理的结果。

在本实施例中，根据要建模数据库的环境配置，将建模语句提交到相应的数据库环境执行，并返回执行结果，返回的该执行结果即为对银行业数据进行分析处理的结果。

针对应用或数据仓库同时使用Gauss、Hadoop等多种计算存储引擎、每个计算引擎可能又有多个集群的架构，用户的业务场景要求导致一个业务模型需要在不同引擎不同集群上都要单独开发，开发效率低且一致性很难保障；不同数据库及引擎有不同语法和规范要求，学习成本高、使用门槛高。

而本实施例通过统一的语法规范，生成多个不同数据库的数据库建模需求信息，从而定义统一建模的语法规范、逻辑建模结构，并通过根据各个数据库的数据库建模需求信息，并结合统一的逻辑建模结构，建立银行业专业知识库，其中，该银行业专业知识库中包括字典、数据项，以及所述数据项对应的码值定义，所述字典包括词根字典和术语字典，然后获取待处理的银行业数据，通过银行业专业知识库，将银行业数据对应的数据逻辑模型，翻译为银行业数据对应的数据物理模型，从而采用统一语义建立逻辑模型，根据要建模的数据库，将逻辑模型翻译为对应数据库的物理模型，再通过根据数据物理模型，生成适配各个数据库的建模语句，从而实现根据物理模型，系统自动生成不同数据库的建模语句，并将建模语句输入至各个数据库对应的数据库环境进行执行，得到综合执行结果，将综合执行结果作为对银行业数据进行分析处理的结果，从而提供一种统一语义的逻辑化建模方法，本申请实施例的数据开发只需定义一次业务模型、系统自动转换生成多引擎多集群的模型和任务，实现一次开发、多集群部署，大幅提升建模效率以及模型的可迁移性，并且降低数据开发的学习成本。

也即，本申请实施例中银行业数据的处理方法可实现统一语义的数据逻辑化建模，通过统一标准的建模语义，满足各种不同数据库的建模需求，用户无需关心数据库的语法差异，能够使用统一语义完成不同数据库的建模。并且，通过统一语义语法的建模，可实现一次定义、多数据库同时建模，大幅提升建模效率，体现了逻辑建模的可复制性与可迁移性，同时统一语义支持扩展，实现不同数据库的兼容，降低了银行业数据在不同数据库上建模的成本和效率，进而有效解决了对银行业数据进行处理分析的效率低和成本高的技术问题。

进一步地，基于上述本申请银行业数据的处理方法的第一实施例，在此提出本申请银行业数据的处理方法第二实施例。

请参照图3，图3为本申请银行业数据的处理方法第二实施例的流程示意图。如图3所示，在上述步骤S30中，所述通过所述银行业专业知识库，将所述银行业数据对应的数据逻辑模型，翻译为所述银行业数据对应的数据物理模型的步骤包括：

步骤S31：通过所述银行业专业知识库，将所述银行业数据对应的数据逻辑模型进行初始化标记，并输出预设的标签引导确认界面；

步骤S32：在接收到响应于所述标签引导确认界面而输入的确认指令后，根据初始化标记后的数据逻辑模型，生成所述银行业数据对应的多个预设目标属性，其中，所述预设目标属性包括业务标签和数据分布形态；

步骤S33：根据所述银行业数据对应的各所述预设目标属性，确定所述银行业数据对应的数据物理模型。

本实施例通过银行业专业知识库，将银行业数据对应的数据逻辑模型进行初始化标记，并输出预设的标签引导确认界面，在接收到响应于标签引导确认界面而输入的确认指令后，根据初始化标记后的数据逻辑模型，生成银行业数据对应的多个预设目标属性，其中，预设目标属性包括业务标签和数据分布形态，再根据银行业数据对应的各个预设目标属性，确定银行业数据对应的数据物理模型，从而通过银行业数据对应的数据逻辑模型作为种子，通过知识库快速进行初始化标记，引导人工确认，最终完成业务标签、数据分布形态等预设目标属性的标记。

为了更助于理解，列举具体实施例一进行进一步描述：

本实施例需要进行源端数据标准管理。具体地，在源端数据采集时，除进行字段映射、端到端配置并隐藏底层细节、推荐术语、业务打标，以及标记数据分布形态外，还需要对业务数据来源进行符合银行业的标准定义，包括所属银行业的领域、影响的报送条目等。

本实施例需要建立源端数据采集与标记策略，通过端到端映射源数据与事实模型/维度模型，快速建立数仓主数据等核心数据资产，并将该类数据作为种子，通过知识库快速进行初始化标记，引导人工确认。最终完成业务标签、数据分布形态等的标记。

具体地，端到端映射源数据与事实模型/维度模型是基于银行业数据架构特性的高度自动化方案：

(1)由用户快速配置数据映射后，系统自动通过源端数据模型建立贴源数据层后，映射生成事实模型与维度模型，无需人工再进行开发。在映射生成过程中，人工标记源端数据的数据分布形态，系统通过知识库关键字检查二次确认后，将根据数据分布形态自动生成增量、全量的过程模型与数据。

(2)通过快速映射生成事实、维度模型后，系统根据知识库自动匹配关键词，生成符合数据规范的字段中英文定义，并标记识别到的业务标签。同时引导人工标记业务所属的领域，以及可能影响的监管和报送条目。同时系统自动根据映射关系，将源端定义的业务标签传递到事实模型与维度模型，包括业务领域、码值定义和分类分级安全标签等等；

(3)通过上述采集的事实/维度模型，具有符合银行业标准的术语定义的相关特征，同时具有业务、安全、监管等多维度标记。

进一步地，对采集的数据，可按业务需要进行进一步的数据处理，即加工建模。加工建模包括模型设计与数据加工逻辑处理两部分，此时应按业务需求，定义模型的名称、字段和数据分布形态，标记银行业务、质量与时效级别、安全级别和监管要求等标签，然后完成数据加工处理逻辑的编写。其中：

步骤一、加工建模首先需按业务需求，创建逻辑模型，包括名称、字段和数据分布形态。在开发过程中，系统自动检索知识库，自动检查银行业术语一致性和中英文匹配度，并自动补充银行业特有数据项的码值配置等属性信息。用户还可在此阶段标记银行业务、质量与时效级别、安全级别和监管要求等标签。

步骤二、用户通过系统提供的低代码可视化方式完成逻辑模型设置后，系统自动检索知识库的银行业模型形态，自动补齐物理字段等信息，然后通过统一语义代码模块生成多引擎的物理模型代码。该模块适配多种数据库如GaussDB、Hadoop、Oracle等等类型系统的语法规范，根据结构化定义的物理模型定义，生成适配各数据库并可执行的建模代码(即建模语句)，生成时根据创建和变更等不同的场景，会选择各数据库不同的代码实现，按照物理模型定义，结合业务和数据架构(即数据库特性)的需要分发到多引擎多集群进行创建。

步骤三、完成物理模型创建后，用户可按业务需求，通过系统提供的低代码可视化方式完成模型的数据处理逻辑编写。系统的低代码可视化配置支持按语句、算子结构录入处理逻辑，完成后自动解析识别当前模型的数据来源，以及分析字段计算关系。

步骤四、识别到数据来源后，可提取来源模型和字段的业务标签，分析字段计算关系的种类，判断标签的传递性：如果计算关系属于引用或简单加工，则表示业务含义未变化，可以传递相关标签；如果计算关系属于复杂加工，则业务含义可能变化，需辅助提醒用户进行判断：如判断结果为业务含义未变化，则传递相关标签；如判断业务含义变化，则不传递相关标签。

其中，可传递的业务标签包括：所属银行业业务领域、质量与时效级别、安全级别、监管要求等等。系统判断传递的业务标签，需要与用户逻辑模型设计时标记的情况进行比对，缺失的自动补齐，有冲突的则辅助提醒用户进行判断。

步骤五、模型结构、加工逻辑、模型标签确定后，系统自动完成多集群的模型部署。

本实施例构建了银行业的专业知识库，在模型设计中提供术语翻译、业务标签生成、业务规则生成等多层次模型设计，通过低代码可视化的逻辑建模方法，让数据开发从业务需求出发，只需关注逻辑模型设计，系统会自动根据逻辑模型生成符合银行业数据标准的物理模型。用户只需定义一次业务模型便自动转换生成多引擎多集群的模型和任务，实现一次开发、多集群部署，大幅提升建模效率以及模型的可迁移性，并大大降低数据开发的学习成本。

需要说明的是，上述具体实施例一虽然示出了诸多技术细节，但仅用于辅助理解本申请的技术构思，并不构成对本申请银行业数据的处理方法的限定，基于此技术构思进行更多形式的简单变换，均在本申请的保护范围内。

在一种可能的实施方式中，所述步骤S33：根据所述银行业数据对应的各所述预设目标属性，确定所述银行业数据对应的数据物理模型包括：

步骤C10，根据所述银行业数据对应的各所述预设目标属性，从所述银行业专业知识库检索得到所述银行业数据匹配的业务合规指标，其中，所述业务合规指标包括所述预设目标属性对应的取值范围信息、安全合规信息和监管要求信息；

步骤C20，根据所述业务合规指标，对所述银行业数据进行多集群的模型布控，得到所述银行业数据对应的数据物理模型。

随着数据作为新的生产要素得到广泛认识和深入应用，以银行业为代表的商业创新力量，基于数据驱动的业务比重越来越大、业务需求越来越多样、数据规模更是呈现爆炸性增长，因此，需要立足于银行业务，建设一套具备银行专业知识库、业务标签与规则建议的智能建模系统，降低银行数据模型设计的学习门槛、开发成本，并从银行业务角度在模型设计中提供安全合规建议和配套规则管控。

基于此，本申请实施例根据银行业数据对应的各预设目标属性，从银行业专业知识库检索得到银行业数据匹配的业务合规指标，其中，该业务合规指标包括所述预设目标属性对应的取值范围信息、安全合规信息和监管要求信息，并根据该业务合规指标，对银行业数据进行多集群的模型布控，得到银行业数据对应的数据物理模型，从而提供了一种构建具有业务标记的银行业数据模型的方法，通过建立银行业的专业知识库，从业务需求出发，让用户聚焦于模型结构设计、业务打标和业务规则生成，可实现一次定义、生成多层次模型，大幅提升构建银行业数据模型的效率同时，提升银行业模型的合规管控。

为了更助于理解，列举具体实施例二进行进一步描述：

本实施例需要对银行业数据进行加工建模。具体地，按业务需求定义逻辑模型的名称、字段、数据分布形态，通过知识库进行属性信息自动补齐。系统自动根据逻辑模型生成多引擎的物理模型代码。然后按业务需求，用户完成新模型的数据处理逻辑，系统会自动识别数据来源，并分析字段业务标签的传递性，对模型设计做复检，为用户推荐银行业务领域、质量与时效级别、安全级别、监管要求等标签，由用户确认后，系统自动完成多集群的模型部署。

本实施例需要对银行业数据进行业务规则推荐。具体地，基于模型的业务标签，检索银行业知识库、找到匹配的取值范围、安全合规、监管要求等业务规则，自动建议要生成的业务规则。用户确认后系统自动生成多引擎的物理规则，并完成多集群的模型布控。

具体地，完成模型结构和业务标签处理后，系统基于模型的业务标签，检索银行业知识库，推荐模型的业务管控规则包括：

(1)每个模型的字段，根据术语和数据项，需要生成取值范围校验、加密和访问策略检查、监管规则校验等多项业务规则。

(2)每个模型根据质量与时效级别、监管相关性等银行业特有合规要求，生成高级别的测试与布控规则、报送时效布控规则等等业务规则，保障数据及时、合规产出。

其中，生成业务规则由业务规则生成引擎处理，该引擎明确标准的规则定义，上述推荐生成时统一采用该定义，并以可视化低代码方式推荐用户进行确认、编辑。确认后的业务规则，由该引擎执行物理规则生成。该引擎以标准交互接口集成各执行系统，并提供扩展性配置，在生成物理规则时可适配各类系统完成具体业务规则的配置，以及各系统的运行触发与结果采集交互配置。

进一步地，本实施例对银行业数据进行模型加工解析。具体地。在加工建模中对模型进行复检，需要系统提供模型加工逻辑的解析能力，以识别当前模型的数据来源，并构建字段计算关系，进而分析数据来源模型的业务标签，分析字段业务标签的传递性，用于与建模时的自动推荐和人工打的业务标签做对比。

另外，物理模型生成时，需要处理数据结构、业务标签和业务规则。系统支持低代码可视化的配置方式，系统自动检查物理规范，并生成系统多引擎代码并部署到多集群：

其中，模型数据结构的物理代码生成分为两步：

(1)补齐信息生成物理模型及其代码：用户在系统完成逻辑模型设计后，系统检索知识库的银行业模型形态，自动补齐物理字段等信息，来生成物理模型。然后通过统一语义代码模块生成物理模型代码，该模块适配多数据库引擎的类型系统、语义规范，可自动将物理数据结构转换为多类型引擎的物理模型代码，包括生成匹配的建模代码，以及根据创建和变更等不同场景调整代码等。

(2)业务规则生成：在业务规则推荐中，需要基于模型的业务标签，自动建议要生成的业务规则。业务规则涉及码值检查、高级别测试与布控、敏感字段加密、敏感字段访问控制和防扩散策略、监管报送的数据规则校验与时效布控等。同时涉及的配置、执行系统普遍具有差异，因此需要构建业务规则生成引擎，由该引擎明确标准的规则定义，规则推荐时统一采用该定义、保障用户统一体验。配置后，在物理规则生成阶段，由该引擎完成对不同系统的适配，完成具体业务规则的配置，以及各系统运行触发与结果采集交互配置。

需要说明的是，上述具体实施例二虽然示出了诸多技术细节，但仅用于辅助理解本申请的技术构思，并不构成对本申请银行业数据的处理方法的限定，基于此技术构思进行更多形式的简单变换，均在本申请的保护范围内。

在一种可行的实施例中，上述步骤S40：根据所述数据物理模型，生成适配各个所述数据库的建模语句包括：

步骤D10，获取各个所述数据库对应的数据库特性，根据各个所述数据库对应的数据库特性，分别对所述数据物理模型进行模型优化和配置补充，得到与各个所述数据库各自适配的目标物理模型；

步骤D20，基于各个所述数据库各自适配的目标物理模型，生成适配各个所述数据库的建模语句；

步骤D30，其中，所述模型优化包括对所述数据物理模型的字段信息、主键与分布键信息的优化，所述配置补充包括对所述数据物理模型的生命周期、存储类型与分片规则的补充。

本实施例通过转换物理模型后，根据不同数据库的特性，系统自动进行物理模型优化和配置补充，优化会根据物理模型的字段信息、主键与分布键信息等，结合数据库的类型，补充物理模型的最优存储配置，例如模型的生命周期、存储类型与分片规则等，如图4所示。

进一步地，在一种可行的实施例中，在步骤S50中，将所述建模语句输入至各个所述数据库对应的数据库环境进行执行，得到综合执行结果的步骤包括：

步骤E10，将所述建模语句输入至各个所述数据库对应的数据库环境，输出得到各个所述数据库环境对应的模型执行指令信息，其中，所述数据库环境包括数据库类型信息，所述模型执行指令信息为新建模型或者变更模型；

步骤E20，执行各所述模型执行指令信息适配的语句策略，得到综合执行结果。

本实施例通过在转换物理模型后，根据要建立模型的数据库类型、新建还是变更模型，选择适配的语句策略，用于下一步生成建模语句，

为了更助于理解，列举具体实施例三，对本申请实施例的建模语句策略进行进一步描述，如图5所示：

1、在取得物理模型后，首先根据新建或变更选择不同的语句策略；

2、如果是新建，可直接根据物理模型对应数据库的语法，直接生成新建模型的语句；

3、如果是变更模型，需要进一步判断对应数据库是否可以使用alter语法并且满足可靠性要求；

4、如果可以使用alter语法，且alter语法变更过程中满足可撤销、可访问、数据一致等可靠性要求，则直接生成基于alter的模型变更语句。注意不同属性可能不能一次性变更，或需要使用类似alter的其他命令，因此可能生成多个变更语句；

5、如果不可以使用alter语法，则语句要采用先创建临时模型，再进行更名替换的策略。生成临时模型可直接采用新建模型语句，模型名需要采用系统缺省的模型名替换。在新建临时模型语句后，增加老模型更名为旧模型、临时模型更名为正式模型名的语句。不同数据库可能选择不同的生成策略，因此确定建模语句策略后，为不同数据库保留各自独立的语句，以便最终提交执行。

需要说明的是，上述具体实施例三虽然示出了诸多技术细节，但仅用于辅助理解本申请的技术构思，并不构成对本申请银行业数据的处理方法的限定，基于此技术构思进行更多形式的简单变换，均在本申请的保护范围内。

此外，为实现上述目的，本申请还提供一种银行业数据的处理系统，请参照图6，图6为本申请银行业数据的处理系统一实施例涉及的功能模块示意图，如图6所示，所述系统包括：

语义定义模块10，用于通过统一的语法规范，生成多个不同数据库的数据库建模需求信息；

逻辑设计模块20，用于根据各个所述数据库的数据库建模需求信息，并结合统一的逻辑建模结构，建立银行业专业知识库，其中，所述银行业专业知识库中包括字典、数据项，以及所述数据项对应的码值定义，所述字典包括词根字典和术语字典；

物理转换模块30，用于获取待处理的银行业数据，通过所述银行业专业知识库，将所述银行业数据对应的数据逻辑模型，翻译为所述银行业数据对应的数据物理模型；

语句生成模块40，用于根据所述数据物理模型，生成适配各个所述数据库的建模语句；

语句执行模块50，用于将所述建模语句输入至各个所述数据库对应的数据库环境进行执行，得到综合执行结果，将所述综合执行结果作为对银行业数据进行分析处理的结果。

可选地，物理转换模块30，还用于：

通过所述银行业专业知识库，将所述银行业数据对应的数据逻辑模型进行初始化标记，并输出预设的标签引导确认界面；

在接收到响应于所述标签引导确认界面而输入的确认指令后，根据初始化标记后的数据逻辑模型，生成所述银行业数据对应的多个预设目标属性，其中，所述预设目标属性包括业务标签和数据分布形态；

根据所述银行业数据对应的各所述预设目标属性，确定所述银行业数据对应的数据物理模型。

可选地，物理转换模块30，还用于：

根据所述银行业数据对应的各所述预设目标属性，从所述银行业专业知识库检索得到所述银行业数据匹配的业务合规指标，其中，所述业务合规指标包括所述预设目标属性对应的取值范围信息、安全合规信息和监管要求信息；

根据所述业务合规指标，对所述银行业数据进行多集群的模型布控，得到所述银行业数据对应的数据物理模型。

可选地，语句生成模块40，还用于：

获取各个所述数据库对应的数据库特性，根据各个所述数据库对应的数据库特性，分别对所述数据物理模型进行模型优化和配置补充，得到与各个所述数据库各自适配的目标物理模型；

基于各个所述数据库各自适配的目标物理模型，生成适配各个所述数据库的建模语句；

其中，所述模型优化包括对所述数据物理模型的字段信息、主键与分布键信息的优化，所述配置补充包括对所述数据物理模型的生命周期、存储类型与分片规则的补充。

可选地，语句执行模块50，还用于：

将所述建模语句输入至各个所述数据库对应的数据库环境，输出得到各个所述数据库环境对应的模型执行指令信息，其中，所述数据库环境包括数据库类型信息，所述模型执行指令信息为新建模型或者变更模型；

执行各所述模型执行指令信息适配的语句策略，得到综合执行结果。

可选地，银行业数据的处理系统还包括语义规范检查模块(未图示)，语义规范检查模块用于：

对所述银行业数据对应的数据逻辑模型进行规范性检查；

在所述银行业数据对应的数据逻辑模型中将所述规范性检查出的非规范信息进行校正更新。

可选地，物理转换模块30，还用于：

获取端到端输入的映射源银行业务数据；

通过所述映射源银行业务数据，结合事实模型设计和维度模型设计，筛选分析得到银行业的数仓核心数据；

将所述数仓核心数据，作为待处理的银行业数据。

此外，本申请还提供一种终端设备，所述终端设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的银行业数据的处理程序，所述银行业数据的处理程序被所述处理器执行时实现如上述的银行业数据的处理方法的步骤。

本申请终端设备的具体实施例与上述银行业数据的处理方法各实施例基本相同，在此不作赘述。

此外，本申请还提供一种计算机可读存储介质，该计算机可读存储介质上存储有银行业数据的处理程序，所述银行业数据的处理程序被处理器执行时实现如以上任一项实施例所述银行业数据的处理方法的步骤。

本申请计算机可读存储介质的具体实施例与上述银行业数据的处理方法各实施例基本相同，在此不作赘述。

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

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

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

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。