共计 5377 个字符，预计需要花费 14 分钟才能阅读完成。
作者|白学余
本文由中原银行大数据平台研发工程师白学余分享，次要介绍实时金融数据湖在中原银行的利用。次要内容包含：
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+。
