作者：袁一

用户背景

中国工商银行成立于1984年1月1日。2005年10月28日，整体改制为股份有限公司。2006年10月27日，成功在上交所和香港联交所同日挂牌上市。经过持续努力和稳健发展，已经迈入世界领先大银行之列，拥有优质的客户基础、多元的业务结构、强劲的创新能力和市场竞争力。连续八年位列英国《银行家》全球银行1000强和美国《福布斯》全球企业2000强榜单榜首、位列美国《财富》500强榜单全球商业银行首位，连续五年位列英国Brand Finance全球银行品牌价值500强榜单榜首。

业务需求

工商银行从 2002 年开始建设数据集市，当时主要使用 Oracle 类单机版的关系型数据库。随着数据量不断增加，开始引入 TeraData、ExaData 等国外高端一体机。为了满足数据时效，以及企业级大规模普惠用数的诉求，企业内部的大数据平台需要不仅支持批量计算，还需要满足各类用数场景全栈覆盖的技术体系。

为了满足数据时效性以及企业级大规模普惠用数的诉求，企业内部的大数据平台需要不仅支持批量计算，还需要满足各类用数场景全栈覆盖的技术体系。以工行为例，大数据平台内部除批量计算之外，包含实时计算，联机分析、数据 API 等平台，主要以 Flink 作为内部引擎，用于缩短数据端到端闭环时间，形成联机高并发的访问能力，提升数据赋能业务的时效。除此之外，还包含数据交换、数据安全等面向特定技术领域的二级平台。在最上面一层，通过可视化工具面向开发人员，数据分析师，运维人员提供了支撑。

平台建设

工行实时大数据平台建设思路，主要会围绕时效、易用、安全可靠和降本增效来展开。

1. 数据实效性

在数据时效方面，上图是描述数据流向的示意图，原始数据从左上角的应用产生，经过蓝色和粉色两条链路。其中，蓝色链路是业务视角上端到端闭坏的链路，应用产生的数据会写入 MySQL 或者 Oracle 等关系型数据库，之后通过 CDC 相关技术，将数据库产生的日志复制到 Kafka 消息队列中，将同一份数据的共享，避免多次读取数据库日志。

在 Kafka 之后，是实时计算平台。实时计算平台除了实现对时效要求较高的计算处理场景之外，它还可以通过 Flink 结合 HUDI/IceBerg 等产品实现实时数据入湖。而且能将 Flink 的结果输出到 HBase\ES 等联机数据库中。将这部分数据以服务的形式暴露，即数据中台服务，从而提供给应用调用。  

粉色链路的数据，最终回到数据分析师那里，是蓝色链路的衍生。各个应用产生的数据，通过 Flink 和 Hudi 的实时数据入湖，通过 Presto 或 CK 等分析型引擎，供数据分析师进行 BI 分析。通过这条链路，数据时效得以提升，让分析师访问到分钟级延时的热数据，更加实时、准确地做出运营决策。一般高时效的业务场景，都包含在这条技术链路的体系之内。  

2. 易用性

早期的实时计算模型都是基于 Java 等高级语言进行开发。在 Spark Dataframe 以及 Flink SQL 出现之后，开发人员可以通过 SQL 来开发实时计算模型。随着分布式体系以及数据中台的发展，很多实时计算模型在处理业务逻辑过程中，需要访问外部联机接口。工行将调用的 HTTP、Dubbo、Redis 等外部接口，抽象成一张张外部表。直接通过一句 SQL 就能将 Kafka 中的流表与 Dubbo 的维表关联，然后将结果送到 HTTP 接口，大幅提升开发效率。

在业务研发方面，通过借鉴业界 DataOps 的理念，工行打造了一条集开发、测试、版本制作及发布于一体的研发流水线。相比于早期大数据工程师基于 UltraEdit 开发的模型，这种可视化 IDE 的开发效率至少提升 10 倍以上。  

在生产运维方面，工行为运维人员提供多个用于展示平台健康状态的仪表盘。同时，并通过机器学习和专家规则相结合的方式，实现了面向多类场景的故障根因自动分析的能力，降低运维门槛。对于开发人员来说，他们更关心作业中断后运维平台能否帮助分析问题，所以在作业中断时，为开发人员提供问题诊断能力，95% 以上的常见问题都可以自动完成分析。  

在 BI 平台方面，工行面向业务人员提供了自助数据分析探索的能力。主要解决用数最后一公里的问题。分析结果提供了多样化的展示仪表盘，不但支持基于拖拉拽的多维分析，而且支持数据下钻挖掘等功能。  

《Apache Flink 案例集（2022版）》——5.数字化转型——工商银行-工商银行实时大数据平台建设历程及展望（2） https://developer.aliyun.com/article/1227988