从数据中台到数据生产力｜社群直播回顾

本文内容来自我们本周在社群的公开课直播，还未进群的朋友，请在文末查看进群方式，以后每周三20:00，我们都将邀请行业专家、大咖分享数字化的相关干货，大家可以在群里进行互动交流。

---

大家好，我是来自网易的郭忆，很高兴能有这样的一个机会来到我们88实验室，去分享网易在大数据方面的最新实践。今天我分享的主题是《从数据中台到数据生产力》。

先简单自我介绍一下，我是网易大数据产品技术的负责人，研究生毕业以后就加入到了网易，一直在从事数据相关系统的设计和研发。

在2018年的时候，我们以网易严选作为第一个业务，开始了整个网易数据中台技术体系的一个搭建，先后支撑的包括网易云音乐、考拉新闻、有道在内的一系列业务数据中台体系的构建，我自己也经常在外部的一些行业峰会上去分享网易大数据的最新的实践经验。

今天的分享主要包括3大部分，首先我为大家来介绍网易为什么要去建设数据中台。

网易为什么要建设数据中台

回顾一下网易大数据的发展历史，我们也是逐渐从后台走向前台，从一个成本中心变成一个价值中心。

其实网易从2009年开始，我们就切换到了Hadoop这样的一个赛道上，我们就开始去做了Hadoop集群的运维，然后后来我们自己去针对Hadoop的特性做相应的一些优化，然后开发出来了一些新的特性。

2014年对于网易来说，是大数据平台的诞生推动了整个网易大数据的规模化的发展。

2015年有数BI的这样的一个上线，可以说是推动了整个大数据应用体系的一个快速的发展，让非常多的人开始接触到数据带来的一个业务的价值。

大量的人开始去使用这个数据之后，我们就诞生出来了很多的问题。所以在2018年的时间点上，我们开始了整个网易数据中台技术体系的一个搭建。

到了2019年在我们数据中台初具规模的时候，我们开始了整个数据产品体系的搭建，这时候我们通过数据产品，我们已经开始去接触到业务，参与到业务过程中。

到2020年，我们认为基于原先数据中台再加上数据产品的一系列的实践，可以构建一个数据生产力的一套体系，所以我们正是把这套体系称之为数据生产力体系，让大数据能够去发挥它的业务价值，推动业务向数字化的这样的一个发展。

所以我们这个时候其实整个演变过程把自己从一个成本中心变成了一个参与业务过程的价值中心。

在这个过程中，其实我们会遇到很多很多的问题，我们这个时候把时间轴拉回到2018年，我们来看一下，在有数BA诞生之后，有非常多的这种数据应用开始大规模的爆发式的发展的时候，我们遇到了什么样的一个问题？

首先就是我们的需求的交付速度非常的慢，经常被业务去Diss。当时其实对互联网来说，它是一个非常注重敏捷的这样的业务研发模式，但是其实还是很难去满足业务的一个需求的。

业务它其实是要去做精细化的、高频的运营，假如我上午做活动，可能下午或者很快我就要拿到相应的数据去做整个运营策略的优化，这个时候如果你的需求交付速度是一周，其实是没有办法去满足业务需求的。

第二个就是找数据非常的困难，像我们当时通过野蛮式的这种增长的话，像我们严选有8万张表，音乐有4万张表。

大家都知道在大数据的里面越往上的一些宽表，它可能一个表含有100多个字段，当我们去找到某张表中的某个字段的时候，我们发现简直就是大海捞针。

第三个就是我们整个报表、BI体系在高峰时间段几乎是不可用的状态，因为太多的这种小文件，太多的这种慢查询，太多的明细数据的直接查询，导致我们的报表基本上是不可以去使用的，导致报表体系基本上是瘫痪的。

数据每天早上其实是出不来的，最后就是我们的查询的效率也非常的低，如果这个查询的速度非常慢，就会导致数据出不来。

比如，一个很常见的现象，我们运营开着一个页面，然后在那跑数，可能到一早上过去了，这个数据也可能还没跑出来。

第二部分就是质量问题，质量是我们数据的生命线，没有质量保障的数据是没有业务价值的，所以我们当时统计下来，我们平均每周就有10个数据质量问题，被业务方来投诉反馈，最终的一个结果是导致什么？

是导致业务方对数据最终产生了一个不信任，其实已经不敢用了，因为你这个数据其实没有办法去保证这个数据一定是正确的。所以基于这样的一个错误的数据，很容易去产生一个错误的运营策略。

