有别于 BATJ，滴滴的中台数据体系建设怎么另辟蹊径？

本文由 dbaplus 社群授权转载。

前年阿里开始讲数据中台业务，去年以来这个概念很火直到最近。我在阿里待了 10 年的时间，也参与了中台建设，今天想跟大家分享一下背后的逻辑，还有我在滴滴的实践，以及中台本质的问题是什么。

今天我的题目叫做“精益生产与敏捷创新”，任何一个中台，不管是技术中台、AI 中台，本质上为了更好支撑业务，让业务能够更好的去把用户价值做出来。从技术角度来讲创造价值的核心就是两点：

• 保证稳定且持续的研发生产持续输出既有价值；

• 在生产过程中去找到可以改进的地方，找到新的创新点，创造更大的新价值。

一、滴滴数据中台发展

看几组数据，这几组数据看起来挺大的，但目的不是为了吹牛逼，目的是为了讲这个东西。

其实滴滴也好，阿里巴巴也好，这些大公司数据都经历了四个阶段，每个阶段有不同的挑战，相信在座的同学不同公司也处于不同的阶段，或者说有可能也走到了这四个阶段的下一次循环。

1、业务发展驱动数据进化

1）业务信息化

其实滴滴很幸运，正好赶上了移动互联网那一波，把个人的位置信息进行信息化了，同时智能手机价格急剧下降，从四五千到几百块钱，任何一个群体都能买到智能手机，最大的核心变革是什么？你的位置与状态随时随地都在线，这就是完成了第一个核心业务的核心化，滴滴赶上了这波一飞冲天。

2）信息数据化

第二波当业务构建起来各个地方有数据被记录下来，如果 10 多年前有同学在做数据，当时肯定会去跟 DBA 吵，你这个数据量太大了，DBA 肯定会说：你删数据吧。因为以前很多的数据是存在数据库里面的，而从 2006 年开始从记录事务本身到记录过程。

这个背后的核心是什么？背后是逻辑范式的变化，因为有了互联网。互联网之前所有的交流、互动其实是中心节点下面有很多小节点单独跟他沟通。比如说我去和银行办业务，我去打电话给某一个人都是这样子的，最多一对 N，互相之间是没有别的互动，去银行办各种业务，顾客间是没有互动的。

但是有了互联网之后，所有的节点之间是可以被连通的，所有的节点是可以被连接的，所有的信息从记录的节点上变成了这个信息是记录到边上，这种范式变成了什么呢？数据的量巨大膨胀，这个时候面临最大的问题是算不动存不了，包括我们在讲很多的实时计算也是一样的道理，随着我们的业务发展、人是需要实时进行反馈，那就意味着实时计算需要的计算能力和存储能力变成更大的问题，当信息变成数据化之后一定会有这样的情况。

当有更多的数据被记录下来的时候，数据不再仅仅是 BI，意味着每个人开始去用数据，每个人用的数据很有可能自己产生的结果，同时是别人的输入，这个时候就意味着一张公司里的数据网开始在编制起来，或者说最简单的数据链条在编制起来。

这个时候会出现很多扯皮的事情了，上游说自己解决自己问题，数据的问题是自己用的，为什么要给你用？你依赖我的数据就依赖，出问题我不负责。被依赖很多上游说要改一个东西，下游说不能改，你改了，所有的代码也得改。

上游说不改怎么行呢，上面的业务要变。这个时候数据用的越多，扯皮事情就越来越多，为什么会扯皮呢？不是大家什么有问题，而是公司里面没有数据的文化，我们核心判断这件事情谁对谁错的价值观，背后唯一判断标准是什么呢？很多公司是没有的，因为数据越多，产生出来的各种扯皮就出现了。

3）数据资产化

这样就到第三个阶段，每个地方都有大量的数据，每个业务都在消费大量的数据，广告业务、运营、财务、现在还有越来越多的算法、人工智能，各个地方都在用数据，每个部门都有数据，每个部门都有自己的数据团队，这个时候开始烟囱林立。

