不知道大家对数据中台这块了解多少，今年数据中台这个概念又火起来了，大家可能会想要了解一下这个东西是什么。比如，菜鸟的数据中台是什么？菜鸟数据中台的整个技术演进？阿里也在前段时间的云栖大会上发布了阿里数据中台，那阿里数据中台和菜鸟数据中台有什么关系，有什么区别？还有菜鸟是怎么做数据中台的，怎么去考核数据中台，等等这些问题。

今天我的分享就是围绕着以上问题。整体会分成三块来讲，一个是概述篇，对阿里生态中台演进、数据中台、菜鸟数据中台做一个简单的概述，方便大家理解一下数据中台到底是个什么东西。第二个是技术演进篇，这部分会回到我们真正的技术这一块去讲整个数据中台的技术演进。最后一部分是一个简单的移动数据运营的示例，一个我们对外的场景。

中台概念

2015 年，阿里启动了中台战略。中台这个词提了这么多年，它到底是什么？

首先，中台是一种经营理念。从整个公司管理来说，这种经营理念就是我利用中台的思想去提升整个公司的组织效率、协同效率和运营效率；中台也是一种组织形式，它不是说我技术业务拉到一起，画个架构图就行了，它其实需要组织架构来保障。

中台火了之后，各种各样的中台就涌现出来了，很神奇。

之所以一夜之间冒出这么多中台，是因为中台其实是“平台思维”的自然演进。今天很多的中台都是之前的一些平台化的东西的升级版，升级后给了它一个新的一个概念，叫中台。当然，它跟平台是有差别的。

我们理解的整个中台其实有三个特点：

• 第一，沉淀，除了要完成业务系统开发、业务场景的开发，做技术要有沉淀的东西，去体现出我的技术能力和价值。

• 第二，提升效率，这个很容易理解。

• 第三，降低创新成本，当你有了中台，你的很多能力沉淀起来了之后，你可以很方便地去做前台的业务创新。比如说有某个 App 火起来了，我们可以很快就做出一个竞对的 App，因为底层的能力都是现成的，我可以很方便地就把 App 做出来。当然，如果你不具备业务中台能力，其实没有必要一定要去提中台，业务内自己运行效率才是最高的。

中台演进历程

下面来讲一下阿里的业务中台、数据中台、菜鸟中台的演进过程。

阿里早期，各个业务线，各个事业群相对独立，自己玩自己的，底层的中间件到上层业务系统，大家会有一定的重复建设。后来开始有一个共享事业部，把整个阿里生态内所有的技术中间件给收掉了，可以看作是一个平台。

再到 2015 年，阿里提出了中台战略，就有了业务中台，比如说淘宝和天猫里面都涉及到交易、会员和支付，这些东西我们往业务中台里去沉，慢慢就变成了阿里说的“大中台小前台”。这是业务中台这一块。

数据中台其实也是一样。从最开始各个事业群自己建设，到横向的“数据技术产品”、到今天的数据中台，阿里的数据中台这样一步一步变成今天的样子。

我们可以看到，不管是业务中台还是数据中台，前面都有一个平台阶段。

那菜鸟的数据中台是什么？

菜鸟数据中台跟阿里数据中台稍有差异。因为菜鸟成立的时间要晚一些，在那个时间点，平台化的思想在整个阿里生态体系内已经非常成熟了，大家对于这个东西的认可度非常高。

所以菜鸟数据最开始做的时候就是“平台产品“+“数仓“用于支撑上面各业务线的数据化运营场景。今年我们提数据中台，是希望将沉淀的的能力（数据、资产、服务、解决方案）以中台的形式去开放赋能到生态中。

这是我们从整个阿里生态内去看中台这块的一个演进的情况。

我稍微展开讲一下阿里的数据中台。阿里数据中台有一个官网，大家去网上搜一下应该就能找到。阿里数据中台是把数据中台分成了三块：方法论、组织、工具。

方法论是什么？

其实可能很多人都听过，比如阿里经常讲的全域数据，背后是一系列在做数据化运营过程当中沉淀出来的一些方法论。

