数据即使资产，业务中台大多承担了“数据仓库”的职责，沉淀了很多的业务数据，下面和大家讨论下应该落哪些数据，对应的注意事项，以及如何发挥数据的价值

一、数据模型统一

在没有中台的情况下，各业务系统独立建设，会存在数据不统一、不一致的问题。

例如 商城有自己的商品中心，点卡业务有自己的虚拟商品，2 套系统完全独立，字段命名和规则都不一样，对于统一的交易中心来说，同时支持商城商品和虚拟商品就很麻烦，因此需要商品中台来定义统一的商品模型。商城商品和虚拟商品都是同一个商品对象，拥有相同的 ID 生成规则，对于交易中心来说，模型就统一了。推广来说，所有同商城、点卡业务交互的系统用的都是同一个商品。

在此之上，中台建设过程中需要考虑两个概念：

1. 主数据

主数据（MD Master Data）指系统间共享数据（例如，客户、供应商、账户和组织部门相关数据）。中台定位之初就是夸部门、夸业务的，中台的数据自然也是可以共享的。是不是中台所有的数据都是主数据，也不尽然，主数据同时具有相对高价值、高共享、相对稳定的状态，例如记录业务活动、波动较大的交易数据等就不是主数据。

从以下几个指标来衡量是不是主数据：

基础性：主业务实体是基础的业务单元，它支持所有主要的业务行为和交易基础，一般不可再拆分。

共享性：主数据通常会被多个业务系统访问，作为共享数据存在。

业务价值：主数据描述了企业最核心的业务，是企业最有价值的资产。

周期性：主数据一般会在很长一段时间内被使用，具有较长的生命周期。

复杂性：主数据一般涉及多个业务系统，具有较高的复杂性。当业务实体的复杂性降低时，可以不再纳入主数据管理范畴。

流动性：主数据变化频率一般不高，小于交易数据的变化频率；但完全不变化的数据不应该判定为主数据。

多特征属性：主数据作为业务操作的主要对象，一般存在多个属性，用于区分不同的操作对象。

来源 https://zhuanlan.zhihu.com/p/86065433

2. oneData

OneData 即是阿里巴巴内部进行数据整合及管理的方法体系和工具，面对爆炸式增长的数据，如何建设高效的数据模型和体系，对这些数据进行有序和有结构地分类组织和存储，避免重复建设和数据不一致性，保证数据的规范性，一直是大数据系统建设不断追求的方向。

业务中台是数据的生产者，应从业务底层进行前瞻性设计，打破数据孤岛，实现数据通融，将多个 ID 映射为同一个主 ID，方面其他业务系统的数据流转。

二、数据沉淀

1. 多维度

要尽可能沉淀足够多维度的数据。后续业务方可能有基于某个维度的数据进行统计需求，此时再去整理需求开发，等一段时间积累数据后才能有业务价值，这个时间周期对业务来说有很大的延后性。因此尽可能在中台建设中，提前于业务把中台相关多维度的数据沉淀来了，成为有价值的数据资产。

例如 等于用户中台来说，除了用户的基本信息外，还可以从这些角度去沉淀数据：

设备信息

浏览器、手机型号、操作系统、运营商、分辨率、语言

地理信息

IP、省、市、区、经纬度

基本信息

登录记录、登录入口、失败次数

2. 实时在线

当前时代变化很快，T+1 延迟的数据甚至延迟几个小时的数据，对业务来说都是不够的快，T+1 延迟的数据甚至延迟几个小时的数据，对业务来说都是不够的，中台大多是业务的原数据，通过一定的技术手段可以做到实时在线，给业务提供最快的保障。

TODO 参考数字化转型的道与术

三、数据准确

数据的准确定对业务的影响非常大，中台是数据的生产者，如果数据源头出现问题，不管后续在数据仓库里如何清洗治理，都是很难解决问题的。异常的数据落入中台，后续的业务流程中出现数据异常导致的问题，增加了问题排查的难度。

同时中台接入多条业务，不同业务不同的字段，字段的格式和类型都不尽相同，不同业务的相同字段也会有不同的校验差别，因此接口层面只会做基本的校验。

可以从下面 3 种方式来提升数据的准确性：

1. 事前拦截

越早发现问题，解决的成本也就越低，最好的方式是在异常数据入库前就检查出来。

在业务接入期，梳理出字段对应的约束条件，约定好错误返回码，异常数据出现时中台服务提供方直接报错，业务系统也能正确处理异常。

• 对于中台关注的核心字段

建议在接口定义中实现强约束，因为这些字段是中台系统处理流程中需要使用到的。

• 对于其他扩展型的字段

中台没有使用这些字段，只是存储下来，或者传递给其他系统，实现方式可以考虑元数据管理，为不同的业务定义有哪些字段，具体字段的类型和约束，不需要开发即可接入业务，同时后续有变更的情况下也能实时生效。

2. 事中报警

有些中台系统没有元数据管理功能，或者业务对部分字段要求一定容错性，业务流程不能被打断，希望在错误数据出现时及时报警，然后排查原因，从上游数据产生的地方去解决。这部分需要是异常数据进行实时报警，同时支持实时变更监控规则。

实现方式如图所示，新建一个独立应用，监听业务系统的消息或者 binlog 生成的消息，动态执行脚本，脚本中是具体的校验逻辑，如果不满足规则，触发实时报警给对应的责任人，同时把报警记录保存下来。校验逻辑可以是简单的正则表达式，同时可以查询其他数据源(建议只读实例，减少对线上业务的影响)，协同进行数据对比。

image.png

3. 事后对账

有些数据的核对延迟较高，实时检查无法满足，例如 支付领域和支付机构或者银行间的对账大多是 t+1 的。

对于内部系统间的对账，可以考虑数据库级别的比对，例如 业务订单和支付流水的比对，可以简单通过不同数据库、不同表的数据记录和状态是否逻辑一致的比对。比较好的做法是把对账的功能沉淀为一个工具，做到灵活配置、实时生效。

四、赋能业务

中台沉淀了大量的数据，当今数字化的时代，数据是宝贵的资产，利用好数据的价值，为业务赋能提供三个思路：

1. 可视化报表

对这些数据，开发出对各个业务通用的报表，是对数据的基本使用，从业务方的角度来说，减少了他们的开发过程，显现了复用的目的。如果不满足业务需求，业务可以参考中台报表的功能，实现他们自己的报表，这也能减少他们从零开发的成本。

例如 用户中台来说实现类似的报表功能

image.png

2. 预测

业务数据时时刻刻都在增长，结合这些数据可以绘制出数据的走势和增长情况，如果数据突然断崖式下跌，那么可能是系统或者业务上有一些问题，需要及时干预。如下图中，2020.10.17 数据出现异常

image.png

基于业务中台生产的数据，利用 AI 和大数据，能发掘对很多对业务有用的价值点。

3. 跨业务分析

结合不用业务的数据，是否能碰撞什么一些火花呢？

例如 同一个门店入驻到不同的业务里，名称和地址都接近，线下的工作人员可能坐在重复拜访的情况，同时对于门店也会有困扰；因此通过相似度匹配，识别出不同业务中的店铺在线下是否同一个门店，有效解决业务问题。

另一个角度，A 业务的数据是否可以提供给 B 业务使用，在 A 业务中没有成交的用户可能会对 B 业务感兴趣，这样最大化发挥了这些业务数据的价值。