搭建数据中台,某商业银行实现数据服务敏捷交付,支撑AI智能化应用

原标题:搭建数据中台 , 某商业银行实现数据服务敏捷交付 , 支撑AI智能化应用

搭建数据中台,某商业银行实现数据服务敏捷交付,支撑AI智能化应用
文章图片
总部位于杭州的浙江某商业银行(以下称“该银行”)成立于1987年 , 2005年完成股份制改造 , 2006年由地方城市信用社改建为商业银行 , 致力于做小微企业和市场商户的商贸金融伙伴 。
几年前大数据浪潮兴起时 , 该银行在传统数据仓库架构之上拓展搭建了大数据平台 , 并与多家厂商合作 , 建设了多个大数据相关系统 , 但是系统间联动能力较差 。 这就导致了数据需求被多个操作人员转化成了数以万计的ETL任务 , 散落在几千张表中 , 无法形成有效的数据资产 。
配合数字化转型战略的实施 , 该银行成立了数字金融部 , 作为数据管控和服务的一级部门 , 主要负责数据资产的管理和对接业务部门的数据需求 。 通常 , 业务部门提出需求后 , 管控部门首先去理解相关需求指标 , 定位源数据表和数据本体 , 再分析指标如何计算实现 , 然后提交科技部门开始开发测试工作 , 完成后通知业务进行结果确认 , 最后进行批量的后台处理 。
这一系列流程周期长 , 从几周到几个月不等 。 对于业务部门 , 数据需求排期流程十分漫长 , 过程中与开发人员反复确认口径 , 沟通成本高 。 由于缺少友好的自助分析工具 , 过于技术化难以理解;对于科技部门 , 业务部门反复提出取数需求 , 挤占大量开发人员时间 , 无暇顾及更高价值的业务分析或AI类需求 。
总结来看 , 该银行面临数据需求兑付缓慢的痛点 , 主要有三个方面的原因:第一 , 系统联动能力差 , 无法形成统一的数据资产 , 新场景开发难以复用已积累的数据资产 , 需要重新取数;第二 , 取数工作流程长 , 耗时长;第三 , 数据分析依赖于开发人员用繁琐的代码完成 , 技术门槛高 , 开发效率低 。
为了解决以上问题 , 该银行经过慎重考核 , 选择了山景智能作为合作伙伴 。 山景智能是一家面向未来银行的数据及业务智能服务提供商 , 旨在帮助金融机构构建和提升数据资产及AI智能化服务能力 , 目前已推出智能数据平台-星际STELLA、智能AI平台-星云NEBULA、智能业务平台-觉醒AWAKE、全流程敏捷开发管理平台系列自研产品 。
经过深入的调研后 , 山景智能为该银行搭建了一套业务中台和数据中台 , 通过数据资产化将行内此前数据治理的成果串联 , 同时满足离线、实时数据查询、分析需求 。
管用一体 , 支撑数据需求的敏捷交付
在本次合作中 , 该银行主要做了三个方面的工作 。
首先 , 对该银行原有技术平台进行串联整合 , 以集中API化的方式在山景智能的底层数据服务平台进行统一的数据调用 。 一方面 , 所有资产发布必须与行内现行的基础数据标准和指标数据标准对标 。 基础数据资产的发布对接该银行现有数据仓库(Oracle , Teradata)或者大数据平台(CDH、TDH等) 。 另一方面 , 各类报表、AI、数据应用和数据API均基于发布后的数据资产进行封装或衍生 。 保证了数据可基于同一套标准进行管控 , 并且保证了数据入口和出口的统一 。
图1:该银行数据数据中台示意图

搭建数据中台,某商业银行实现数据服务敏捷交付,支撑AI智能化应用
文章图片
其次 , 山景智能为该银行制定了数据资产的规划项目 , 让科技部门用贴近业务的语言准确表达需求 , 并将该需求自动生成为数据资产 , 避免实现过程中的理解差异与反复 , 也让科技部门更好的复用数据资产 , 实现快速交付 。
具体而言 , 在数据资产化的环节 , 山景智能采用本体建模的方法 , 基于面向业务的语言构建数据资产 , 映射元数据 , 进而形成全行级的知识图谱 。 随后 , 以乐高积木的方式对数据资产进行拼装 , 数据资产的衍生通过配置实现 , 便于追溯 , 保证资产的可复用性 。 并以图形化对数据血缘进行展示 , 这样可以更好的反应数据资产或数据标准的系统分布 。 基于数据资产外放的指标库、标签库、API库 , 用户自定义形成的查询、分析、模型、报表构成了数据应用市场 , 最终实现场景赋能 。
图2:该银行数据中台的工作流

搭建数据中台,某商业银行实现数据服务敏捷交付,支撑AI智能化应用
文章图片
在数据中台的模式下 , 从业务需求到数据资产化的整个过程实现了闭环 。 业务人员提出需求后 , 需求随后流转到数据资产管理部(即数据金融部) , 数据资产管理人员对需求的业务指标进行分析 , 如果发现该指标已存在于数据平台中 , 则直接进行资产发布;反之 , 管控人员会将需求转达至科技部开发人员 , 进行模型研发工作 , 根据需求自动生成数据资产 。