如 OneID，就是我去拉通去看，我们把所有的消费者或者是把所有的商家的数据合到一起，我们去打造一个全域数据。如 OneModel，数据建设了这么多年，沉淀的一套数据建设方法论。还有 OneService，是再数据向上使用的时候，一套工具和方法论。

组织是什么？

组织结构上来说跟业务中台的差别，业务中台可能都是做技术的，数据中台里面有数据开发的人员、产品经理，还有产品开发的同学等等，可能还有其他一些细分的工种，构成了整个中台的一个组织。

最后是工具。

所有的理念需要变成具象的东西，可操作的东西，需要通过工具去承载。

这是整个阿里数据中台。

再下来讲讲我们菜鸟数据中台。

菜鸟数据平台，我们给它起了个名字叫 CBD，不是大家熟知的城市中的 CBD（中央商业区）。C 是 Cainiao，B 是 Best，D 是 Data。合起来就是我们把我们认为菜鸟最好的数据放在这个地方，提供给大家去用。

顺便讲一个问题，就是数据中台怎么去衡量它？首先中台一定要有前台的场景来去使用它，一定要被集成的。为了看我们数据中台建设是好还是坏，我们定了三个 KPI 来量化：

• 第一，数仓的核心表有多少，这个很直观，你说你是数据中台，结果就三五张表，谈什么数据中台。

• 第二，累计接入应用数，接入应用数是在衡量今天你的数据中台有多少应用集成了你，有多少应用接入了你，这个其实是在标识我们中台到底有没有在发挥价值。

• 第三个是服务调用，数据好像有一百个应用接了，但其实一天就调个 10 万次，这有什么意义呢？调用次数其实也是衡量整个数据中台价值的一个核心的指标。

背景

接下来讲讲菜鸟数据中台，为什么我们要做菜鸟数据中台？

我前面讲过，菜鸟数据中台在最开始的时候，就是平台化的思维，“平台产品“加上“数仓“来去支撑菜鸟各个业务线的数据化运营工作，有数据平台的搭建，数据产品的开发 等。

我们为什么要往中台升级？我认为大概有三个出发点或背景，第一升级，第二效率，第三协同。

第一，升级。怎么理解？从 2015 年甚至更早的时间到今天，我们的体系化和数据都有了很多沉淀，工具化体系化已经非常完备。对于我们自己而言需要有新的突破，所以从内部来说，我们需要有这么一个新的升级。

第二，效率。这是从菜鸟整个业务来看的。不知道大家对菜鸟了解有多少，可能有些人觉得是个快递公司，是个物流公司，是不是就送个包裹？

不是那样，大家把它想得有点简单。大家可以在菜鸟官网上看，其实我们的业务线非常多，十个左右，这还是还比较大的业务线。这么多业务线，只靠今天的数据部去支撑，有些场景是覆盖不到的。一些业务线或者是相对没有那么重要的场景下面，他们也有数据化运营、数据分析的需求。所以其实我们是希望能够把我们的沉淀以中台的形式开放出来，让他们去集成使用，从而提升整个菜鸟的数字化运营效率。

第三，协同。协同怎么理解？这里我要提一下菜鸟的使命，全国 24 小时必达，全球 72 小时必达。大家看起来只是一个数字，背后是包裹经过了一系列的物流网络，一系列的物流节点最终送达到了你的手里，比如说分拨、网点，国际还有很多干线、海关等等很多的环节。

为了达到 24 小时，72 小时，需要整个物流网络非常高效。高效是从哪来的？就是今天我们希望通过数智化的手段来去提升整个物流网络的运营效率。

在这个过程当中，菜鸟自己的数据化运营做得很好，但是能不能达到 24 小时、72 小时，还需要跟很多菜鸟的合作伙伴，菜鸟生态公司一起来提升整个物流网络的效率。所以这里有一个协同，我们希望把我们的数据、工具、方法论能够给到大家，然后共同提升整个物流网络的效率。

