创新生态数据中台建设理念

陈建周

前世今生

“舆论往往会更强调技术对业务的推动作用，但事实上，在商业领域，更多的时候，技术发展都是跟着业务走，技术的发展常常来自于业务需求和业务场景的倒逼。”

如图1-1所示，各集市应用与业务源系统的数据交互会呈现为网状结构，即源业务系统的一份数据会与N个下游应用系统进行交互，需要卸载N次，传输N次，效率极为低下。

因此，数据仓库应运而生，如图1-2所示，保证了个各业务系统和应用系统都通過数据仓库进行交互，由于数据仓库汇聚了各业务系统的数据，因此，为方便存储及数据区分使用，数据仓库的定义是“是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策”。可见，数据仓库即面向上游业务系统—收数，又面向下游系统—供数。因此，在面向收数这方面，其在存储方面需要面向主题以区分不同数据，在建模方面有三范式、维度建模等，而在供数方面，为了提升效率，需要计算和访问分离。而站在资源共享的角度，各应用集市总有一些共性的加工指标，它们会沉淀在数据仓库的公共计算层。笔者认为，这个时候已经具备数据中台的雏形或萌芽，这就是数据中台的“前世”。也难怪有不少人认为数据中台就是抽取共性加工的东西，做成公共模块供调用而已。

但是这里面涉及到一个问题，就是数据仓库和下游应用之间会互相挤压，像某国有银行经过十几年的数据仓库建设，数仓里虽然也有公共计算层，但是由于各种历史原因，现有数仓逐渐沦为按一定业务规则进行纯数据加工的“原材料粗加工地”—数据人员可以不懂业务，由应用系统提数据需求即可，毫无知识沉淀可言，本应由数仓提供的能力却最终实现在业务应用中，最终就是各应用集市越做越大，各集市不断搬迁数据重复加工，可以用“小中台大前台”来形容。

因此，“大中台，小前台”的数据中台战略思想在这一历史时期的提出便尤为可贵，这也是为什么该理念能迅速被接受的关键之一。在“大中台，小前台”这一战略思想下，中台与前台的此消彼长，不是为了厚此薄彼，而是为了更好地赋能前台。

业界给出数据中台的定义基本有两种，一是“数据采集交换、共享融合、组织处理、建模分析、管理治理和服务应用于一体的综合性数据能力平台，提供面向数据应用支撑的底座能力。”二是“聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念”。无论哪一种，在笔者看来， 现有银行已建的数据仓库都可认为是数据中台的初级版本，因为数据中台所定义那些属性，现有的数据仓库也都基本具备。

从经济学的角度讲，因为资源是稀缺的，所以在企业内部，各前台应用之间、前台应用与后台数据仓库之间，不可避免地存在资源争抢，或者说某种程度上的零和博弈，因此，提出了创新生态数据中台的理念。创新生态的数据中台是一种资源重新分配的方案，它能够引导资源向投资回报更高（一处加工，多处使用）、更可持续的方向流动，从被动地接收下游前台应用系统的加工需求，逐步转变为前台应用主动赋能。而之所以倡导数据中台是个创新生态的平台，是因为创新生态中各要素通过长期协作、结合业务创新、技术创新，在数据中台上面才能不断生长各种可复用的数据服务。在后文的“中台各要素的共生共荣”会详细描述创新生态各要素的合作机制。创新生态的协作型竞争、生态中各要素对彼此重要性的认可都将有助于生态的稳定性。

数据中台应具备的核心能力

以上通过分析数据平台的发展历程分析了引入数据中台的必要性，即数据中台这个初级版本如果不加控制，就容易走向“小中台、大前台”的老路子。

因此，为了避免重走老路，数据中台应具备哪些核心能力？

1.数据服务化能力

帮助企业快速实现数据资产的可视化分析，提供包括实时流数据分析、预测分析、机器学习等AI服务的能力，数据洞察源于分析，不仅帮助洞察驱动业务的通路，更以实时调用、批量供数、可视化展示、辅助支持等多种形态“嵌入业务”，为企业数字化运营赋能。

Data API 是数据中台的核心之一，它是连接前台和后台的桥梁，通过 API 方式提供的数据服务是否好用，是否具有灵活性和可定制性，直接决定了数据中台的生命力。

另一方面数据服务化能力也依赖于数据的集成整合能力和数据资产的治理能力。

2.数据集成整合能力