有些时候数据在一个地方用的好，可能在别的地方用的不好。当年在阿里的时候，2012 年左右的时候最大的问题，怎么把消费者的数据打通。因为不同的业务环节里面同一个消费者 ID 可能都不一样，到滴滴后来也面临同样的问题，快车、顺风车、出租车快速的发展，从来没有考虑过数据打通问题。每个部门都觉得数据是自己的私产，我对这个数据质量保证只为自己负责。数据资产从公司角度来讲它是没有被盘点的，只在点上产生价值。

在滴滴我们是面临强监管的公司，可能在别的公司大家没有受到这么强的监管。所以数据本身的安全合规对于我们讲是非常重要的事情，还好 2017 年加入到滴滴，对这件事情的重视程度比较高，第一个解决了隐私数据的处理，第二个数据分级管控，第三个数据的安全打标，还有关键的权限管理。最近我跑的公司也比较多，发现做一些互联网金融类的公司内部的数据都没有做权限管理，这是非常恐怖的一件事情。第三个一定得有对应的安全合规管控，这样公司才能走的长久，不然数据做的越大，很有可能就成为公司归零的大风险。

第三个是数据资产面临一个问题，可能这个资产在很久之前很多咨询公司会讲一个东西叫做数据治理，包括像最近的 G20 各个政府的首脑也提到这个问题，数据越来越重要，数据需要流动起来才能产生价值，如果不把它标准化好，数据的价值是很难打通的。

但是我们可以发现很多的企业去做数据治理的时候，这个项目都是无疾而终，或者做了项目很好，但是用着用着这个数据又不行了，不得不过一段时间又提一个大项目劳民伤财来去做这件事情，背后本质上的问题是什么呢？为什么数据治理这件事情这么困难，投入这么大资金去做，但是产出却很少，而且数据是越治一会儿又难用了，能不能让这个数据越用越好用呢？我们发现背后还是一些本质上的东西去用的。

我们都在讲用大数据去赋能别人，大数据去做广告，大数据去赋能 AI，让 AI 更高效解决各种问题。但我们有没有想过我们用数据能治理自己本身呢？这也是我们当时的思考，我们重要核心问题在数据资产化这个阶段要解决两个问题：数据质量混乱的问题；另外一个，高投入低产出问题，我好像做了标准化的事情，做了治理的事情，好像不太管用。

最后，当数据梳理通顺了，这个资产在公司里面流动起来，大概在 2018 年左右滴滴所有的数据在内部都是开放的，当然是分等级的，需要走相应的合规申请流程，每一个人经过相应的安全申请都能获得所有的数据，相应的合规数据都能做查询、分析，甚至做研发。

4）资产变现化

这样的情况我们作用到第四个阶段，怎么样把数据的价值最大化？怎么样变现？现在我们来看一下主要三个方面，一个是赋能人，让数据的门槛下降，让每一个人都能把数据用起来，这是我们背后非常难的理念，在座各位很多都在做各种各样数据产品，有的是面向于工程师，有的面向分析师，但我们希望是整个数据平台体系能让公司所有的人在他需要的时候把数据用起来，把数据做到平民化。

第二个现在越来越多系统应用是数据密集型的，再往下一步走是数据智能化的，需要有算法、规则、数据来反馈这样的应用系统，数据必须把它服务化，去和前台的业务集成打通。

第三个滴滴是一个非常依赖数据的公司，后面我会讲为什么，绝大部分业务是靠算法来去驱动的，所以算法需要的大量特征本质上就是来源于中台数据再次加工，怎么能够更好赋能 AI？这也是变现里面第三个难题。

滴滴究竟在数据方面和传统的互联网或者说 BATJ 这样的公司有什么样的不同？左边这个图是工业领域常用的东西叫做资源投入和业务价值产出的微笑曲线，当一个公司在两头进行投入，同样投入产出会更高，公司在研发、实验、营销、运营。其实，前面的很多同学分享都提到这一点，我们去做营销投入一块钱到工程师那儿，我们能通过广告收回来多少钱。

