2022 年 10 月底,爱分析举办了“2022爱分析·银行数字化网络研讨会”。爱分析邀请Kyligence 副总裁周涛进行了题为《创新数据能力,驱动数字化转型:解读银行业趋势和实践》的主题演讲。
随着银行数字化转型进入深水区,智能化的数据产品和服务能力明显增强,金融服务质量和效率显著提高。在信创政策的推动下,数据成为银行业主要生产要素,各银行在前端应用、支撑平台等数字化基础设施转型方面重点发力,产生了显著的前进轨迹。
Kyligence 副总裁周涛在会上的演讲围绕银行业数字化转型实践和趋势洞察展开,分享了银行业代表客户数字化实践案例,展示了数字化转型中数据架构范式、数据服务方式和数据平台产品的需求变化及相关行业解决方案。
现将周涛总的演讲实录整理后分享如下。
Kyligence 副总裁周涛:
今天我跟大家分享的题目是《创新数据能力,驱动数字化转型:解读银行业趋势和实践》,本次分享结合了 Kyligence 这几年在银行业的实践、趋势洞察以及服务银行业客户的代表案例。
01
公司简介
首先简单介绍一下我们公司,公司名字 Kyligence 其实是 “ kylin ” 加 “ Intelligence ” 的一个组合。关于 Kyligence 的前身,大家应该知道在开源技术和大数据领域,有一个知名开源项目叫 Apache Kylin,这是第一个完全由中国人贡献到 Apache 基金会的顶级开源项目,Kyligence 由 Apache Kylin 创始团队创建,打造下一代企业级智能多维数据库,为企业简化数据湖上的多维数据分析。公司于 2016 年成立,经过 6 年的时间,在全球已经积累超过1500 家开源生产用户,上百家付费企业客户,分布在中国、美国、欧洲及亚太的多个银行、证券、保险、制造、零售等行业。
除了 Apache Kylin,我们还有一个 “ Byzer(白泽)” 的开源项目,旨在帮助用户以低成本和高效率的方式落地数据平台和完成 AI 工程化,这相当于我们从大数据开始,逐渐能够去做大数据 AI 的解决方案。除此之外,我们现在也在基于 Kyligence 核心 OLAP 能力打造一款产品 Kyligence Zen,为企业提供整合的、轻量级的、开箱即用的指标中台服务。在国外,指标中台被称为“Metrics Store”,非常火热。
02
数字化转型趋势洞察
接下来重点分享下 Kyligence 对银行业的数据能力转型趋势的洞察。刚才有提到过,我们服务的银行业客户占比很高,在国内外加起来已经有数十家。在国内经过几年的耕耘,算是小有成就,已经服务超过一半的国有大行和股份制银行,头部城商行、农商行企业也都是我们的客户。基于对银行业的深耕细作,Kyligence 其实对整个国内银行业的数字化转型有一个深度实践的过程,也有一些洞察积累。
从趋势角度来说,我这里列了今天主要会聊的三点,这三点应该是一个从大到小,或者是从顶层到底层的过程,主要包含整个数据架构的范式、数据服务的方式以及数据平台的产品三个方面的趋势。
第一个趋势是数据架构范式的趋势,叫做“从数据归集到数据联结”。其实不仅仅是银行,我觉得企业现在面临的大环境是,数据来源越来越多,而且数据呈现爆炸式增长。在做传统的数据能力建设时,大家做的是单体式分析架构。所谓的单体式分析架构,就是在做传统的数据仓库、数据湖时,先把数据汇集到一起,然后有一个集中的平台来提供整个数据能力的支撑。无论数据分析或者其他数据服务,都会有这样的一个动作,所以大家可能经常听到做数据的人会提到“做数仓”、“做数据采集”、“做 ETL ”等等的一些动作。但是在新的大数据环境下,无论是内部数据还是外部数据,无论部署模式是在本地还是云上,传统的单体式分析架构都开始遇到瓶颈,并且暴露出很多痛点。对于银行业来说,随着业务模式的转型,企业会更多地关注外部数据,在新业务出来后,数据来源的增长是远远超过其本身的数据采集和归集能力,说白了就是数据收回来的速度赶不上数据消费的速度,这种模式也会带来数据冗余的存储,相应的管理成本会更高,支撑一线数据分析需求的难度也会更大。
所以从业内趋势来看,在原本数据仓库或者数据湖的方法论上,现在也有比较新型的方法论,比如 Data Fabric(数据编织)和 Data Mesh(数据网格),这两种方法虽然本质上有差异,但整体来说都是在改变原来的集中式数据架构范式,大家都在采用去中心化的思路解决数据爆炸的问题,这里的数据爆炸不仅仅指数据量的爆炸,更多指的是数据源的爆炸。以我个人角度来看,2010 年开始的大数据时代,Hadoop 解决的是数据量爆炸的问题,那现在我们开始面临的是数据源爆炸的问题,这个问题也可以理解为如何解决数据孤岛越来越多的问题。当然这两个新型方法论的区别在于,Data Mesh 更多是以顶层业务域的角度来做数据的治理和服务,Data Fabric 更多是从底层技术的视角通过数据的联结来进行数据服务。
打个简单的比方,如果我们把数据看作人群,把整个数据平台或者数据能力看作一个城市的交通服务能力的话,要解决人员流动带来的交通拥挤和堵塞问题,原本单体式架构的思路就是把所有人先集中到一起,然后再分发到各个地方去上学或者工作。Data Mesh 是以重新规划城市功能区的方式,使得人群在相应功能区里解决工作、住宿、上学等需求,通过减少人员流动来缓解交通拥挤,这种方式相当于是通过顶层的城市规划治理方式来解决交通问题。而 Data Fabric 不一样,类似于通过大力发展各种交通设施(比如地铁、公交、出租车)等方式,并通过智能化的调度来增强整个城市的交通联结能力,从而解决交通拥挤的问题。所以二者是从不同层面来看待和提升数据能力建设的。总结来说,我个人认为 Data Mesh 更加美好但是难度也更大,因为对于银行业来说,经过多年的数据能力建设,已经有很多历史积累存在,所以它很难打破所有东西重新建设,就好比一个有着悠久历史的城市,即使碰到了交通拥挤的难题,也难以把城市推倒重来,所以 Data Fabric 通过数据联结来提升数据能力的方式,其落地的可行性也会更高一些。当然,拉长时间来看,我认为两者最终都会殊途同归。
去年,我们和中国银联成立数据联合实验室,共建创新型金融数据服务。在这个案例里,我们基于现状重新设计了企业的整体数据能力体系,不仅要将数据统一存储起来,更要将数据联结起来。从实验室的整体目标来说,会偏向用 Data Fabric 的理念。对于金融机构来说,如果数据源都在同一个存储环境里(比如说云),那么数据联结会比较简单,但是大型金融企业数据不太会上公有云,私有云是大家共同的选择。金融机构本身要做是打造云原生容器化的基础数据底座,这样数据才能存储在统一的平台上。在此基础上,还要考虑怎样减少数据的搬动和复制,这相当于要更多地借用 Data Fabric 里主动元数据的概念。在这样统一的平台上,我们能够实现元数据的统一管理,通过元数据能够对所有数据的存储进行识别和智能化管理,在此基础上我们还会实现整个计算引擎的可插拔和容器化。这里所实现的是不同计算引擎通过同一份元数据对不同数据交叉访问,可以减少整体数据的 ETL 工作。
从智能化的角度来讲,元数据除了知道数据存储位置和格式,还能通过统一的服务平台知道数据被使用的频次和效率如何,从而智能地调整底层的数据存储位置和格式,而不用人为去做同样的事,实现整体数据高性能服务的能力。这相当于从底层逻辑上重构企业的数据架构和能力,以此提升整体对外的数据服务能力,即通过数据联结的方式支撑整个企业的数据服务需求。这个概念听起来很吸引人,但是在业内并不是每个企业都走到了这一步。从我们目前的实践来看,只是比较前沿的一些企业在做这方面的探索,他们更多是承担了国家的数据基础设施能力打造以及科技输出的任务,像我们与中国银联、建设银行、浦发银行等的深度合作,也是要去打造类似 后Hadoop 时代新一代的大数据技术底座。
第二个想跟大家分享的趋势是关于数据服务方式,叫做“从被动式需求支持到主动式科技赋能”。左边列出来的传统数据服务方式的痛点,相信大家都有所了解,我们把数据服务方式未来的发展定义为三个阶段。大家知道传统的数仓建设服务都是类似报表或者仪表盘的分析方式,IT 对于业务需求都是被动地响应。但是随着银行的数字化转型,数据消费需求不仅限于中后台管理者需要做数据分析,一线业务人员对数据的消费需求也会越来越大,因为银行的数字化转型更多地是来自于业务驱动。业务人员去做增长的时候也需要更多的数据支撑,以传统的“业务提需求,我做一个报表”的被动响应模式已经不能满足业务增长的需求。所以我们把原本的时代叫作“报表时代”,现在我们定义的未来数据服务时代一个叫“数据头条时代”,一个叫“智慧运营时代”。
以数据头条作为一个简单的比方,在最早的互联网时代我们看新闻的时候,是自己登到网站上去看,比如“网易新闻”、“新浪新闻”,后来随着头条的智能推送出现,它可以把你感兴趣的东西主动推荐给你,包括抖音也是加入了更多智能化的方式实现内容的精准推送。那其实未来银行业做数据服务也是要实现这样的效果,从原来的被动响应业务需求,到基于历史数据和业务特点,主动推荐你需要的东西,同时我也把数据消费能力给你,你可以像搭积木一样从底层向上搭建。再进一步,这样的数据服务能力能够更加智能化的嵌入到业务流程里,那么业务流程和数据分析就不再是两个分裂的界面(在这个界面里做业务,然后去另外一个界面做数据分析),而是会形成一个闭环。智能化数据服务能力嵌入到业务中,系统能在业务流程中智能地分析出业务人员在做业务时需要怎样的数据,然后进行主动推送,并且对于推送的结果进行闭环分析,以一个更先进的方式去做事。就好比现在大家在看新闻或者刷短视频时,能够明显感觉到如果你对某些主题感兴趣,后台会立刻捕获到,并且马上推送相关的内容给到你。目前,在改变数据服务方面,我们已经和不少领先的银行客户有了成功实践,大部分的股份制银行、国有银行其实都在改变传统报表模式,往数据头条的方式去建设,因为原本的被动响应模式已经难以赶上数据消费需求的爆炸,所以银行业需要更多的数据基础设施搭建好,把数据能力释放出去,让业务人员能够自己去玩数据,让数据转起来。
在这里跟大家分享一家股份制银行的案例。这张图是平安银行的指标中台,大家知道平安银行在零售业务上的增长非常快,也是国内少数能够成功进行零售业务转型的银行。我们跟平安银行也有着长年的合作关系,基于我们的产品和解决方案,平安银行打造了一个叫做“潘多拉”的指标中台,通过这个案例可以看出在数据服务方面有非常大的转变:
- 首先,这个平台改变了传统的被动响应的服务方式。目前平台的 IT 部门主要负责的是基础设施的建设和原子指标的输出,再往上的话,业务要做衍生指标或者要看个性化指标都是通过这个平台自己去搭建,相当于一线业务人员是通过这个平台去配置日常工作所需或者对业务最有帮助的指标。
- 其次,这个平台也带有非常强的互联网基因或者说社区文化。用户在平台上除了可以自由设置自己的指标,平台上还有指标推荐功能,这个推荐的底层逻辑不是技术,而是来自于指标的热度,比如,某个分行用了某一系列指标来指导某个业务的开展,这些指标有着很好的业务指导意义,一定会被频繁使用,平台会把这些指标推荐给其他分行或者区域的同类型业务人员,这种自动化、智能化的跨区域、跨条线的业务拉通,对整体业务的推进有着非常大的帮助,而且也有力推动了银行内部的数据文化。
- 而从 IT 的角度来说,这个平台也实现了降本增效、释放产能的目的。整体需求交付速度提升了 240% ,这是一个什么概念呢?就是原本业务提一个需求要看一个指标或者做一个报表,相关人员需要花一周时间去做这个报表。但是现在业务提一个需求,相关人员可能分析一下之后发现所缺的只是几个原子指标,只需要把原子指标加工好,而业务可以像搭积木一样在上面完成自己想要的指标。通过这样的方式,该人员不需要花很多时间去准备数据,基本上只需要 1 到 2 天把原子指标加工好即可,整体实现了降本增效的目的。
- 平安指标平台的上线对整体的报表替换达到了 25% 。不知道大家是否了解银行业维护一张报表大概要花多少钱?这里我们跟客户计算过,银行业制作和运维一张报表所需要的计算、存储以及后期人工运维的成本大约是10 万元/年,如果能下线100张报表,一年省掉的成本就在1000万。可以看到,通过指标平台带来的数据服务方式的改变,对内部降本增效的收益是巨大的。
在指标平台的建设上,平安银行在这方面算是走得比较靠前,同时也可以看到各大头部银行业也都在积极进行这方面的建设,希望能够用主动式的数据服务方式来满足日益膨胀的数据消费需求。
第三,数据平台产品的国产化替换趋势“从软件替换到能力结构与创新”。银行业由于信创的要求,各方面的 IT 设施都在进行国产化替换,数据能力建设范畴内主要包括 BI 分析工具、MPP 数仓软件、OLAP 分析引擎、Hadoop 大数据平台以及数据挖掘软件等。在跟客户多年的合作中,我们也参与了很多国产化替换项目。最近我们可以看到的趋势是,原本只是一个产品对产品的替换需求,随着 IT 基础设施云化大环境的改变以及国产化逐渐走到深水区,原本单体和本地部署的产品,现在都需要基于分布式架构和云化基础设施的大前提下去考虑替换方案,而且随着开源改变软件这个大趋势的存在,替换方案还需要考虑如何能积极的拥抱新技术。
所以现阶段在谈国产化替换的时候,不仅是讨论有没有对标的产品,更多也要考虑替换过程中如何能拥抱新的架构要求和基础设施环境。尤其是云计算的发展,对整个 IT 行业产生了根本性的变化,无论部署方式、资源的使用方式还是运维的方式都发生了变化。而硬件基础设施的变革,一定会需要软件去做相应的适配,所以现在我们跟大行谈到满足信创要求的国产化替换时,谈论的不仅是一个产品,而是一个能力解耦和功能的创新。可以看到,基本上所有的软件最后去做能够解耦的时候,都脱离不了采集、存储、计算、调度、分析、服务、AI、集成这些能力范围,但是如果要做某个产品的替换,并不是按照原本的功能模块去对标,更多是通过新的方案去满足这些能力,并且同时考虑如何把原有的应用能够平滑迁移或者切换过来。
Kyligence 有幸参与了某国有银行进行传统 OLAP 分析软件和数据挖掘产品的国产化替换过程,我们不是拿自己的软件去跟国外的被替换软件对标,而是在满足基本能力的同时,配合客户未来的数字化转型需求和数据能力建设规划进行不断的创新,并且要同时考虑如何能兼容和迁移原有的应用。这里我想举个例子,例如国内的汽车市场,在燃油车领域去超越国外其实已经很难了,国外车企在这个领域有很多先发优势和专利门槛,但是我们通过电动车的模式去替换的时候,发现这是一个可以弯道超车的方式,国内相关企业并不是以完全对标原来的汽车组件的方式,而是以一整套新的解决方案去解决问题,这也是我们看到的接下来在国产化软件替换方面存在的趋势。