以上菜鸟数据中台建设的背景。

内容

这是菜鸟数据中台的一张简图，下面是中台，上面是前台。

数据中台里面又分成四块内容：数据，服务，解决方案和心智。

最基础的就是数据，包含数据中心和数据服务。数据中心很容易理解，那数据服务怎么理解？我们沉淀了一些重要的全域数据之后，把它服务化，别人想用的时候可以很便捷地把它拿到自己的业务系统里面去调用，所以服务化简单理解就是一个 RPC 服务。

再往上是解决方案。解决方案我们又细分成了两块，一个叫数据智能解决方案，另外一个叫业务数据解决方案。

数据智能是说今天我们生产了这么多的数据，不管你是要去做一个数据平台，还是把数据拿到业务系统里面做业务决策，或是用来做风控，在众多场景应用的过程当中，其实需要一系列的工具和平台去支撑，我们把这个东西统称为“数据智能解决方案“。

还有一块业务数据解决方案，就是数据围绕某个特定的业务场景，通过工具化的形式也好，通过数据输出的形式也好，我们为解决一个切切实实的业务问题来打造的解决方案。比如说你的一个包裹从一个仓出库了，我需要找一条线路送达到你，哪条线路时效是最快的，哪条线路成本是最低的。这个时候就需要数据的支撑，可以根据历史上每条线路，哪条最快，出风险的概率是多少等等，做一个判断，最终选一个最优解。这就是围绕一些业务场景去做的一些解决方案。

还有一块是什么呢？你说你有数据中台，但是谁知道你有数据中台，谁知道你的数据中台有什么内容？

我们数据中台有一块专门处理这些问题，叫中台心智。中台心智简单理解是一个偏运营的工作，我把建设完的数据、做出来那些工具解决方案，通过定期邮件也好，通过培训也好，告诉大家我们中台有这么多内容，我们这个数据能做这些事情，希望大家可以跟我多发生一些连接。

这里不仅仅是一个运营，我告诉你我们有什么，其实也是在量化我的价值，拓展我们数据的价值。所以数据中台的心智也是很重要的一块。

概述

最后对菜鸟数据中台做一个概述：

菜鸟数据中台是什么？仅仅是数据、服务、解决方案这些就够了吗？

不够。

我一直在说组织架构，整个中台的团队，当这些东西合在一起才是整个菜鸟数据中台，才是我们的 CBD，通过这个东西我们去支撑菜鸟，去支撑生态公司，去做生态协同，还有我们内部的数智化运营，数据创新。

小结

这里简单做个小结。首先这里有很多概念性的东西，中台是什么？中台是一种经营理念，是一种组织形式，是平台产品或平台思维的自然演进。然后是阿里数据中台，它是方法论 + 组织 + 工具。菜鸟数据中台是数据 + 服务 + 解决方案 + 中台。

看到这里大家可能产生了新的问题，菜鸟数据中台和阿里数据中台怎么不一样，你们不是一个生态体系吗？怎么又搞出两个概念出来呢？

其实它们本质上是一样的东西。只是比如说我们说的一些服务解决方案，其实映射的就是阿里数据中台讲的方法论和工具，而它的组织对应的就是我们的中台团队。本质上其实是一样的，只是在不同的场景下，我们面临着不同的问题，讲法可能稍微会有些差异。

接下来讲讲整个数据中台的技术演进，从 2015 年到现在我们做的一些事情。

先看一张整体技术架构图，分三层，底层是基础设施，基础平台，中间是中台，上面是前台。

有些同学可能会有困惑“数据中台和大数据平台”的区别是什么？图中的基础平台就是我们过去常说的大数据平台，包含了数据的采集、计算、加工等。阿里内部是 ODPS，Blink；开源有 Spark、Hadoop 等等。数据中台是构建在整个大数据平台之上的，它是围绕数据运营、分析、应用等场景去做的一套解决方案。

数据中台分成两块，一个是数据层，一个是服务层。