即便没有广告平台，投入到自己的营销上面拉了更多新客也会赚更多的钱，投入到研发也会让产品竞争力更高，赚更多的钱。但滴滴有点不一样，我们除了在研发实验投入资源产出的效益很高之外，我们在营销领域产出并不高，我们更多是要把它投入到生产领域。

在日本精益思想里面，他们说了日本企业和中国企业最大的区别是什么？中国企业只知道在微笑的两端引进新技术获得增长，但不知道把中间这块进行更好的管理，把微笑曲线变成武藏曲线。这是一家日本企业都能活的很好很久的原因，他们把曲线拉的更平，从研发、实验、生产、运营、营销各个环节都能做到很好的竞争力。

为什么滴滴微笑曲线会是这样呢？任何一家大型互联网公司本质上是这两个商业模型的内核双轮驱动，网络效应和数据智能，而且往往是网络效应是大于数据智能，但是滴滴却是反着的，本身这个平台没有太大的网络效应，乘客与乘客之间是不互动的，司机与司机也是不互动的，司机和乘客之间的连接是靠当时的时刻和那个时间节点上空间正好能匹配，系统硬拉在一起的，我们没有太多的网络效应，我们只有规模效应，乘客越多可能会吸引司机一下，司机说你这儿好拉活。司机越多可能会吸引乘客一下，这块我打车的概率也高一点，但本质上这个护城河很低。

我们在这儿是没有商业模式护城河，唯一一个护城河是来自于数据智能，怎么样通过更好的算法找到更好的匹配，怎么去做供需的预测，怎么去做调度，怎么去做时间的分配，怎么去鼓励司机在什么样的情况下往哪个方向去走，我们在每一个出行环节里面我们都需要用数据进去结合起相应的算法，把这个效率做到最高，所以从这个角度来讲在滴滴去做数据平台或者做数据中后台工作压力非常大的。因为整个公司的护城河是依赖数据的，网络效应在我们这儿是大大缩小。

2、中台数据体系建设的核心困难

我们再看一下为什么在滴滴中台数据体系建设这么困难？数据其实是要在两条价值线上去发挥价值，第一个每天日常生产价值线，每天业务要保障正常运转，要从一个状态变到另一个状态，用户进来要从一个业务做完，要稳定的生产，让我们客户能打到车，这里面很多的算法通过数据，生产加工到最后产生价值。

这里面随时随地在提三个词，质量、效率、成本，因为我们没有大规模的网络效应，我们依赖网络效应去做创新的空间没有那么大，我们只能在各个业务的环节，用数据去发现这样的效率增加的地方，或者在里面去做模式的挖掘。

这样对于数据来去驱动创新的压力更大了，我们可能不像抖音，或者是说不像淘宝，我们可以做一个消费者靠主观感受发现有哪些模式可以把网络效应激发出来，对于我们来讲必须用数据看整个滴滴出行网络里面有些什么样的模式，有些什么样的问题，有些什么样关联的情况能够被我们发现出来，有哪些 idea 去做实验，一堆筛选以后找到一个真正产生正价值的 idea。

每个这样的想法要通过大量的数据分析、数据驱动的方式，才能最终融入到数据生产价值线来。这个时候对于数据平台团队来讲意味着很纠结了，一条线要求稳定。另外一条线要求数据质量高情况下还要快速，必须得尽快把相应的数据支援到我，你希望把很多没有稳定下的数据业务背后的数据支援到我，这是非常困难的一件事情。

因为滴滴把竞争力放在了数据智能这块，意味着我们是互联企业里面对于数据场景使用最多的一个企业了，总结了一下大概有 13 个主要数据使用场景，从最简单的看报表、临时分析、做对比，再去做相应的聚类分析，再去做模式挖掘，再去做算法、人工智能驱动，每一个环节需要大量的数据和平台支撑它。

