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

数据中台建设系列篇：什么样的企业适合建设数据中台 / 上篇文章（ 数据中台建设系列 篇：什么是数据中台）我们聊清楚了什么是数据中台，也知道了数据中台的巨大价值，那是不是就可以开始建设数据中台了呢？ 我想，在正式进入数据中台建设之前，我们来聊聊什么样的企业适合建设数据中台，以便大家能够按照企业实际情况，理性分析，按需选择，防止盲目跟风带来巨大损失。 一、建设数据中台 前企业常见数据痛点由于工作原因，参与了多个数据中台项目，在此过程中，我发现很多企业在建设数据中台前通常会存在一系列的痛点，总结起来，可以概括为以下5大类： 1. 指标口径不统一 两张报表里面名称相同的指标【销售额】，展示的结果却不一样，业务怀疑数据有问题，便找开发排查，排查结果显示，这两个指标，一个含税，一个不含税。业务人员面对这些指标的时候，如果不知道指标的业务口径，很难去使用这些数据。 2. 需求响应时间长 随着需求的不断增长，运营和分析师抱怨需求的交付时间太长，无法满足快速发展和变化的业务对数据的敏捷研发要求。 3. 取数效率低 随着数据的不断增长，面对海量的数据表，运营和分析师们准确找到数据、理解数据变得越来越困难，大量临时取数工作只能依赖数据研发来完成，使得数据研发无法专注于数仓模型的构建上，从而形成【数据不完善——研发忙于各种临时取数需求——数据不完善】的恶性循环。 4. 数据质量差 时常有数据结果计算错误，导致做出错误的业务决策的情况发生。数据bug频发，故障溯源和恢复常常消耗大量时间。 5. 数据成本大 随着业务的发展和时间的推移，企业数据成本呈线性增长，企业每年要为此花费大量的真金白银。 通常，这些问题会随着数据中台的成功上线被解决掉。那数据中台是如何解决这些痛点的呢，在回答这个问题之前，我们先看看以上这些痛点背后的原因是什么？ 二、问题背后的原因是什么 1. 指标口径不一致 通常表现在3各方面：业务口径不一致、计算逻辑不一致、数据来源不一致。 业务口径不一致：业务口径不一致的指标，应该要有不同的标识去区分，比如上面提到的销售额这一指标，明明口径是不一致的，但却没有区分，容易让业务误解。 计算逻辑不一致：业务口径的描述往往是一段话，但对于一些计算逻辑比价复杂的指标，一段话通常是描述不清楚的，如果碰巧两个相同业务口径的指标是不同的数据研发实现的，极有可能会出现计算逻辑不一致的情况。 数据来源不一致：对于部分指标，有多个数据源可供选择，如果数据源正好有些细微差异不被发现时，即使加工逻辑一样，也有可能结果不一致。另外，实时数据和离线数据也会有一定差异。 因此，要实现一致性，就要确保对同一个指标，只有一个业务口径，只加工一次，且数据来源必须一致。 2. 需求响应速度慢 主要在于烟囱式的开发模式，使得数据复用性低，导致大量重复逻辑代码的研发，影响需求响应速度。 比如，两个指标都需要对同一份原始数据进行清洗，原则上来说，只用一个任务对原始数据做清洗，产出一张明细表，另一个指标开发时，便可直接引用已经清洗好的明细表，这样便可节省一个清洗逻辑的研发工作量。但现实往往是对同一份原始数据做了两次清。洗。 因此，要解决需求响应速度慢的问题，就要提升数据的复用性，确保相同数据只加工一次，实现数据的共享。 3. 取数效率低 主要表现在两个方面，一方面是找不到数据，另一方面是取不到数据。 要解决找不到数据的问题，就要构建企业数据资产目录，让数据使用者快速找到并理解数据。取不到数据的主要是非技术人员不会写SQL去提取数据，所以可以为其提供自助取数工具，使其简单快速的获取数据。 4. 数据质量低 背后的原因主要是数据问题很难被主动发现和快速修复，经常是使用数据的人反馈投诉时才知道有问题。 数据的加工链路一般比较长，有时超过几十个上百个节点，收到问题反馈时，研发需要逐个任务去排查，然后再重跑有问题的任务及其下游链路的每个任务，这一过程往往需要花费很长的时间，导致故障恢复效率低。 因此，要解决数据质量低的问题，就要实现在业务反馈问题之前主动发现问题，并能快速恢复。 数据成本问题主要是数据重复建设导致的存储和计算资源的浪费，因此，解决这一问题的关键是提升数据共享能力，避免数据重复建设，消除冗余数据。 三、数据中台是如何解决这些问题的 1. 构建全局一致的指标词典，实现指标体系化管理 按照数仓主题域的方式对所有指标统一命名、分类，明确指标口径、数据来源、计算逻辑，产出企业的指标词典，由专门团队来负责指标口径的管控； 设计上线方便业务人员查询的指标词典管理系统，所有的数据产品、数据报表都引用指标系统的口径，当鼠标Hover到某个指标上时，浮现该指标的指标口径定义。 2. 统一数仓建模，构建全局一直的公共层，提升数据复用性 制定统一的数仓建模规范，在模型设计阶段，强制相同聚合粒度的模