数据中台学习笔记-原理篇

概述

最近使用鹅厂的tbds和整套的数据中台产品，通过最近的使用和学习，略有些心得和体会，所以随笔记录以备学习和共享。

首先聊一下，到底什么是数据中台？如何来建设数据中台？数据中台有哪些应用价值？说到数据中台，你肯定不陌生，从 2018 年末开始，它突然在大数据圈儿走红。大家聊天如果不提中台，好像就落伍了。也正是因为数据中台，大数据受到了前所未有的关注。作为一个数据人，我非常高兴，也感到责任重大，因为大家对数据中台寄予了很大的期望，把它当作企业数字化转型的金钥匙，投入了上百万，甚至是千万，希望解决企业经营效率的问题。但是我们也看到一些企业未能达到预期的结果，比如说，指标口径不一致造成数据不可信；数据经常无法按时产出，影响工作效率；敏感数据泄露，引发安全危机。最终的结果就是数据不好用，无法发挥应有的价值。所以有人泼冷水说：数据中台就是一个充满诱惑的陷阱，看上去很美好，但是根本不可能落地成功。那数据中台到底是陷阱？还是金钥匙呢？ 为什么这些项目很难成功呢？

在我看来，这里面既有客观原因，又有主观原因：客观上讲，数据中台的建设是一项系统性工程，从组织架构、支撑技术到流程规范，既要有宏观的顶层设计，又要有强有力的落地执行，所以对整个团队的要求会比较高；从主观上讲，这些企业本身数据建设经验不足，或者还处于比较初级的阶段，不知道数据建设中有哪些痛点，更不知道用什么样的技术手段和管理机制去解决这些问题。

数据中台崛起过程

深入大数据的发展历史，先从数据仓库的出现讲起，途径数据湖，再到大数据平台，因为这样，你才能理解大数据发展的每个阶段遇到的问题，从而深入理解数据中台在大数据发展中的历史定位。

启蒙时代：数据仓库的出现

商业智能（Business Intelligence）诞生在上个世纪 90 年代，它是将企业已有的数据转化为知识，帮助企业做出经营分析决策。比如在零售行业的门店管理中，如何使得单个门店的利润最大化，我们就需要分析每个商品的销售数据和库存信息，为每个商品制定合理的销售采购计划，有的商品存在滞销，应该降价促销，有的商品比较畅销，需要根据对未来销售数据的预测，进行提前采购，这些都离不开大量的数据分析。而数据分析需要聚合多个业务系统的数据，比如需要集成交易系统的数据，需要集成仓储系统的数据等等，同时需要保存历史数据，进行大数据量的范围查询。传统数据库面向单一业务系统，主要实现的是面向事务的增删改查，已经不能满足数据分析的场景，这促使数据仓库概念的出现。

数据仓库之父比尔·恩门（Bill Inmon）首次给出了数据仓库的完整定义，他认为：数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合。

为了帮你理解数据仓库的四要素，我举个电商的例子。

在电商场景中，有一个数据库专门存放订单的数据，另外一个数据库存放会员相关的数据。构建数据仓库，首先要把不同业务系统的数据同步到一个统一的数据仓库中，然后按照主题域方式组织数据。

 主题域是业务过程的一个高层次的抽象，像商品、交易、用户、流量都能作为一个主题域，你可以把它理解为数据仓库的一个目录。数据仓库中的数据一般是按照时间进行分区存放，一般会保留 5 年以上，每个时间分区内的数据都是追加写的方式，对于某条记录是不可更新的。除了这个概念之外，我还要提一下他和金博尔（Kimball） 共同开创的数仓建模的设计方法，这个方法对于后来基于数据湖的现代数据仓库的设计有重要的意义，所以你有必要了解。恩门提出的建模方法自顶向下（这里的顶是指数据的来源，在传统数据仓库中，就是各个业务数据库），基于业务中各个实体以及实体之间的关系，构建数据仓库。

金博尔建模与恩门正好相反，是一种自底向上的模型设计方法，从数据分析的需求出发，拆分维度和事实。那么用户、商品就是维度，库存、用户账户余额是事实。

这两种方法各有优劣，恩门建模因为是从数据源开始构建，构建成本比较高，适用于应用场景比较固定的业务，比如金融领域，冗余数据少是它的优势。金博尔建模由于是从分析场景出发，适用于变化速度比较快的业务，比如互联网业务。由于现在的业务变化都比较快，所以我更推荐金博尔的建模设计方法。传统数据仓库，第一次明确了数据分析的应用场景应该用单独的解决方案去实现，不再依赖于业务的数据库。在模型设计上，提出了数据仓库模型设计的方法论，为后来数据分析的大规模应用奠定了基础。但是进入互联网时代后，传统数据仓库逐渐没落，一场由互联网巨头发起的技术革命催生了大数据时代的到来。

