数据中台第一贴--开篇明义

写数据中台第一帖，首先来个开篇明义，希望不要闭门造车。

由于很多同行在聊中台，那么这里我们聊中台需要做到有差异和有真实背景。这个帖子是基于建设银行广州开发中心、广发行数据中心的一些情况来聊的。目前各个国有大行、股份制银行在大数据方面的投入很大，寄予希望通过数据产业推动业务升级、推动生产和管理上的改革和进步、促使效率提升和产业结构变化。

建行广开申请下来大量服务器，搭建起很多组件的集群，CDH集群、FI集群、storm集群、ES集群、spark集群、ELK集群、Redis集群、Flink集群等，并且有些集群还有多套（AB角），例如FI集群就有多套。

然而这些集群似乎没有完全应用起来，存在空置状态。但并不意味着大数据的应用已经做到尽头，而相反的是，基于大数据的很多应用的成效并未达到银行的预期，还没有做到通过数据化运营来推动业务的快速升级。

大数据还在一个“变现”的阶段，多年来年的积累和努力集中在于建立一个大数据平台（相当于池子），积蓄和储存数据（相当于水）。而数据的应用比较多的是在银行风控和银行营销方面的实践。目前发展空间还是比较大。那么下一个阶段的大数据究竟是怎么样的形态。

参考阿里提出了“双中台”规划，一个是业务中台，一个是数据中台，银行又应该如何建立中台。这就是写这个文章的出发点，并且努力做到不空谈不妄言，把银行的实际情况分享出来。那么我们就以此为引子，来开展关于数据中台的探讨。

 

与数据中台相对应的银行内部架构应该怎么样

把具体的中台的规划、目标都放到后边去聊。这里先想想一个问题。当数据中台和业务中台都构建好了之后，银行的内部架构会变成怎样。想想康威定律，这必然是一个很有趣的话题。

广发行的混乱

广发行的开发中心和数据中心都在广东佛山千灯湖的金融中心。数据中心做大数据平台的建设和基于大数据的应用，而开发中心做各个业务渠道，包括对公、个人、信用卡等的应用系统。

然而这个过程并不无混乱。

前端时间传出，开发中心已经在构建自己的大数据平台，和数据中心的大数据平台存在一定的重叠。另外原本划分在数据中心的风控应用系统及其开发团队，因为各种原因被划分到了开发中心。因为风控划分在数据中心时，整个风控的调用链路过长而不好控制响应时间；也因为数据中心存在需求响应速度和质量控制不好的问题而备受业务部门的非议。所以才存在这种业务上的调整。

然而其中肯定是有值得商榷的地方的。因为风控的数据来源于大数据的风险画像，很多指标和标签的计算都在大数据离线批次中完成。并且风控过程也可能存在实时流的计算和加工。这些就是数据开发能力的一部分。所以划分到开发中心后，就存在了业务边界模糊的情况了。

幸好这个过程还是比较良性的，相信调整的方向是往更好的协作方式去走。

建行的混乱

建设银行的开发中心划分为北开（北京开发中心，位于稻香湖附近）、广开（广州开发中心，位于科韵路）、厦开（厦门开发中心）。

也许是建行总行的鼓励内部竞争策略或其他的出发点，各个开发中心之间的业务是存在相互争抢的。例如厦开偏重数据仓库（EDW）的建设，而广开偏重于渠道上的应用建设和维护，但厦开会做应用、广开也会建设数仓和大数据平台。相互之间既是建行这个大架构中的重要组成部门而完成整个银行的业务，但又争抢着基于大数据的应用建设业务。这是不利于架构调整的。

而中台的构建能不能作为一把锤子，重锤打破这种格局。

理想中的银行架构

基于上述总总，我们聊聊，银行的企业架构的理想状态是怎么样的。业务部门-开发中心-数据中心应该如何分工。然后我们再去聊中台应该怎么开展。

 

无论中农工建交这些国有大行，或如广发、兴业、浦发这些股份制商业银行，又或者是城商行、农信等，都需要清晰划分数据中心的业务边界和开发中心的业务边界。数据中心对应的是数据中台、开发中心对应的是业务中台。

按照不同银行的合规要求，对行内各部门各渠道的数据采集可采取离线或实时的方式，而对行外第三方数据的采集，出于安全的要求，可通过开发中心的接口进行透传采集。那么就可以做到统一的全行性的采数。

然后进行ETL、然后存入大数据分层中。

然后就是数据探索、数据开发。而数据开发加工分为批量离线加工、内存计算加工、实时流计算加工。

之后是数据模型建设，包括建模过程管理、统一模型管理、模型验证等。

之后是对数据资产的管理。包括依赖管理和血缘管理。

最后，数据通过统一的服务中间价对外提供数据和消费数据。产生数据的价值。

 

如果，这里是说如果，银行的分工真做到丁是丁卯是卯，数据中心只管理数据，开发中心只管理应用。那么数据中台和业务中台就可以真的定义好各自的边界了。

待续。