在“技术+数据”双轮驱动改革转型的大背景下，民生银行于2018年启动了数据中台的论证建设，2019年全线完工投入使用。数据中台的技术诉求与云原生有着“天然”的契合，我行自主探索、自主研发，在建设中进行了诸多探索创新，走出了一条自己的道路。近期作者将分成工具篇和管理篇两个篇章分享这些数据中台在云原生领域的落地实践。

民生银行数据中台建设概况

数据中台是当下一个比较火的理念，由阿里在2017年左右率先对外提出，本质是通过数据技术统一标准和口径，对“全域”数据进行采集、加工、存储，形成一个口径统一的数据服务中间层，进而高效为业务层和决策层提供数据支撑。数据中台理念对大企业更具吸引力，可以对症很多企业成长到一定规模后的“数据病”，金融行业首当其冲，各家金融机构也都在探索中。

图1民生银行数据中台建设概况

民生银行在数据中台的论证实施上走在了金融机构的前列，是首家在金融领域探索并落地金融数据中台的机构，获得金融电子化颁发的《2018年度金融行业科技创新突出贡献奖》，整体架构基于“微服务+容器化”思路设计，Store数据存储体系、Service数据服务体系、Open数据路由体系、Plus管理体系4大功能体系核心模块自主研发，基础组件按照安全可控（国产化）标准落地。现阶段正在为民生银行个金、小微、私银、网金、公司、供应链、资管、监管等10余个业务领域的数据诉求提供支撑，涵盖100余项专业化金融场景、数百项数据服务，日均调用次数超1000万。

初探云原生

云原生（Cloud Native）的概念在2013年左右提出，2015年Linux基金会推出独立的云原生应用基金会（CNCF），云原生技术与应用的发展开始走上快车道，孵化了包括Kubernetes、Prometheus等众多耳熟能详的优秀项目。“原生”即为土生土长的意思，指应用在设计阶段即明确将进行“云化”的部署运行（而非基于虚拟机技术的迁移改造），充分利用弹性、松耦合等云化的优势进行架构设计。CNCF公布的云原生代表技术包括容器（Container）、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施（immutable infrastructure）和声明式API（declarative APIs）。这里作者结合民生银行基础技术栈，将云原生的建设思路抽象为按照微服务、容器化的架构设计应用、兼顾DevOps标准，满足持续交付基本诉求，即：

云原生=微服务+DevOps+持续交付+容器化

图2云原生建设思路

从数据中台建设“痛点”谈云原生技术架构“诉求”

开篇提到数据中台的架构诉求与云原生（微服务与容器化）有着“天然”的技术契合，契合点在于：数据中台在打造金融领域数据服务场景的过程中所面临的“痛点”与云原生技术的特长不谋而合。

近年来银行经营压力持续增大，各业务条线在一线经营上，为了寻求新的增长点，提出了诸多个性化数据分析和服务的述求，在没有数据中台时，要满足诸如小微、私银、网金、公司、供应链、监管等诸多银行业务条线的数据需求，数据分析师和工程师需要在后台数据仓库上完成T+1的数据加工，然后将数据文件推送给各个业务前端系统，每个业务前端系统都维持一个小规模的数据团队，专门负责将数据文件转化为自己领域内的数据服务，实现业务述求。这种模式下痛点以及对数据中台架构选型的要求主要体现在以下几点：

痛点1：存储浪费大。数据以文件方式分发到各个下游系统，均需要占用业务库宝贵的存储资源，尤其是通用场景数据（例如用户画像标签等），重复的资源浪费尤为突出，亟需集中化的存储和服务支撑，体现在架构选型上，即需要“云化的异构存储能力”支撑；

痛点2：传递效率低。文件式数据传递链路以T+1批量为主，数据需要“一股脑”全部加载进本地应用库后方可使用，数据获取的效率远低于通过服务“按需”调用获取指定内容（例如指定客户信息、指定机构指标），数据中台为了支持前端各具业务特色的数据应用场景，需要借助“微服务”解耦和组装；