技术革命：从 Hadoop 到数据湖

但 2005 年 Hadoop 出现的时候，大数据技术才开始普及。我认为 Hadoop 相比传统数据仓库主要有两个优势：完全分布式，易于扩展，可以使用价格低廉的机器堆出一个计算、存储能力很强的集群，满足海量数据的处理要求；弱化数据格式，数据被集成到 Hadoop 之后，可以不保留任何数据格式，数据模型与数据存储分离，数据在被使用的时候，可以按照不同的模型读取，满足异构数据灵活分析的需求。随着 Hadoop 技术日趋成熟，2010 年，Pentaho 创始人兼 CTO James Dixon 在纽约 Hadoop World 大会上提出了数据湖的概念，他提到：数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统。

数据湖概念的提出，我认为是 Hadoop 从开源技术走向商业化成熟的标志。企业可以基于 Hadoop 构建数据湖，将数据作为一种企业核心资产。数据湖拉开了 Hadoop 商用化的大幕，但是一个商用的 Hadoop 包含 20 多种计算引擎， 数据研发涉及流程非常多，技术门槛限制了 Hadoop 的商用化进程。那么如何让数据的加工像工厂一样，直接在设备流水线上完成呢？

数据工厂时代：大数据平台兴起

对于一个数据开发，在完成一项需求时，常见的一个流程是首先要把数据导入到大数据平台中，然后按照需求进行数据开发。开发完成以后要进行数据验证比对，确认是否符合预期。接下来是把数据发布上线，提交调度。最后是日常的任务运维，确保任务每日能够正常产出数据。

如此繁杂的一个工作流程，如果没有一个高效的平台作为支撑，就跟写代码没有一个好用的 IDE， 用文本编辑器写代码一样，别人完成十个需求，你可能连一个需求都完成不了，效率异常低下，根本无法大规模的应用。提出大数据平台的概念，就是为了提高数据研发的效率，降低数据研发的门槛，让数据能够在一个设备流水线上快速地完成加工。大数据平台是面向数据研发场景的，覆盖数据研发的完整链路的数据工作台。

大数据平台按照使用场景，分为数据集成、数据开发、数据测试……任务运维，大数据平台的使用对象是数据开发。大数据平台的底层是以 Hadoop 为代表的基础设施，分为计算、资源调度和存储。

Hive、Spark、Flink、Impala 提供了大数据计算引擎：

Hive、Spark 主要解决离线数据清洗、加工的场景，目前，Spark 用得越来越多，性能要比 Hive 高不少；

Flink 主要是解决实时计算的场景；

Impala 主要是解决交互式查询的场景。

这些计算引擎统一运行在一个称为 Yarn 的资源调度管理框架内，由 Yarn 来分配计算资源。目前最新的研究方向中也有基于 Kubernetes 实现资源调度的，例如在最新的 Spark 版本（2.4.4）中，Spark 已经能够运行在 Kubernetes 管理的集群上，这样的好处是可以实现在线和离线的资源混合部署，节省机器成本。

数据存储在 HDFS、Kudu 和 HBase 系统内。HDFS 不可更新，主要存全量数据，HBase 提供了一个可更新的 KV，主要存一些维度表，Kudu 提供了实时更新的能力，一般用在实时数仓的构建场景中。大数据平台像一条设备流水线，经过大数据平台的加工，原始数据变成了指标，出现在各个报表或者数据产品中。随着数据需求的快速增长，报表、指标、数据模型越来越多，找不到数据，数据不好用，数据需求响应速度慢等问题日益尖锐，成为阻塞数据产生价值的绊脚石。

数据价值时代：数据中台崛起

时间到了 2016 年前后，互联网高速发展，背后对数据的需求越来越多，数据的应用场景也越来越多，有大量的数据产品进入到了我们运营的日常工作，成为运营工作中不可或缺的一部分。在电商业务中，有供应链系统，供应链系统会根据各个商品的毛利、库存、销售数据以及商品的舆情，产生商品的补货决策，然后推送给采购系统。

大规模数据的应用，也逐渐暴露出现一些问题。业务发展前期，为了快速实现业务的需求，烟囱式的开发导致企业不同业务线，甚至相同业务线的不同应用之间，数据都是割裂的。两个数据应用的相同指标，展示的结果不一致，导致运营对数据的信任度下降。如果你是运营，当你想看一下商品的销售额，发现两个报表上，都叫销售额的指标出现了两个值，你的感受如何? 你第一反应肯定是数据算错了，你不敢继续使用这个数据了。数据割裂的另外一个问题，就是大量的重复计算、开发，导致的研发效率的浪费，计算、存储资源的浪费，大数据的应用成本越来越高。