然后我们发现90%的问题都是被数据的使用方向去发现的，而且是被投诉到领导这个层面，对于数据部门来说非常的被动，很多时候都是被投诉的。

很多时候出了问题，对于数据部门来说，他并不知道数据出了问题，平均每个季度都有9个，因为指标口径不一致被反馈的数据问题，而这些问题中超过50%的问题都是数据开发自身的一些bug。

第三个我们来看一看我们的数据，我们每天都在研发数据，每天都在运维数据，但是这些数据到底有没有产生价值，有没有人再去用，是一个很大的问题。

我们发现每个业务线都有超过50%以上的表，在30天内没有人访问，而这些数据每天都在源源不断的生产和加工，不仅消耗我们的计算存储资源，也消耗我们研发的人力，运维的人力，但是这些数据其实都是静静的躺在我们的树仓里面，其实是没有人去看，对公司来说其实是一种浪费。

最后就是安全，数据如果要让它能够大规模的用起来，没有安全保障，这个数据是没有办法去备用的。当然这里面还会有很多的这种安全的漏洞。

我举个例子，当时我记得是我们的一个开发，它是一个管理员，create了一个database，然后location到了have的根目录上，但是后来这个人脑子短路了，直接drop了 Database，当时情况非常的危急，差点造成了整个仓的全部被删，非常的惊险。

我们当时发现这个问题，第一反应是我们的n当时被直接打垮了，发现有太多的小文件的这种数据的扫描，大量的文件的删除，出现了bgc整个rpc的响应非常的慢，后来我们才发现是因为有误操作，结果导致了整个数据被删。

当时我给我们的领导去汇报这个事情的时候，我们领导的第一反应是我们的数据中台、数据仓库还在不在？

所以针对这样的问题，其实对于我们要去搭建一整个数据仓库是非常严峻的，所以基于这样的一系列的问题，我们才去思考，我们必须要通过数据中台的这样的一套模式去完成整个数据体系的一个升级。

网易数据中台建设实践

好，接下来我就为大家来介绍一下网易在数据中台建设这方面的一些实践经验。

网易要去搭建一个数据中台，我们认为它一定是有一些着手点的，而且必须是要有一套方法论去做相应的支撑的。而我们的着手点其实是基于原数据驱动的一个数据中台建设的方法论，也就是说我们的数据中台的构建一定要先构建在基于原数据基于原数据驱动，然后去发现问题解决问题这样的一套闭环去推动整个数据平台的建设。

这里面其实有5个着手点。

第一个是规范化，规范化里面其实包括了统一指标体系的构建，高复用的数据模型的设计和数据的标准化。

第二个是在质量，质量这个里面又分为事前和事后，对于事后我们必须要建立全链路的集合监控，对于事前我们必须要构建DataOps，能够基于 cicd develop的一套能够去完成自动化的这种数据的测试发布，回归这样一整套的一套排排。

第三个就是安全，我们要建立基于数据资产等级的数据安全的管理。

还有就是成本和价值，我们要基于roi的这样的一套方法论去构建我们哪些数据它是可以服用的，它具备高价值的，它是需要沉淀的，而哪些数据其实是不需要去积累的，不需要去做沉淀的，我们是需要进行清理的，最后是使用我们要让人能够一站式的数据资产的门户去很方便的去找到这个数据，并且能够通过数据服务很方便的把这个数据输送到我们的业务侧，输送给我们的数据产品，去完成整个数据的一个闭环。

所以我们会从规范、质量、安全、成本价值和使用这5个维度去完成整个数据中台的建设。

但是大家值得注意的一个点，我们发现在每一个地方我们都标注了后面的一个产品，所以大家要建设数据中台一个很重要的点就是要产品化。

如果我们所有的规范质量安全成本价值和使用都停留在是一个流程或者是一个规范或者是一个文档的角度，这个东西是很难去落地的。我们必须要把这些东西全部融入到我们日常的数据的研发流程，数据的管理流程，并且通过产品进行落地，才能够去让它很好的运转起来。

所以在这个过程中，产品化是一个非常重要的手段，而且也是我们最终积累下面的一个经验的载体和沉淀。

好，我们先一个个来看，为什么指标口径是不一致的，这里面当然是有方法论上面的缺失，我们缺少一套指标的标准化的定义，标准化的规范。