数据层就是我前面说的“数仓“，这里边包含菜鸟的所有数据，沉淀的数据资产。再往上是服务层，这里划分成了几个套件，每个套件都是围绕数据使用的一个场景做的解决方案 / 工具。先不展开，稍后我会分开细讲。

旁边纵向的东西是数据管理套件，从数据的加工生产到使用，它从全链路的视角把数据给管理起来。

先讲讲数据运营。我们提数据平台、数据仓库，要解决的问题就数据化运营的问题。数据最基础的应用形式就是看板 / 报表，这是 2015 年我们开始做中台的时候面临的最重要的问题。当然，那个时候还没有提中台的概念。

当时我们大概有好几个研发同学，每天写数据服务向上提供接口到前端，前端通过可视化组件做个渲染，开发一堆的报表出来。这不是个很复杂的业务，没有什么业务逻辑，不需要领域架构，不需要划分域，不用搞领域建模那套重的东西。就简单把数据取出来，然后提供接口给前端，前端做个展示，这么简单的东西，研发人员的价值怎么体现？

所以我们就去做了整个数据运营套件。大家做数据化运营的过程当中，一定会有一个门户网站 / 产品，或者说数据平台，你进去之后能看到跟业务相关的所有的数据，能基于这些数据去做分析决策。里面最核心的就是站点以及看板，这个套件也是围绕这两块去建设。

站点搭建的部分我就不细讲了，主要就是账号体系、权限体系和站点配置管理这些东西。

看板搭建这块我稍微展开讲一下。看板本质上就是把所需数据以一种可视化的形式展现出来。这里面我们把它分成两块，数据服务 / 数据集 负责把数据取出来，看板配置负责把数据展示出来。看板又细分为 分析看板、数据大屏、指标看板和移动看板 几种形式。

• 分析看板：结构通常是上面是几个大的指标，反映整个业务的情况；中间可能有一些预警的东西，哪个指标有异常，是因为什么原因导致的，细分 / 下钻维度的情况；下面可能是一些明细数据。这种分析看板相对比较固定，如果有灵活分析需求，还有一种形式，把多维的宽表，放在 OLAP 引擎里，看板可以自由选择分析纬度、下钻、上卷等。

• 大屏看板：双十一的时候经常有各种各样的媒体大屏，我们内部其实也会在各个指挥室做各种各样的数据大屏。

• 指标看板：这是一套围绕业务做的定制化解决方案。当你去做一条业务的时候，最核心的是什么？你怎么去看待业务做得好还是坏？你的业务的指标体系是什么？这些核心指标可以在指标看板里体现。

• 移动看板：为移动端制作的看板，满足移动办公需求。

站点搭建和看板搭建构成了数据运营套件。经过几年，我们所有的研发已经全部从看板开发工作当中释放出来了，现在都是分析师自己基于这套工具去搭他想要的数据运营站点。

到了 2016 年的时候，其实菜鸟已经建设了很多的数据，这些数据不仅仅可以用来搭看板，其实很多业务系统也需要基于数据做风控或者业务决策等。

现在分布式微服务架构这么成熟，数据最简单提供服务的方式其实就是写个 SQL 把数据查出来，包一个服务化的接口暴露出去。这种方式有个很大的弊端，数据的管控会非常难：我很难知道你把我的服务接口用在了哪个产品和哪个场景，而且在有些场景下，我的数据甚至不是以服务化的方式给你的，而是放到一张 DB 里面，我完全不知道我的数据被谁用了，我也不知道我开放出去了多少数据，调用情况怎么样，整个链路管控起来会非常难，针对这个问题，我们做了数据服务套件。所有数据都是放在自己的存储里，以统一服务化的方式给到需求方，需求方直接对接一个标准化的服务就可以了，不用关心底层的存储。