如果你是运营，当你想要一个数据的时候，开发告诉你至少需要一周，你肯定想是不是太慢了，能不能再快一点儿？如果你是数据开发，当面对大量的需求的时候，你肯定是在抱怨，需求太多，人太少，活干不完。如果你是一个企业的老板，当你看到每个月的账单成指数级增长的时候，你肯定觉得这也太贵了，能不能再省一点，要不吃不消了。

这些问题的根源在于，数据无法共享。2016 年，阿里巴巴率先提出了“数据中台”的口号。数据中台的核心，是避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用。之前，数据是要啥没啥，中间数据难于共享，无法积累。现在建设数据中台之后，要啥有啥，数据应用的研发速度不再受限于数据开发的速度，一夜之间，我们就可以根据场景，孵化出很多数据应用，这些应用让数据产生价值。

说数据中台是大数据的下一站， 在我看来，有这样几个原因：

数据中台构建于数据湖之上，具备数据湖异构数据统一计算、存储的能力，同时让数据湖中杂乱的数据通过规范化的方式管理起来。

数据中台需要依赖大数据平台，大数据平台完成了数据研发的全流程覆盖，数据中台增加了数据治理和数据服务化的内容。

数据中台借鉴了传统数据仓库面向主题域的数据组织模式，基于维度建模的理论，构建统一的数据公共层。

总的来说，数据中台吸收了传统数据仓库、数据湖、大数据平台的优势，同时又解决了数据共享的难题，通过数据应用，实现数据价值的落地。

数据中台的作用

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

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

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

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

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

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

5. 数据成本线性增长。数据成本随着需求的增长而线性增长，2017 年的时候，我们一个业务的大数据资源在 4000Core，但是 2018 就已经到达 9000Core 水平，如果折算成钱的话，已经多了 500 多万的机器成本。相信你能在我“惨痛”的经历中，找到自己的影子，这些事儿的确很头疼，好在后来，我们用数据中台解决了这些问题。

为什么数据中台可以解决这些问题？要想回答这个问题，

你需要了解上述问题背后的原因。指标口径不一致，可能原因包括三种：业务口径不一致、计算逻辑不一致、数据来源不一致。

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

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

而数据需求响应慢在于烟囱式的开发模式，导致了大量重复逻辑代码的研发，比如同一份原始数据，两个任务都对原始数据进行清洗。如果只有一个任务清洗，产出一张明细表，另外一个任务直接引用这张表，就可以节省一个研发的清洗逻辑的开发。所以，要解决数据需求响应慢，就必须解决数据复用的问题，要确保相同数据只加工一次，实现数据的共享。

取数效率低，一方面原因是找不到数据，另一方面原因可能是取不到数据。要解决找不到数据的问题，就必须要构建一个全局的企业数据资产目录，实现数据地图的功能，快速找到数据。而非技术人员并不适合用写 SQL 的方式来取数据，所以要解决取不到数据的问题，就要为他们提供可视化的查询平台，通过勾选一些参数，才更容易使用。数据质量差的背后其实是数据问题很难被发现。我们经常是等到使用数据的人反馈投诉，才知道数据有问题。而数据的加工链路一般非常长，在我们的业务中，一个指标上游的所有链路加起来有 100 多个节点，这是很正常的事情。等到运营投诉再知道数据有问题就太迟了，因为要逐个去排查到底哪个任务有问题，然后再重跑这个任务以及所有下游链路上的每个任务，这样往往需要花费半天到一天的时间，最终导致故障恢复的效率很低，时间很长。所以，要解决数据质量差，就要及时发现然后快速恢复数据问题。

最后一个是大数据的成本问题，它其实与需求响应慢背后的数据重复建设有关，因为重复开发任务的话，这些任务上线肯定会花费双倍的资源。如果我们可以节省一个任务的资源消耗，满足两个数据需求，就可以控制不必要的资源消耗。所以，成本问题背后也是数据重复建设的问题。正当我们为这些问题苦恼的时候，数据中台的理念给了我们全新的启迪，那么数据中台到底是怎么一回事儿呢？在我看来，数据中台是企业构建的标准的、安全的、统一的、共享的数据组织，通过数据服务化的方式支撑前端数据应用。

数据中台消除了冗余数据，构建了企业级数据资产，提高了数据的共享能力，这与我们需要的能力不谋而合，所以很快，我们开启了数据中台的建设。

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

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

首先是要管好指标。原先指标的管理非常分散，没有全局统一的管理，在数据中台中，必须要有一个团队统一负责指标口径的管控。其次，要实现指标体系化的管理，提高指标管理的效率。在指标系统中，我们会明确每个指标的业务口径，数据来源和计算逻辑，同时会按照类似数仓主题域的方式进行管理。最后，要确保所有的数据产品、报表都引用指标系统的口径定义。当运营把鼠标 Hover 到某个指标上时，就可以浮现出该指标的口径定义。通过对全局指标的梳理，我们实现了 100% 的数据产品的指标口径统一，消除了数据产品中，指标口径二义性的问题，同时还提供了方便分析师、运营查询的指标管理系统。

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