第二个从技术的层面来说，数据同源是我们指标保证口径一致性一个很重要的手段。当然如果我们都是烟囱式的开发模式，你开发你的我开发我的，我们就很难去保证我们的计算逻辑、加工逻辑的数据来源是一致的。

所以烟囱式的开发模式是导致我们指标口径不一致一个很重要的因素。

另外就是我的数据如果是不同的来源，也会导致我的指标口径是不一致的。

当然除了技术手段，除了方法论层面，我们的组织架构也会成为我们指标管理的一大障碍。

我们原先如果没有数据中台这样的一个部门或者一个组织架构，其实是没有人去牵头去梳理我们整个面向公司的一个统一的指标体系的，这样就会导致不同部门之间，甚至同一个部门的不同的这种业务，不同的这种小的部门之间，它的指标可能都是口径不一致的。

同时我们也缺乏一套统一的指标管理的一套规范。所以我们先来看如何来去规范化的去定义这样的一个指标。

在定义指标的时候，首先我们先要对我们所从事的一个业务按照主题域的形式先进行切分，因为主题域它是一个业务过程的抽象，也就是说我们要先按照我们的业务过程去划分出来，具体我们业务线有哪些业务过程，然后我们可以去组织出来哪些主题。所以主题域下面我们是有业务过程和可分析的维度。

在业务过程下，比如说我们的交易是一个业务过程，我们的内容是一个业务过程，我们的售后是一个业务过程，在交易这个里面我们有什么架构，有下单，有支付等各个业务过程，在每个业务过程下，我们可能都会有一些指标。

当然针对于指标，我们又要去细分的去拆，它是一个原子指标还是一个派生指标，很多人在去做这个指标拆分的时候会感到非常的困惑，就是原子指标和派生指标经常分不清楚。

那对于网易来说，我们不会去强调说原子指标它是一个不可再分的指标，这种太抽象了。我们认为原子指标它是涉及到口径的，就叫原子指标，派生指标不涉及到口径。

那同学可能会问我说什么叫口径？

口径就是我们数仓对于从业务系统过来的数据，按照一定的逻辑进行加工和计算，这个时候计算过程就叫做口径。如果不涉及到对数仓业务员系统的数据按照某个计算过程去做加工的话，那就不涉及到数据口径的管理。

所以我们认为原子指标它是带口径的，而派生指标它是根据原子指标再加上修饰词，再加上时间周期进行组合，它就叫派生指标。

对于修饰词来说一般它是一些什么？

比如说类目，商品，比如说一些渠道，这些都可以作为一些修饰词，对我们来说很多都是维度的属性值。

这个时候一般来说我们不会对这种维度属性值，比如对于商品业务员系统进来是什么就是什么，我们不会对它进行进一步的计算和加工，这个时候其实它就不存在。

不带口径的原子指标是什么？

比如说消费金额，这是一个带口径的，口径表现在什么？它是含税的还是不含税的，它是含退货的还是不含退货的？它是已下单且支付的，还是已下单没支付的，也包含了。

这个时候其实它是带口径的，但是比如说它是牛奶的，或者它是一个水壶的，这对于水壶和牛奶，我们其实对于素餐来说，我们没有对修饰词进行过进一步的计算和加工，所以这个词本身就来自于业务系统的，它本身就是不带口径的，所以我们发现派生指标它是不带口径的，原子指标它是带口径的，

我们区分原子指标和派生指标的目的，其实是为了做什么？为了做精细化的管理，就是能够让设计口径的我们需要进行统一化的管理，对于不涉及口径的，我们可以交给业务部门自由的进行组合，来去简化指标管理的流程。

对于中台部门我们最关注的是什么？我们最关注的是原子指标，因为原子指标我们管住口径以后，对于派生指标来说，它的口径是不会去错的。

比如说牛奶的消费金额和水壶的消费金额，大家对消费金额的定义一定是一致的。当然在这个图里面大家可以看到我们对原子指标还进一步的细拆，包括它有一个叫做衍生原子指标。

衍生元素指标为什么叫衍生词？

这里面包括了一些活跃，比如说我们有时候会有新用户消费金额和新用户数，这个时候新用户大家的定义是不是一致的，这个时候其实也会涉及到大家理解上面是不是一致，我们也需要进行单独的一些管理。

当然要看你管理的一个精细度和复杂度，如果你觉得能够有这样的一个能力去管理，你的原则指标足够的多，并且确实会出现这种衍生词，大家不一致的这种理解的话，那就需要进一步的进行拆分，所以最终大家一定要明确一个点，就是我们指标拆分的目的，其实是为了确保指标口径的统一。

