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

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

上篇文章（数据中台建设系列篇：什么是数据中台）我们聊清楚了什么是数据中台，也知道了数据中台的巨大价值，那是不是就可以开始建设数据中台了呢？

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

一、建设数据中台

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

1. 指标口径不统一

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

2. 需求响应时间长

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

3. 取数效率低

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

4. 数据质量差

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

5. 数据成本大

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

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

二、问题背后的原因是什么 1. 指标口径不一致

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

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

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

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

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

2. 需求响应速度慢

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

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

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

3. 取数效率低

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

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

4. 数据质量低

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

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

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

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

三、数据中台是如何解决这些问题的 1. 构建全局一致的指标词典，实现指标体系化管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

题图来自Unsplash，基于CC0协议