对于非技术人员，数据中台提供了可视化的取数平台，你只需要选取指标、通过获取指标系统中每个指标的可分析维度，然后勾选，添加筛选过滤条件，点击查询，就可以获取数据。同时，数据中台构建了企业数据地图，你可以很方便地检索有哪些数据，它们在哪些表中，又关联了哪些指标和维度。通过自助取数平台和数据地图，公司的非技术人员开始自助完成取数，相比通过提需求给技术人员的方式，取数效率提高了 300%。

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

最后一个是成本问题。我们在构建数据中台的时候，研发了一个数据成本治理系统，从应用维度、表维度、任务的维度、文件的维度进行全面的治理。 从应用的维度，如果一个报表 30 天内没有访问，这个报表的产出价值就是低的，然后结合这个报表产出的所有上游表以及上游表的产出任务，我们可以计算加工这张表的成本，有了价值和成本，我们就能计算 ROI，根据 ROI 就可以实现将低价值的报表下线的功能。通过综合治理，最终我们在一个业务中节省了超过 20% 的成本，约 900W。通过数据中台，最终我们成功解决了面临的问题，大幅提高了数据研发的效率、质量，降低了数据的成本。那么现在让我们回到课程开始时的问题，到底什么样的企业适合建数据中台？ 是不是所有企业都要构建一个数据中台？

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

不可否认，数据中台的构建需要非常大的投入：一方面数据中台的建设离不开系统支撑，研发系统需要投入大量的人力，而这些系统是否能够匹配中台建设的需求，还需要持续打磨。另外一方面，面对大量的数据需求，要花费额外的人力去做数据模型的重构，也需要下定决心。所以数据中台的建设，需要结合企业的现状，根据需要进行选择。我认为企业在选择数据中台的时候，应该考虑这样几个因素。

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

数据中台的价值

过去，数据的利用形式主要是商业智能，说直接一点就是做报表，做报表的目的就是让管理者知道现在的业务在发生什么，为什么会发生这些事情，接下来可能会发生什么，这一切都是提供给我们的管理者去看的，帮助管理者去做出一个业务决策。随着业务复杂度的提升，一个决策背后的因素是非常多的，一个现象需要多个维度的解读才能够体现业务全貌。于是，管理者需要的报表就越来越多，很多企业会有多个不同业务线的数据仓库，每个数据仓库里都有千张以上的报表，最后就陷入了报表的迷宫。当我们回头来看这个过程，我们发现，报表并不是我们所需要的，而数据本身也不是我们所需要的，我们所需要的是一个业务决策，一个业务行为。

比如，当用户打开电商产品目录的时候，将他最有可能购买的产品展示在第一页，而原来的 OLTP、OLAP 分离的数据处理流程是做不到的，那么，在业务交易的过程中，也没有办法从历史数据和全域数据的分析结果中获得行动的指引。总而言之，市场对于数据中台的期待，是提供直接驱动业务流程的数据服务，而不仅是需要经过人去转化和解读的数据可视化报表，原来商业智能时代已经过去，市场和用户期待的是数据智能的时代。

数据中台给了应用开发人员这样的希望，那就是他们不需要关注具体的取数逻辑，只需要关注客户需求，可以像搭乐高一样方便的组合各种数据中台的数据服务到自己的应用当中去，数据准确并且一致。所以，如果用一句话来说数据中台的价值，那就是改变原来企业利用数据的形式。

诉求在这里了，建设数据中台似乎能够提供解决方案。但是建设中台不是一蹴而就的事情，也不是一件容易的事，需要在技术上、组织架构上都做对应的调整才可以，落地过程也会面临种种挑战。那企业为啥还要兴师动众地来落地数据中台呢？结合这些年我自己的经验，我认为这个问题的答案就是：数据中台的愿景是打造数据驱动的智能企业。

今天呢，我想深入和你聊聊企业建设了数据中台，成为了数据驱动的智能企业，这对企业到底有什么收益呢？我认为企业能够获得两个方面的收益：优化现有业务和实现新业务的转型。

优化现有业务