当然，这样的一套指标定义的规范，也会有一套配对的指标管理的流程。

这套流程包括我们新建一个指标，对于如果它是一个原子指标的话，它可能是需要我们中台部门的指标管理员进行审批的，如果它是一个派生指标，他只要业务域的负责人去审批就好了。

大家可能会疑问说是他怎么去判断这是个原则指标，派出指标其实很简单，有指标需求的这个人在我们的指标系统上，它能够根据现有的原子指标去筛选去组合出来一个派生指标的话，他就不需要去做进一步的原则指标的创建。

如果它组合不出来，他发现现有指标系统上面没有它需要的原则指标的话，这个时候就会涉及到发起新建原子指标的这样的一个需求的流程。

当然我刚才其实前面已经强调过，所以我们的指标的规范定义，包括指标的整个的流程，其实都是要通过产品化进行落地的，指标这个东西它其实是业务和我们数据团队的一个交汇点。

就是如果我们在指标这一侧，大家的需求是不对齐的，大家的理解是不能够达成一致的话，我们后面做的很多数据其实都是在做无用功。

所以我们需要有一套产品来去完成整个指标的一套管理，对外我们这套指标系统它要能够去升到我们的数据产品上，能够在我们的数据产品上去展示出来这个指标的一个口径的定义，向下能够跟我们的数仓的模型能够关联起来，我能够通过指标找到模型，然后通过模型找到对应的数据，基于数据再去做进一步的分析，去做一些洞察，这是我们整个向下的一套链路。

所以它是一个承上启下这样的过程。

同时指标大家可以看到他不是只是给数据开发用的，它其实涉及到很强的一个组织协作的流程，所以这里面会涉及到流程引擎的一个作用，包括指标的整个审批的流程，指标的这种上传下载发布，整个一个流程化的管理，包括指标的多版本的管理，这个是我们指标和我们的BI系统的一个集成。

大家可以看到在我们的BI系统上可以直接展示出来这个指标的一个口径，同时这个是跟我们的一个建模过程的结合，就是我们在建模过程中去可以去关联我这个模型的某个字段，去关联了这样的一个指标。

当然我们其实在做这个过程中，我们能够感觉得到每个企业都有一些自己的指标管理的特殊的属性，包括这个指标是不是涉及到KPI考核的，是不是涉及到财务的，是不是企业的一个核心的指标，是哪一个、什么样的、有什么样的属性？

所以我们做了一个比较有意思的实践，就是做了一个自定义的指标模板，我们可以去自定义指标填报的模板，然后比如说我可以加一个字段或者加一个值的选择范围，让用户自己去按照这样的一套模板去完善它自己的一个指标的属性。

当然这里面还有我刚才说到指标的口径，它不是一成不变的，它会涉及到指标口径的一个版本的变化和跟踪，在我们这个系统上必须能够去跟踪到我指标的整个的一个变化的生命周期。

当然当我们的指标爆炸到一定程度的时候，它这个指标之间的依赖关系是很复杂的，尤其是我们涉及到一些复合指标的时候，我们发现一个复合指标可能是有多个原子指标和派生指标进行加减，进行一些四则运算，或者是一些更复杂的运算计算出来的，这个时候我们就需要用到指标之间的一个血缘

我们可以根据这个指标去看这个指标是有哪几个指标，根据什么样的一个计算规则计算出来的，包括一个指标它的下游有多少派生指标，我们都可以看到它有哪些派生指标，并根据派生指标去理解派生指标和原子指标它俩之间关联关系。

当然我们的指标系统，刚才有说我们要提供一些API接口，能够让我们的业务人员或者我们的数据应用、数据产品能够通过接口很方便的去引用到这个指标的口径的定义。

这个是我们当时在网易考拉业务线，当时网易考拉其实是有记载的，我们分析师的Excel上有记录的一共是824个指标，通过按照这样的一套规范化体系的梳理，我们把一些这种口径，定义重复的、定义不清晰的，还有一些口径定义不完整的一些指标进行梳理，然后我们最终沉淀出了123个这样的一个指标，并且我们的原子指标的占比其实是可以占到1/3这样的一个规模，然后覆盖了13个数据产品，完成了整个指标口径的统一。

