数据中台建设系列篇:什么样的企业适合建设数据中台

1 评论 3486 浏览 1 收藏 12 分钟

编辑导语:近年来,数据中台特别火热,数据中台有着它的巨大价值。但是并不是所有企业都适合建设数据中台,需要依照实际情况进行理性分析,按需选择。我们一起来看看什么样的企业才适合建设数据中台吧。

上篇文章(数据中台建设系列:什么是数据中台)我们聊清楚了什么是数据中台,也知道了数据中台的巨大价值,那是不是就可以开始建设数据中台了呢?

我想,在正式进入数据中台建设之前,我们来聊聊什么样的企业适合建设数据中台,以便大家能够按照企业实际情况,理性分析,按需选择,防止盲目跟风带来巨大损失。

一、建设数据中台

前企业常见数据痛点由于工作原因,参与了多个数据中台项目,在此过程中,我发现很多企业在建设数据中台前通常会存在一系列的痛点,总结起来,可以概括为以下5大类:

1. 指标口径不统一

两张报表里面名称相同的指标【销售额】,展示的结果却不一样,业务怀疑数据有问题,便找开发排查,排查结果显示,这两个指标,一个含税,一个不含税。业务人员面对这些指标的时候,如果不知道指标的业务口径,很难去使用这些数据。

2. 需求响应时间长

随着需求的不断增长,运营和分析师抱怨需求的交付时间太长,无法满足快速发展和变化的业务对数据的敏捷研发要求。

3. 取数效率低

随着数据的不断增长,面对海量的数据表,运营和分析师们准确找到数据、理解数据变得越来越困难,大量临时取数工作只能依赖数据研发来完成,使得数据研发无法专注于数仓模型的构建上,从而形成【数据不完善——研发忙于各种临时取数需求——数据不完善】的恶性循环。

4. 数据质量差

时常有数据结果计算错误,导致做出错误的业务决策的情况发生。数据bug频发,故障溯源和恢复常常消耗大量时间。

5. 数据成本大

随着业务的发展和时间的推移,企业数据成本呈线性增长,企业每年要为此花费大量的真金白银。

通常,这些问题会随着数据中台的成功上线被解决掉。那数据中台是如何解决这些痛点的呢,在回答这个问题之前,我们先看看以上这些痛点背后的原因是什么?

二、问题背后的原因是什么

1. 指标口径不一致

通常表现在3各方面:业务口径不一致、计算逻辑不一致、数据来源不一致。

业务口径不一致:业务口径不一致的指标,应该要有不同的标识去区分,比如上面提到的销售额这一指标,明明口径是不一致的,但却没有区分,容易让业务误解。

计算逻辑不一致:业务口径的描述往往是一段话,但对于一些计算逻辑比价复杂的指标,一段话通常是描述不清楚的,如果碰巧两个相同业务口径的指标是不同的数据研发实现的,极有可能会出现计算逻辑不一致的情况。

数据来源不一致:对于部分指标,有多个数据源可供选择,如果数据源正好有些细微差异不被发现时,即使加工逻辑一样,也有可能结果不一致。另外,实时数据和离线数据也会有一定差异。

因此,要实现一致性,就要确保对同一个指标,只有一个业务口径,只加工一次,且数据来源必须一致。

2. 需求响应速度慢

主要在于烟囱式的开发模式,使得数据复用性低,导致大量重复逻辑代码的研发,影响需求响应速度。

比如,两个指标都需要对同一份原始数据进行清洗,原则上来说,只用一个任务对原始数据做清洗,产出一张明细表,另一个指标开发时,便可直接引用已经清洗好的明细表,这样便可节省一个清洗逻辑的研发工作量。但现实往往是对同一份原始数据做了两次清。洗。

因此,要解决需求响应速度慢的问题,就要提升数据的复用性,确保相同数据只加工一次,实现数据的共享。

3. 取数效率低

主要表现在两个方面,一方面是找不到数据,另一方面是取不到数据。

