到底什么样的企业应该建设数据中台？

大数据真有意思 2020-07-31

193

点击关注上方“知了小巷”，

设为“置顶或星标”，第一时间送达干货。

关于《数据中台到底是不是大数据的下一站？》中数据仓库的定义：

数据仓库是面向主题的、集成的、反应时间变化的、相对稳定的数据集合，用于支持管理决策。AWS比较接地气的定义：Big data is when your data sets become so large and diverse that you have to start innovating around to collect, store, process and analyze data.

数据仓库两本书，公众号后台回复odsdwdm即可获取

关于大数据开篇之作的三篇论文，公众号后台回复zero即可获取

数据中台潜台词-数据==>价值-低成本而高效地通过数据应用实现数据商业化落地变现。

OneData和OneService

众所周知，数据中台自阿里提出以来，受到了业界前所未有的关注，足见其价值之大，2019年更被称为“中台元年”，那是不是所有企业都适合建设数据中台呢？或者，到底什么样的企业应该建数据中台？什么样的企业希望通过中台获得未来？

#00 建设中台前，面临哪些挑战，痛点在哪儿

对于绝⼤多数互联⽹企业来说，2018年绝对是煎熬的⼀年，因为⾯临线上流量枯竭，业绩增⻓乏⼒，企业成本⾼筑，利润⻜速下滑的⻛险。原先粗放的企业管理模式和经营模式（⽐如我们在采购商品的时候，凭借经验去做出采购哪个商品的决策）已经没办法继续⽀撑企业的⾼速增⻓，越来越多的企业开始提数字化转型，强调数据是企业增⻓的新动⼒，它应该深⼊企业经营的各个环节。数据需求的爆发式增⻓，促进了数据产品的蓬勃发展，在每个业务过程中，都有⼤量的数据产品辅助运营完成⽇常⼯作。例如，在电商的场景中，⽤⼾运营、商品运营、市场运营...每个场景下，都有很多的数据产品，每天有⼤量的运营基于这些产品完成经营决策。⽐如在供应链决策协同系统中，我们有⼀个智能补货的功能，会根据商品的库存、历史销售数据以及商品的舆情，智能计算商品的最佳采购计划，推送给运营审核，然后完成采购下单。

大量数据产品（数据应用）的出现，在不断提高企业运营效率的同时，也暴露出很多尖锐的问题，下面是普遍存在的5个痛点。

0. 指标⼝径不⼀致

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

1. 数据重复建设，需求响应时间⻓

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

2. 取数效率低

⾯对数⼗万张表，我们的运营和分析师找数据、准确地理解数据⾮常困难，想找到⼀个想要的数据，确认这个数据和⾃⼰的需求匹配，他们往往需要花费三天以上的时间，对新⼈来说，这个时间会更⻓。除了查找数据效率低，从系统中取数分析对于⾮技术出⾝的分析师和运营来说也是⼀个难题，这就导致⼤部分的取数⼯作还是依赖数据开发来完成。数据开发⼤部分的时间都被临时取数的需求占据，根本⽆法专注在数仓模型的构建和集市层数据的建设，最终形成了⼀个恶性循环，⼀⽅⾯是数据不完善，另⼀⽅⾯是数据开发忙于各种临时取数需求。

3. 数据质量差

数据经常因为BUG导致计算结果错误，最终导致错误的商业决策。比如，在⼤促期间，某类商品搜索转化率增⻓了，于是我们给这个商品分配了更⼤的流量，可转化率增⻓的原因是数据计算错误，所以这部分流量也就浪费了，如果分配给其他的商品的话，可以多赚200W的营收。

4. 数据成本线性增⻓

数据成本随着需求的增⻓⽽线性增⻓，2017年，⼀个业务的⼤数据资源在4000Core，但是2018就已经到达9000Core⽔平，如果折算成钱的话，已经多了500多万的机器成本。

#01 为什么数据中台可以解决上面的这些问题

追本溯源，看看上述问题背后的原因。

##00 指标⼝径不⼀致

可能原因包括三种：业务口径不一致、计算逻辑不一致、数据来源不一致。

如果是业务⼝径不⼀致，那就要明确区分两个指标不能使⽤相同的标识或指标名称，像上⾯的例⼦，含税和不含税的两个指标，不能同时叫销售额。可以扩展为含税销售额和一般销售额。业务⼝径的描述往往是⼀段话，但是对于很多指标，涉及的计算逻辑⾮常复杂，仅仅⼀段话是描述不清楚的，此时，两个相同业务⼝径的指标，恰巧⼜分别是由两个数据开发去实现的，这样就有可能造成计算逻辑不⼀致。⽐如，有⼀个指标叫做排关单（排关单：把关单的排除；关单：关闭订单）的当天交易额这个指标，A认为关单的定义是未发货前关闭的订单，B认为关单是当天关闭的订单，⼤家对业务⼝径理解不⼀致，这样实现的计算结果也就会不⼀致。最后，还可能是两个指标的数据来源不⼀样，⽐如⼀个来⾃实时数据，另⼀个是来⾃离线数据，即使加⼯逻辑⼀样，最终结果也可能不相同。