支持多样化数据采集，包括但不限于客户端、服务端埋点、网络爬虫等，支持海量多态数据存储、高性能计算，结构化、半结构化和非结构化数据处理，通过内外部数据融合，链接跨领域数据，实现一站式从数据接入到数据消费的全链路数据构建，并以场景化为依托，借助于智能数据映射、建设数据可信的标签体系、访问权限可控的数据资产体系，以满足企业业务对数据的需求。

3.数据成果的共享能力

企业的数据中台一定是跨域的，需要跨部门实现业务价值，因此需要让大家都知道数据资产目录在哪里。只有实现共享和开放，构建创新生态数据中台，企业的数据才能有效地流动起来。所以在数据安全的基础上，企业的数据资产目录要对利益相关者、价值创造者开放，要让业务人员能够做到“Self-Service”。特别是，在银行中，某些应用的复杂计算指标经常会被全行作为共性指标所引用。在数据共享的基础上，跨部门的协作才会被真正激发出来，数据中台的创新生态才能被有序构建出来。

相较于以往的数据共享，创新生态的数据中台更强调数据的智能推荐能力。现在人们已经对购物APP的智能推荐司空见惯，那么在一个成熟数据中台里的数据共享中，业务人员通过简单的搜索或在用数过程中，就应该被智能推荐数据服务或数据成果，这也是另一层面的挖掘需求或满足其潜在需求。当然，数据的智能推荐不仅依赖于机器学习，也依赖于数据的累积和沉淀。

创新生态数据中台建设理念

理解了数据中台所应具备的核心能力，那么就很容易理解，数据中台初级版本向高级版本演进应朝着创新生态数据中台发展的建设理念，避免重走“小中台大前台”的老路。笔者总结了以下几点创新生态数据中台的建设理念，希望对银行在新一轮的数据中台升级换代中有所帮助。

1.做好顶层设计与快落地

“欲事之无繁，則必劳于始而逸于终”。

今年武汉的火神山医院从项目规划到建成，只用了10天的时间，这种高效率离不开3万名工人加班加点，24小时不停歇地工作，但更离不开项目一开始的顶层设计。在建筑设计上，从局部看，是一个“工”字型，“工”字形的那两“横”，是病人住院的地方，而“工”字的那一竖，是医生主要活动的区域。如果把几个“工”字形通过中间那一竖串联起来，那整个医院，就像在撘积木一样，可以无限延展。

大道相通。数据中台的顶层设计包括数据中台的技术体系、数据体系、服务体系、运营体系。技术体系是基础支撑，使得整个数据中台能够像搭积木一样快速搭建，中台常见的技术体系一般选择分布式计算平台如hadoop或MPP架构。数据体系就像是数据中台的积木，规划了数据体系，就如同规划了积木要如何去搭建，是用“工”字型还是什么型，对应在数据中台的数据体系就是建模用维度建模还是三范式建模，数据架构是用Lambda架构还是批量数据架构，简单理解数据体系解答的是数据的组织方式。服务体系是数据中台的价值变现，就像火神山医院不仅要为病人提供住处，还要提供优质可信的医疗服务一样。运营体系是相当于医院的后勤保障，能够不断接收新的病人、批准痊愈病人出院、不断吸纳和欢送来自全国各地的“逆行者”，也就说，通过运营体系保证整个中台是一个创新生态的中台，能健康、持续运转。

如今，云计算平台虽然为数据中台的技术体系无限扩展提供了可能性，但是这种扩展不应该是无序增长，资源总是稀缺，如果毫无规划，大量系统、功能和应用重复建设，就会存在巨大的数据资源、计算资源和人力资源的浪费，同时组织壁垒也导致数据孤岛的出现，使得企业在进行内外部数据融合时再次陷入各应用的重复计算。

因此，数据中台从建设初期开始，就应该制定实施指南，指导各角色团队，帮助其厘清在数据中台建设中的角色、权限、边界、分工。

在做好顶层设计的基础上，需要倡导“重场景、轻标准、快落地”。要充分理解市场的动态性，标准一定要轻量，不要试图去做一个放之四海皆准的企业级数据中台标准，越细致的数据标准实施起来就是枷锁，很难落地。有了顶层设计和高效的开发工具，数据中台的快落地就不会只是一句空话。

2.挖掘并解决业务的核心诉求

