11
22
33
1
首页>协同观察>致远要闻
致远要闻 媒体聚焦 市场活动

数据中台——设计原则

发布时间:2020-06-11 来源: 40 次浏览

数据中台是整个数据分析系统的灵魂与核心:


  • 对下要对接每个业务系统以及外部数据;

  • 对上要为企业整体决策分析服务,还要为其他业务系统提供数据服务;

  • 对内要服务于企业内的每一个人;

  • 对外服务于上级单位甚至供应链上下游伙伴。


这就对数据中台提出了很高的要求,包括但不限于:


1

数据准情性与可靠性。

2

数据统一性:

无论是内部还是外部数据是统一的,在不同的时间查询某一特定时间的数据是一致的;

3

据安全性:

严格的权限管理,保证数据安全没有外泄风险;

4

数据可追溯:

一旦发生数据错误,能够快速定位错误发生来源,并且知道错误影响范围,包括影响哪些报表,影响哪些人员,哪些人员已经看到了错误数据并做出了决策;

5

好的解耦性:

对于大中型企业,企业的管理相对固定,一般半年到一年有一次变化,但是信息化系统及数据随时可能发生变化;对于中小型企业信息化系统及数据相对固定,但是管理模式及需求随时可能变化,这就要求数据的变化与管理的变化互相不干扰,这才能保证数据分析服务能时时为管理提供“贴身”服务;

6

平滑的可扩展性:

数据对企业越来越重要,但是企业内数据种类越累越多,数据量越来越大,这就要求数据中台一直处于扩充状态,每次扩充都要在原来基础上实现,而不会对原有架构与业务产生影响。

7

易维护性:

代企业对数据依赖性越来越高,已有很多企业报表与分析动辄在几千张,而一般传统企业往往在IT投入很有限,这就要求数据中台必须很容易被维护,比如1-2人维护几千人几千张报表的使用


因此,数据中台的设计必须遵循一定的原则,否则数据中台的作用无法体现出来,将把数据中台系统建设成为数据仓库系统或者报表系统。



1、扁平性原则

传统数据仓库的显著特点是面向主题的,比如财务主题、客户主题、商品主题,其优势在于同一主题内进行数据分析非常方便且查询效率非常高;


劣势在于不同主题之间数据分析非常不方便且查询效率很低,因此现实中为了跨主题使用数据,往往会使得一份数据在不同主题内多次存储,造成了存储资源的浪费与系统维护的复杂度,也使得不同主题内的数据可能无法保持同步。



举个例子:

比如企业想实现客户分析和商品分析,分析内容如下:


客户分析:时间、客户、地区、商品、要求运送方式、实际运送方式、订单单据数量、订货数量、订货金额、发货数量、开票金额、回款金额。


商品分析:时间、商品、订货数量、发货数量、商品成本、毛利。



用数据仓库实现:

表设计如下:


客户分析_Fact(时间、客户、地区、商品、要求运送方式、实际运送方式、订单单据数量、订货数量、订货金额、发货数量、开票金额、回款金额)


商品分析_Fact(时间、商品、订货数量、发货数量、商品成本、毛利)


可以明显看出,在两个Fact内,订货数量、发货数量是重复的。


用数据中台实现:

表设计如下:


订单业务表(时间、订单号、地区、客户、商品、要求运送方式、订货数量、订货金额)


发货业务表(时间、订单号、发货单号、客户、商品、实际运送方式、发货数量)


开票业务表(时间、订单号、发票号、客户、开票数量)


回款业务表(时间、订单号、发票号、客户、开票数量)


成本业务表(时间、商品、商品成本)


其中订单业务表、发货业务表是商品分析与客户分析公用内容,所有业务分析表是平行关系,最后模型层会引用这些业务表。



2、性原则

所谓“”,有三层含义:


一是数据抽取脚本的性,比如订单业务表,需要从原有销售系统中抽取数据,这是数据分析不可避免的,但是所有涉及到订单的抽取脚本只能有一份,这样当原有销售系统升级或者其他原因导致数据库变化,进而需要更改抽取脚本时,只需要修改一处即可;


二是数据存储的性,比如订单业务表,所有跟订单相关的数据都存储在该表内,在空间、查询效率、维护成本上做了很好的平衡(如果表内数据量太大,可以用分布式存储);


三是指标的性,比如订货数量,所有模型内应该只有一份订货数量,所有需要使用订货数量的报表都要引用该指标,如果确实需要有多个指标,比如预订货数量,一定在指标名称上明确区分,以避免使用者之间产生混淆与分歧。



3、数据历史与当前并存原则

数据中台与数据仓库很大的一点不同就是对历史数据的处理,