数据中台前世今生（三）：互联网下半场 + 数字化转型 = 数据中台

时间来到 2018 年，对于绝大多数互联网企业来说，这一年绝对是煎熬的一年。

2 年前，美团创始人王兴提出“互联网行业已经进入下半场”，似乎从 2016 年开始，下半场已经变成了“终章”。

王兴发表“互联网下半场”演讲

01

互联网下半场和数字化转型

一方面，线上流量获取越发困难，流量枯竭导致业绩增长乏力，利润飞速下滑；另一方面政策加强对互联网产业融资的管控，部分企业债台高筑，互联网经典的“烧钱”模式难以为继。

曾经的烧钱大战战场

这背后粗放型的企业管理理念和经营模式（例如，我们在采购商品的时候，凭借经验去做出采购哪个商品的决策），已经没有办法继续支撑互联网业务的高速增长。

越来越多的企业开始关注精细化运营，尤其是数据的精细化运营变成企业增长的新动力，深入企业各个环节。

某电商精细化运营产品功能

由此，互联网巨头掀起的数字化转型大幕逐渐拉开。

数据需求的爆发式增长，促进了数据产品的蓬勃发展。在每个业务过程中，都有大量的数据产品颠覆原有线性运营模式，辅助运营完成日常工作。

全渠道企业资源管理

在电商的场景中，用户运营、商品运营、门店运营等，大量的运营基于这些产品完成经营决策。例如，在供应链业务中，会根据商品库存、历史销售数据以及商品舆情，智能计算商品的最佳采购周期，推送给运营审核，然后完成采购下单行为。

02

数字化转型出现的问题

大量数据产品的出现，在不断提高企业运营效率的同时，也暴露出很多尖锐的问题，主要有以下几点。

第一，指标口径不一致。

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

第二，取数效率低，需求响应时间长。

面对数十万张表，运营和分析师及时地找数据、准确地理解数据非常困难。

想找到一个目标数据，确认这个数据和自己的需求匹配，他们可能往往需要花费一天以上的时间。对新人来说，这个时间会更长。

除了查找数据效率低，从系统中取数分析对于非技术出身的分析师和运营来说也是一个难题，这就导致大部分的取数工作还是依赖数据开发来完成。

知乎上一个吐槽数据分析师被当作取数机的问题达到 24 万浏览量

数据开发大部分的时间都被临时取数的需求占据，根本无法专注在数仓模型、数据集市的构建或运维。

第三，数据质量差。

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

数据质量是个系统性的大问题，影响很大

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

为什么数据中台可以解决这些问题呢？要想回答，首先我们需要了解上述问题背后的原因。

03

数字化转型出现问题的原因

干货分析：篇幅有限，会在配图提前给出对应解决功能，下一篇再具体讲解。

• 首先，针对指标口径不一致问题，可能原因包括三点：业务口径不一致、计算逻辑不一致、数据来源不一致。

如果是业务口径不一致，那就要明确两个指标不能使用相同的标识，像之前的例子，含税和不含税的两个指标，不能同时叫销售额。

业务口径的描述往往是一段对指标计算的描述。但是对于很多指标，涉及的计算逻辑非常复杂，仅仅一段话是描述不清楚的。

此时，两个相同业务口径的指标，恰巧又分别是由两个数据开发去实现的，这样就有可能造成计算逻辑不一致。

例如，有一个指标叫做排关单（排关单：把关单的排除；关单：关闭订单）的当天交易额这个指标，A 认为关单的定义是未发货前关闭的订单，B 认为关单是当天关闭的订单，大家对业务口径理解不一致，这样实现的计算结果也就会不一致。

最后，还可能是两个指标的数据来源不一样，比如一个来自实时数据，一个是来自离线的数据，即使加工逻辑一样，最终结果也可能不相同。

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

• 其次，数据需求响应慢在于烟囱式的开发模式，导致了大量重复逻辑代码的研发。

例如，同一份原始数据，两个任务都对原始数据清洗。如果只有一个任务清洗，产出一张明细表，另外一个任务直接引用这张表，就可以节省一个研发的清洗逻辑的开发。

数据市场：避免重复开发数据服务

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

• 取数效率低，一方面原因是找不到数据，另一方面原因可能是取不到数据。

要解决找不到数据的问题，就必须要构建一个全局的企业数据资产目录，实现数据地图的功能，快速找到数据。而非技术人员并不适合用写 SQL 的方式来取数据，所以为他们提供可视化的查询平台，通过勾选一些参数，才更容易使用。

数据目录加类 Google 式查询解决取数难题

• 最后，数据质量差的背后其实是数据问题很难被发现。

企业里一般等到使用数据的人反馈投诉，才知道数据有问题，而数据的加工链路一般非常长，一个指标上游的所有链路加起来有 100 多个节点，这是很正常的事情。

数据探查+质量报告+API 行为分析让数据问题无处遁形

等到运营投诉再知道数据有问题就太迟了，因为要逐个去排查到底哪个任务有问题，然后再重跑这个任务以及所有下游链路上的每个任务，这样往往需要花费半天到一天的时间，最终导致故障恢复的效率很低，时间很长。

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

篇幅有限，“数据中台的诞生——如何解决这些问题”在下一篇文章告诉大家，想要提前获得关于数据中台的全套学习资料，可以点赞关注然后私信麦聪。

猜你想看：

数据中台前世今生二：从数据湖到大数据平台看数据应用需求发展

数据中台的前世今生（一）：数据仓库——数据应用需求的涌现

数据中台：始于阿里，兴于DaaS