要解决找不到数据的问题,就要构建企业数据资产目录,让数据使用者快速找到并理解数据。取不到数据的主要是非技术人员不会写SQL去提取数据,所以可以为其提供自助取数工具,使其简单快速的获取数据。

4. 数据质量低

背后的原因主要是数据问题很难被主动发现和快速修复,经常是使用数据的人反馈投诉时才知道有问题。

数据的加工链路一般比较长,有时超过几十个上百个节点,收到问题反馈时,研发需要逐个任务去排查,然后再重跑有问题的任务及其下游链路的每个任务,这一过程往往需要花费很长的时间,导致故障恢复效率低。

因此,要解决数据质量低的问题,就要实现在业务反馈问题之前主动发现问题,并能快速恢复。

数据成本问题主要是数据重复建设导致的存储和计算资源的浪费,因此,解决这一问题的关键是提升数据共享能力,避免数据重复建设,消除冗余数据。

三、数据中台是如何解决这些问题的

1. 构建全局一致的指标词典,实现指标体系化管理

按照数仓主题域的方式对所有指标统一命名、分类,明确指标口径、数据来源、计算逻辑,产出企业的指标词典,由专门团队来负责指标口径的管控;

设计上线方便业务人员查询的指标词典管理系统,所有的数据产品、数据报表都引用指标系统的口径,当鼠标Hover到某个指标上时,浮现该指标的指标口径定义。

2. 统一数仓建模,构建全局一直的公共层,提升数据复用性

制定统一的数仓建模规范,在模型设计阶段,强制相同聚合粒度的模型,度量不能重复,保证相同粒度的指标、度量只加工一次;建设数据地图,方便数据研发能快速查找并准确理解数据。

3. 提供企业数据地图和自助取数系统

数据中台构建了企业数据地图,数据使用者可通过数据地图快速了解企业当前有哪些数据,在哪张表里可以看到,关联了哪些指标和维度;

非技术人员可通过自主取数工具,选取指标,勾选指标的可分析维度,添加筛选条件,点击查询,就可以方便获取数据。

4. 配置数据质量稽核规则和数据预警

通过配置数据质量稽核规则和数据预警,对数据一致性、完整性、正确性和及时性进行监控,确保第一时间发现、恢复、通知数据问题。

5. 上线数据成本治理系统

数据治理系统可实现表维度、任务维度、应用维度的全面数据治理。比如一个30天内没有被访问的报表,我们认为其产出价值较低,这时我们可以结合这个报表的所有上游表和下游表产出任务,计算这张表的加工成本,有了价值和成本,便可计算出ROI,根据RO评估,实现低价值报表的及时发现和下线。

四、什么样的企业适合建设数据中台

数据中台的构建需要大量人力物力的投入,所以数据中台的建设一定要结合企业的现状,按需选择,不可盲目跟风。在我看来,企业在选择是否构建数据中台的时,可以从以下几个方面思考:

首先,看企业是否有一定的信息基础,是否实现了业务数据化的过程,有了一定的数据沉淀,数据中台,顾名思义,数据是基础,毕竟巧妇难为无米之炊;

其次,企业是否存在业务数据孤岛,是否有需要整合各个业务系统的数据,进行关联分析的需求,如果有,需要通过构建数据中台,打通数据孤岛,整合各业务系统数据,满足关联分析的需求。

比如某零售企业,在业务发展初期,商品、销售、供应链等都是独立的数据仓库,后期要构建智能补货系统,需要打通多个业务系统的数据,因此选择建设数据中台。

最后,在日常的数据使用过程中是否遇到指标口径不一致、需求响应速度慢、数据质量差、数据成本高等痛点。

如果满足前两个条件,且在数据应用中存在以上所述的一些痛点,那建议你可以考虑将数据中台项目提上日程了。

 

作者:微微;热爱技术的产品一枚,持续更新数据中台系列文章,“数据人创作者联盟”成员。

本文由@一个数据人的自留地 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 👍🏻

    回复