好，我们前面介绍了我们关于指标这块的一些最佳的实践，指标结束之后，我们就要进入到下一个pipeline的 Checkpoint，就是建模这块了。

我们先来看一看原先为什么我们称自己不是一个数据中台，这里面其实涉及到一个很关键的点，就是到底什么是数据中台？

我们复盘一下我们原先的数据仓库建设的好不好？

我们发现超过40%的表都是没有分层的，因为在我们的一个数据中台的模式下，我们分层的命名跟大家同步一下，就是最底下是ods层，往上的明细数据层叫dwd，再往上是轻度汇总成dws，然后再往上ads是我们的数据应用层，dm是我们的数据集市层，这是横向切分。

纵向区分我们是按照主题域去进行组织的，包括交易供应链域客服，还有各种各样的商品，我们超过40%的表都是没有分层的，代表什么？

这些表其实是很难被找到的，很难被复用的，超过50%的任务都是在读原始数据进行加工。

其实这个数据一出来，一个很重要的现象就出来了，烟囱式的开发模式。我有一半的任务都是直接在读原始数据进行加工，数据的复用性是非常的差。

然后再来看，超过30%的查询都是在查原始数据，如果原始数据再加明细数据，比例高达60%。所以大部分的计算过程我们都是在查明细，那就说明我们的汇总层建设的太差了，几十层建设的更差。

我们查一个几千亿行记录的表和查一个几万行记录的表，它的查询速度和查询计算存储资源的消耗是完全不一样的。

烟囱式的开发模式，导致我们的需求的响应速度是非常慢的。基于这样的一个现实，我们必须要先制定出来一个目标，什么是数据中台模式下数仓一个好的模型设计？

我们从各个维度去看，首先我们会有一些比如说跨层引用率，是考核我们明细层数据建设的好不好，也就是说我们什么叫跨层引用率，我们的汇总层数据直接去使用ods层的原始数据进行加工开发的一个比例。

如果说这个比例很高，就说明我们的明细数据层DWD层没有进行统一的沉淀和积累。

一般来说我们的原子指标都是在DWD层的，如果说我们的原子指标没有在DW层进行统一的隔离，也就没有进行统一的覆盖，这个时候就会导致一个更严重的现象，比如指标口径的不一致。

因为你没有用过统一的DW层上面的指标口径，而是自己又去搞了一套指标口径。当然是没有办法保证跟我们数据中台的指标口径是一致的。

所以跨层引用率产生的一个更严重的后果就是指标口径的不一致。

第二个就是查询的覆盖率。

我们会去看我们的汇总层建设的好不好，我们会去看有多少查询，它是能够通过汇总层去解决的。

也就是说我们希望把越来越多的一些固化的查询，能够去推到一些汇总层上，进行一些预计去降低我们全部查明细数据对计算存储资源的消耗。

第三个我们看模型的引用系数。

我们会去追求模型的复用和共享，我刚才前面讲过了，对于一个数据中台来说，在规范化这个层次来说，我们会去追求高复用的数仓模型的设计，所以我们会去看一个模型，它的直接引用下游有多少个。

第四个就是我们会去看有多少没有分层的表，有多少没有主题域的表。

这些表其实都是需要进行相应的治理的，所以有了这样的一个目标，有了这样的一套方法，然后有了这样的一个现状，接下来就要开始我们的整个模型的治理的过程。

首先我们就要去按照我们的主题域，按照我们的业务过程去划一个总线的矩阵。

我们要去看每个业务过程下面有哪些事实，哪些可分析的维度，基于这样的一个总线矩阵，我们可以去构建出来我们的一些明细数据的表，这个表里面有哪些度量，有哪些是维度，然后去构建我们的事实表。

有了这样一个师表以后，我们其实就可以去构建我们的一些原子指标了。

大家要明白指标它是原子指标，它是带口径的，度量是不带口径的，所以我们就可以去构建出来我们的一些原子指标，去关联上我们的一些字段了。

然后接下来我们就可以去做构建我们的一个派生指标，因为有了原子指标，有了可分析的维度，再加上一些时间周期，我们就可以构建出来我们的派生指标。

有了派生指标之后，我们取派生指标就可以构建出来一个轻度汇总层数据，一个整体，数据中台比较关注的、我们关注的就是DWD和DWS的模型设计和建设，总体我们是基于维度建模的一套方法论去完成整个体系的构建。

当然在构建过程中，我们有前面的一些指标或去监控模型设计的一些质量。