数据中台的建设目的不是为了建设中台而建设中台，其根本目的最终是为了服务业务需求，满足业务的核心诉求，所以数据中台的建设需求，要围绕业务价值产生，解决业务痛点。因而，所有的功能设计要 有对应的业务场景需求为根源，但是数据服务是要抽象、建模、复用的，所以数据中台在业务场景的基础上要高于业务场景，同时能主动去挖掘业务的核心诉求，并帮助业务实现差异化竞争优势。

如某银行在实践数据中台过程中，借助于数据中台，在小微新模式探索中实现了全流程数据驱动，并在助力网金数字化运营、促进数字化转型落地方面取得了成效。

3.平衡快速响应、创新、可复用之间的关系

业务场景是随着时代发展、要及时顺应市场变化不断创新和快速变化，为了满足这种快速变化，现有阶段的数据服务，无论是专题、报表或取数，基本是烟囱式数据生产模式或者是项目制建设方式，往往在模型和服务设计的可扩展性上、数据知识的沉淀上考虑甚少，疲于奔命地不断建各种数据接口或者临时取数以满足下游和业务用数，从而造成模型不能真正成为可重用的组件，反复地“造轮子”，而越是不能实现数据模型和服务的可重用，就越是在不停地在“造轮子”，陷入死循环。

在机器学习界流传这样一句话：“数据和特征决定了机器学习算法的上限，而模型和算法只是不断逼近这个上限而已”。而标签体系的构建，能帮助特征工程快速构建。标签体系的构建，又很大程度上依托于对指标体系的构建，即不是一拿到报表需求就填映射做数据开发，而是要进行属性和指标拆解。可见，做好指标拆解、指标体系的构建，不仅是数据知识的沉淀，更是为后续的机器学习打下坚实基础，缩短机器学习项目的建设周期。而基于指标体系也能快速构建灵活可复用的模型，统一的基础模型将相关业务领域的数据做了很好的汇聚，解决了数据互通的诉求，同时，数据模型在业务需求的“不断滋养”下，逐渐丰富为企业最为宝贵的模型资产，数据模型源于业务，服务于业务，形成创新生态的闭环。

4.中台各要素的共生共荣

业界对数据中台的团队角色一般给出如下建议：

中台开发团队：负责数据中台的功能层开发，包括平中台本身的架构，中台上的应用（客户服务、业务监控等）功能的开发，对应的绩效是功能的稳定性和客户的满意度。

数据服务开发团队：负责数据中台之上的数据服务的开发，包括数据处理链的开发，服务的开发等，对应的绩效是数据服务的稳定性、性能和客户的满意度等。

中台运营团队：将整个数据中台的服务和功能作为产品来运营，对应的绩效是用户满意度，用户存留等用户相关的指标。

上文中讲到某国有银行反思十几年数据仓库的经验教训，尝试新的做法是原有的数据仓库团队和直接面向业务的应用团队一起建设数据中台，并借助于大数据技术和云计算技术，让基础的共性加工与特色且共用的应用复杂计算加工共生共存。原有数仓团队成员以前对于业务需求的把握总是停留在较低层次，现在通过这种方式，数据人员能更深入地研究业务、数据和模型，端到端的去实践，中台人员若能逐步建立起对于业务的话语权，从仅仅是接受需求的角色，转变为能提出合理的建议，那么就能为业务带来新的增长点，而由此打造出数据中台，才是最大的价值创造，才能使得持续创新成为可能。因此，笔者认为，这是构建创新生态数据中台的一种有益尝试。

天阳科技数据团队基于对银行4.0（无处不在的银行）的思考以及行业实践的归纳总结，提出了科技与业务融合的敏捷化组织架构组织创新模式，该创新模式认为，基于数据中台，银行可以由无数个“微银行”组成，而“微银行”的建设方式，可以是基于数据中台的业务人员独立自助建设的“微银行”，也可以是由数据分析师独立建设的“微银行”，或者是业务人员和数据分析师共同组建的“微银行”。如果基于业务中台，以上方式只要再加上轻应用开发人员去作用于业务中台，就可以成为迅速构建“微银行”的新方式，会比以上模式多了一个轻应用开发周期。因此如何运营整个中台是数据中台建设成功的关键要素所在。运营团队是整个生态中台是否具备并持续保持生态的管理者、监督者、中坚力量。

结语

随着当前大数据背景下的商业银行正在从“规模化”向“差异化”“价值化”进行数字化转型变革，相信商业银行可有效借助于“创新生态数据中台”建设，为不断深化精细化管理、差异化产品创新和服务创新积极赋能，拥抱银行4.0的到来。