另外，用的场景越多，涉及到的链路越复杂，这个背后代表的是团队，大家知道了人多了就有江湖，有了江湖很多事情就很麻烦，组织上我们会面临巨大的困难。两个不同的目标，这么多的场景，这么多的组织在一起，这是我们需要支撑 6 个最大业务场景的人员，数据工程人员，业务分析的人员，产品研发的人员，数据科学的人员，人工智能，其实背后还有一个财务。

每个人的诉求都不一样，每个人在数据链条的环节都不一样，他们每一个人的能量也不一样，所以做一个数据平台团队是如履薄冰，我们面临非常大的困难。我们怎么来解呢？因为滴滴和车有关系，我们背后是这么复杂的，这条链是稳定的高质量数据交付，在整个全世界的生产制造环节里面，什么样的链式制造在哪个行业里面最复杂、最稳定的呢？是汽车制造行业。在这里面做的最好的是丰田，我们就借鉴了丰田精益制造的理念，以它为基础变成了我们精益数据的管理体系。

首先我们定义目标，我们究竟做数据平台的目的是什么，是要处理更多的数据，还是要算的更快，还是说出各种各样很好看的报表，我们认为最核心的是高价值、高可靠、高效率、低成本、少浪费的做数据服务的交付。我们不一定做应用，不一定自己去拿到很好的业务效果，但是我们关键是要把数据赋能业务的同学，把数据的价值交付出去。

基于这样的目标，我们认为最关键的点首先要有文化，不然组织间的摩擦会有很大。这个东西也是和滴滴高层管理一起往下推，从庙堂和江湖之间一起去发力。

关键的两个一个是持续改进，我们认为数据平台、数据体系或者数据中台不是一天能够建成的，也不是一个大项目做了数据治理，做了数据资产管理，这事就完事了，很多企业，尤其是传统产业企业领导觉得数据这件事情交给 CIO 或者数据平台的领导者就好了，把这个数据弄好，后面就好了，其实不是这样子的。数据是跟着业务在发展和生产的，必须得持续改进才能跟上业务的节奏。

数据本质上背后是人，人用数据，人开发的 AI 用数据，我们必须得尊重人，尊重人是什么样的意思？尊重人的创意，我们应该让每一个人都有机会平等用上数据，所以要把这个门槛降到最低。

第二个数据的链路里面涉及到的方方面面各种各样的人，我们一定要让每一个链路中的人意识到，你做的任何一件事情都有可能会影响到上游或者下游，那核心价值观是不要给别人添麻烦，客户第一。以这个为基础的价值观遇到很多问题的时候，我们就回到这样的初心，再来看怎么做持续改进。

二、滴滴精益数据管理体系

基于这样的数据文化，我们去做了精益的数据生产的体系，我们把它总结为以价值链为拉动。在滴滴梳理出来了将近 2000 多条数据生产的链条一路，从数据的采集再到数据的使用，经过这样的梳理来判断哪些数据产生的价值更大，哪些数据的影响面更广。基于这样的数据价值链我们就做了下面相应的工作，很多是像丰田生产流水线学习的。

第一个是分级，我们认为不可能把所有的数据问题用所有的精力解决掉，这也是不现实的，或者这个是浪费。精益里面最关键一点是减少浪费，把所有的东西用同样的方式做同样的处理，所以第一个分级，对数据做了 T1、T2、T3 的分级。

第二个监控，我们必须实时知道这个数据在怎么被加工处理，进入的情况是什么样的，产出的情况是什么样的，加工处理过程中间的产出各种日志是什么样的。在《管理》那本书里要提到要控制好任何一个生产线的质量，最关键的就是持续统计管理。在生产过程中任何数据都被统计下来，来发现这里面的问题。

第三个复盘，有了监控之后知道系统里面会出现哪些问题、变化，每一个这样的异常、变化和问题都会有一个小组召开相应的复盘，从 2017 年 4 月份到 2019 年 1 月份做了 150 多次的复盘，复盘率超过了 89%，相应每一次复盘对于系统的改进都是巨大的。

