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

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

整体思路：
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 工作台、一组云原生底座则不可或缺。

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

暂时不提中台概念：
1）数据治理，原则上需应该从原交易系统提升，把控质量，到数据平台后，仅能做合规检查或者部分处理。
1.1）数据采集完成后，可通过数据管控机制提升反馈给业务系统来提升数据质量。这里可能你需要的是数据管控平台
2）数据的利用方面：除了给监管报送，风险管理，经营决策类外，在营销、渠道管理、运营类等应用方面中小行应该是急需。再次就是外部数据的利用了，这个不能强求。但总体上各家需求不尽相同。
3）使用什么样的技术平台，要看行内具体发展阶段，还有就是现有业务系统的具体情况以及将来的规划。如果使用开源的产品，最好选用有大型厂商支持的（一般开源产品需要加固、升级的），开源产品总体使用成本也不低，中小银行要有准备，人才可能是比较麻烦的，如果突破现有薪酬待遇是个问题。
4）就目前看，单说数据库产品，完全成熟尚需一定的周期，不能完全靠等。该选择就要选择了，数字化转型的形势等不及。
5）建议中小行根据自己的实际情况分阶段实施，具体缺什么，自己最清楚。

本人作为在大、中小型银行都有过经历的人，对这一问题的理解谈下自己的看法，第一，相比大型银行，中小银行的科技力量是相对薄弱的，甚至有很多是不具备对现有技术架构，特别是中台架构理解的很透彻的，盲目的上，会导致技术的跨越和人才梯队的断层，第二，中小银行的科技部门始终在中小银行的地位不高，用技术的力量去驱动业务系统的全面转型，存在难度。但如果不实施数据中台，需要补课的东西就更多，我的建议是，在数据中台上还是要推动，起码要从业务架构上进行中长期的规划，数据架构马上就要开始梳理，技术选型同步就要开展，新建系统必须要打破数据壁垒，逐步往“数据中台”里迁移

中小银行面临数字化转型 ，要实现数字化转型：
1、首先要数字化，在中小银行发展的进程中，虽然不能和大型国有或是银行相比，但肯定也是有一定的信息化基础和很多业务系统的，数据也是有了一定的基础的积累的，
2、其次是要通过数字化来驱动业务，如何来驱动？数据中台是一个不错的选择， 数据中台的核心就是让数据用起来 让数据发挥更大的价值，让数据具备生产力，来指导和引导银行业务
3、数据的重要性，数据现在已经被很多行业重视，和固定资产相对应的有了数据资产，如何形成数据资产，让这些资产来发展更大的价值，数据中台是必须的
4、数据中台的核心功能包括多源异构的数据的汇聚整合、数据的提炼加工（数据就和石油一样需要经过提炼之后才能使用）、数据资产的可视化（包括数据标准体系、元数据、数据治理、数据质量等）和数据的服务化（像水一样的对外提供服务，不需要为每个应用都单独建设管道和水龙头）
总结还是需要建设数据中台的

个人觉得以上   “ 技术不够成熟”    “ 基础设施基础架构不够重视 ”  都不是实施数据中台的理由，要想把控数据调度、治理、质量，应该有系统化的管理办法，技术部门内部就可以决策了。
至于数据中台的实施，要有非做不可的必要前提、要得到技术一把手的支持、要有清晰的组织结构划分，不然就肯定得不到好的结果(条件齐备了也要看实施质量)。举个现实中遇到的例子，两个业务部门一方做事开放，另一方做事保守 ，单单一个数据权限审批流程的设计，就能让双方冲突。
所以首先亮出遇到的问题，看看单纯依靠技术的解决方案是什么、实施成本有多高，再对比看看是否要放大到做数据中台

个人觉得，如果没有技术能力自主把控，还是先不要引入的好
数据治理做不好，中台更难做好，不是有个中台，就能做好数据治理，输出高质量数据了，相反，是做好了数据治理，有了高质量数据，才容易做中台。

你看那几个大厂有谁中台做好了？没有吧，更多的吹嘘的成分，为什么？因为部门太多，系统太多，数据在企业内不规范不标准，没有实现高质量数据治理，去做中台，事倍功半。

所以中台落地步骤和关系不要弄反了，否则会很累

数据调度，数据治理，数据质量是中台基础，建不建中台都不影响去完善这些事情