综合看来，要实现指标数据一致，就必须确保对同一个指标，只有一个业务口径，只加工一次，数据来源必须相同，否则就是另外一个新的指标。

##01 数据需求响应慢

烟囱式的开发模式，导致了⼤量重复逻辑代码的研发，⽐如同⼀份原始数据，两个任务都对原始数据进⾏清洗。如果只有⼀个任务清洗，产出⼀张明细表，另外⼀个任务直接引⽤这张表，就可以节省⼀个研发的清洗逻辑的开发。

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

##02 取数效率低

⼀⽅⾯原因是找不到数据，另⼀⽅⾯原因可能是取不到数据。要解决找不到数据的问题，就必须要构建⼀个全局的企业数据资产⽬录，实现数据地图的功能，快速找到数据。⽽“⾮技术⼈员”并不适合⽤写SQL的⽅式来取数据。

所以要解决取不到数据的问题，就要为他们提供可视化的查询平台，通过勾选⼀些参数，才更容易使⽤。

##03 数据质量差

其实是数据问题很难被发现。我们经常是等到使⽤数据的⼈反馈投诉，才知道数据有问题。⽽数据的加⼯链路⼀般⾮常⻓，在我们的业务中，⼀个指标上游的所有链路加起来有100多个节点，这是很正常的事情。等到运营投诉再知道数据有问题就太迟了，因为要逐个去排查到底哪个任务有问题，然后再重跑这个任务以及所有下游链路上的每个任务，这样往往需要花费半天到⼀天的时间，最终导致故障恢复的效率很低，时间很⻓。

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

##04 数据成本

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

正当我们为这些问题苦恼的时候，数据中台的理念给了我们全新的启迪，那么数据中台到底是怎么⼀回事⼉呢？

数据中台是企业构建的标准的、完全的、统一的、共享的数据组织，通过数据服务化的方式支撑前端数据应用。数据中台消除了冗余数据，构建了企业级数据资产，提⾼了数据的共享能⼒。

#02 数据中台是如何解决这些问题的？

指标是数据加工的结果，要确保数据需求能够获得⾼质量的交付。

### ⾸先是要管理好指标

原先指标的管理⾮常分散，没有全局统⼀的管理，在数据中台中，必须要有⼀个团队统⼀负责指标⼝径的管控。

### 其次，要实现指标体系化的管理，提⾼指标管理的效率

在指标系统中，我们会明确每个指标的业务⼝径，数据来源和计算逻辑，同时会按照类似数仓主题域的⽅式进⾏管理。

### 最后，要确保所有的数据产品、报表都引⽤指标系统的⼝径定义

当运营把⿏标Hover到某个指标上时，就可以浮现出该指标的⼝径定义。通过对全局指标的梳理，实现100%的数据产品的指标⼝径统⼀，消除数据产品中指标⼝径⼆义性的问题，同时还提供了⽅便分析师、运营查询的指标管理系统。

那么，数据中台是怎么实现所有数据只加工一次的呢？

简单来说，就是对于数仓数据，我们要求相同粒度的度量或者指标只加工一次，构建全局一致的公共维度。

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

⼀个是数仓设计中⼼，在模型设计阶段，强制相同聚合粒度的模型，度量不能重复。

另外⼀个是数据地图，⽅便数据开发能够快速地理解⼀张表的准确含义。

这样就解决了数据重复加⼯导致研发效率瓶颈的问题，一般可以把需求的平均交付时间从⼀周减少到2〜3天，⼤幅提⾼数据产能。

数据中台通过服务化的方式，提高数据应用接入和管理效率。

原先数仓提供给应⽤的访问⽅式是直接提供表，应⽤开发⾃⼰把数据导出到⼀个查询引擎上，然后去访问查询引擎。在数据中台中，数仓的数据是通过API接⼝的⽅式提供给数据应⽤，数据应⽤不⽤关⼼底层不同的查询引擎访问⽅式的差异【可以是MySQL、Impala、Phoenix等等】。

对于使用数据的非技术人员，数据中台提供了可视化的取数平台，只需要在页面选取指标、通过获取指标系统中每个指标的可分析维度，然后进行勾选，添加筛选过滤条件，点击查询，就可以获取数据。

