引言
银行是传统行业中非常重视信息化的，而且起步早，信息化程度高，但是由于技术的高速发展，互联网思维的冲击使得银行纷纷面临数字化转型的挑战，这里的转型不仅是业务转型，也有技术转型。
如今，许多业务不用跑去网点、柜台，人们通过银行的手机客户端，动动指尖就能完成转账汇款、购买理财产品等，这些便捷的操作方式正是得益于银行的数字化转型。当然，数字化转型转并不只是表面上看到的业务转型，还有其背后的技术、组织架构和人的思想的转型。
银行一直是新技术的实验场，因其具有资金优势和丰富的客户类型，对于技术应用而言，有良好的用户基础，并能支撑住研发的资金投入。但是银行业面临的痛点也很明显，国内银行业同质竞争非常严重，业务类型、监管标准、客户群体都高度重叠，但是流程却各不相同，因为流程的背后是组织结构和部门利益，各个银行之间部门设置和职责边界都是有差别的，这种差别会直接体现在系统结构上。银行都在谈转型，但真能大刀阔斧改革，并不容易。
民生银行场景化数据服务中台就是在数字化转型的大背景下诞生的，正因为此次中台实践的成功，民生银行场景化数据服务中台也被云计算开源产业联盟选为“2020云原生应用十大优秀案例”。
银行为什么要建数据中台？
一般来说，数据中台是指通过数据技术对海量数据进行采集、计算、存储和处理，同时统一标准和口径，形成全域级、可复用的数据资产中心和数据存储能力中心，形成大数据资产层，进而为客户提供高效的服务。
数据中台构建的服务具备“可复用性”，每项服务都像一个积木，可以随意组合，灵活高效地解决前台的个性化需求。其核心理念是“让一切业务数据化，一切数据业务化”。与传统数据平台相比，数据中台着眼于业务的积累和沉淀，构建了从数据生产到消费、消费后数据返回到生产的闭环过程。
银行为什么要建数据中台？
近年来银行经营压力持续增大，为了寻求新的增长点，各条业务线提出了诸多个性化数据分析和服务的诉求，在没有数据中台时，要满足诸如个金、私银、小微、公司、供应链、资管等诸多业务线的数据需求，数据分析师和工程师需要在后台数据仓库上完成T+1的数据加工，然后将数据文件推送给各个业务前端系统，每个业务前端系统都维持一个小规模的数据团队，专门负责将数据文件转化为自己领域内的数据服务，实现业务需求。这种模式下有几个明显的痛点：
痛点1：存储浪费大。数据以文件方式分发到各个下游系统，均需要占用大量宝贵的存储空间，特别是通用数据（例如用户属性标签等）的存储和服务，亟需集中化的存储和服务支撑，并且需要“云化的异构存储能力”支撑。
痛点2：传递效率低。文件式数据应用链路以T+1批量为主，全量数据“一股脑”加载进本地应用库，数据获取的效率远低于通过服务“按需”调用获取指定内容，数据中台为了支持前端各具业务特色的数据应用场景，需要“微服务”支撑。
痛点3：人力投入大。虽然每个业务前端系统只维持一个小规模的数据团队，但银行前端业务系统众多，整体投入不容忽视，并且很多方向并没有对应的数据团队，因此很多业务数据上的一些思路和诉求，迭代较慢，在技术上需要“云化的部署运营能力”支撑。
痛点4：管控力度弱。目前的文件式数据应用方式，文件传送出去后，缺少有效的管控手段，无法准确回答数据如何使用、使用频次等问题，数据的价值很难评估，这就需要考虑“云化的协作管理能力”建设。
“微服务”、“云化的异构存储能力”、“云化的部署运营能力”、“云化的协作管理能力”是数据中台解决目前金融业数据应用痛点的思路，将数据服务集中进行开发和处理，盘活数据，让数据在线。
数据中台体系技术方案
民生银行数据中台体系采用“微服务+云化技术”作为基础技术架构选型，核心运转模式由 Engine 引擎体系、 Service 服务体系、 Open 路由体系、 Plus 管理体系各类专项组件协同运转完成：
体系 | 模块 | 定位 |
Engine引擎体系 | 查询检索引擎 | 提供基于分布式数据服务组件的数据查询检索能力 |
标签引擎 | 提供标签查询、标签筛选能力 | |
推荐引擎 | 提供基于规则和模型的实时推荐能力 | |
决策引擎 | 提供可视化策略配置、实时策略决策能力 | |
模型引擎 | 提供高阶机器学习模型的在线执行能力 | |
Open路由体系 | OpenAPI | 联机服务路由、联机服务调用跟踪 |
OpenFILE | 批量数据路由，批量数据交互跟踪 | |
OpenMSG | 实时消息路由，实时消息订阅跟踪 | |
OpenCFG | 界面化参数配置与应用，界面化规则配置与应用 | |
Plus管理体系 | 数据服务云平台 | 数据服务开发、测试发布、云化管理、运行追踪的一站式管理台 |
数据服务目录 | 数据服务能力汇总展示的门户网站 | |
数据大屏 | 数据能力指标、运营统计指标的可视化大屏展示 | |
基础组件 | 数据服务组件 | 数据中台共享的数据服务组件，包含关系型数据库、分布式数据库、统一缓存、检索等 |
结合民生银行现阶段业务经营的迫切诉求，阿里云从技术平台和数据交付两个层面为民生银行制定了架构设计路线。
在技术平台层面，通过微服务架构完成数据及模型的服务化，便于直接在系统上高效对接，结合技术组件特点和场景特点完成服务的标准化，形成标准的交付模式，进一步在技术上形成可配置化的服务框架，快速生产场景数据服务。在底层技术上，由于中台数据服务的集中化建设，底层采用分布式以及云化的相关技术完成基础层建设，让服务更高效可靠地发布、运行并可管控。
在交付的内容层面，将团队组织架构配合场景数据标准分区，形成小队敏捷的交付模式，提高业务交付效率。在统一的平台工作标准和模式下，沉淀共性数据内容，领域内形成工具、数据的复用，做到在灵活高效交付的同时，实现降本增效。
民生银行数据中台核心运转模式如下图所示。
数据中台核心模块运转模式
首先，由Engine引擎体系完成对数据能力、模型能力的抽象封装，以应对不同场景的智能数据需求。
其次，Service 服务体系完成引擎抽象能力与实际业务数据的结合应用，通过微服务模式灵活搭配，打造具备业务属性的数据服务产品。
第三，通过 Open 体系（OpenAPI、OpenFILE、OpenMSG、OpenCFG）完成对业务系统与业务人员的快速赋能。最后，Plus 管理体系完成微服务云化管理、数据资产目录、数据可视化等统一管理功能，并通过DevOps、容器、高性能数据访问缓存等前沿技术组件完成数据服务高并发、高可用、弹性部署等技术能力的提升。
引擎、服务、路由协同运转，统筹管理，共同打造了场景化金融数据服务能力。从数据指标、数据决策、智能推荐、智能模型等多个层面提供了立体化的快速支持，为金融业务数字化、智能化转型升级的重要支撑。
异构分级存储方案
数据中台支撑的金融业务场景多样，民生银行结合数据应用特点、数据存储组件能力、运维服务级别等因素，构建了一套异构大数据存储组件的分级应用体系，在大数据存储组件服务能力和业务场景诉求间取得平衡，取长补短，根据场景选择合适的存储组件，灵活组合、插拔式使用。
以常规的数据分级存储方案为例，如下图所示，引入 Redis 作为统一缓存，屏蔽下级组件服务性能波动，通过数据业务日期进行分割，近期数据存储在 MySQL，提供 7*24 小时的运维服务保证支撑，历史数据存储在 HBase&SDB 等大数据存储组件，提供强大的服务能力和水平扩展能力。
数据中台云原生应用实现两个“易”
金融领域里，数据中台云原生应用服务的特点相对明确：
一是让业务需求方真正能够感受到数据“易用”，数据能够直接输出到系统、能够在线闭环、能够快速敏捷迭代开发。
二是在技术平台层面，集中的平台要面对不同业务条线、业务系统以满足他们的数据服务诉求，平台自身也具备支撑多样化需求的能力。
1、技术平台上“易”
数据中台改变过去数据以文件输出的模式，将数据、模型等服务化，能够直连场景，便于形成在线的数据闭环。针对不同的数据服务场景，结合技术分级，按分级形成标准交付模式。通过标准化后，在开发上也抽象数据服务框架，结合“微服务+云化”支撑，以及配套DevOps体系完善，最后达到通过配置即可产生新的数据服务，提高效率，同时也便于质量管控。
2、交付内容上“易”
数据中台可以实现交付敏捷化，快速满足业务需求，数据运营和经营本质就是一个不停迭代往前的过程，通过标准化、配置化的技术平台，按照条线领域配置矩阵式的人员交付工作模式。通过数据服务的集中开发和服务管控，通过集中监控去量化数据价值，准确了解数据使用的状况，并最终实现成果共享化。
更多创新探索
民生银行数据中台体系在践行云化架构思想上，结合金融领域数据服务特点，进行了三个方面的创新探索：
1. 平台层面打造一站式的数据服务云化DevOps工作台
核心模块“数据服务云平台”与“场景化数据存储组件”联合打造具备服务场景化管理、技术框架灵活插拔、运维工具丰富全面的“云化开发”、“云化存储”、“云化发布”、“云化运维”的一站式工作台。
2. 管理层面提出一套场景金融服务管理方案
民生银行根据自身业务经营状况，采用“场景分区+技术分级”方案，保证数据中台服务在业务场景高交付下做到可管理、可控制，能够长期有序运行。
3. 组件层面提出一套异构组件分级应用方案
金融数据应用特点、数据存储组件能力、运维服务级别等因素，民生银行数据中台构建了一套异构大数据存储组件的分级应用体系，在大数据存储组件服务能力和业务场景诉求间取得平衡，取长补短，并能根据场景选择合适的存储组件，灵活组合、插拔式使用。
场景化数据中台的效果
数据中台是连接前台和后台的核心资源。通过为前台提供强大的“能力炮火”支持，可以将后台系统中需要频繁变化或前台需要直接使用的业务能力“提取”到中台层，赋予这些业务能力更高的灵活度和更低的变更成本。
民生银行建设场景化数据中台的效果非常明显：首先是数据能力的提升，围绕数据指标在线化、实时化，算法模型服务化，开放更多大数据能力，将数据应用方式由后台向中台化、服务化演进，直接为业务赋能；
其次是交付效率的提升，结合业务场景，将分布在不同模块和组件中的数据服务统一管理、规划服务方式和标准，统一服务调用方式，统一开发框架，统一缓存机制和辅助开发工具，缩短新产品开发周期，提升了交付效率；
三是运维效能的提升，采用阿里云微服务+基于Docker容器的云化技术，应用的部署、启动、升级、停止、蓝绿发布、弹伸缩等运维操作一键化，实现功能及服务的灵活打包部署，构建位置透明的集群服务体系，降低领域繁杂的数据应用运维成本。
最后是管理效能的提升，在统一的平台工作标准和模式下，沉淀共性数据内容，领域内形成工具、数据的复用，做到在灵活高效交付的同时，丰富了管理抓手，实现提效降本。
总结
数据中台的建设是一项系统性工程，从组织架构、支撑技术到流程规范，既要有宏观的顶层设计，又要有强有力的落地执行，数据中台的建设没有一劳永逸的办法，企业需要从战略层面进行更多思考，再配合选择合适的数据中台服务商，方能在数据中台建设之路上走得稳妥。
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