最后把复盘得到的从人员、流程、系统上得到改进的方案，通过系统的方式把它给沉淀下来。我们认为只有通过自动化的方式，才能真正的去落地规范，才能真正落地文化和流程。所以说在自动里面用了一个日文字，我们认为这个“働”，不仅仅是要流程串在一起，有一个程序让它跑起来就行了，这里面需要人参与的，人在这里面持续迭代更新它，人是最聪明的，以及现在人还可以做出人工智能来替它更高效优化。

另外一条支柱我们有了稳定的数据生产链，我们有方法可以让它持续稳定下来之后，另外开始着手建立数据创新的体系。我们从哪儿去借鉴呢？这 20 多年来敏捷的软件开发就在我们身边，我们完完全全可以借鉴这套，包括从五年前开始火起来的 DevOps，我认为是数据体系需要认认真真去学习这个方法论，而不是有些时候过于强调数据工程的独特性。我们把数据工程很多处理的方式归结为 ETL 模型，但是随着现在越来越多的应用随着数据驱动，大家现在看到数据实时计算平台非常火热，本质上是前台的业务需要数据实时反馈来驱动它。也就是说，大量的数据工程本身就应该是和业务的应用，用一套方法论体系，一套软件工程体系去构建。

这样才能让一个公司的软件开发人员能够更快速的去交付相应的软件价值，不然一个公司里面会越来越臃肿。从这个角度来讲我们去认认真真把软件工程去看了一遍，创新要容忍混乱，混乱来自什么？或者换句话说叫活力，活力来自于连接，连接越多活力越大，所以我们构建一个创新网，把整个数据平台采集到的各种各样数据，以及数据在加工处理过程中，以及数据流动处理过程中间再次沉淀下来的数据，我们都把它记录下来，以及产生这个数据的物和人，也记录下来，从而形成了背后数据的知识图谱。

我们知道这个数据从哪儿来到哪儿去，被什么人来使用，使用的过程是什么样的，使用的反馈是什么样的，使用完之后沉淀下来的感悟是什么样的，比如说分析方法论是什么样的，数据工程师使用这个数据发现的问题是什么？我们把这些东西都沉淀下来，并且和内部的效能工具做打通，和运维数据做打通，和财务系统做打通，去和各种各样的流程审批系统做打通，这样构建了数据创新的网络。

我们再把相应的用户群进行分层，我们认为一部分人是直接用数据的，所以说把这个定义成用结果，这里面就是传统的报表体系。我们为了把报表的东西做到更敏捷，我们做了一个什么事呢？我们发现公司很多的用户不需要把它做的太漂亮，尤其是一线员工，更多是看数据来反馈前几天的系统和系统上实时操作的结果是什么样子的，其实有自己的办法去做相应的可视化分析，我们把很多的报表再做了简化，我们认为不用发很多可视化报表，就把它数据模板化就好了，并且给他一定的灵活性，第二步自配置。

我们现在每天可以产生 600 多个分析的小模板，来自于各个业务方向，复盘、实验、测试，大家可以想到背后什么，每一个一线业务同学，不管是产品还是运营，都在用数据驱动它做任何改进的事情，滴滴的创新就这样起来。

第三个模仿做，这里面代表的思想是什么？一切皆代码，很多情况下你要模仿别人做一个东西，你看花花绿绿的东西，你不知道背后的东西是什么，其实是很难模仿的。我们尽可能在数据分析这一块，把数据背后分析的代码都开放给用户。比如说我看到这样的数据结果，我会让它找到背后分析的代码是什么，我看到这个报表，我会告诉他背后分析的 DSL 是什么，这样一些高阶的用户基于代码更快速的理解背后的逻辑是什么，进一步模仿可以去做。这样会让我们很多中低阶的同学，在这块技能不是那么丰富的同学可以做一些偏高阶的工作，降低成本，提升效率。

