一、 什么是数据湖
关于数据湖，现在是众说纷纭，有人认为数据湖只是数据存储，是旧瓶装新酒，没啥新义;也有人认为数据湖主要用于冷数据的备份，时间一长，基本等同于数据沼泽;但更多的人倾向于数据湖是解决现有大数据场景问题的一套完整的解决方案。
亚马逊定义的数据湖是一个是集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据，并运行不同类型的分析，从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。
微软定义的数据湖是微软Azure公共云平台的一部分，该平台包括200多种产品和云服务。它为结构化，半结构化或非结构化数据提供了无限的存储空间。它可以用于存储任何大小的任何类型的数据。
参考主流公有云服务提供商的数据湖产品，现在的数据湖不仅包括数据的存储，还包括数据的分析计算，是一整套解决方案。实时金融数据湖，是数据湖在中原银行实时场景下的理解还有应用，希望本文可以给大家带来一定的参考。
二、 背景概况
2.1 建设背景
1.银行的决策方式正发生巨大的变迁
银行传统的数据分析主要针对收入、成本、利润、监管等财务数据分析。随着互联网金融的发展，银行业务逐步受到挤压，现在银行需要更多的了解客户，做有针对性的实时化营销和决策分析。即决策方式已经从财务分析转向面向客户(KYC)的实时分析和决策。
2.在银行体系下，传统的数据仓库还无法替代
银行面向收入、成本、利润、监管等财务数据的分析，需要规范、精准的数据加工，而面向规范、精准加工的传统数仓体系，能够较好的解决问题，这已经形成一个共识并存在很长时间，并且现在没有可以完全替代数据仓库的方案，即银行的数据仓库体系在很长时间内仍会是主流方案。
3.银行数据仓库无法有效支持创新业务发展需求
数据仓库整体变更困难，单位存储成本较高，不适合海量日志、事件等变更频繁，实时性高的数据，且对半结构化和非结构化数据兼容差等，也决定了传统数仓无法有效支持银行业务不断创新发展的需求。
2.2 实时金融数据湖
实时金融数据湖建设背景阐明了银行数据分析决策方式的改变，说明了银行传统数据仓库的优势和不足，引出需要建设实时金融数据湖来应对业务不断发展的需求。整体上，实时金融数据湖应具备以下三个特点：
1.开放性：实时金融数据湖追求海纳百川，不仅要支持传统面向财务数据分析，还需要非财务数据分析，整体上不限场景。
2.时效性：实时金融数据湖需要具备T+0实时性，实现T+0实时BI和实时决策。
3.融合性：实时金融数据湖应包含数据仓库，与银行数据仓库具备架构融合，形成统一数据视图。
实时金融数据湖方案融合理念，包括数据汇聚的融合，规范设计的融合，数据管理的融合，技术实现的融合，物理位置的融合和数据存储的融合。通过数据湖融合理念，让数据湖和数据仓库原本两个独立的集群，形成湖仓一体化方案，以更好的助力于银行分析业务发展。
三、 体系架构
建设一个具有融合架构的实时金融数据湖，需要一个完整的体系架构。下面将从架构、平台、场景等方面，依次介绍。
实时金融数据湖功能架构上，数据源支持结构化、半结构化和非结构化数据源;通过统一数据接入平台，按业务数据的不同类型，写入对应的存储;数据存储有数据仓库和数据湖，湖仓数据支持智能数据分布;在数据存储之上，提供数据服务和数据开发平台，全面支持数字化应用;其中数据开发平台，不仅仅针对银行传统离线数据任务开发，还包括实时数据任务开发，是一站式数据开发平台。
实时金融数据湖逻辑架构上，存储层有数据仓库和数据湖，数据仓库是面向规范精准的财务分析场景，针对的是结构化数据的分析，数据湖是面向非财务分析场景，支持结构化、半结构化和非结构化数据，存储层实现集群级冷热数据分级管理;计算层实现统一元数据服务，包括数据仓库的元数据和数据湖中的元数据，存储层计算层是存算分离的架构;服务层支持联邦数据计算和数据服务API，联邦数据计算是一个联邦查询引擎，可以实现数据湖和数据仓库数据的跨库查询。产品层使用统一的服务层，实现统一的数据查询分析。
通过实时金融数据湖架构的介绍，我们对它应具备的能力有了一定的认识。下面将从工程实践角度进一步介绍，整体实践基于开源方案实现，有存储层、表结构层、查询引擎层和联邦计算层。存储支持HDFS和对象存储S3或OSS，表结构支持Iceberg、Hudi和Delta三种开源数据湖方案，对接Flink使用的是Iceberg。查询引擎支持Flink、Spark, Hive等;联邦计算层开源方案基于Presto，同时也在调研公有云服务提供商的联邦查询引擎。存储层和表结构层，支持Upsert/Delete、Table Schema和ACID语义保证，兼容存储非结构化和半结构化数据。查询引擎层和联邦计算层，支持统一数据开发平台，实现一站式实时、离线数据任务的开发、管理、运维工作。
随着银行数字化转型工作的不断推进，银行在营销、风控、报表等业务的实时性要求越来越高且需求旺盛;但流计算技术使用门槛高，不适合普通银行业务人员做通用业务需求开发;因此银行需要统一的流计算开发平台，提供通用化的实时任务开发解决方案，来解决银行实时业务的需求。
我行流计算开发平台以Flink引擎为基础，支持实时任务的开发、管理和运维工作。平台统一资源调度支持K8s，具有云原生特性;且支持多租户管理和多项目管理，做到不同项目组逻辑和物理上隔离。通过流计算开发平台的不断推进，我行数据开发人员可使用SQL的方式实现实时数据任务需求的自主化开发。
流计算平台通过Flink引擎，可以做到数据处理的准确性和实时性，通用的流式数据处理流如下所示，数据实时写入Kafka后，经过Flink处理后实时写入目标端Kafka，如果涉及维表数据，使用ES进行存取。
上面通用流式数据处理流程，我们称为“直通式”实时场景架构，它架构简单，可以支持数据实时处理，数据不落地直通应用，一般用在实时决策场景。以贷后临期催收为例，贷后临期催收依赖帐户余额，交易金额和本期应还金额，决定贷款是通过短信、智能语音还是人工电话的方式催收;传统的离线数仓是T+1时效性，会有客户已经还款但还是打电话催收的问题。通过“直通式”场景架构，实时处理决策，彻底解决了误打电话的问题，有效提升了客户体验。
简单的实时决策场景可以通过“直通式”场景架构解决，但在实时BI场景下，问题和实时决策场景又不一样。下面看一个实时BI的需求，我们需要实时获取过去一段时间到现在理财产品销量信息，这个需求需要实时数据，需求中提到一段时间的数据，涉及历史数据查询，且理财信息业务逻辑复杂，涉及较多的业务逻辑，有较多的表JOIN。
简单来说，上面的场景涉及多表Join、历史数据查询，使用“直通式”实时场景架构，无法有效处理。金融场景业务大都逻辑复杂，关联依赖表众多，涉及历史数据查询。因此，我们需要探索新的区别于“直通式”场景架构新的架构来有效解决问题。
这个新的架构是“落地式”实时金融场景架构，如图所示，数据实时写入Kafka，Flink读Kafka数据实时处理不变，Flink处理的中间结果数据先写入到数据湖中，再逐步进行处理，形成最终处理结果，结果通过Flink, Hive, Presto，Spark等查询引擎对接应用。通过上面流程，针对实时BI需求，我们可以将业务逻辑拆分，以此来支持历史数据查询和复杂SQL查询，更大程度的扩展实时金融场景。
上面介绍了实时金融数据湖的架构、工程实践、流计算平台和实时金融场景，系统说明了实时金融数据湖应具备的能力，整体上有以下三点：
1. 开放性：支持大量金融场景，兼容支持复杂SQL查询和历史数据查询。
2.时效性：支持T+0数据分析，支持实时BI和实时决策;支持“直通式”和“落地式”两种应用对接方式
3.融合性：实现流批一体的结构化数据存储、查询、分析，兼容存储非结构化数据和半结构化数据。
目前我行实时金融数据湖已上线运行，完成上下游各个平台的对接，打通了数据壁垒，开放了平台开发、存储和分析算力，各开发团队均可自主调用开发。通过实时金融数据湖的建设，支持了20+的金融场景，实现T+0数据时效性，且在存储成本上，相对于数据仓库降低5倍。
四、 应用场景
实时金融数据湖在实时决策中典型应用是实时反欺炸，我行在上线实时反欺炸平台之后，可日均处理140w条风险数据，日均阻断110次，预警108次，整体涵盖交易监测、线上开户、信用卡申请、异常客户操作等复合场景。
实时金融数据湖在实时BI场景下的典型应用是客户实时洞察平台，通过实时洞察平台的应用，现已落地实时BI分析用例26800个，实时BI分析平台平均月活10000+，每天辅助分析各类实时BI需求30000+，整体打通实时分析类场景常用的需求和服务。
五、 未来规划
实时金融数据湖是一个融合的数据湖方案，目标是解决金融行业大数据场景下，特别是实时数据在分析处理过程中面临的问题，未来需要在技术和场景上持续探索。技术上，实时金融数据湖会推进流批一体、联邦查询、统一元数据管理、统一开发平台等技术持续落地，通过技术优化各平台使用体验;场景上，实时金融数据湖会深入结合场景，真正走进业务，充分理解并帮助业务解决实时、批数据处理场景下的痛点，实现数据、平台、业务的有机融合，真真正正让平台更实用，更好用。
end
最后给大家一个小福利：公众号“数据社”后台回复“资料”，即可直接下载！