痛点3：人力投入大。虽然每个业务前端系统只维持一个小规模的数据团队，但银行前端业务系统众多，整体投入不容忽视。这部分工作收归沉淀在数据中台后，为了继续保持对各业务场景迭代诉求的快速响应、同时确保数据中台不会被突增的繁复工作压垮，就需要考虑通过技术手段降本增效，提升持续交付能力。体现在技术诉求上，就是需要“云化的部署运营能力”支撑；

痛点4：管控力度弱。文件式的数据应用方式，文件传送出去后，缺少有效的管控手段，无法准确回答数据使用场景、使用频次等问题，数据的价值难以量化评估，这就要求数据中台建设时除了技术架构考量外，需要同等注重“云化的协作管理能力”建设。

图3数据中台建设“痛点”与技术“诉求”

“微服务”、“云化的异构存储能力”、“云化的部署运营能力”、“云化的协作管理能力”就是数据中台解决目前金融业数据应用痛点的思路，与云原生技术的特长不谋而合。

民生银行数据中台在云原生领域的探索与创新

“求木之长者，必固其根本；欲流之远者，必浚其源泉。”在我行数据中台近两年的摸索、弯路中，上述经验被反复印证，云原生应用不止要在技术层面“达标”，更要在配套管理层面“创新”，配套管理就是云原生应用的本和源。我行数据中台在践行云原生架构思想上结合金融领域数据服务特点进行了三个方面的探索与创新：

探索1：工具层面，打造一站式的数据服务云化DevOps工作台。

核心模块“数据服务云平台”与“场景化数据存储组件”联合打造具备服务场景化管理、技术框架灵活插拔、运维工具丰富全面的“云化开发”、“云化存储”、“云化发布”、“云化运维”的一站式工作台。

探索2：管理层面，提出一套场景金融服务管理方案。

结合民生银行自身业务经营状况对云化微服务集、异构服务组件，从业务场景、是否对客、组件多租户使用等角度进行管控，“场景分区+技术分级”，保证数据中台服务在业务场景高交付下做到可管理、可控制，能够长期有序的运行。

探索3：组件层面，提出一套异构组件分级应用方案。

数据中台结合金融数据应用特点、数据存储组件能力、运维服务级别等因素，构建了一套异构大数据存储组件的分级应用体系，在大数据存储组件服务能力和业务场景诉求间取得平衡，取长补短，根据场景选择合适的存储组件，灵活组合、插拔式使用。

下面作者将分成工具篇（探索1）和管理篇（探索2和探索3）两个篇章分享这些数据中台云原生领域的落地实践。

实践：工具篇

我行数据中台在云原生工具层面，探索打造了一套一站式的数据服务云化DevOps工作台，下文将以点代面，从一项项实用、易用的工具层面，挑选有代表性的功能点，串联中台服务开发、投产、运行的全过程，从而分享数据中台是如何践行云原生架构的（如图4）。

图4数据服务云化DevOps工作台小工具示例

1）插拔式的开发框架与代码生成器

在数据中台上开发应用需要满足微服务设计、支持云化部署、支持异构存储组件等技术特点，这些均对代码标准、开发人员综合能力提出很高的要求，例如：

（1）微服务设计具有低耦合+高内聚的特点，这就要求任何一个微小的服务都要集成诸如日志、缓存、注册与追踪等大量基础功能，且支持在云化环境中运行；

（2）中台的异构存储组件涵盖关系型、内存KV型、分布式KV型等，或独立、或组合以适配不同的应用场景（适配方案在管理篇中介绍），每项组件的连接池管理、最优操作实践、基本规范等均有所不同。

基于以上几点考量，数据中台提供了一套便捷的开发框架生成器（见图5）和代码生成器（见图6），开发人员通过界面勾选方式选择该业务场景微服务所需要使用的基础功能（目前支持服务注册、日志模块、服务拦截、数据拦截、多线程模块、缓存模块等）和存储组件（目前支持MySQL、Redis、Gauss、SDB、HBase），代码生成器会直接生成包含所选功能、包含最优操作实践、可直接云化部署运行的工程代码，开发人员可以快速上手的同时，可以将更多的精力投入到核心业务逻辑的开发中。