第二个问题是效率会非常低。数据量小的情况下 MySQL 就能支持简单的分析；数据到了亿级别，百亿、千亿级别，MySQL 搞不定了，这个时候会引入 OLAP 引擎 ，开源的有很多，这里就不例举了，我们内部使用的是 ADB，阿里云上也有这个产品。另外有些场景中，数据是 KV 形式，做大数据的都知道 HBase，高吞吐，但 HBase 是不支持 SQL 查询的（最新版本可以通过 Apache Phoenix），你需要通过 SDK 去操作它，而且它是 free  schema 的，连个表结构都没有，可能每一行的数据结构都有差异。每一个应用去接这些数据的时候都要去了解这么多的存储、SDK，学习成本高、效率低下。

围绕这两个问题，我们做了统一数据服务平台，它解决了几个核心问题：

• 第一，统一之后整个管控的问题就解决掉了，我知道我的数据在哪里，数据被谁用了，被调用了多少次。

• 第二，我们做了一套  Engine，通过 SQL 统一去查询背后的所有数据。简单一点讲，就是你一写完一个 SQL，我通过 SQL Parser 解析成 AST 之后，把里边所有原信息拿出来，我就知道你是在查哪张表，哪个字段，你的条件是什么， 我会通过你写的 SQL 去做解析，去转换成 NoSQL（HBase） 的 SDK。再比如内部有个产品叫 Tair，是一个内存缓存的中间件，基于 SQL 标准化之后，整个效率提升得非常快。现在写一个数据服务接口，只要逻辑比较清楚，分钟级就能完成一个数据服务接口，别人可以通过 HCF 或者是 HTTP 的形式来调用。

​

里边还有几个特性，比如跨源 Join，单元化部署，本地模式。下面稍晚展开讲一下跨源 Join。有些场景下，流计算的数据，它的数据写入的 TPS 非常高，通常是放 NoSQL，另外有部分业务数据在 MySQL 里边，业务场景需要 2 个数据 结合起来展示，即跨源去做 join。实现的方案是，SQL 解析完之后，如果是跨 DB 的查询，会把它拆分成多个 DB 查询的执行计划，各 DB 查完后再在内存中做一个内存的 Join 以及聚合计算。这里考虑稳定性结合场景，我们会限定各 DB 的返回行数。

现在整个数据服务，每周的调用量大概在亿级别，每天几千万，根据不同的场景提供 SLA。最高级别可以做到业务核心链路中。举个具体的业务场景，人在香港通过天猫国际下单，通过商品的一些重量数据，动态计算运费，背后的重量测试服务，就是通过数据服务提供的。这是绝大部分数据服务解决方案达不到的。

2016 年，数据服务这块也做得挺好之后，一个新的挑战来了，随着数据看板增多，同样的一个指标，比如说物流订单量，都叫这个名字，在不同的页面里，展示的数值有差别，一个页面可能是 10000，另一个可能是 10010（纯假设）。用户（分析师、运营......）一看，这两个值对不上，你们这个数据不准。其实背后是指标口径有细微的差异。我们考虑去做整个数据协同的解决方案。

整个解决方案大概是这样的，最核心的是中间的指标管理，分析师、业务运营，去指标管理系统里面，把指标体系和口径管理起来，然后需求提给数据开发的同学，数据开发的同学接到需求之后，根据数据口径把数据开发完，再把这个数据关联回指标上面。分析师、业务运营同学，就可以基于前面的工具去搭他的看板。这样的话，看板上面展示的每个指标，我都能知道这个指标清晰的口径是什么。这解决了数据协同的问题。

另外还有一个问题，我们有了这么多的看板，很多的数据，它们的生命周期如何管理？就像开发人员经常会接手一些遗留系统，需要有监控来告诉我，系统还有谁在访问？访问了什么？访问了多少次，我才能决定这些系统的未来。数据也是一样，我们需要知道数据在哪里？数据用在了哪里？哪些人在用？

所以我们做了整个数据的全链路追踪：

• 第一，ODPS 也好，Blink 也好，对于我们本身数据的生产计算这块的东西，我们自身是有元数据的，我可以知道我有生产了多少数据，花了多少成本。

• 第二，前面提到的数据服务，能提供数据放在了哪些存储里面，被哪个系统调用了，被集成了多少次。