第一，增加现有业务的收入。这是企业建设数据中台的一个直接诉求。比如，通过分析产品的价格、销量、用户数据来优化产品定价、优化产品组合、进行精准营销，从而能够促进产品的销售，增加现有产品的收入。给你举一个典型的案例，是我们给一个能源类企业做的数据中台。建成后能够根据历史销量、市场份额、市场容量等数据进行建模，从而帮助企业的销售部门去优化销售任务的分配，最后提升销售额。这样的一个看上去很小的项目，能给企业带来啥价值呢？这么说吧，过去，企业每年年初给全国的几十个销售定业绩并持续去跟踪，是一个很痛苦的事情，原因主要在于目标不好锚定，每个销售管理着一堆经销商，经销商的销量、退货都不拉通，所以无法客观地量化和追踪销售的业绩。怎么办呢？过去这一切靠的都是销售总监的经验去拍数，更多靠的是谈判能力，是一个不确定性很高的工作。有了数据中台后，把行业数据、市场竞争数据、往年销售数据以及经销商的数据都拉通来看，一下子能够给到销售总监全貌，还可以做模拟，让销售业绩分配这个工作变成一个可量化、可预测的确定性工作。

第二，促进生产效率。通过数据中台的建设，能够促进生产效率的提升。关于这一点，直接给你说个场景吧。比如，某个大型电信服务商，通过对勘测、规划、设计工作的建模，实现数据自动化处理，减少人工干预和问题的出现，从而大幅提升工程师的设计效率和准确性，将工程设计的周期缩短一半以上。分析下原因。电信服务商的投标是一个很复杂的工作，从客户发出需求到根据需求去勘测、做出规划、具体实施设计再到把实施设计转化成物料设计、工程设计、财务设计，最后再形成投标方案，这个过程过去至少需要一个月，需要众多不同业务部门和专业技能的协作，其中大部分工作都花在了不同数据的合并、拉通、对齐和映射上。那么当这个企业建设了数据中台后，所有的数据能够自动处理，大家在同一个数据服务里获取、修改、加工同样的一套数据，并且每次做方案的过程都沉淀成新的服务，后面的项目可以服用，这样大大缩短了工期，有些标准化比较高的项目类型，可以从原来的一个月缩短到三天。

第三，降低运营成本，提升运营的利润。这个是目前利用场景最多的，主要就是通过数据分析来优化业务流程、缩短运营周期，从而提升运营的利润。比如，我之前做的一个项目，是给一家大型的钢铁厂进行配方的规划优化，通过对配方数据、市场价格、销量数据的综合分析建模，给到成本最优、产值最高的生产组合，从而能够降低运营成本，提升利润。你可能对钢铁这个行业不太了解，钢铁行业里配矿决策是一个很复杂但是很重要的环节，不同的配矿方案，其成本和工艺都不一样，对利润的影响很大。如何根据技术和商业的众多因素去选择最优的配方呢？过去都是根据经验来维护和计算配矿规则，效率低、周期长。有了数据中台后，将原材料的性能、化学工艺、产品质量等技术因素和价格、成分、运营成本及销售收入等商业因素的数据统一进行建模，统一计算后最终做出综合规划，这样做大大提升了利润、降低了运营成本。

第四，提升用户体验。提升用户体验的核心是企业要理解自己的用户，知道用户对自己产品、服务的认知，然后对应优化自己的产品和服务，这就需要建设用户数据平台，构建统一的用户视图，建立起用户画像。这里我举个富国银行的例子，他们在数据转型中，利用数据中台分析用户的行为数据，来重构在线银行的网站，提升用户体验。富国银行在 2016 年的时候面临很大的业绩挑战，为了更好地了解用户，他们建立了企业级的数据中台，把全行的用户信息都打通，做成用户画像，打上各种标签，并根据这些用户画像和标签，重新设计了电子银行网站，让网站的服务和风格以用户为中心。

第五，提升资产利用率。这一点主要是指分析、优化高价值资产，提升资产的利用率。我举一个我们做过的物流领域路径优化的案例。我们曾经给国内最大的物流企业之一做过路径优化的项目，帮助他们提升人员和车辆的使用率。过去，每天早上每个区域都有一个经验丰富的员工，统一规划前一天收到的派件和收件订单，把这些订单分配给对应的小组。这个过程的目的就是最大化地利用车辆和快递员这两个核心资产。但是这个规划是很复杂的，因为不仅要考虑成本，还要考虑到每个件积压的时间不一样、紧急程度不一样、不同的地点路况对于车辆的要求也不一样等等，这些数据的采集、拉通、建模是很重要的基础工作而这一切都依赖与数据的打通。建设数据中台，拉通了数据后，派单收单的路径更优化了，更好的分配给快递员，提升了车辆的使用率提升了 20% 左右。你看，这样的场景就很典型，体现了数据中台所能支撑的智能规划业务的价值。

业务创新和转型

接下来，我们继续来看建设数据中台的第二个收益，实现业务创新和转型。这里我总结了四个主要的价值，这些价值乍一听好像都比较抽象，我会用具体的例子来分析。