最后自主化，我们通过对于前面精益数据生产链路，去彻底打通数据从采集、加工、预处理、分析和系统对接再到服务化，我们打通了整个流程环节，任何一个稍微懂一点数据的同学，就能完成从数据的接入，再到数据的处理。这样不会有很多的数据门槛，不需要一个同学要去做分析的时候，要去做数据探索的时候，需要有相应的工程师同学去配合他，才能完成相应的动作。

基于这样的方法论，我们就去开发数据系统的工具链，这个工具链要达到前面的分级监控、复盘和自动化，要去能够让大家各个层面上方便降门槛去用数据。在这里面产品设计秉承核心的方法论，第一个数据要越用越好用，要把数据引入到产品设计中驱动产品设计的优化。第二个目标是让尽可能多的人能够把数据用起来，所以数据工具之间必须去做强打通，让每一个人都能完成数据处理工作，这是产品设计的核心方法论，我们还通过相应的指标体系来去衡量是否在往这个方向去发展。

数据基础设施，还是基于开源的体系来去做。基于这样的方式做了两年，2017 年 4 月份加入到滴滴，第二天就出了很大的故障，从那个时候开始一直到年底基本上每周两次，每天晚上被短信吵起来很多次，我下面的几十号兄弟每天都得起来好几次。

三、滴滴数据系统组成

我们有了这套东西我们持续改正之后，从用户价值来讲每个 Q 都会做 NPS 调研，打 8 分、9 分、10 分的人减去打 1 分、2 分的人，打五六分的人我们不认为他满意。这个是非常苛刻的，很多公司很多产品 NPS 能做到 30%是不错了，从 2017 年的 4 月份 19%还诟病比较多的，到最近的一次调研做到 60%。

在相应的数据生产这一块，事故从一年十几次其实是二十次到去年可能只发生了一次。我们核心的数据产出时间最晚的处理时间已经提前到了 5 点，我们把所有数据采集的生产链路实时化，根据后面的用户需要来选择究竟是实时还是准实时，还是小时，还是按天。

另外，我们创新体系里面有一个衡量的指标，我们的同事每天都在问很多问题，这些代表在思考解决很多新问题，可能在组合很多情况去解决复杂问题，我们认为这都在做微创新，从两天任务变到了 2 万个，有了十倍的增加。

为了把这两套体系连接起来，发挥更大的作用，我们构建的智能数据目录，相当于目每周会有 20%的员工在高频的使用，相当于 20%的员工在去找公司里面有哪些数据可以帮助到他做各种各样业务的问题，目前也在系统性进行对外进行输出。

另外，敏捷的数据治理，很多时候是数据治好一段时间，然后又坏，怎么能够让它好用起来呢？第一个必须得全面量化，第二个改变思路。以前的思路是我的数据治理目标数据质量好，我们想数据质量好的本质是什么？能够把数据用起来，我们认为所有的数据治理目标是让更多人把数据用起来，能够用起来的第一点是量化，数据怎么在被使用。

我们把整个数据体系里面的任何数据存储引擎，数据分析的产品，用户的日志都记录下来，我们希望对用户行为进行相应的结构化，我们来看用户在怎么用这些数据，我们在看数据依赖关系是什么，哪些数据是高价值的，哪些数据是低价值的，哪些数据是影响面宽的，我们形成了几百万个节点，将近 4 亿条边的数据图谱。

基于这样的图谱，借鉴了 Google 的 PageRank 算法，我们来计算出来哪些数据价值高，哪些数据的影响面广，我们做了一些对比，通过专家做这个评测，我们发现用算法算出来的，基本上和专家的打分是一致的，所以很快应用到生产体系里面去。我们用这种东西来衡量治理的效果是什么样的，实时监控，每天都产出这样的情况来，从 2018 年初 40 分到现在 70 分，我们整体的数据使用处于持续好转的阶段，现在应该说还比较不错。

