建设中台前，面临的挑战

对于绝大多数互联网企业来说，2018 年绝对是煎熬的一年，因为面临线上流量枯竭，业绩增长乏力，企业成本高筑， 利润飞速下滑的风险。 原先粗放的企业管理模式和经营模式（比如我们在采购商品的时候，凭借经验去做出采购哪个商品的决策）已经没办法继续支撑企业的高速增长，越来越多的企业开始提数字化转型，强调数据是企业增长的新动力，它应该深入企业经营的各个环节。
数据需求的爆发式增长，促进了数据产品的蓬勃发展，在每个业务过程中，都有大量的数据产品辅助运营完成日常工作。例如，在电商的场景中，用户运营、商品运营、市场运营……每个场景下，都有很多的数据产品，每天有大量的运营基于这些产品完成经营决策。
比如在供应链决策协同系统中，我们有一个智能补货的功能，会根据商品的库存、历史销售数据以及商品的舆情，智能计算商品的最佳采购计划，推送给运营审核，然后完成采购下单。
大量数据产品的出现，在不断提高企业运营效率的同时，也暴露出很多尖锐的问题，在我看来，主要有五点。
1. 指标口径不一致。 两个数据产品一个包含税，一个不包含税，它们相同的一个指标名称都是销售额，结果却不一样。运营面对这些指标的时候，不知道指标的业务口径，很难去使用这些数据。
2. 数据重复建设，需求响应时间长。随着需求的增长，运营和分析师不断抱怨需求的交付时间拉长，面对快速变化的业务，需求响应时间已经无法满足业务对数据的敏捷研发要求。
3. 取数效率低。 面对数十万张表，我们的运营和分析师找数据、准确地理解数据非常困难，想找到一个想要的数据，确认这个数据和自己的需求匹配，他们往往需要花费三天以上的时间，对新人来说，这个时间会更长。
除了查找数据效率低，从系统中取数分析对于非技术出身的分析师和运营来说也是一个难题，这就导致大部分的取数工作还是依赖数据开发来完成。数据开发大部分的时间都被临时取数的需求占据，根本无法专注在数仓模型的构建和集市层数据的建设，最终形成了一个恶性循环，一方面是数据不完善，另一方面是数据开发忙于各种临时取数需求。
4. 数据质量差。数据经常因为 BUG 导致计算结果错误，最终导致错误的商业决策。分享一个我们踩过的坑，在大促期间，某类商品搜索转化率增长，于是我们给这个商品分配了更大的流量，可转化率增长的原因是数据计算错误，所以这部分流量也就浪费了，如果分配给其他的商品的话，可以多赚 200W 的营收。
5. 数据成本线性增长。数据成本随着需求的增长而线性增长，2017 年的时候，我们一个业务的大数据资源在 4000Core，但是 2018 就已经到达 9000Core 水平，如果折算成钱的话，已经多了 500 多万的机器成本。

为什么数据中台可以解决这些问题？