这个是我们在网易严选的一个实践的成果，跨层引用率从30.8降到了9.42，治理了跨层依赖模型有200多个，然后模型的复用比从2.4提升到了9.6，这个背后其实是迁移3.4万张表，当然对应的是我们的需求交付速度从一周提升到了三天，平均查询从降到了21秒。

讲规范化这块我就列举这么多。

接下来我们来看一看数据质量这块，我其实是对整个一年下来，我们一共321次数据质量的故障进行了一个复盘。

我们发现这种局面主要有4大类，包括业务员系统的一个变更，包括数据开发的一些任务的变更，包括一些物理资源的不足，另外还有一些基础设施的问题。

当然我们发现有超过50%的问题，其实都是数据开发的一些任务变更导致的，比如说我们使用了固定分区，然后没有配任务依赖，包括一些数据倾斜，还有一部分其实是业务员系统那边的数据过来的，这个数据本身是有问题的。所以对于我们来说，最重要的就是早发现早恢复，就是这样的一个方法。

但是我们发现其实如果只关注于数据中台内部的表与表之间的这种集合监控，我们其实很难去做到比较好的数据质量的，所以我们提出的一套方法论是端到端的全链路的数据质量的集合监控。

这个端一端是我们的数据源，一端是数据产品。当然这涉及到我们的首先我们要能够去对数据源做数据的集合监控，我们是能够发现在数据源这一侧它的数据本身就已经有问题了。

第二个就是在数据入户的过程中，我们要能够实现这种脏数据的识别，同时在基于数据湖里面的数据，我们要去做建模的时候，要对模型上面去加这种数据质量的一个集合的监控，当然集合监控其实是基于一套数据标准的一个体系，我们针对于每个数据标准的数据源，都有一些约束，包括它的值域，它的控制的比例，然后它是不是唯一等，都会有一些约束，基于这些约束，我们其实可以去生成我们模型的一个集合监控。

当然最后我们指标也要进行一些监控，包括我们指标的波动范围非常的大，其实也会存在这样的一系列的问题。

所以我们强调的是一个端到端的全链路的数据质量集合的监控，所以很多团队在去做数据质量的时候，如果它的聚焦点只关注在数据中台内部的话，其实它这个质量是没有办法做到非常好的，它可能会解决一部分数据中台内部的一些问题，但是其实如果涉及到这种业务系统，涉及到数据产品这一侧的话，其实是没有办法去有效的解决的，所以我们一定要强调的是端到端。

然后另外一部分就是我们的任务的运维，这个时候我们会引入一个叫做基线运维这样的一套技术体系，我们可以提前去发现一些问题。

我举个例子，我们的值班人员这个预测就是我们在00:45的时候就收到了一个基线的预警预测，6:30的基线是存在破线的。

后来排查是因为提交了一个大的任务上来，然后造成了这种资源的阻塞，因为资源问题导致了任务的阻塞延迟，然后我们这时候停止了一些大任务或者非核心任务，加大队列资源。

在1:21的时候，我们这个任务就追上，基线就追上了，通过这样的一种方式，相当于我提前发现了这样的一个问题。

这个背景基线运维很重要的能力是在于什么？

它是一个全链路的一个任务血源，再加上它的一个任务，历史运行时间的一个管理，还有包括我们当前资源队列的一个等待情况，我们就可以完成一个任务产出的基线的预测，基于这个预测我们就可以进行一些人工提前的干预。

基于基线运维，其实像我们在网易严选业务构建了6条，去实现这种精细化的运维，首次实现了s级大促的零延迟任务，完成率达到了96.14。

其实我们之前都一直在关注，事后去做相应的早发现和早恢复，后来发现我们能不能在事前阶段就去介入去完成，去把一些这种问题拦截掉？

这时候我们就引入了Data oops的一些技术，这里面包括发布的流水线自动化的测试、发布的影响分析、还有数据沙箱。

我们来看 Data oops的一个核心技术，它是构建了一条完整的数据发布的pipeline，而这条pipeline其实我们在业务系统里面其实是非常熟悉的，它其实叫做cicd demos。

对于我们数据开发这个领域里面，我们希望任务开发从任务的发布，开发发布然后整个经过一套自动化的一套数据测试的流程，然后完成整个任务的发布上线，可以做到代码可持续性的集成和可持续性的一个发布。

这个时候会涉及到一些关键的技术，尤其是我们在数据测试这块的一些关键的技术。首先我们会涉及到发布包的生成，这时候我们需要有一个批量的发布的打包的过程。