第一，数字化产品创新。这里有一个很生动的例子，我们有一个合作了十多年的海外房地产交易网站客户，主要是定期和他们做黑客马拉松。有一次我们黑客马拉松的一个小组，通过数据分析发现了一个小模式，就是有一群用户，在一段时间内高频访问网站，但是不产生任何看房、卖房的行为。这是为什么呢？最后通过数据分析，发现这样的用户都有一个共同的特点，那就是她们大部分都是女性，而且基本上访问链接停留时间最长的，很多都是图片，而且是室内的图片。基于这些数据，我们推测，这群人是来看装修的，于是，基于这个推测，这个小组孵化了一个新产品，专门提供装修服务，这个产品最后还成功了，成为了公司除房地产中介服务之外的新业务线。这也是典型的通过数据洞察发现业务新价值，从而实现数字化产品创新的场景。

第二，数字化资产销售。这一点说的就是将已经积累的数据，通过组合、包装、分析、脱敏，形成对于一部分用户有价值的数据资产，比如行业报告或者优质的内容，直接销售产生收入。这个典型的场景就是搜索引擎，搜索引擎将用户的信息进行统计分析、脱敏处理后，变成一系列的知识和分析报告，然后以会员的方式，提供给有需要的用户。我们都用过百度指数吧，这里面，用户可以定义和购买自己感兴趣的关键词，一年是 198 元，然后百度就会把所有搜索过这个关键词的记录统计出来，变成这个关键词的搜索指数。比如，数据中台的关键词就是我去年购买的，我就能实时追踪这个关键词在中文市场被搜索的热度。这就是数据化资产销售的价值模式。

第三，业务平台化收益。有一句话在去年很流行，“未来的企业，要么自己做平台，要么被别人平台化”。平台经济成为了这几年数字化领域炙手可热的概念。总的来说，平台化就是你搭建一个平台，让需求方和供给方上来交易，最后你来收取服务费。那么如何建立平台呢？拉通一个领域数据，形成数字化平台，再通过平台来运营一个特定的业务和客户群体，从而通过平台来产生收益。典型的场景就是交易撮合平台，比如非常玄幻的比特币交易平台。你可能会说，这个和数据中台有什么关系？这个过程其实也是一个领域数据中台的建设过程，因为作为平台方，其实主要做的就是数据的生意，对接信息、对接交易双方。那么数据中台在企业内部，就相当于一个数据采集、加工、交易的平台，业务方既可能是数据服务的消费者，又可能是生产者，最终的产品是数据服务。

第四，数字化生态业务。这一点是从更高的一个维度来看的，就是在平台化基础之上，通过打穿产业供应链，帮助企业建设自己的数字化生态，从而在生态中产生新的业务价值和收入。一个典型的例子就是 Google 的应用商店。当有足够多的伙伴在这个平台上进行交易的时候，它就可以在这些海量的交易和行为数据中去发现特别多的规律，然后产生更多的产品创新，利用数据来牵引着这个生态朝自己设计的方向发展。在这个生态里，有非常多的角色参与其中，开发者、自由开发者、广告商、应用购买者等，而 Google 掌握着所有方的数据，用户的浏览、下载、付费、交易，一切的数据都能够被分析、被利用，帮助 Google Play 的运营方去发现新的业务价值，创造收入。

数据中台建设

现在有很多讲“如何建设数据中台”的文章，大家的观点各不相同：有的观点说，数据中台是一种数据建设的方法论，按照数据中台设计方法和规范实施就可以建成数据中台了；也有观点认为，数据中台的背后是数据部门组织架构的变更，把原先分散的组织架构形成一个统一的中台部门，就建成了数据中台；除此之外，你可能还听到过一些大数据公司说，他们可以卖支撑数据中台建设的产品技术。

那数据中台到底如何建设呢？咱们先不着急回答这个问题，而是看一个例子。你肯定见过盖房子，盖房子之前，是不是先得有设计图纸，知道如何去盖这个房子？然后还必须要有一个好用的工具（比如水泥搅拌机、钢筋切割机）帮你盖好这个房子。当然了，盖房子离不开一个靠谱的施工队伍，这里面涉及很多角色（泥瓦工、木工、水电工等等），这些人必须高效协作，最终才能盖出一个好的房子。如果我们把建数据中台比作是盖房子，那么设计图纸就是数据中台建设的方法论；工具是数据中台的支撑技术；施工队伍就是数据中台的组织架构。这三者缺一不可。这一讲我就以全局的视角，让你从宏观上了解如何建设一个企业级的数据中台。

早在 2016 年，阿里巴巴就提出了数据中台建设的核心方法论：OneData 和 OneService。经过这么多年，很多公司都进行了实践，但你很难找出一个准确的定义去描述这些方法论，而我结合自己在网易数据中台建设的经验，对方法论进行了系统化的定义，你可以借鉴参考一下。

OneData

