中小银行数据中台是否有必要？

数据中台建设必要性的论证是每家机构必做的功课，目前没有一个成熟且可量化的论证方案。这次讨论交流中也有很多朋友在咨询，这里我结合金融数据中台的建设实践，分享一个论证方案的思路，供各位参考。

整体思路：
Step1 ：数据中台的“能力“有哪些 -> Step2 ：企业当前数据体系的“痛点“有哪些 -> Step3 ：企业建设数据中台的技术储备是否满足 -> Step4 ：数据中台”完整版“与”轻量版“的选择

下面我简明扼要提一下每个论证环节的要点：

**论证环节 1 ：数据中台的“能力“有哪些
**
数据中台本质是通过数据技术统一标准和口径，对 “ 全域 ” 数据进行采集、加工、存储，治理形成一个口径统一的数据服务中间层，进而高效为业务层和决策层提供数据支撑。抽象几个关键词方便理解中台的“能力“：（ 1 ）数据质量治理的抓手（抓口径）、（ 2 ）数据出口治理的抓手（抓出口）、（ 3 ）数据服务的仓库（抓内容）、（ 4 ）高效迭代、高效运营（敏捷交付）。

**论证环节 2 ：企业当前数据体系的“痛点“有哪些
**
数据中台理念对大企业更具吸引力，可以对症很多企业成长到一定规模后的“数据病”。数据中台是否能够对症下药，需要我们架构师能够清晰分别和总结出各自企业的“数据病”症结。

这里以金融机构的数据体系发展到数据仓库阶段时，举例分析所面临的“数据病”，以及论证环节 1 中总结的数据中台“能力”能否对症这些“痛点”：

金融机构在目前的市场化阶段，各业务条线在一线经营上，为寻求新的增长点，提出了诸多个性化数据分析和服务的述求，在没有数据中台时，要满足诸多业务条线的数据需求，数据分析师需要在后台数据仓库上完成 T+1 的数据加工，然后将数据文件推送给各个业务前台系统，每个前台系统都维持一个小规模的数据团队，专门负责将数据文件转化为自己领域内的数据服务，实现业务述求。这种模式下痛点以及对数据中台架构选型的要求主要体现在以下几点：

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

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

（ 3 ）痛点 3 ：人力投入大。众多前台系统的数据转化工作收归沉淀在中台后，为了继续保持对业务场景迭代诉求的快速响应，就需要通过技术手段降本增效，提升中台持续交付能力。体现在技术诉求上，就是需要 “ 云化的部署运营能力 ” 支撑；

**论证环节 3 ：企业建设数据中台的技术储备是否满足
**
接下来要看，各位架构师所在的机构是否具备论证环节 2 中提到的数据中台“技术门槛”，例如包括“微服务”、“云化的异构存储能力”、“云化的部署运营能力”，概括出来就是目前另一个流行的理念“云原生”，数据中台的架构诉求与云原生有着“天然”的技术契合，这个在我另一篇发表过的文章中有详细阐述。这里将技术储备的要点，列出如下：

**论证环节 4 ：数据中台”完整版“与”轻量版“的选择
**
分析清楚了 1-3 环节，那么我们基本具备了构建数据中台“完整版”的素材，这个“完整版”是一个包含一些列工具平台和管理规范的大工程，笔者所在机构构建的数据中台涵盖 Store 存储体系、 Service 服务体系、 Open 路由体系、 Plus 管理体系 4 大体系十余个子系统。

但实际实践上，数据中台建设其实是有轻、重之分的，这时候就是考验我们架构师功底的时候，如何从庞大的体系中，抽取各家机构最关注的“轻量版”进行建设。举个例子，如果关注中台能力 1 “数据质量治理的抓手（抓口径）”，那么数据服务目录、数据指标管理两项功能模块就是必备功能；如果关注中台能力 4 “高效迭代、高效运营（敏捷交付） ” ，那么一套支持容器化运营的 devops 工作台、一组云原生底座则不可或缺。

限于篇幅，不能完整展开每一项论证环节，各位架构师可以选取关注点，深入交流。