因为我对数据进行量化，我知道哪些是高价值的数据，高影响的数据，我们发现非常有趣的现象，10%的数据支撑了公司 90%的业务和使用，所以我们只需投入更少的资源去解决那 10%的数据治理问题，我们可以让这些资源每天盯着，10%的数据量。我们可以通过全面的量化做到重点的攻关和突破，而其他的 90%使用众包和 AI。

我们有了知识图谱之后可以构建各种各样的算法来提示大家或者驱动大家做什么样的优化，举一个最简单的例子，我们通过解析，发现大量数据处理的模式。我们把这些都推给了相应的数据工程师，他们拿到这个东西之后可以快速做相应的改进，这样让我们的数据仓库又能快速的相应需求的同时，上面各种各样业务创新人员去做数据查询，性能也得到更好的提升。

最后数据的文化，我们一年多的时间将近两年做了 150 次的复盘，每一次复盘都落地到从流程、人员到系统，都有详细的改进计划，我们成立了专门全链路的小组来去跟进，每一块必须得落地到位。基于这样整体的建设，我们整个中台用户使用的活跃度，从两年前的 1700 人到 5000+人，现在数据最新是 5400 左右，相当于滴滴 49%的员工一周会用一次数据，这在整个行业里面相当高的，我们做了一些调研，但不是特别全面，发现这个数据大概在 20-25%。

基于这样的方法论，我们系统这样去搭建的，这个和阿里的数据中台的组成部分或者网易数据中台组成部分很类似。核心还是前面方法论，我想说的东西是什么呢？这个东西就像武器，先进的武器大家是可以买得来的，可能花钱买或者雇人能够造的出来，各种各样的经验大家也能够借鉴，但是一支能打胜仗的队伍，只有本国的军队、自己的军事理论，再加上持续的训练和实战才能锤炼出来，胜利不是靠买来的。这些只是你需要的武器而已，你需要公司的文化、公司组织、公司业务来去灵活制定数据体系的方法论，才能拿到相应的结果。

这就是我们产品做出来的情况，这是智能的数据目录，让数据越用越好用的方式，所有的数据资产在这儿都能通过检索的方式做到，基本上这样的数据还能做推荐，把它变成相应的数据支持实体，做及时的沟通，还能评价，还能 diss 你，很多同学也能点赞。

让数据持续可靠，从最开始怎么做好技术质量，再到怎么找到相应的数据，再到最后更简单的去使用数据。数据的服务化，数据能够持续被人依赖，被服务依赖。

实时数据的集成，我没有把它写成数据的实时计算，我认为更多是把数据集成，把集成好的数据交付给更多的前台业务应用去使用，监控其实是里面价值最低的，更多是怎么能够驱动前台实时响应类的应用，来给用户发挥价值。

这是运营轻量级分析的流程，就像刚刚提到的从两年前的 2000 次再到现在的 2 万次。这是数据可能今后发挥价值最大的地方，去赋能 AI。通过建立好数据中台服务层，再把它演变成对应的特征层，来驱动出这样强化学习的营销体系。

四、中台是买不来的

最后想讲的感悟，数据中台不是买来的，也不是简单地把数据相应的模块系统放在公司里面搭建起来就 OK 的，它其实是尊重公司内部的客观经济规律，包括公司的文化、组织、人员、业务模式管理和治理的结果，其实更多的是需要大家用同样的价值观面向长期用户价值合理的分工，以及基于分工下合理的协同，怎么去梳理出价值链？怎么梳理出创新网？本质上做这样的事情，所以说到最后中台其实是组织和体系建设的一个成果，背后是靠大数据技术和系统来做支撑。

今天我就分享到这里，谢谢大家！

Q&A

Q1：您刚才把日本的管理哲学也融入到滴滴系统里面去，大数据架构能不能展开说一说，数据中台和数据湖之间是什么样的关系？

