什么企业适合建设数据中台？-编程知识

从历史脉络中，看到数据中台凸显价值，数据中台是大数据下一站。所有企业都适合建设数据中台吗？什么样应该建数据中台？

2018年我们在建数据中台前面临的窘境，通过了解我们建数据中台的背景，你也可以对照着看一下自己所在的企业是否存在这样的问题，从而针对“是否需要构建一个数据中台”这个问题形成自己看法。

1 前言

2018年线上流量枯竭，业绩增长乏力，企业成本高筑，利润飞速下滑。原先粗放的企业管理模式和经营模式（如采购商品时，凭经验做出采购哪个商品的决策）已没法继续支撑企业高速增长，越来越多企业开始数字化转型，强调数据是企业增长新动力，它应深入企业经营各环。

数据需求爆发式增长，促进数据产品发展，在每个业务过程中，都有大量数据产品辅助运营完成日常工作。如电商中，用户运营、商品运营、市场运营……每天有大量运营基于这些产品完成经营决策。

比如在供应链决策协同系统中，我们有一个智能补货的功能，会根据商品的库存、历史销售数据以及商品的舆情，智能计算商品的最佳采购计划，推送给运营审核，然后完成采购下单。

2 大量数据产品的问题

2.1 指标口径不一

两个数据产品一个包含税，一个不包含税，它们相同的一个指标名称都是销售额，结果却不一样。运营面对这些指标的时候，不知道指标的业务口径，很难使用这些数据。

根因

可能：业务口径、计算逻辑、数据来源不一致。

业务口径不一致，要明确区分两个指标不能使用相同的标识，含税、不含税两个指标，不能同时叫销售额。

业务口径描述往往是一段话，但对很多指标，涉及计算逻辑复杂，一段话描述不清，此时，两个相同业务口径的指标，恰分别由两个数据开发去实现，就可能造成计算逻辑不一。如有个指标叫排关单（排关单：把关单的排除；关单：关闭订单）的当天交易额这个指标：

A认为关单定义是未发货前关闭的订单
B认为关单是当天关闭的订单

大家对业务口径理解不一致，实现的计算结果也不一致。

最后，可能两个指标的数据来源不一：

一个来自实时数据
一个来自离线的数据，即使加工逻辑一样，最终结果也可能不相同。

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

2.2 数据重复建设，需求响应时间长

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

根因

在于烟囱式开发导致大量重复逻辑代码研发，一份原始数据，两个任务都对原始数据进行清洗。如只有：

一个任务清洗，产出一张明细表
另外一个任务直接引用这张表

就能节省一个研发的清洗逻辑的开发。

所以，要解决数据需求响应慢，就必须解决数据复用的问题，要确保相同数据只加工一次，实现数据的共享。

2.3 取数效率低

面对数十万张表，我的运营和分析师找数据、准确地理解数据非常困难，想找到一个想要的数据，确认这个数据和自己的需求匹配，他们往往需要花费三天以上的时间，对新人来说，这个时间会更长。

除了查找数据效率低，从系统中取数分析对于非技术出身的分析师和运营来说也是一个难题，这就导致大部分的取数工作还是依赖数据开发来完成。数据开发大部分的时间都被临时取数的需求占据，根本无法专注在数仓模型的构建和集市层数据的建设，最终形成了一个恶性循环，一方面是数据不完善，另一方面是数据开发忙于各种临时取数需求。

根因

找不到数据

须构建全局的企业数据资产目录，实现数据地图，快速找到数据。
取不到数据

而非技术人员不适合用写SQL取数据，所以要解决取不到数据的问题，就要为他们提供可视化的查询平台，通过勾选一些参数，才更容易使用。

2.4 数据质量差

数据经常因为BUG导致计算结果错误，最终导致错误的商业决策。

大促期间，某类商品搜索转化率增长，于是我们给这个商品分配更大流量，可转化率增长的原因是数据计算错误，所以这部分流量也就浪费了，如果分配给其他的商品的话，可以多赚200W的营收。

根因

数据问题难被发现。我们常等使用数据的人投诉，才知数据异常。而数据加工链路长，在我们的业务中，一个指标上游的所有链路加起来有100多个节点都很正常。等到运营投诉再知道数据有问题，太迟！因为要逐个排查到底哪个任务有问题，再重跑这个任务及所有下游链路上的每个任务，要半天到一天，最终导致故障恢复效率低，时间长。

所以，要解决数据质量差，就要及时发现然后快速恢复数据问题。

2.5 数据成本线性增长

数据成本随着需求的增长而线性增长，2017年的时候，我们一个业务的大数据资源在4000Core，但是2018就已经到达9000Core水平，如果折算成钱的话，已经多了500多万的机器成本。

根因

与需求响应慢背后的数据重复建设有关，因为重复开发任务，上线肯定花双倍资源。如节省一个任务资源消耗，满足两个数据需求，就可控制不必要资源消耗。所以，成本问题背后也是数据重复建设问题。