同时，数据中台构建了企业数据地图，可以很⽅便地检索有哪些数据，它们在哪些表中，⼜关联了哪些指标和维度。通过⾃助取数平台和数据地图，公司的⾮技术⼈员开始⾃助完成取数，相⽐通过提需求给技术⼈员的⽅式，取数效率提⾼了300%（微笑表情）。

数据中台，由于数据只能加工一次，强调数据的复用性，这就对数据的质量提出了更高的要求。需要实现全链路的数据质量稽核监控，对⼀个指标的产出上游链路中涉及的每个表，都实现数据⼀致性、完整性、正确性和及时性的监控，确保在第⼀时间发现、恢复、通知数据问题。原先，当技术⼈员问我们“今天数据有没有问题？”的时候，我们很难回答，现在我们可以很⾃信地回答，数据对不对，哪些数据不对，什么时候能恢复了。数据质量稽核监控能力对最终达成99.8%的数据SLA⾄关重要。

最后一个是成本问题。在构建数据中台时，研发⼀个数据成本治理系统，从应⽤维度、表维度、任务的维度、⽂件的维度进⾏全⾯的治理。从应⽤的维度，如果⼀个报表30天内没有访问，这个报表的产出价值就是低的，然后结合这个报表产出的所有上游表以及上游表的产出任务，我们可以计算加⼯这张表的成本，有了价值和成本，我们就能计算ROI（投资回报率），根据ROI就可以实现将低价值的报表下线的功能。通过综合治理，最终可以在⼀个业务中节省超过20%的成本，约900W。通过数据中台，最终我们成功解决了⾯临的问题，⼤幅提⾼了数据研发的效率、质量，降低了数据的成本。

#03 那么，到底什么样的企业适合建数据中台？

是不是所有企业都要构建一个数据中台？

不可否认，数据中台的构建需要⾮常⼤的投⼊：⼀⽅⾯数据中台的建设离不开系统⽀撑，研发系统需要投⼊⼤量的⼈⼒，⽽这些系统是否能够匹配中台建设的需求，还需要持续打磨。另外⼀⽅⾯，⾯对⼤量的数据需求，要花费额外的⼈⼒去做数据模型的重构，也需要下定决⼼。所以数据中台的建设，需要结合企业的现状，根据需要进⾏选择。一般来说，企业在选择数据中台的时候，应该考虑这样⼏个因素。

企业是否有⼤量的数据应⽤场景，数据中台本⾝并不能直接产⽣业务价值，数据中台的本质是⽀撑企业快速地孵化数据应⽤。所以当你的企业有较多数据应⽤的场景时（⼀般有3个以上就可以考虑），比如电商中有各种各样的数据应⽤场景，此时就要考虑构建⼀个数据中台。

经过了快速的信息化建设，企业存在较多的业务数据的孤岛，需要整合各个业务系统的数据，进⾏关联的分析，此时，你需要构建⼀个数据中台。⽐如在做电商的初期，仓储、供应链、市场运营都是独⽴的数据仓库，进行数据分析的时候，往往跨了很多数据系统，为了消除这些数据孤岛，就必须要构建⼀个数据中台。

当你的团队正在⾯临效率、质量和成本的苦恼时，⾯对⼤量的开发，却不知道如何提⾼效能，数据经常出问题⽽束⼿⽆策，⽼板还要求你控制数据的成本，这个时候，数据中台可以帮助你。

当你所在的企业⾯临经营困难，需要通过数据实现精益运营（精细化运营），提⾼企业的运营效率的时候，你需要构建⼀个数据中台，同时结合可视化的BI数据产品，实现数据从应⽤到中台的完整构建，这种类型往往出现在传统企业中。

企业规模也是必须要考虑的⼀个因素，数据中台因为投⼊⼤，收益偏⻓线，所以更适合业务相对稳定的⼤公司，并不适合初创型的⼩公司。

如果你的公司有以上⼏个特征，不要怀疑，把数据中台提上⽇程吧。

总结重点：

效率、质量和成本是决定数据能否⽀撑好业务的关键，构建数据中台的⽬标就是要实现⾼效率、⾼质量、低成本。

数据只加⼯⼀次是建设数据中台的核⼼，本质上是要实现公共计算逻辑的下沉和复⽤。

如果你的企业拥有3个以上的数据应⽤场景，数据产品还在不断研发和更新，你必须要认真考虑建设数据中台。

建设数据中台不能盲⽬跟⻛，因为它不⼀定适合你，在⽣活中⻅到了很多不符合上述特征，却想要建设数据中台的公司，⽐如⼀些初创型的⼩公司，初期投⼊了⼤量⼈⼒成本建设数据中台，因为业务变化快，缺少深⼊数据应⽤场景，结果却是⻁头蛇尾，价值⽆法落地。

观点：