共计 4435 个字符，预计需要花费 12 分钟才能阅读完成。
本文整顿自中国工商银行大数据平台负责人袁一在 Flink Forward Asia 2021 的分享。次要内容包含：
- 工行实时大数据平台建设历程
- 工行实时大数据平台建设思路
- 瞻望
FFA 2021 直播回放 & 演讲 PDF 下载
一、工行实时大数据平台建设历程
工商银行从 2002 年开始建设数据集市，过后次要应用 Oracle 类单机版的关系型数据库。随着数据量一直减少，开始引入 TD、ED 等国外高端一体机。2014 年工行正式基于 Hadoop 技术建设了大数据平台，在其之上构建了企业级数据湖及数据仓库。2017 年，随着 AI 技术的衰亡，又开始建设机器学习平台，2020 年开始建设数据中台和高时效类场景。
为了满足数据时效，以及企业级大规模普惠用数的诉求，企业外部的大数据平台须要不仅反对批量计算，还须要满足各类用数场景全栈笼罩的技术体系。以工行为例，大数据平台外部除批量计算之外，蕴含实时计算，联机剖析、数据 API 等平台，次要以 Flink 作为外部引擎，用于缩短数据端到端闭环工夫，造成联机高并发的拜访能力，晋升数据赋能业务的时效。除此之外，还蕴含数据交换、数据安全等面向特定技术畛域的二级平台。在最下面一层，咱们向开发人员、数据分析师、运维人员提供了可视化的撑持工具。
二、工行实时大数据平台建设思路
工行实时大数据平台建设思路，次要会围绕时效、易用、安全可靠和降本增效来开展。
在数据时效方面，上图是形容数据流向的示意图，原始数据从左上角的利用产生，通过蓝色和粉色两条链路。其中，蓝色链路是业务视角上端到端闭坏的链路，利用产生的数据会写入 MySQL 或者 Oracle 等关系型数据库，之后通过 CDC 相干技术，将数据库产生的日志复制到 Kafka 音讯队列中，将同一份数据的共享，防止屡次读取数据库日志。
在 Kafka 之后，是实时计算平台。实时计算平台除了实现对时效要求较高的计算解决场景之外，它还能够通过 Flink 联合 Hudi/IceBerg 等产品实现实时数据入湖。而且能将 Flink 的后果输入到 HBase/ES 等联机数据库中。将这部分数据以服务的模式裸露，即数据中台服务，从而提供给利用调用。
粉色链路的数据，最终回到数据分析师那里，是蓝色链路的衍生。各个利用产生的数据，通过 Flink 和 Hudi 的实时数据入湖，通过 Presto 或 CK 等剖析型引擎，供数据分析师进行 BI 剖析。通过这条链路，数据时效得以晋升，让分析师拜访到分钟级延时的热数据，更加实时、精确地做出经营决策。个别高时效的业务场景，都蕴含在这条技术链路的体系之内。
在余额变动场景，客户进行一次动账交易，可能触发多种告诉内容，例如账户收入揭示、账户支出揭示、积分生产揭示等，造成客户手机间断收到短信揭示，用户体验不佳。因而，工行基于 Flink 多流合并和会话窗口的能力，将同一时刻产生的多条音讯关联，将告诉的逻辑合并在一起发送给客户。而当一条音讯呈现晚到的状况，通过会话窗口的 GAP 设置能主动降级，将逻辑分为两条音讯收回去。大幅晋升对用户的敌对性。
每家商业银行在每年 12 月 31 日时须要出年报，所以那天银行须要对全年的利润分配等指标进行试算。工行和其它商业银行一样晚期应用 DB2 主机实现外围交易，年初时的损益、预查问都在主机上实现。但主机是按 MIPS 免费，所以当这种预查问屡次执行时，老本很高。
因而工行做了架构革新，通过 CDC 数据复制技术，将主机实时产生的数据复制到大数据平台，通过 Flink 进行实时 ETL，数据搬运过去之后，充分利用大数据平台海量的计算能力，大幅晋升预查问效率。原来每天跑 10 轮，当初每天能够跑 30 轮，原来每轮 30 分钟，当初每轮只有 10 分钟，既晋升了时效又节俭了老本。
实时大屏场景个别都是基于日志采集或 CDC 技术实现数据的对立会集，基于 Flink 进行实时的业务量统计。工行也是通过这种形式实现的实时大屏，并应用了 Flink 的 mini-batch 的个性。尽管 Flink 能逐条实时处理数据，但在大部分场景，它会有 1ms 和 100ms 的延时，mini-batch 的个性相似于 Spark Streaming 微批的解决形式，在减少小量数据延时的状况下，大幅晋升海量数据的吞吐能力，十分实用于实时大屏的场景。
在银行业晚期，大家基于 DB2 主机撑持外围业务。随着国内去 IOE 以及自主可控转型的浪潮，各家商业银行都开始将主机上的业务，迁徙到分布式体系上，通过服务化接口的调用，满足不同业务零碎之间的合作。业务迁徙到分布式体系后，在调用多个服务化接口时，因为网络抖动等影响，会呈现交易中，局部环节失败的状况。
为了解决这个问题，工行基于 Flink 研发了业务一致性对账核心，将服务化接口调用过程中的调用日志，对立会集到 Kafka。基于 Flink 会话窗口的个性，判断交易中各个环节的调用是否残缺。如果发现不残缺的状况，会触发业务上的补账 / 核查动作，及时打消对客户账务的影响。
晚期的实时计算模型都是基于 Java 等高级语言进行开发。在 Spark Dataframe 以及 Flink SQL 呈现之后，开发人员能够通过 SQL 来开发实时计算模型。随着分布式体系以及数据中台的倒退，很多实时计算模型在解决业务逻辑过程中，须要拜访内部联机接口。
工行将调用的 HTTP、Dubbo、Redis 等内部接口，形象成一张张内部表。间接通过一句 SQL 就能将 Kafka 中的流表与 Dubbo 的维表关联，而后将后果送到 HTTP 接口，大幅晋升开发效率。
接下来，给大家分享一下工行在用数撑持工具方面的实际。在业务研发方面，通过借鉴业界 DataOps 的理念，工行打造了一条集开发、测试、版本制作及公布于一体的研发流水线。
相比于晚期大数据工程师基于 UltraEdit 开发的模型，这种可视化 IDE 的开发效率至多晋升 10 倍以上。同时工行的开发平台也于往年通过了中国信通院“数据开发平台”的认证测评，信通院在 12 月 10 日通过官网公众号颁布了测评的后果。
在生产运维方面，工行为运维人员提供多个用于展现平台衰弱状态的仪表盘。同时，并通过机器学习和专家规定相结合的形式，实现了面向多类场景的故障根因主动剖析的能力，升高运维门槛。
对于开发人员来说，他们更关怀作业中断后运维平台是否帮忙剖析问题，所以在作业中断时，为开发人员提供问题诊断能力，95% 以上的常见问题都能够主动实现剖析。
在 BI 平台，工行面向业务人员提供了自助数据分析摸索的能力。次要解决用数最初一公里的问题。剖析后果提供了多样化的展现仪表盘，岂但反对基于利落拽的多维分析，而且反对数据下钻开掘等性能。
接下来，给大家介绍工行在大数据平台平安可靠性方面的实际。
近几年各个行业对数据安全的器重水平都越来越高，而大数据平台作为全集群数据的会集地，对数据安全保障方面能力的建设就显得更加重要。大数据平台岂但要存储很多数据，而且要提供的各式各样的数据拜访形式。
因而工行设计了一套全生命周期用数监控审计，相似于 Ngnix 的 access.log，次要用于预先追溯审计。当用户将数据拖回到本地时，平台会对数据加上水印，当有些数据被非正常公开后，就能够通晓数据透露的起源，同时对身份证、手机号、卡号等敏感字段，在返回时动静脱敏，比方 11 号的手机号两头几位都会变成””。
动静控权是因为有些数据拜访权限管制粒度较细，工行实现了一套 SQL 改写引擎，在运行时对 SQL 进行解析，依据用户与表权限的对照关系，对 SQL 加上管制条件及脱敏函数，防止数据被越权拜访。敏感数据辨认是基于专家规定或 ML 模型，自动识别海量数据中的敏感信息，并主动进行分类分级。同时，揭示管理员对敏感信息和分类分级后果进行核实确认。
在大数据平台建设的晚期，大家次要将一些非关键的增值类业务放到大数据平台。随着技术的一直成熟，很多机构开始将外围的业务部署到大数据平台。为此工行在上海外高桥和嘉定两个数据中心建设了双活的大数据平台，通过零碎级复制确保两边根底数据同步。对于局部要害业务会在两边同时运行，通过这种架构来确保要害业务的稳固。
上图是数据离线备份架构。金融机构在监管方面，对于数据存储可靠性的要求很高，所以，咱们将 NBU 磁带备份零碎和 Hadoop 以及 MPPDB 数据库的接口做了集成，实现了相似于 Oracle RMAN 的数据存储，增量备份的能力。
依据国家监管的要求，大部分金融机构的大数据平台个别都以私有化的部署形式为主。在晚期 Hadoop 技术刚呈现时，大数据平台的设施选型以物理机 + 本地磁盘为主，尽可能实现本地计算。目前，支流的私有云大数据云服务以存算拆散的架构为主。那么在建设金融机构大数据公有云时，到底应为物理机 + 本地磁盘为主，还是以存算拆散架构为主呢？
在私有云实现存算拆散的最重要的起因就是：资源的超调配。超调配就是，假如私有云上有 10 个租户，每个租户别离申请了一个 10 节点的集群，但因为这 10 个租户的资源应用都会存在错峰的状况，因而云平台只有筹备 50 台设施就能够满足上述需要，并不需要理论筹备 100 台设施，这就是超调配。
公有云的大数据平台，个别会按业务线来划分集群。每个集群可能是数百台设施的规模，并不会呈现大量的小租户、小集群，但集群间的确会存在肯定错峰的状况。
对于这种状况，工行更偏向于应用固定资源 + 弹性资源混合部署架构。如图所示，右边基于裸金属的固定资源池，用于满足日常的资源需要。左边基于容器的弹性资源池，用于满足特定事件产生时突增的需要。同时，这部分弹性资源池，能够在不同的集群之间，动静调配复用。
三、瞻望
咱们先来讲讲 Flink 1.14 版本中公布的 HybridSource 能力。目前，在上线一新的实时模型时，如果波及到历史数据的统计指标，以金融行业为例，在一个反欺诈模型里，须要最近 7 天累计交易额的统计指标。这种状况下，咱们个别会先跑 Hive，批量算出前 6 天的统计值，放进 Redis，而后基于 Flink 读取 Kafka 中的数据，统计当天的增量数据，再进一步汇总成最近 7 天的统计值。这个过程，须要分两个作业来实现。
而通过 HybridSource 能够将 Hive 和 Kafka 中的数据抽象成一张表，通过一个作业就能够统计出最近 7 天的值，在 Flink 外部主动实现相似于 union 的性能，大幅晋升研发效率。
对于动静资源调整，随着平台规模越来越大，资源利用率的关注度就越来越高。实时计算在肯定特定的场景，会呈现交易量突增的状况。对于这类状况，工行目前还是采纳手工扩容，或者通过业务侧将批和流联合的形式解决。比方在双十一大促之前，工行都会提前一周对交易相干的实时计算模型，进行手工扩容，大促之后再手工缩容。这个过程，总体比较复杂。
因而后续心愿 Flink 通过具备动静扩缩容的自适应能力，配置 min 和 max，引擎能够主动依据数据量的负载在 min-max 之间，调整应用的资源量从而进步整个平台的资源利用率。
FFA 2021 直播回放 & 演讲 PDF 下载
更多 Flink 相干技术问题，可扫码退出社区钉钉交换群；
第一工夫获取最新技术文章和社区动静，请关注公众号～