指标口径不一致，可能原因包括三种：业务口径不一致、计算逻辑不一致、数据来源不一致。
如果是业务口径不一致，那就要明确区分两个指标不能使用相同的标识，像上面的例子，含税和不含税的两个指标， 不能同时叫销售额。
业务口径的描述往往是一段话，但是对于很多指标，涉及的计算逻辑非常复杂，仅仅一段话是描述不清楚的，此时，两个相同业务口径的指标，恰巧又分别是由两个数据开发去实现的，这样就有可能造成计算逻辑不一致。比如，有一个指标叫做排关单（排关单：把关单的排除；关单：关闭订单）的当天交易额这个指标，A 认为关单的定义是未发货前关闭的订单，B 认为关单是当天关闭的订单，大家对业务口径理解不一致，这样实现的计算结果也就会不一致。
最后，还可能是两个指标的数据来源不一样，比如一个来自实时数据，一个是来自离线的数据，即使加工逻辑一样，最终结果也可能不相同
综合看来，要实现一致，就务必确保对同一个指标，只有一个业务口径，只加工一次，数据来源必须相同。
而数据需求响应慢在于烟囱式的开发模式，导致了大量重复逻辑代码的研发，比如同一份原始数据，两个任务都对原始数据进行清洗。如果只有一个任务清洗，产出一张明细表，另外一个任务直接引用这张表，就可以节省一个研发的清洗逻辑的开发。
所以，要解决数据需求响应慢，就必须解决数据复用的问题，要确保相同数据只加工一次，实现数据的共享。
取数效率低，一方面原因是找不到数据，另一方面原因可能是取不到数据。要解决找不到数据的问题，就必须要构建一个全局的企业数据资产目录，实现数据地图的功能，快速找到数据。而非技术人员并不适合用写 SQL 的方式来取数据，所以要解决取不到数据的问题，就要为他们提供可视化的查询平台，通过勾选一些参数，才更容易使用。
数据质量差的背后其实是数据问题很难被发现。我们经常是等到使用数据的人反馈投诉，才知道数据有问题。而数据的加工链路一般非常长，在我们的业务中，一个指标上游的所有链路加起来有 100 多个节点，这是很正常的事情。等到运营投诉再知道数据有问题就太迟了，因为要逐个去排查到底哪个任务有问题，然后再重跑这个任务以及所有下游链路上的每个任务，这样往往需要花费半天到一天的时间，最终导致故障恢复的效率很低，时间很长。
所以，要解决数据质量差，就要及时发现然后快速恢复数据问题。
最后一个是大数据的成本问题，它其实与需求响应慢背后的数据重复建设有关，因为重复开发任务的话，这些任务上线肯定会花费双倍的资源。如果我们可以节省一个任务的资源消耗，满足两个数据需求，就可以控制不必要的资源消耗。所以，成本问题背后也是数据重复建设的问题。
正当我们为这些问题苦恼的时候，数据中台的理念给了我们全新的启迪，那么数据中台到底是怎么一回事儿呢？在我看来，数据中台是企业构建的标准的、安全的、统一的、共享的数据组织，通过数据服务化的方式支撑前端数据应用。
数据中台消除了冗余数据，构建了企业级数据资产，提高了数据的共享能力，这与我们需要的能力不谋而合，所以很快，我们开启了数据中台的建设。

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

指标是数据加工的结果，要确保数据需求高质量的交付，首先是要管好指标。
原先指标的管理非常分散，没有全局统一的管理，在数据中台中，必须要有一个团队统一负责指标口径的管控。
其次，要实现指标体系化的管理，提高指标管理的效率。在指标系统中，我们会明确每个指标的业务口径，数据来源和计算逻辑，同时会按照类似数仓主题域的方式进行管理。
最后，要确保所有的数据产品、报表都引用指标系统的口径定义。当运营把鼠标 Hover 到某个指标上时，就可以浮现出该指标的口径定义。
通过对全局指标的梳理，我们实现了 100% 的数据产品的指标口径统一，消除了数据产品中，指标口径二义性的问题，同时还提供了方便分析师、运营查询的指标管理系统。
那么数据中台是怎么实现所有数据只加工一次的呢？简单来说，就是对于数仓数据，我们要求相同粒度的度量或者指标只加工一次，构建全局一致的公共维表。要实现上述目标，需要两个工具产品：
一个是数仓设计中心，在模型设计阶段，强制相同聚合粒度的模型，度量不能重复。
另外一个是数据地图，方便数据开发能够快速地理解一张表的准确含义。
这样就解决了数据重复加工导致研发效率瓶颈的问题，现在我们把需求的平均交付时间从一周减少到 2～3 天，大幅提高了数据产能，得到了分析师和运营的认可。
数据中台通过服务化的方式，提高了数据应用接入和管理的效率。原先数仓提供给应用的访问方式是直接提供表，应用开发自己把数据导出到一个查询引擎上，然后去访问查询引擎。在数据中台中，数仓的数据是通过 API 接口的方式提供给数据应用，数据应用不用关心底层不同的查询引擎访问方式的差异。
对于非技术人员，数据中台提供了可视化的取数平台，你只需要选取指标、通过获取指标系统中每个指标的可分析维度，然后勾选，添加筛选过滤条件，点击查询，就可以获取数据。
同时，数据中台构建了企业数据地图，你可以很方便地检索有哪些数据，它们在哪些表中，又关联了哪些指标和维度。通过自助取数平台和数据地图，公司的非技术人员开始自助完成取数，相比通过提需求给技术人员的方式，取数效率提高了 300%。

