作者:袁一
用户背景
中国工商银行成立于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