用一句话定义 OneData 的话，就是所有数据只加工一次。 这个概念具体是啥意思呢？我们来看一个例子。

 电商业务建设数据中台之前，每个部门内部都会有一些小的数仓去完成本部门的数据分析需求。有一天，供应链团队接到一个数据需求，那就是计算“商品库存”指标，供应链的运营需要根据每个商品的库存制订商品采购计划，部门的数据开发从业务系统同步数据，进行数据清洗、聚合、深度加工，最终，产出这个指标花了 1 周的时间。而恰逢全年最重要的大促节日，市场部门也需要根据每个商品的库存，制订商品的促销计划。该数据开发接到这个紧急的需求（与供应链团队类似）从需求开发到上线，也足足花费了 1 周的时间。同部门的运营会抱怨说，为什么数据需求开发这么慢，根本无法满足大促期间高频的市场运营决策。而对公司而言，等待 1 周意味着遭受巨大损失，该促销的商品没有促销，不该促销的却低价卖了。

如果你是这个公司的老板， 肯定会问，既然供应链团队已经计算出来了商品库存的数据，为什么市场部门不直接用，还要从头再计算一遍呢？这个看似很傻的行为，却处处出现在我们日常的数据建设中。而数据中台就是要在整个电商业务形成一个公共数据层，消灭这些跨部门的小数仓，实现数据的复用，所以强调数据只加工一次，不会因为不同的应用场景，不同的部门数据重复加工。那具体来说，如何去做才能实现数据只加工一次呢？有这样五点：

试想一下，现在你构建了数据中台，但存在几万张表，同时又有几十个数据开发维护这些表，如何来确保这些表的管理效率？ 我建议你选择划主题域。我们可以将这几万张表划到不同的主题域中，比如在电商业务中，商品、交易、流量、用户、售后、配送、供应链都可以作为主题域。好的主题域划分，是相对稳定，尽可能地覆盖绝大多数的表。除此之外，还要对表的命名进行规范化统一， 表的名称中最好能够携带表的主题域、业务过程、分层以及分区信息。比如，对于仓储域下的一张入库明细表，规则命名可以这样：

另外，为了实现模型的复用，数据中台适合采用分层的设计方式，常见的分层包括：ODS 原始数据层，DWD 明细数据层，DWS 轻度汇总数据层，ADS/DM 应用数据层 / 数据集市层。最后，数据中台的数据必须尽可能的覆盖所有的业务过程，数据中台中每一层的数据也要尽可能完善，让数据使用者尽可能的使用汇总后的数据。OneData 体系的目标是构建统一的数据规范标准，让数据成为一种资产，而不是成本。资产和成本的差别在于资产是可以沉淀的，是可以被复用的。成本是消耗性质的、是临时的、无法被复用的。

OneService

OneService，数据即服务，强调数据中台中的数据应该是通过 API 接口的方式被访问。这里我想提个问题：为什么数据一定要通过 API 接口的方式被访问，不通过 API 接口，直接提供数据表给用户又存在哪些问题呢？如果你是数据应用开发，当你要开发一个数据产品时，首先要把数据导出到不同的查询引擎上：

数据量小的使用 MySQL；大的可能用到 HBase；需要多维分析的可能需要 Greenplum；实时性要求高的需要用到 Redis；

总的来说，不同的查询引擎，应用开发需要定制不同的访问接口。如果你是一个数据开发，当某个任务无法按时产出，发生异常时，想要了解这个表可能会影响到下游的哪些应用或者报表，但是却发现单纯依赖表与表的血缘无法触及应用，根本无法知道最后的这些表被哪些应用访问。与此同时，当你想下线一张表时，因为不知道谁访问了这张表，无法实施，最终造成了“上线容易，下线难”的窘境。而 API 接口一方面对应用开发屏蔽了底层数据存储，使用统一标准的 API 接口查询数据，提高了数据接入的速度。另一方面，对于数据开发，提高了数据应用的管理效率，建立了表到应用的链路关系。那如何来实现数据服务化呢？

屏蔽异构数据源：数据服务必须要能够支撑类型丰富的查询引擎，满足不同场景下数据的查询需求，常见的有 MySQL、HBase、Greenplum、Redis、Elasticsearch 等。数据网关：要实现包括权限、监控、流控、日志在内的一系列管控能力，哪个应用的哪个页面访问了哪个模型，要做到实时跟踪，如果有一些模型长时间没有被访问，应该予以下线。使用数据的每个应用都应该通过 accesskey 和 secretkey 实现身份认证和接口权限的管理。另外，访问日志可以方便在访问出现问题时，加快排查速度。逻辑模型：从用户的视角出发，屏蔽底层的模型设计的实现，面向用户提供逻辑模型。什么是逻辑模型呢？熟悉数据库的同学应该知道，数据库中有一个视图的概念，视图本身并没有真实的数据，一个视图可以关联一张或者多张表，每次在查询的时候，动态地将不同表的查询结果聚合成视图的查询结果。逻辑模型可以类比视图，它可以帮助应用开发者屏蔽底层的数据物理实现，实现相同粒度的数据构造一个逻辑模型，简化了数据接入的复杂度。性能和稳定性：由于数据服务侵入到用户的访问链路，所以对服务的可用性和性能都有很高的要求，数据服务必须是无状态的，可以做到横向扩展。OneService 体系的目标是提高数据的共享能力，让数据可以被用得好，用得爽。

