实时大数据平台建设历程与展望

实时大数据平台建设历程与展望hi，大家好！2022年1月20日，农历腊月十八，大寒的第一天，漫天的鹅毛大雪！没错，文章的首图就是我亲自拍摄的北京雪景图，是不是很哇塞！俗话说：瑞雪兆丰年，希望大家在新的一年里都能有所得。今天给大家分享的这篇文章来自中国工商银行大数据平台负责人袁一，他分享的主题是《工商银行实时大数据平台建设历程及展望》。文末附演讲PPT的下载方式本篇内容将通过三个部分来介绍工商银行实时大数据平台建设历程及展望。

一、工行实时大数据平台建设历程

二、工行实时大数据平台建设思路

三、展望一、工行实时大数据平台建设历程工商银行从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的特性类似于SparkStreaming微批的处理方式，在增加小量数据延时的情况下，大幅提升海量数据的吞吐能力，非常适用于实时大屏的场景。在银行业早期，大家基于DB2主机支撑核心业务。随着国内去IOE以及自主可控转型的浪潮，各家商业银行都开始将主机上的业务，迁移到分布式体系上，通过服务化接口的调用，满足不同业务系统之间的协作。业务迁移到分布式体系后，在调用多个服务化接口时，由于网络抖动等影响，会出现交易中，部分环节失败的情况。为了解决这个问题，工行基于Flink研发了业务一致性对账中心，将服务化接口调用过程中的调用日志，统一汇集到Kafka。基于Flink会话窗口的特性，判断交易中各个环节的调用是否完整。如果发现不完整的情况，会触发业务上的补账/核对动作，及时消除对客户账务的影响。早期的实时计算模型都是基于Java等高级语言进行开发。在SparkDataframe以及FlinkSQL出现之后，开发人员可以通过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数据库的接口做了集成，实现了类似于OracleRMAN的数据存储，增量备份的能力。根据国家监管的要求，大部分金融机构的大数据平台一般都以私有化的部署方式为主。在早期Hadoop技术刚出现时，大数据平台的设备选型以物理机+本地磁盘为主，尽可能实现本地计算。目前，主流的公有云大数据云服务以存算分离的架构为主。那么在建设金融机构大数据私有云时，到底应为物理机+本地磁盘为主，还是以存算分离架构为主呢？在公有云实现存算分离的最重要的原因就是：资源的超分配。超分配就是，假设公有云上有10个租户，每个租户分别申请了一个10节点的集群，但由于这10个租户的资源使用都会存在错峰的情况，因此云平台只要准备50台设备就可以满足上述需求，并不需要实际准备100台设备，这就是超分配。私有云的大数据平台，一般会按业务线来划分集群。每个集群可能是数百台设备的规模，并不会出现大量的小租户、小集群，但集群间确实会存在一定错峰的情况。对于这种情况，工行更倾向于使用固定资源+弹性资源混合部署架构。如图所示，左边基于裸金属的固定资源池，用于满足日常的资源需求。右边基于容器的弹性资源池，用于满足特定事件发生时突增的需求。同时，这部分弹性资源池，可以在不同的集群之间，动态调配复用。三、展望我们先来讲讲Flink1.14版本中发布的HybridSource能力。目前，在上线一新的实时模型时，如果涉及到历史数据的统计指标，以金融行业为例，在一个反欺诈模型里，需要最近7天累计交易额的统计指标。这种情况下，我们一般会先跑Hive，批量算出前6天的统计值，放进Redis，然后基于Flink读取Kafka中的数据，统计当天的增量数据，再进一步汇总成最近7天的统计值。这个过程，需要分两个作业来实现。而通过HybridSource可以将Hive和Kafka中的数据抽象成一张表，通过一个作业就可以统计出最近7天的值，在Flink内部自动实现类似于union的功能，大幅提升研发效率。关于动态资源调整，随着平台规模越