摘要：目前商业银行数据仓库主要采用基于MPP（Massively Parallel Processing）架构的离线数据存储计算方式，离线数仓的数据源主要以文件形式提供，由统一批量采集传输原始数据至客户端服务器，对数据进行清洗、转换、加载至MPP数据库贴源层，然后再

文/交通银行软件开发中心 杨智飞

目前商业银行数据仓库主要采用基于MPP（Massively Parallel Processing）架构的离线数据存储计算方式，离线数仓的数据源主要以文件形式提供，由统一批量采集传输原始数据至客户端服务器，对数据进行清洗、转换、加载至MPP数据库贴源层，然后再经由明细层、汇总层逐层加工，形成轻、高度汇总模型，最终以批处理方式将数据下发到各应用系统使用。该实现方式的主要问题在于数据统计时延长，统计报表只能展示前一天甚至两天前。随着大数据存储技术和计算技术的快速发展，低延时、高并发的业务需求越来越多，上述高时延、低并发的离线数仓架构已经不能满足业务需求。基于此，本文提出一种基于Flink+Hudi的实时数据湖架构，实现秒级延迟和日均十亿级吞吐量的处理能力，提供商业银行数字化营销、客户画像、实时风险决策等各类实时服务能力和数据，有效支撑商业银行内部业务运营决策。

本文以提升商业银行分析决策的实时性为目的，构建从底层数据源到上层应用服务的全流程数据加工框架。在数据处理的全流程阶段，需要选择合适的组件解决相应的技术问题，从而实现实时数据湖。

1. 实时数据采集。数据源的实时接入，需要借助变更数据捕获（Change Data Capture，CDC）技术。CDC是一种捕获数据库变更数据的技术，当源端应用对其数据库进行任何操作时，操作记录信息都将在日志中保存，CDC通过实时解析数据库的日志，以复制的形式增量提取数据操作语言更改（插入/更新/删除）的事件和更改的数据本身，并将数据分发到下游系统，支持对接多种数据库以及Kafka等存储引擎，输出格式灵活配置，近乎实时地实现了事实数据的增量加载。

2. 实时计算引擎。数据处理实时计算需要引入实时计算引擎Flink，Flink是由Apache开源软件基金会发布的，为分布式、高性能的流处理应用程序打造的开源流处理框架。Flink提供了同时支持高吞吐和exactly-once一致性语义的实时计算，支持迭代计算、状态管理和内存管理，可实现低延迟的实时数据计算。Flink具有低延迟、高吞吐、支持有状态计算、支持事件时间、支持高可用配置等特性。

3. 数据存储引擎。实时数据湖引入Hudi数据湖存储引擎以实现流式数据的实时处理、海量数据的持久化以及历史数据准实时计算查询的能力。

Hudi（Hadoop Updates and Incrementals）是用于在分布式文件系统（Hadoop Distributed File System，HDFS）管理的数据库层上构建具有增量数据管道的流式数据湖，同时针对湖引擎和常规批处理进行了优化。简言之，Hudi是一种针对分析型业务的、扫描优化的数据存储抽象，在HDFS数据集海量存储的基础上提供了两种原语：首先是更新/删除记录，Hudi使用细粒度的文件/记录级别索引来支持该功能，同时还提供写操作的事务保证。查询会处理最新提交的快照，并基于此输出结果。其次是基于变更流的增量处理，Hudi对获取数据变更提供流式读取的支持，可以从指定的时间点获取指定表中已更新/插入/删除的所有记录的增量流。

基于上述设计，Hudi提供了基于DFS抽象的流/增量处理能力。这种架构设计使得Hudi具有如下的优势。一是提升效率：Hudi提供了记录级更新的标准支持。二是优化ETL性能：Hudi可以通过增量查询处理一张或多张输入表，同时结合常驻式Flink作业仅处理来自上游表的增量更改，可以大大加速此类数据管道应用。三是实现统一存储。

1. 系统目标和总体架构。如图1所示，现有数据中台架构中，以批量数据仓库和批量数据湖为主，缺少实时数据指标加工能力。本文提出实时数据湖建设方案，基于Flink+Hudi流批一体架构设计，从数据采集、传输、计算、存储到服务全链路，实现实时数据应用场景所需的实时数据处理能力，解决传统离线数据仓库无法处理T+0数据、流式计算系统烟囱式开发等痛点，满足日益增长的实时类应用需求，最终提供秒级和分钟级的实时加工能力。总体设计分为实时数据集成、实时数据处理以及实时数据服务多个模块。

