数据中台=数字化+业务系统化+数据治理+科研团队

(懒得编辑，有缘人随意看，有意见请提)

数据中台是大工程

很多人问我啥是数据中台，怎么做？我想阿里爸爸的大佬也不是很清楚。我只能做个猜想。

“数据中台”的概念提自马财主，云徒科技帮忙搞出理论篇，看过他们的书，繁琐又复杂，不过干货还是有的，至少指导思想在。

根据个人经验做出了以下猜想，尽量(企图)简单化这个理论，用系统角度可以更好落地

数据中台=数字化+业务系统化+数据治理+科研团队

数据中台的核心，

1，最大化减少复用。科研复用，接口复用，业务流程复用，逻辑复用，代码复用(可能还很多复用)

2，最大化将共用(基础业务)数据集中到一个系统。

回头先讲下公式内的内容

数字化，既然是数据中台，肯定缺少不了数字化，业务数据数字化，线下数据数字化，以及共有导入平台(难免有没法做成系统输入的数据)，自己数据归集。没数字化怎么数据中台嘞？基本的概念。

系统体现是: 全业务系统数字化，要求高可用，可实时抽取数据。以及一个导入系统。

同时存在一个类似数据湖，数据仓库概念的事物归集数据，应用实时非实时技术，还有一个可以应对多数据接口的层级，以及高可用不断数据服务器集群。

业务系统化(简称业务中台)，组建业务统一逻辑团队或组织。针对共同kpi，共同基础数据进行规整。比如零售，用什么数据作为零售概念？订单的？开票的？发票过账？或者用采购单替代零售概念？

比如生产数据，什么算下线？哪个环节？什么环节？

系统体现:

一个类似公布系统，字典系统，公布各个kpi计算方式，签字人，历史文档。计算公式的演变原因。

同时还有一个监控kpi逻辑是否有变化的检查平台，是否符合预期。可以考虑从字段层级监控。

数据治理(标准中台)，无规矩不成方圆，中台需要标准化。治理核心就是标准化，从技术层面。严格控制代码方式，建表方式。数据字典，如什么表什么字段，代表什么含义，精细到备注必须加内容。控制发布流程。审核缺失字段。转化不规则的业务信息为规则统一，如性别。ps:此处抛开元数据，因为元数据这东西都是由各自系统的log管理，我有时候不大明白数据治理的概念为何加入元数据管理？闲的？

系统表现形式:

一个数据清洗的系统，清洗规范统一，可以可视化规则。此内容可能需要借助业务中台进行规则管理。

一个规则审核系统，在代码发布环节监控如java 大概怎么规范，建表的语句，索引之类等

科研团队(研发中台)

一个技术的研究团队(可能需要再加一个业务规则的研究团队，但职业容易跟业务中台冲突，主偏向世面流行的业务和敏捷的业务逻辑流程规定定制化)

技术研究内容有，最新技术，接口可复用代码，逻辑代码可复用。

系统表现: 一个系统进行标准的输出，各个开发团队，需要建个表，或接口代码，点一下某某按钮，代码就“啪”，出来一个标准的模板。提供给中台下游使用。

同时只需要研究架构，开源部署之类的。开发提供环境(不论生产还是测试)给开发测试组使用。

然后加起来就，减少复用不管业务还是技术。

也把数据归集到一个系统。

补充下，各自下游系统可以将数据传到中台，中台清洗又反馈给下游系统。

补充下落地难度和落地方法论:

难度1，各系统，各组织不配合。

方法1，没办法。硬刚。这种项目自上而下的。中书省需要皇帝钦点。

难度2，开发成本浩大，布局范围大。

方法2，开发成本就是很大，非常大，小公司一般搞不起。或者精简化整个项目，麻雀虽小，五脏俱全！！建立系统可以一步一步来，从数据湖建起，再做数据治理。后研发中台，后业务中台。同时同步数字化，哪个系统或业务变动最小，哪个系统搞。

难度3，团队内业务沉淀不够。

方法3，不同部门人员双职，或招有业务的人。这里难点在业务，不在技术。业务沟通，不在技术沟通。虽说这种系统有强制力，但是强扭的瓜不甜，何不如大家开开心心，毕竟业务还是他们在做。不要搞得别人觉得莫名其妙抢了他们业务一样。

以上为个人猜想，将内容简单化。从业务角度呢，有空再写一个。