• 第三，通过数据运营套件，能知道数据是在哪个看板上，看板被谁访问了，访问了多少次，什么时间访问的。基于全链路跟踪，就可以解决数据生命周期闭环的问题。可以基于这套链路发现哪些数据是没在用的，哪些看板是没在用的，可以把它下掉。可以量化数据的价值，数据今天在哪个看板里被某个总裁看到了，这个总裁天天看这个的数据。

再下来到了 2017 年，看板越来越多，但在一些场景下（比如：大促），不能天天盯着这么多的看板。我们在想是不是可以把这个模式稍微做一个转变，过去都是人找数据，今天我们把它反过来，变成数据找人。当这个数据可能异常的时候，可以把预警或者一些看板推送给相关人，请相关人进行关注。

这套理念和监控系统的理念差不多，大家都知道监控系统， CPU 超 80% 或者多少了报个警，概念比较类似。我们把那套理念套到了数据运营这个场景里面去。

里面有个触发器，它可以是定时的，也可以基于数据去做一些判断，比如说同行比超出多少等等。还有个信息卡，我们在信息卡这块做了很多工作，比如说图中的信息卡，它可以是一段文字，可以是个图表，可以是跟它相关联的一些指标，最终这些元素构成了一整个信息卡，然后通过钉钉去推给你。阿里内部所有人办公都是用钉钉的，我们所有的消息都会通过钉钉去触达，触达率其实远高于传统的邮件。

差不多接近尾声了。因为篇幅的原因，我没法去把所有的每一个套件都展开去讲。整理了一个时间线，从 2015 年到现在，虽然是按时间线讲的，但是每年基本都是很多事情一起在做的。

最后讲讲我们在做数据中台过程当中，对架构的一个思考。虽然我们没有那么复杂的业务、不是在线业务系统、不需要领域建模、但还是有一些自己的思考。

在做技术中台过程中，我们总结出了一个 2D 原则。

第一个叫 DIP+。

搞技术应该都懂 DIP，为什么提 DIP 呢？因为今天我们把数据中台输出给我们的生态公司以及合作伙伴的时候，他们不可能把他们的系统部署在阿里内部，他一定是在云上，这个过程当中就会遇到一个什么问题？

同样一个工具，自己内部使用，我要去维护一套代码，这个客户在云上使用，因为中间价的差异，难道我又要维护一套代码？这个成本也太高了。

于是我们通过 DIP 的依赖倒置把基础设施给隔离开。所有套件都关心核心逻辑，而在具体场景里边，我通过基础设施的一个插件来解决具体场景依赖问题，这样就可以一套代码解决不同环境部署问题。

那为什么叫 DIP+ 呢？我们在不同的场景里面，它的功能可能是有差异化的，但是我们去做能力建设的时候，不希望做那么多版本出来，所以对于我们而言，能力在不同的场景里面，通过配置或开关来去解决不同场景下的一个诉求。

第二个叫 DLCF。我们在中台一直在说要被集成，怎么集成？

• 有些场景定制化程度非常高，中台能力不具备，要定制化帮他去开发，定制化去对接。

• 有些其实能力差不多，但需要一些简单的插件，或者简单写一些脚本。这叫低代码。

• 它通过简单的配置，就能把我们整个的套件集成进去。最后就是开箱即用。

我为什么没有在这张图上把它画在一起，而是阶梯型，一个个慢慢往上走？因为我觉得这个东西也在衡量中台的成熟度，当你始终都是在做定制化开发的话，我觉得这个中台的技术成熟度是很低的。当你如果基本上做到了大部分都配置开发，那你的中台成熟度是相对比较高的。

小结一下，技术演进这部分里面，我们讲了数据运营套件、数据服务套件、数据管理套件和智能推送套件，最后介绍了一个 2D 原则。

这是一张简单图，是我们在提了中台概念之后帮我们的一些生态公司，或者是我们合作伙伴做的移动端的一个驾驶舱，方便他们随时在钉钉端就可以看到业务的情况。

我的分享就到这里，希望对大家有用，谢谢大家。