2. 实时数据集成。实时数据集成是指通过数据采集工具收集各个业务系统的实时数据，对非结构化的数据进行结构化处理，保存原始数据至实时数据处理模块贴源层，实现从源端到目标端秒级同步。实时数据的业务类型主要分为两类：第一类是业务交互数据，即业务流程中产生的支付、转账、赎回、确认份额等相关的数据，通常存储在数据库中，如Mysql、OceanBase等。第二类是埋点用户行为数据，用户在使用过程中，与客户端产品交互过程中产生的数据，比如页面浏览、点击、停留、评论、点赞、收藏等。

对于第一类存储在DB中的数据，选择Flink CDC技术进行采集，源数据库捕获到数据和数据结构的增量变更，转换为可被Flink读取的json格式，以近乎实时地将数据通过网络传输到指定目标端。

Flink CDC是一种基于Flink的流式数据处理技术，用于捕捉数据源的变化转换为流式数据，并实时将数据流发送到下游系统。对比常见的开源CDC方案，如下表所示。

表  常见开源CDC方案对比

可以发现，Flink CDC是基于日志的方式，具有优秀的增量同步能力，同时也可以支持全量同步，可实现全量+增量。Flink CDC采用分布式的架构，支持数据读取能力和写入能力水平式扩展。相较于其他方案，Flink CDC具有更丰富的生态。基于上述原因，选择Flink CDC作为实时数据集成的数据采集技术。

对于第二类业务应用运行中产生的实时消息，由业务应用产生后直接调用API推送至Kafka，再使用Flink CDC采集至贴源层。

3. 实时数据处理。实时数据处理是指实时数据入湖后的数据处理流程，由于Hudi支持Upsert/Delete、Table Schema和ACID的语义保证，并且Hudi提供了变更流的增量处理能力。因此选择Hudi作为存储引擎，Flink作为计算引擎，对于实时数据集成后入湖的增量同步数据，将清洗、补维、分流等逻辑通过增量流式进行处理，即可实现批流一体的实时数据湖架构建设，并在其中设计贴源层、明细层、汇总层以及应用层的数据分层模型，提升实时数据可复用性，避免烟囱式开发（见图2）。

贴源层：用于存放未经处理过的原始数据，结构上和源系统保持一致，数据源中的数据经过实时数据集成后写入贴源层。

明细层：为了解决重复建设的问题，要进行基于模型的统一构建，参考离线数仓的模式，建设统一的基础明细数据层，按照主题进行管理。明细层的目的是给下游提供直接可用的数据，因此要对贴源层进行统一的加工，比如清洗、过滤、扩维等操作。

汇总层：基于上层的指标需求，以分析的主题思想作为建模驱动，构建公共统计粒度的汇总表。汇总层是基于明细层的基础数据，通过Flink的简洁算子直接可以计算出结果，并且形成汇总指标池，所有的指标都统一在汇总层加工，按照统一的规范管理建设，形成可以复用的汇总结果。

应用层：主要提供给数据服务和数据分析直接使用的数据，一般会存放在Kafka、ElasticSearch、关系型数据库、ClickHouse等目标端中。

4. 实时数据服务。实时数据湖经过实时数据集成、实时数据处理加工完成后的结果，最终通过ElasticSearch、ClickHouse、数据库等查询引擎对接不同的应用，即对外提供数据服务以支撑实时查询、实时报表、实时风控、实时营销等金融行业典型实时数据应用场景。

实时查询：主要面向客户的报表，其业务特点是根据唯一标识去检索数据，需要低延迟、高并发、数据时效性要求高，而且需要明细数据，而不仅仅是聚合模型。基于明细可以实现更灵活的自助分析。对于这类场景，可以选择Mysql、OceanBase等关系型数据库增速点查或者范围查询。

实时报表：主要面向主管、客户经理等管理人员的报表，其特点是查询维度变化快，不只聚合成一种预设的模式，同时要求响应低延迟，查询性能要求高。因此选择将明细数据导入Clickhouse中，以处理复杂多维、大数据量分析计算场景。

实时风控：依赖于实时计算平台、知识图谱平台、机器学习平台、实时数据模型等，提供一系列的数据服务，包括关系欺诈服务、行为监测服务、设备指纹服务、位置解析服务等，以此来支持交易反欺诈场景、营销反欺诈场景等业务。

实时营销：基于百万日活和数千万事件的用户规模下产生的用户行为日志，聚合高维度的用户标签数据，同时提供基于事件实时触发低延迟的营销活动通知，保证整个链路在毫秒级内完成。

来源：新浪财经