本文由中原银行大数据平台研发工程师白学余分享，主要介绍实时金融数据湖在中原银行的应用。主要内容包括：
1、背景概况
2、实时金融数据湖体系架构
3、场景实践
一、背景概况
首先简单介绍一下中原银行，它位于河南省郑州市，是河南省唯一的省级法人银行，是河南省最大的城市商业银行。2017 年 7 月 19 日在香港成功上市。中原银行在成立之初就将科技利行和科技兴行作为我行的战略，我行立志要成为一个科技银行和数据银行。我们一直在从事技术，也崇尚技术，希望用技术的手段来解决现在的问题。
本文将从实时金融数据湖的建设背景、体系架构、场景实践三个方面分享。
1.数据湖诞生的业务背景
■ 决策方式变迁
下面来看一下背景概况，我们认为现在的银行的决策方式正面临巨大的变迁。
- 首先，传统的银行数据分析主要集中在银行的收入、成本、利润的分配和应对监管部门的监管。这些数据分析非常复杂，但也存在一定的规律，它属于财务数据分析。随着互联网金融的不断发展，银行的业务不断受到挤压，如果仍然将数据分析集中在收入、成本、分配及监管方面，已经不能满足业务的需求。如今，更好的了解客户，收集大量的数据，做更多有针对性的营销和决策分析是当务之急。因此，现在银行的业务分析决策由传统的财务分析逐步转向面向 KYC 的分析。
- 其次，传统的银行业务主要依靠业务人员进行决策以满足业务的发展需求。但是随着银行业务的不断发展，各种各样的应用产生大量的多类型数据。仅仅依靠业务人员去做决策，已无法满足业务的需求。当前面临的问题更加复杂，影响因素也日渐增多，需要用更全面、智能的技术方式来进行解决。因此，银行需要将传统的纯业务人员决策方式转变为越来越多依靠机器智能的决策方式。
■ 问题分析
大数据的时代最大的特点就是数据量大、数据的类型多。在使用大规模数据的过程中涉及各种各样的技术，包括：
- 传统的面向财务分析离线数据分析
- 面向非财务的数据分析
- 面向事件或日志等频繁变更
- 实时性较高的数据分析
我们需要多样化的数字营销手段来描绘更全面、准确、科学的客户画像。同时，也需要实时风险决策技术来实时监控业务面临的风险、多模数据加工技术来有效支撑不同类型的数据，包括结构化数据、半结构化数据、非结构化数据等。当然也需要机器学习和人工智能技术来支持问题的智能分析和决策。
如此多的技术，加上数据驱动决策的场景，决定了当前银行的数据分析面临着一个巨大的变迁，从传统的面向财务的、面向离线的数据分析，逐步转向面向客户的、面向实时的数据分析。以上是实时金融数据湖建设的第一个观点。
2.数据湖诞生的技术背景
实时金融数据湖建设的第二个观点是，在银行体系下，面向规范化、精准加工的传统数仓体系，能够较好的解决财务分析等场景，并在很长时间内仍会是主流方案。
■ 传统数仓架构
下图展示的是传统的数仓架构。从下往上，依次是基础贴源层、公共数据的整合层、业务集市层和应用加工层。不同的层每天通过批的方式执行大量的运算，来得到业务想要的结果。银行很长时间内非常依赖传统的数仓体系，因为它非常好的解决了财务分析的问题。其特点也比较明显：
- 精准、规范
- 多层数据加工
- 口径统一
- T+1 数据处理
- 具备较高的性能
- 经过长时间积累沉淀
- 适合财务分析
以上是传统数据仓库的优势。当然它的缺点也比较明显：
- 变更困难
- 单位存储成本较高
- 不适合海量日志、行为等变更频繁，实时性高的数据
- 半结构化数据和非结构化数据兼容差
以上是实时金融数据湖建设的第二个观点，即传统的数据仓库有它的优势和不足，并将长期存在。
■ 数仓的变迁
实时金融数据湖建设的第三个观点是，面向 KYC、机器智能的分析，需要支持多类型数据、多时效数据、更加敏捷的使用，因此需要新的与数据仓库互补的架构体系。
3.实时金融数据湖的特点
通过以上介绍的三个观点引出今天介绍的主题，实时金融数据湖。 主要有三个特点：
- 第一，开放性。支持多类型场景，如 AI、非结构化、历史数据，海纳百川。
- 第二，时效性。具备有效的支持实时分析与实时决策的体系架构。
- 第三，融合性。与银行数据仓库技术架构融合，统一数据视图。
整体的实时金融数据湖是一个融合的数据湖，它的融合理念主要体现在以下 6 个方面：
- 第一，数据汇聚的融合，各种海量、多样数据汇聚的地方，包括结构化、半结构以及非结构数据。
- 第二，技术实现的融合，包含云计算、大数据、数据仓库的融合以及流计算和批处理技术的融合。
- 第三，规范设计的融合，数据模型主题设计灵活，同时支持 Schema-on-read 和 Schema-on-write 模式，支持多维、关系数据模型。
- 第四，数据管理的融合，数据湖和数仓元数据管理的统一以及用户开发体验的统一。
- 第五，物理位置的融合，可以是物理集中的单一大集群，也可以是物理分散，逻辑集中的逻辑集群。
- 第六，数据存储的融合，分析数据统一存储的技术平台，符合入湖仓标准的数据按照要求放入，降低存储和运维成本。
1
二、体系架构
1.实时金融数据湖架构
■ 功能架构
首先来看一下实时金融数据湖的功能架构。在功能上，包括数据源、统一的数据接入、数据存储、数据开发、数据服务和数据应用。
第一，数据源。不仅仅支持结构化数据，也支持半结构化数据和非结构化数据。
第二，统一数据接入。数据通过统一数据接入平台，按数据的不同类型进行智能的数据接入。
第三，数据存储。包括数据仓库和数据湖，实现冷热温智能数据分布。
第四，数据开发。包括任务开发，任务调度，监控运维，可视化编程。
第五，数据服务。包括交互式查询，数据 API，SQL 质量评估，元数据管理，血缘管理。
第六，数据应用。包括数字化营销，数字化风控，数据化运营，客户画像。
■ 逻辑架构
实时金融数据湖的逻辑架构主要有 4 层，包括存储层、计算层、服务层和产品层。
- 在存储层，有 MPP 数据仓库和基于 OSS/HDFS 的数据湖，可以实现智能存储管理。
- 在计算层，实现统一的元数据服务。
- 在服务层，有联邦数据计算和数据服务 API 两种方式。其中，联邦数据计算服务是一个联邦查询引擎，可以实现数据跨库查询，它依赖的就是统一元数据服务，查询的是数据仓库和数据湖中的数据。
- 在产品层，提供智能服务：包 RPA、证照识别、语言分析、客户画像、智能推荐。商业分析服务：包括自助分析、客户洞察、可视化。数据开发服务：包括数据开发平台，自动化治理。
2.实时金融数据湖工程实践
下面讲一下实时金融数据湖的工程实践，主要针对实时结构化数据分析。整体基于开源架构搭建，如下图所示，主要有 4 层，包括存储层、表结构层、查询引擎层和联邦计算层。
- 存储层和表结构层是数据智能分布的组成部分，支持 Upsert/Delete、Table Schema 和 ACID 的语义保证，并且它可以兼容存储半结构化数据和非结构化数据。
- 查询引擎层和联邦计算层是统一数据开发平台的一个组成部分。统一数据开发平台提供的是一站式的数据开发，可以实现实时数据任务的开发和离线数据任务的开发。
本次分享主要针对的是实时数据任务的开发。后面主要介绍的是一站式流计算开发平台，它可以实现实时任务的开发、管理、运维，保障实时任务的稳定运行。
1
3.流计算开发平台
为什么银行需要流计算开发平台，流计算开发平台的优势是什么？
■ 优势
流计算开发平台的优势在于可以有效降低实时数据开发准入门槛，助力实时业务快速发展。通过流计算开发平台，提供一个一站式的实时数据开发平台，包括可视化的数据开发，任务管理，实现多租户和多项目的管理，统一运维管理、权限管理，可以在这个平台上完成实时数据任务的开发。流计算开发平台是基于 Flink SQL 来做的，Flink SQL 本身是一种生产力。
通过 Flink SQL 的不断应用，可以把流计算开发平台的能力下推至分支行，分支行可以通过平台，按照业务需求自主的开发实时数据的任务，以此来促进银行业务的发展。
■ 架构
流计算开发平台的架构如下图所示。主要有数据存储、资源管理、计算引擎、数据开发、Web 可视化等。
它可以实现多租户的管理、多项目的管理，并且用户可以在上面实现一个实时任务的运维监控。流计算开发平台资源管理方式，支持物理机和虚拟机的方式，同时支持统一的云底座 K8s。平台计算引擎是基于 Flink，提供了数据集成、实时任务的开发、运维中心、数据管理，和可视化数据开发 IDE 等功能。
■ “直通式”实时场景
上面主要介绍了流计算开发平台的架构和优势，下面针对具体的场景做进一步介绍。首先是“直通式”实时场景架构。
不同的数据源数据被实时的接入到 Kafka，Flink 实时读取 Kafka 数据进行处理，将处理的结果发送给业务端。业务端可以是 Kafka，也可以是 HBase 等不同的下游。业务的维表数据是用 Elastic 来存储。“直通式”架构可以实现 T+0 的数据的时效性，主要用在实时决策场景中。
- 实时决策分析
这里举了一个简单的例子，临期贷后催收业务。贷款快过期了需要进行催收。业务依赖账户余额、交易金额、本期应还金额。通过三个数据，针对不同的业务进行决策，是通过短信催收、智能语音催收，还是电话催收？
如果是基于原有的离线数仓的架构，得到的数据都是 T+1 的。用过期的数据决策，可能客户已经还款，但是仍然存在电话催收的问题。而通过“直通式”场景架构的应用，可以实现 T+0 的账户余额，交易金额和本期应还金额，实时进行决策，提升用户的体验。
- 实时 BI 分析
再来看一个例子，实时获取过去一段时间到现在的理财产品销量信息，这个需求有一些关键字，需要“实时获取”，即需要 T+0 的数据。“一段时间到现在”，它涉及历史数据的查询。理财产品的销量信息涉及到银行业务，一般都比较复杂，需要用到多流 join。
整个需求是一个实时 BI 需求，这个需求使用“直通式”的架构无法有效解决，“直通式”架构用的是 Flink SQL，但 Flink SQL 无法有效应对历史数据的查询，并且银行的业务一般都比较复杂，现在主要用的双流 join。要解决这个问题，需要探索区别于“直通式”实时场景架构的新架构。
■ “落地式”实时场景
下面介绍“落地式”的实时场景架构，数据源被实时接入到 Kafka 之后，Flink 可以实时处理 Kafka 的数据，并将处理的结果写入到数据湖中。数据湖整体基于开源方案搭建，数据的存储是用的 HDFS 和 S3，表格式用的是 Iceberg。Flink 读取完 Kafka 的数据之后进行实时处理，这时候可以把处理的中间结果写入到数据湖中，然后再进行逐步处理，最终得到业务想要的结果。处理的结果可以通过查询引擎对接应用，包括 Flink、Spark、Presto 等。
4.实时金融数据湖
■ 架构
下面是中原银行的实时金融产品架构。包括“直通式”实时应用场景和“落地式”的实时金融场景。数据会实时的接入到 Kafka，然后 Flink 实时的读取 Kafka 中的数据进行处理。如果涉及维表数据，则是存在 Elastic 中。这里存在两种情况：
- 业务逻辑简单，Flink 实时读取 Kafka 中的事件数据和 Elastic 中的维表数据进行处理，处理的结果会直接发送给业务。
-
业务逻辑复杂，会进行分步处理，将中间结果先写到数据湖，再进行逐步的处理，得到最终的结果。然后最终的结果会通过查询引擎对接不同的应用。
■ 数据流向
这是实时金融数据湖的数据流向图。实时数据的数据源都来自于 Kafka，然后 Flink SQL 通过 ETL 方式实时读取 Kafka 中的数据。通过实时数据的 ETL 和数据湖平台两种方式对接应用，提供的是实时和准实时的输出结果。其中，实时数据 ETL 对应的是“直通式”实时场景架构，而数据湖平台对应的是“落地式”的实时应用场景架构。
■ 实时金融数据湖特点
实时金融数据湖的特点有三点。
- 第一，开放性。数据湖兼容支持复杂 SQL，支持大量的金融场景。
- 第二，时效性。支持实时和准实时的数据分析处理，并且有落地和非落地的两种应用对接的方式。
- 第三，融合性。数据湖提供的是一个金融数据湖的架构，支持流批统一的结构化数据的分析处理。当然也支持半结构化和非结构化，因为数据湖用的是分布式存储。
■ 建设成果
通过数据湖的不断建设，整体也取得了一系列成果。我们现在是 T+0 的数据时效性，已经支持 20+ 的金融产品，存储成本可以降低 5 倍。
三、场景实践
1.智能实时反欺诈
实时金融数据湖主要应用在两个大的方面，一个是实时 BI，一个是实时决策。其中，实时决策的典型应用是智能实时反欺诈业务，它依赖于实时计算平台、知识图谱平台、机器学习平台、实时数据模型，提供一系列的数据服务，包括关系欺诈服务、设备指纹服务、行为监测服务、位置解析服务和共性匹配服务，以此来支持交易反欺诈场景、申请反欺诈场景和营销反欺诈场景。
当前已经实现日均实时处理 140 万条风险数据，日均实时阻断 110 次，日均实时预警 108 次。
2.实时 BI
再来看一个实时 BI 场景，主要是客户实时洞察平台，内部叫知秋平台，依赖于实时计算平台、知识图谱平台、客户画像平台、智能分析平台。不同的平台组合在一起，提供了交互式查询服务、统一的元数据管理服务、SQL 质量评估服务、配置式开发服务、统一可视化数据展示等。支持了趋势分析、圈子分析、留存分析、客户客群分析等场景。现在已经可以打通实时分析类场景常用需求和服务，实现实时 BI 分析闭环可视化，分行自主数字化实时 BI 分析，已落地实时 BI 分析用例 26800 个，实时 BI 分析平台平均月活 10000+，每天辅助分析各类实时 BI 需求 30000+。