A1：我们大概是分成了下面四层，最底层是数据架构这一层，相当于解决刚才提到的第二个阶段计算存储的问题，这里面主要做的是什么呢？要能够支持尽可能多的计算存储模式，像刚才提到有些连续性的，关键是稳定性。

再往上面是 iPass 层，我们认为主要是两个核心，一个是数据的中间件，能更好搭建出上层数据的应用。另外是数据的研发，我怎么把数据集加工出来或者数据服务加工出来。再往上是数据的应用或者赋能。一块叫数据资产更多去赋能应用，赋能上策的产品、赋能算法。右边这块是赋能人，让他们自主查询去做可视化，去做交互式复杂的探索。

数据资产管理里面核心三点，第一个让大家找到理解、发现，并且能够信任数据；第二个能够敏捷治理数据，相应的抓手，数据资产是量化的抓手，把数据归属到人，这是一个组织管理，资产的优化相当于是建立前面反馈之后，每天告诉给资产的负责人应该做什么样的优化，确保数据的质量提升。另外数据内容持续建设，再往上是相应的数据服务，数据服务现在主要是分成这几大类，一种是分析类的去支撑各种各样洞察的结果。

另外一个相当于实验类的，以及滴滴比较有特色的地理围栏、营销、流程、财务管控、合规安全，还有面向高层的决策支撑，基本上这样的体系。

Q2：基础设施这一层怎么支撑数据湖和数据中台的？

A2：我们数据湖是这样的，基础数据存在 HDFS 里面，HDFS 因为有很大的弹性，不管是容量还是对于结构化和非结构化不那么敏感，但是性能和效率比较低，在数据湖上面构建了不同的查询引擎。

解决什么样的问题呢？现在还没有一个查询引擎既查的又快，又稳定，在不同的数据量下稳定的工作。那我们就构建这样不同的查询引擎，根据对数据查询的分析来去调用不同的引擎完成最后的查询，这个是数据湖。

这个是基础的结构，但是我们认为这样的数据湖最后会变成什么？会变成数据沼泽，或者变成数据死海，为什么？会越来越乱，上面需要构建起相应的数据治理的东西。我们一个相对于传统的厂商的数据湖或者很多公司做数据湖不一样的地方在什么呢？我们把数据目录做强整合，你在数据湖做这样的工作，沉淀下来的经验，立马变到知识体系来，供下一次使用。

你也可以用数据目录很好去利用别人经验对数据进行加工处理，这样就能通过对数据使用过程中巨大的透明，保证数据湖的湖水干净。另外把数据模式提取出来之后，给到专业的数据仓库人员，来对数据湖里面的数据做持续的集成和规划。

Q3：刚才您提到 HDFS 实际上比较擅长做离线的分布式存储，为什么不选择（ceph）呢？

A3：我们现在数据量是很大的，（ceph）首先存在一些技术问题，最关键是成本，用 HDFS 成本要低一些。

Q4：360 有 500 个集群，每个集群上面可以跑 1500 个节点承载上面集团级的视频流的数据量。除了成本以外，（ceph）本身是开源的，对于一个公司也不需要成本，为什么不用（ceph）？

A3：在滴滴也有用，只是我们现在最大的数据湖用的是 HDFS，因为我们认为数据必须得在基础设施层面上做打通，数据尽可能不要搬来搬去，大家看起来是成本上的浪费，最关键是降低了门槛和提升了稳定性。至于说在很多其他领域，我们也有用 ceph 的。

作者介绍：

张茂森，滴滴首席工程师，负责滴滴数据平台建设和数据产品商业化工作。致力于企业级敏捷数据体系的落地。曾在阿里负责量子恒道店铺分析产品技术架构，打造从零到 300 万卖家的数据分析服务，曾负责阿里云 dataworks 5k+项目整体架构师工作。最早实现数据安全计算产品淘宝御膳房平台，用数据赋能电商生态。

原文链接：

https://mp.weixin.qq.com/s/Ounubq5J0U5ijQsFgQZU0A