数据中台是企业构建的标准的、安全的、统一的、共享的数据组织，通过数据服务化的方式支撑前端数据应用。

数据中台消除冗余数据，构建企业级数据资产，提高数据共享能力，所以很快，我们开启数据中台建设。

3 数据中台如何解决问题

指标是数据加工结果，要确保数据需求高质量交付，首要管好指标：

原先指标的管理分散，没有全局统一的管理，数据中台中，须有一个团队统一负责指标口径管控
要实现指标体系化的管理，提高指标管理的效率。在指标系统中，我们会明确每个指标的业务口径，数据来源和计算逻辑，同时按类似数仓主题域的方式进行管理
最后，要确保所有的数据产品、报表都引用指标系统的口径定义。当运营把鼠标Hover到某个指标上时，就可以浮现出该指标的口径定义。

通过对全局指标的梳理，我们实现了100%数据产品的指标口径统一，消除了数据产品中，指标口径二义性问题，同时还提供方便分析师、运营查询的指标管理系统。

数据中台咋实现所有数据只加工一次？对数仓数据，要求相同粒度的度量或指标只加工一次，构建全局一致的公共维表。

实现上述目标，需两个工具产品：

数仓设计中心，在模型设计阶段，强制相同聚合粒度的模型，度量不能重复
数据地图，方便数据开发能快速理解一张表的准确含义

这就解决数据重复加工导致研发效率瓶颈的问题，把需求的平均交付时间从一周减到2～3天，大幅提高数据产能，得到分析师和运营的认可。

**数据中台通过服务化方式，提高数据应用接入和管理效率。**原先数仓提供给应用的访问方式是直接提供表，应用开发自己把数据导出到一个查询引擎，然后访问查询引擎。数据中台中，数仓的数据是通过API接口提供给数据应用，数据应用不关心底层不同查询引擎访问方式的差异。

**对非技术人员，数据中台提供可视化取数平台，**你只需选取指标、通过获取指标系统中每个指标的可分析维度，然后勾选，添加筛选过滤条件，点击查询，就能获取数据。

同时，数据中台构建企业数据地图，方便检索有哪些数据，它们在哪些表，又关联哪些指标和维度。通过自助取数平台和数据地图，非技术人员开始自助完成取数，相比通过提需求给技术人员，取数效率提高300%。

EasyFetch 网易自助取数界面：

**数据中台由于数据只能加工一次，强调数据复用性，对数据质量提出更高要求。**而我们实现全链路的数据质量稽核监控，对一个指标的产出上游链路中涉及的每个表，都实现了数据一致性、完整性、正确性和及时性的监控，确保第一时间发现、恢复、通知数据问题。

原先，当技术人员问我们“今天数据有没问题？” ，我们难答，现在可自信回答，数据对不对，哪些数据不对，啥时能恢复。这能力对最终达成99.8% 数据SLA很重要。

成本问题

构建数据中台时，研发了一个数据成本治理系统，从应用维度、表维度、任务的维度、文件的维度进行全面治理。

从应用维度，如一个报表30天内没访问，这报表产出价值就低，然后结合这报表产出的所有上游表及上游表的产出任务，可计算加工这张表的成本，有价值和成本，就能计算ROI，根据ROI可实现将低价值报表下线的功能。通过综合治理，最终在一个业务中节省超20%成本，约900W。

通过数据中台，最终成功解决面临的问题，大幅提高数据研发效率、质量，降低数据成本。

4 啥企业适合数据中台？

数据中台构建需大投入：

数据中台建设离不开系统支撑，研发系统要投入大量人力，而这些系统是否能够匹配中台建设的需求，还需要持续打磨
面对大量数据需求，要花费额外人力做数据模型重构

所以数据中台建设，要结合企业现状，按需选择。选择数据中台时，应考虑：

企业是否有大量的数据应用场景：数据中台本身不能直接产生业务价值，数据中台本质是支撑快速孵化数据应用。所以当你的企业有较多数据应用场景时（3个以上就可考虑），像电商有各种各样数据应用场景
经过快速的信息化建设，企业存在较多业务数据的孤岛，需整合各业务系统的数据，进行关联分析。此时，需构建数据中台。如电商初期，仓储、供应链、市场运营都是独立数据仓库，当时数据分析时，往往跨很多数据系统，为消除这些数据孤岛
当团队面临效率、质量和成本苦恼，面对大量开发，却不知如何提高效能，数据经常出问题而无策，老板还要求你控制数据成本
当企业经营困难，需通过数据实现精益运营，提高企业运营效率。同时结合可视化BI数据产品，实现数据从应用到中台的完整构建，在我的接触中，这种类型往往出现在传统企业中。
数据中台投入大，收益偏长线，更适合业务稳定大公司，不适合初创型小公司