图5插拔式的开发框架生成器

图6便捷的代码生成器

2）一键式的云化编译、部署、封版工具

微服务的云化部署运行是一项十分繁复的工作，包含诸多操作细节（例如源码编译、应用打包、镜像构建、容器部署等）和配置细节（涵盖应用配置、数据库配置、集群配置、缓存配置、容器配置等），但同时也是一项直接影响云化运行是否稳定稳定的重要工作，包含多项重要的管理抓手（诸如源码版本、配置版本、运行的环境、镜像的管理、部署的集群、资源的调配等），对服务开发人员技术门槛要求极高。

数据中台整合集成、将繁琐的操作和配置透明化，提供了一套面向docker云化运行环境的一键式编译、部署工具（如图7），微服务应用在云化环境中从构建到部署一键触发、各中间环节执行进展一目了然、历史版本一键追溯回滚。

图7一键式云化编译、部署工具

同时结合民生银行生产变更与版本管理标准，提供一键式的封版、校验工具（如图8），将源码校验、配置校验等工作固化到标准流程中。

图8一键式云化封版、校验工具

两项工具配合使用，在落实云化运行各项管理抓手稳定可控的同时，降低了开发人员云化应用开发的技术门槛。

3）自动化的源码校验、配置校验工具

数据中台针对敏捷交付中版本快速迭代可能出现的风险点，推出了人性化自动校验工具，包含：

（1）源码级别的Change List校验（如图9），提供任意两次版本（或两次投产）间源码级别的更新信息、更新内容等；

图9源码级别的Change List校验工具

（2）配置级别的Change List校验（如图10），提供任意两次版本间配置文件比对提示（新增、差异、缺失等）、文件内容差异化展示（键同值不同、键缺失、键新增等），人性化的设置了红黄警示，配置文件缺失、配置项缺失时用红色进行严重问题警告，配置值不相同用黄色进行一般性的提示。出现一项红色警示则为校验失败，中断后续流程。

图10配置级别的Change List校验

4）云化的全链路服务跟踪

随着云化运行的微服务达到一定的量级，微服务的运行状态追踪、依赖调用分析、热点分析成为云原生领域的技术难题。民生银行数据中台在起步阶段就行了系统性设计，通过服务注册、API Key识别、流水号串接、服务拦截、数据拦截、日志留痕、准实时分析等一系列规范和技术手段，联合打造了一整套完整的云化服务全链路跟踪体系（如图11-13）。

同时针对数据中台微服务的业务特性（主要为数据类服务），在链路跟踪体系中增加对数据存储层访问与数据返回量级的追踪，方便运营人员更全面了解每项微服务的健康状态。

图11微服务依赖分析

图12微服务链路追踪与耗时分析

图13微服务链路日志

5）异构组件联动的生命周期管理工具

数据中台在大数据存储组件层面打造了一套支持异构组件联合使用的分级应用体系，在存储组件服务能力、业务场景诉求、运维级别间取得平衡，取长补短，组合使用（将在管理篇中介绍）。

异构存储组件种类多样，涵盖传统关系型、分布式关系型、内存KV型、分布式KV型等，这就要求中台数据生命周期管理工具在支持基本的单组件数据退役功能的同时，还要支持多组件的数据升降级管理，例如在MySQL退役的历史数据需要联动加载到SequoiaDB，实现数据降级服务。

6）可视化的缓存热管理工具

中台另一项与云化运行结合紧密的小工具是可视化的缓存热管理工具（见图14），针对配置有缓存组件的微服务，支持在应用运行阶段，动态调整缓存时效和缓存开关，同时配备缓存KV检索看板和缓存使用分析等辅助功能。

图14缓存热管理工具

结语

“工具篇”是数据中台云原生应用实践的开篇，一个好的原生应用不止要在技术层面“达标”，更要在配套管理层面“创新”，下一篇章“管理篇”，将从云原生的配套管理方案视角，分享民生银行在诸如“微服务解耦粒度如何把控”、“异构存储组件中的数据如何保持一致性”等云原生难题上是如何落地实践的。