接下来有了这个任务包以后，我们会对它进行一些静态代码的扫描，这里面会包括我们有没有跨层依赖，这时候我们就可以扫描出来了。

我们有没有ads层的表直接去依赖了我们ods层的表，这时候有跨层依赖的话，这个任务就直接被拦截了，你要修改后才能提交发布上线，所以我们可以看到我们前面制定的这些方法论，最终其实都是融入了我们整个开发的一个流程的各个环节中，而不是说我只是制定了一套规范，然后大家来去遵从这条规范，这种其实是很难去落地的。

所以我一直在强调我们一定要产品化，同时要把这些流程和规范自然而然的去融入到我们整个研发的流程和管理的流程中。

当然这里面还包括了数据形态的探查，然后数据的比对，包括我们经常在去做模型的迁移和模型的重构，我们有没有去看过模型迁移前和迁移后数据是不是一致的？

包括我们在提交一个任务发布上线的时候，我们知不知道我们影响的是一张止损的表，是一张老板看的一张报表？

当然这里面如果每个任务都去走一遍什么测试发布上线的流程确实是很影响效率，所以我们要去根据任务的影响范围去做一些任务提交策略的控制。

可以根据任务下游影响的数据报表、止损表、标签去控制任务的发布流程，对于一些比较非核心的任务，我们可以去走一些更加轻量化的发布流程。

但是涉及到一些资本的表，我们就必须要去做数据的比对，必须要去做数据形态的探查，必须要生成质量报告，必须要进行code review才可以去发布上线。

这样的一个过程可以确保我们在保证质量的前提下去极大的提高我们的一个效率。

当然对于数据测试来说，还有一个很重要的点，就是将我们的测试环境和我们的生产环境，在Hadoop这个层面或者在基础设施这个层面，它是隔离的情况下，我们怎么去很方便的去利用我们的生产的数据，在测试环境进行验证，这是我们很头疼的一个问题。

原先我们可能很简单的去搞一个测试环境，一个生产环境，然后但是我们没有办法再次去读生产环境的数据，但是如果基础设施不分离也会有问题，我们在测试环境很容易去影响生产环境，而且在很多金融行业其实是不符合规范的。

所以我们做的一个数据沙箱是我们两套Hadoop他其实共用了同一个hive的maths Daw，原数据是打通的，我在测试环境可以直接去读生产环境的这样的一个表，但是我的代码其实是不用改的，就是我的代码可以根据我的运行环境去自动的适配。

大家可以看到在这个代码中其实利用了一套类似于宏这样的一套模式，当然任何的敏捷都是必须要建立在质量的前提下，就是我们一定要保证质量的情况下，再去提升我们的一个发布的效率，所以追求效率和追求质量是我们对POS的一个最核心的理念。

好，我们讲完质量之后，我们再来看下一个，我们在日常开发过程中经常会提到一个问题，我的人做不完我的需求，我每个业务部门都有很着急的需求，但是我的资源我的研发就这么多，我的资源就这么多，我怎么去合理的评估我应该去做哪一个需求。

当然这里面还会存在说我这个数据开发天天抱怨说我们分析师circle写的太差，分析师天天抱怨我们 circle跑得太慢，所以我们需要有一些精细化的管理的手段去看.我们做了这么多报表，做了这么多表，做了这么多的任务，到底有没有人去用？

所以我们每一张报表它在30天内它的有没有人去访问，这个数据在30天内有没有访问？同时我们会去看这个报表一天消耗的成本是多少钱？对于一些报表它每天可能要消耗几万块钱，但是在30天内都没有人访问，这样的一个数据其实就应该去做相应的下线。

只有通过这样的一套groi的一套思路去完成整个数据的管理，我们才能实现资产的最大化。对于没有人使用的，我们就认为这个数据其实没有必要持续性的进行保留，所以我们需要的是突出高价值的这种资产。

而什么叫高价值？

就是有广泛的去使用和广泛的去共享的叫高价值。

最后我们来看一下在安全能力这块的沉淀，当然我刚才讲过了，你要让数据很容易的去被使用起来，你不能采用原先的这种一个人去管理权限授权的这种模式。

你必须要有什么？必须要有权限的自动化自助式的权限申请的流程。

当然你要让很多人去你这个平台上去用数据，这时候这个数据可能会被误删，这时候除了要有权限的管理，我们可能还要有回收站，回收站如果不够的话，还要有数据的冷备，我们还要去做一些目录的冻结，有一些目录是不能被删的。