数据中台支撑技术

我们接着要来讲数据中台的支撑技术，因为一个好用的工具，可以让你的数据中台建设事半功倍。

这个图完整地描述了数据中台支撑技术体系，它的底层是以 Hadoop 为代表的大数据计算、存储基础设施，提供了大数据运行所必须的计算、存储资源。

以 HDFS 为代表的分布式文件系统，以 Yarn/Kubernates 为代表的资源调度系统，以 Hive、Spark、Fink 为代表的分布式计算引擎，都属于基础设施范畴。如果把数据中台比作是一个数据工厂，那可以把它们比作是这个工厂的水、电。

在 Hadoop 之上，浅绿色的部分是原有大数据平台范畴内的工具产品，覆盖了从数据集成、数据开发、数据测试到任务运维的整套工具链产品。同时还包括基础的监控运维系统、权限访问控制系统和项目用户的管理系统。由于涉及多人协作，所以还有一个流程协作与通知中心。

灰色的部分，是数据中台的核心组成部分：数据治理模块。它对应的方法论就是 OneData 体系。以元数据中心为基础，在统一了企业所有数据源的元数据基础上，提供了包括数据地图、数仓设计、数据质量、成本优化以及指标管理在内的 5 个产品，分别对应的就是数据发现、模型、质量、成本和指标的治理。

深绿色的部分是数据服务，它是数据中台的门户，对外提供了统一的数据服务，对应的方法论就是 OneService。数据服务向下提供了应用和表的访问关系，使数据血缘可以延申到数据应用，向上支撑了各种数据应用和服务，所有的系统通过统一的 API 接口获取数据。

在数据服务之上，是面向不同场景的数据产品和应用，包括面向非技术人员的自助取数系统；面向数据开发、分析师的自助分析系统；面向敏捷数据分析场景的 BI 产品；活动直播场景下的大屏系统；以及用户画像相关的标签工厂。这套产品技术支撑体系，覆盖了数据中台建设的整个过程，配合规范化实施，你就可以搭建出一个数据中台，关于具体的细节我会在实现篇中逐一分析讲解，这里你只需要知道这个框架就可以了。

组织架构

如果你要建设数据中台，单纯有方法论和支撑技术还不够，还必须要有一个独立于业务部门的中台团队。

数据中台提供的是一个跨业务部门共享的公共数据能力，所以，承担数据中台建设职责的部门一定是一个独立于业务线的部门。这个部门的负责人应该直接向公司的 CTO 汇报工作，当然这个也要取决于数据中台建设的层次，例如在网易内，有云音乐、严选等多个产品线，数据中台的建设层次是在产品级别的，也就是说，云音乐有一个数据中台，严选有一个数据中台，所以严选的数据中台应该向严选的 CTO 汇报。而独立部门的最大风险是与业务脱节，所以我们对数据中台的组织定位是：懂业务，能够深入业务，扎根业务。数据中台要管理所有的指标，而每个业务线之间的指标既有差异，也有交叉，要理解指标的口径定义，就必须要了解业务的过程。同时，当我们要制定一些新的指标时，必须要了解各个业务线新的业务目标，指标的本质还是为业务目标服务的。综合来讲，什么样的组织架构是适合数据中台建设的呢？

数据产品部门：负责数据中台、数据产品的体系规划、产品设计、规范制定、应用效果跟进，指标口径的定义和维护（有的部门是由分析师管理）。

数据平台部门：负责研发支撑数据中台构建的产品，例如指标系统、元数据中心、数据地图等。

数据开发团队：负责维护数据中台的公共数据层，满足数据产品制定的数据需求。

应用开发团队：负责开发数据应用产品，比如报表系统、电商中的供应链系统、高层看板、经营分析。

而且，中台组织的绩效目标一定是要与业务落地价值绑定的，比如在电商中，我们提供了供应链决策系统，有智能补货的功能，会根据商品的库存，各个地区的历史销售情况，生产加工周期，自动生成补货决策，由人工审核以后，直接推送给采购系统。那我们评估价值时，我们会拿由系统自动生成的采购计划占整体采购计划的比例来衡量数据的应用价值。最后，数据中台的组织架构改革涉及原有各个部门的利益，所以这个是数据中台构建最难又不得不做的地方，必须要取得高层领导的支持和重视。

总结

以后关于数据中台系列的总结大部分来自Geek Time的课件，大家可以自行关键字搜索。