数据资产变现能力一直是困扰中小型城市商业银行业务运营转型的关键痛点，虽然通过试点引入外部数据，引入实时计算引擎和数据建模，在辅助营销决策，网贷风控等方面做了一些尝试，但是还没有找到为银行数字化运营赋能的关键。
一、现状和痛点
目前中小型城市商业银行在数据方面存在以下的痛点：
业务层面
数据研发中心无法快速支持业务数据任务要求
各个系统提供的数据标准规范不一致，主要体现在命名规范不一致、不同的人所跑出来的数据分析结果不一致，数据统计口径不一致
部分行有数据门户，但是业务部门无法操作，无法自助快速获取数据
数据应用大部分面向统计报表和监管报送，面向业务应用支持能力几乎没有。
数据孤岛现象还是比较严重。特别是业务相关数据的融通和价值发掘不够。
技术层面
城商行烟囱式项目建设模式，给数据建设带来灾难性后果，数据标准、规范无法按预期实施。数据质量提高与预期相去胜远。
烟囱式项目建设模式很多内容重复建设，数据研发中心处理任务量冗长，处理效率低
不能专注与数据价值发掘的工作，每天疲于应对业务部门的数据任务要求
数据研发中心生产任务繁重，计算资源紧张，数据批量计算慢，时效性不强。
面对这些痛点，部分银行想通过数据治理项目来解决问题，投入了大量人力，财力之后发现烟囱式的外包项目建设模式下数据治理由于没有落地抓手，最终只能得到一大堆的文档，成效甚微。所以绝大部分的数据治理项目是失败的。
二、契机
随着技术的不断进步，软件架构在不断演进，微服务架构当今大行其到，银行所采购的业务商用软件也基本上被java生态覆盖，数据建模、规范方面也趋于统一。同质化的建设模式，为银行数据规范化带来了契机。
数据处理技术也在飞速的发展，lambda架构利用大数据的计算能力对外提供离线+实时数据服务。近两年以Flink为代表的数据批流一体化模式在计算层面实现了统一的计算框架支撑，批处理仅作为流处理的一个特殊场景纳入框架中，使得实时业务分析场景技术可以在银行业务场景中大量使用，离线计算模式的不断演进也使得银行批流处理效能得到质的飞跃。
数据中台的思想也受到业界热捧，数据中台在数据研发中心内部成为一个数据治理落地的抓手，使得数据治理不在停留在表面；也极大的提升了银行数据资产变现的能力，使得数据能够为银行的业务应用提供运营支撑。
引入数据中台，已经成为银行数字化转型途径上比业务中台更能让让各方达成一致的一个环节。但是数据中台其实是一个建设模式和方法论，是重新购买一套成熟的数据中台产品，还是在现有数据仓库基础上按照中台的思路建设，成为数据中台落地的争论点。
三、数据中台建设思路和步骤
1、中小型城商行数仓建设现状
中小型城商行数仓建设大概有以下几种：
传统数仓
主要负责全行报表、经营数据指标供数和监管报送
传统数仓+大数据平台
主要服务报表、经营数据指标供数和监管报送
历史明细整合查询
客户360视图
高管驾驶舱供数
网贷实时授信
智能营销支持
大数据平台
功能同传统数仓+大数据平台
2、传统数仓和数据中台定位
3、传统数仓和数据中台功能边界
总结一下，数据中台主要是建立健全全行数据资产管控能力，面向全行业务应用提供数据决策，实时数据分析等数据化运营能力。传统数仓，是面向行内数据，给报表和决策支持系统供数，并且数仓建设过程中对于数据资产的管控能力较弱，数据管控没有形成完整意义上的闭环。
四、数据中台建设思路和路径
其实不管是传统数仓和数据中台，对于数据资产管理的建设思想并没有太大区别，主要区别是传统数仓积累了非常多了技术债，所以在数据资产管理上有非常多的痛点。给业务和业务运营提供的能力支撑也非常的弱。
数据中台主要是为业务转型和运营提供智能数据化支撑，深入各类业务场景，并且利用现有先进的架构和技术（主要是先进的数据底盘）对数据资产管理能力进行重构。
数据中台的能力完全可以覆盖传统数仓的能力，但是银行对业务风险和监管报送的零容忍不可能让我们撸起袖子就替换，在建设过程中必须考虑传统业务稳定性、中台建设过程中短期效能体现的业务目标，信息技术人员能力匹配程度，以及业务人员的逐步接受适应情况。因此对于中小型城市商业银行个人认为比较理想的建设路径和思路是：
最稳路径（多少有些无奈）
这个实时路径的整个架构前提是在中台实施期间尽量保持稳态传统能力不做功能修改，您可能觉得这个是个很可笑的事情，但是中小型城商行的科技现状却是是比较堪忧的，大部分科技人员甚至中层领导是拒接走出舒适圈的。
所以这个是一个最把稳的路径，如果您所在机构有能力有意愿做好数据中台，又能大量的投入人力物力，那么可以使用跟激进的一些建设路径，在建设数据中台的时候就可以落地实施过度方案，中台建成后很多能力可以一次性过度到中台，特别是数据可视化和降低数据使用门槛的能力可以提前考虑。
五、双态架构数据中台技术架构全图
1、整体技术架构图（涉及到的开源技术框架，产品就不在这里详细描述，后续章节会有详细描述）
2、最终替换后的数据流图
六、实施过程中需要关注的技术关键点
由于是购买大厂的产品，数据中台和底盘的技术选型很重要，这里不便多描述，一旦选定之后其实整体技术框架，产品组件我们是没法自己再去干预的，所以这块不是技术关注的关键点。
技术关注关键点我认为有一下几个：
并行期数据中台和原数仓并且的业务边界要划清楚，虽然有了前面的架构设计原则，但是如果您想进一步深入的话就要把边界划清楚。
并行期根据您的规划明确数据中台和原数仓数据交付方式，特别要明确要从原数仓的哪个层去抽取数据。
涉及到业务中台用户、账户等数据的支持，需要与原业务系统进行数据同步，优先采用数据库级别准实时同步，当然关键数据需要采用实时同步需要对 OGG/Canal/DTS-->Flume-->kafka-->中台对应业务库的流程中详细设计，业务层面也需要准备查询不到去稳态拉数据的机制。
关注数据API的定位和使用情况
要明确分布式事情的范围，不是所有事务都要使用分布式事务。（这个好像跟主题没多大关系）
数据规范这个关一定要把住
七、最后
有些人会觉得方案很low，但是如果您了解城商行的现状，我想多半会同意我的一些观点。当然你所供职的机构是土豪，完全可以自研，其实大数据框架，实时计算框架，消息队列等等都是都有开源软件支持，但是要踩多少雷？多少坑真？这种付出是城商行无法承受的。
后续会深入技术细节做一些讨论。