菜鸟数据中台技术演进之路

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

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

概述篇阿里生态中台演进 中台概念

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 原则

最后讲讲咱们在作数据中台过程中，对架构的一个思考。虽然咱们没有那么复杂的业务、不是在线业务系统、不须要领域建模、但仍是有一些本身的思考。

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

第一个叫 DIP+。搞技术应该都懂 DIP，为何提 DIP 呢？由于今天咱们把数据中台输出给咱们的生态公司以及合做伙伴的时候，他们不可能把他们的系统部署在阿里内部，他必定是在云上，这个过程中就会遇到一个什么问题？一样一个工具，本身内部使用，我要去维护一套代码，这个客户在云上使用，由于中间价的差别，难道我又要维护一套代码？这个成本也过高了。因而咱们经过 DIP 的依赖倒置把基础设施给隔离开。全部套件都关心核心逻辑，而在具体场景里边，我经过基础设施的一个插件来解决具体场景依赖问题，这样就能够一套代码解决不一样环境部署问题。那为何叫 DIP+ 呢？咱们在不一样的场景里面，它的功能多是有差别化的，可是咱们去作能力建设的时候，不但愿作那么多版本出来，因此对于咱们而言，能力在不一样的场景里面，经过配置或开关来去解决不一样场景下的一个诉求。

第二个叫 DLCF。咱们在中台一直在说要被集成，怎么集成？第一，有些场景定制化程度很是高，中台能力不具有，要定制化帮他去开发，定制化去对接。第二，有些其实能力差很少，但须要一些简单的插件，或者简单写一些脚本。这叫低代码。第三，它经过简单的配置，就能把咱们整个的套件集成进去。最后就是开箱即用。

我为何没有在这张图上把它画在一块儿，而是阶梯型，一个慢慢往上走，由于我以为这个东西也在衡量中台的成熟度，当你始终都是在作定制化开发的话，我以为这个中台的技术成熟度是很低的。当你若是基本上作到了大部分都配置开发，那你的中台成熟度是相对比较高的。

小结

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

场景篇移动数据运营

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

个人分享就到这里，但愿对你们有用，谢谢你们。