另外可能还会有一些异常目录的访问的审计，然后一些数据的加密，数据的脱敏，还有一个就是行列权限，另外其实还有一个比较好的权限管理的模式叫做tric。

就是我们可以在表上面去打一些标签，基于这些标签去完成权限的授权，这样子可以实现更加简单的这种权限的管理。

当然我们数据中台基于前面的整套的一套技术实践，我们最终实现了整个业务价值，实现了一些成果。

我们解决了我们当前的一些痛点，比如说我们的需求交付速度的提升，从一周提升到了2.5天，模型的复用比从2.4提升到了9.6，95%的报表能够在5秒内打开。我们整体研发的质量成本和安全，为整个集团节省了20%的成本。

我们做完数据中台之后，其实在2019年我们整个完成了一个提效降本这样的一个过程的构建。

数据生产力架构

但是一个新的问题摆在了我们数据团队的眼前，就是我到底产生了什么业务价值？

提效降本对于我们数据中台来说，我们很好讲，我们做了很多这种模型的重构，实现了模型的复用，研发效率的提升，但是因为我们是站在一个中台部门，我们站在一个后端，我们很难把我们的价值直接跟业务关联起来，这时候对于中台来说，你始终是处于一个被动的地位。

所以我们再去考虑在2020、2019年的时候，就开始考虑要去做数据产品了，我们要去把我们的手伸到业务部门里面参与业务过程了。

我们来举个例子，这是我们在网易严选的一个案例。

我们严选这个业务它其实是一个非常复杂的业务，它其实是从商品的研发、采购、生产、物流整个全链路的一个管理，它只是跟淘宝很大的不同在于，它会有很重的供应链的管理过程，所以这时候靠人去管理的话，效率是非常低的。

然后协同也非常困难，很容易下游卖断销了，然后上游还没有采购。要不就是商品滞销非常的厉害，然后还有一些管理的力度是非常粗的，所以最终会导致一个核心的指标，库存周转很高。

库存周转其实代表的是企业的现金流，它的一个现金的压力是非常大的，所以我们做了一个什么？

做了一个叫做供应链决策协同系统，我们内部把它叫做合作这样的一个系统，他做的就是我们首先要把所有的业务系统的数据孤岛全部打通，汇聚到我们数据中台中来，形成面向八大业务主题域的业务这个数据中台。

然后在这个之上我们要去做销量预测，要去做库存分析，要去做捕获决策，要去做采购。

建议我们能够根据采购，根据仓库，根据它的一个销量，然后完成自动的一个捕获决策的建议，推送给我们的采购系统，然后完成整个采购的自动下单和补货过程。

当然这个效果还是非常不错的，就是我们现在其实整个采购订单的系统自动下单的占比已经占到82%，当然对应的其实我们的总体的整个库存周转天数都实现了一个比较好的改善。

其实我们通过数据加算法，我们已经超过了基于人的这样的一种运营的模式，就是让我们数据直接参与到了业务过程中来。

基于这样的一个案例，我们就在反思，我们数据除了说是作为一个职能部门，作为一个支撑部门，去响应需求以外，我们需要更主动的去参与到业务过程中来，我们可以去做一些智能化的场景。

所以我们就在想业务系统它是一个流程管理的系统，我们把业务系统产生的各个孤岛的数据汇聚到数据中台中来，形成一个企业级的数据底座。

在这个底座之上，我们可以形成一些高质量的带口径的一个统一的数据，提供给我们的数据产品。而数据产品它可以作为一个业务过程的触点，它可以持续的监控业务过程去发现业务问题，去产生一个运营的决策。反哺给我们的业务系统去改良我们的业务过程，这样就形成了一个数字化的这种数据加智能化的这样的一个循环。

我们将这个循环称之为数据生产力的这样的一个循环，我们认为未来的一个整个企业的数字化的转型，它一定是去搭建这样的一个数据生产力的循环的架构。

也就是说业务系统它一定是完成业务流程化的管理，它实现的是在线化的过程，而数据中台再加上数据产品，它实现的是一个数字化的过程，通过数字化才让我们的企业的运营的效率得到了一个提高，这才是未来企业的核心的竞争力。

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

温馨提示

下一期的社群公开课将在12月22日（下周三）晚上20:00开播，欢迎大家根据下图指引报名。