数据中台由于数据只能加工一次，强调数据的复用性，这就对数据的质量提出了更高的要求。而我们实现了全链路的数据质量稽核监控，对一个指标的产出上游链路中涉及的每个表，都实现了数据一致性、完整性、正确性和及时性的监控，确保在第一时间发现、恢复、通知数据问题。
原先，当技术人员问我们“今天数据有没有问题？” 的时候，我们很难回答，现在我们可以很自信地回答，数据对不对，哪些数据不对，什么时候能恢复了。我个人认为这个能力对我们最终达成 99.8% 数据 SLA 至关重要。
最后一个是成本问题。我们在构建数据中台的时候，研发了一个数据成本治理系统，从应用维度、表维度、任务的维度、文件的维度进行全面的治理。 从应用的维度，如果一个报表 30 天内没有访问，这个报表的产出价值就是低的，然后结合这个报表产出的所有上游表以及上游表的产出任务，我们可以计算加工这张表的成本，有了价值和成本，我们就能计算 ROI，根据 ROI 就可以实现将低价值的报表下线的功能。通过综合治理，最终我们在一个业务中节省了超过 20% 的成本，约 900W。
通过数据中台，最终我们成功解决了面临的问题，大幅提高了数据研发的效率、质量，降低了数据的成本。那么到底什么样的企业适合建数据中台？ 是不是所有企业都要构建一个数据中台？

什么样的企业适合建数据中台？

不可否认，数据中台的构建需要非常大的投入：一方面数据中台的建设离不开系统支撑，研发系统需要投入大量的人力，而这些系统是否能够匹配中台建设的需求，还需要持续打磨。另外一方面，面对大量的数据需求，要花费额外的人力去做数据模型的重构，也需要下定决心。
所以数据中台的建设，需要结合企业的现状，根据需要进行选择。我认为企业在选择数据中台的时候，应该考虑这样几个因素。
企业是否有大量的数据应用场景： 数据中台本身并不能直接产生业务价值，数据中台的本质是支撑快速地孵化数据应用。所以当你的企业有较多数据应用的场景时（一般有 3 个以上就可以考虑），要考虑构建一个数据中台。
经过了快速的信息化建设，企业存在较多的业务数据的孤岛，需要整合各个业务系统的数据，进行关联的分析，此时，你需要构建一个数据中台。比如在我们做电商的初期，仓储、供应链、市场运营都是独立的数据仓库，当时数据分析的时候，往往跨了很多数据系统，为了消除这些数据孤岛，就必须要构建一个数据中台。
当你的团队正在面临效率、质量和成本的苦恼时，面对大量的开发，却不知道如何提高效能，数据经常出问题而束手无策，老板还要求你控制数据的成本，这个时候，数据中台可以帮助你。
当你所在的企业面临经营困难，需要通过数据实现精益运营，提高企业的运营效率的时候，你需要构建一个数据中台，同时结合可视化的 BI 数据产品，实现数据从应用到中台的完整构建，在我的接触中，这种类型往往出现在传统企业中。
企业规模也是必须要考虑的一个因素，数据中台因为投入大，收益偏长线，所以更适合业务相对稳定的大公司，并不适合初创型的小公司。

总结

效率、质量和成本是决定数据能否支撑好业务的关键，构建数据中台的目标就是要实现高效率、高质量、低成本。
数据只加工一次是建设数据中台的核心，本质上是要实现公共计算逻辑的下沉和复用。
如果你的企业拥有 3 个以上的数据应用场景，数据产品还在不断研发和更新，你必须要认真考虑建设数据中台。
设数据中台不能盲目跟风，因为它不一定适合你，我在生活中见到了很多不符合上述特征，却想要建设数据中台的公司，比如一些初创型的小公司，初期投入了大量人力成本建设数据中台，因为业务变化快，缺少深入数据应用场景，结果却是虎头蛇尾，价值无法落地。