网易数据中台建设实践

数据中台无疑是今年大数据圈最火的名词，不仅是互联网企业，就连很多传统企业都参与到数据中台的建设中，基于数据提高企业运营效率。作为网易集团公共技术研发部门，网易杭州研究院在过去一年一直致力于数据中台支撑产品的研发，推动数据中台在网易电商、音乐、传媒等业务的落地。本文将结合网易数据中台的建设实践，对数据中台的定义、建设方法论以及落地价值进行深入探讨。

数据中台是什么？

从 Hadoop 集群的开发运维，到构建大数据平台，再到数据中台建设，这是很多大型互联网公司大数据的建设历程。到底什么是数据中台，数据中台跟我们之前一直说的大数据平台有什么区别，我想可以通过一个例子来说明。

如果我们把数据中台看作是一个汽车工厂，那大数据平台就是工厂中的设备，Hadoop 集群则是工厂运作所必须的水、电、煤。Hadoop 提供的是大数据生产所必须的计算和存储资源，大数据平台使得数据开发人员具备了对数据的加工和处理能力，类比设备使得工人具备了对原材料的加工能力，但是大数据平台还不能提供产品，这么多的原始数据，要按照一定的方法论，进行良好的组织，加工，才能生成最终的指标，就如只有切割机、油漆机还不能生产汽车，各个零部件要按照一定的规则，通过设备组装在一起，才是一辆完整的汽车。

 
我们认为数据中台是企业级大数据通过系统化的方式实现统一、标准、安全、共享的数据组织，以服务化的方式赋能前台数据应用，提高数据的使用效率。

数据中台与数据平台最本质的区别在于数据中台是具备业务属性的，输入的是原始数据，输出的是指标。数据中台包含了业务对数据的组织方法论，体现在主题域，业务过程的划分，数据模型的设计，指标、维度、度量的管理，如果我们想确定一个数据是指标还是维度，就必须理解业务。大数据平台提供的是与业务属性无关的工具集合，是数据的加工能力，至于加工的什么数据，平台并不关心。

数据中台解决的三大问题

在明确了数据中台与大数据平台的区别之后，我们需要探讨的是，数据中台到底解决了什么问题。归结起来，主要是三个：效率、质量和成本。

效率问题可以分为数据研发的效率、数据发现的效率和数据分析的效率。

首先是数据研发的效率，在我所接触的很多项目中，在项目初期，由于业务模式还不固定，变化比较快，往往缺少良好的主题域和分层的设计，烟囱式的开发模式占据了主导，随着业务复杂度和规模的上升，大量重复性的数据开发，制约了数据需求交付效率。一个需求往往需要一个星期甚至更长的时间才能上线，需求响应速度经常被业务部门诟病。

其次是数据发现的效率，由于开发数据的和使用数据的往往是不同的人，面对动辄数万张表，每张表有数十个甚至上百个字段，准确理解每张表的含义是一件非常困难的事。如果没有一个好用的系统，往往需要大量的沟通成本，对于数据开发，经常抱怨工作被打断，每天都在回答重复性的问题；对于分析师而言，想要知道有哪些数据可以用，找到自己想要的数据，需要花费大量的时间。在网易，建设数据中台之前，很多业务都在用很原始的方法，每个分析师都自己维护了一个 Excel，相当于自己的知识库，记录着一些常用的表。一个新的分析师想要了解数据，需要花费大量的时间。

最后是数据分析的效率，我们希望越来越多的人能够基于数据进行分析决策，但是数据分析本身确实存在门槛，取数对于大多数非技术专业的运营和分析师就是一个大问题，经常看到一个分析师的 SQL 把整个集群资源跑满还跑不出来，经常看到分析师遇到一个 SQL 异常不知所措。另外，传统的数据分析依赖的是分析师的经验，一个指标异常波动，需要从哪些维度去分析，完全靠分析师的个人技能，如何将经验变成一种知识，甚至是一种规范，沉淀到产品中，通过系统自动地进行全维度的钻取分析，降低数据分析的门槛，这其实也是业务面临的难题。

质量是数据中台需要解决的第二个问题，质量包括数仓设计的质量、指标的一致性、数据研发的质量。

数仓设计得好不好，主要体现在三个方面，完善度、复用性和规范性。数仓设计一般采用的是面向主题域的分层设计，对于 ODS 层保存的是业务原始数据，DWD 保存的是经过清洗的明细数据，DWS 是经过轻度聚合的汇总数据，ADS 或者 DM 是应用层、集市层数据，这是一个常见的 4 层模型划分。完善度的意思就是对于使用者而言，“要啥有啥”，对于不同分层，完善度的衡量方式也是有区别的，对于明细层，如果数仓中存在汇总层（DWS）数据直接引用 ODS 原始数据的情况，我们称之为跨层引用，这就说明细层数据建设是有缺失的，如果其他汇总层也要使用相同的数据，都从 ODS 层去引用，就存在重复清洗的问题。对于汇总层数据而言，如果 Query 覆盖率比较低，说明大量的查询都是直接查询明细数据，甚至是原始数据，这就说明汇总层数据建设完善度不够，对于使用数据的人而言，查询明细数据，不仅慢，而且查询成本高，经常出现一个查询 hang 住整个集群的情况。复用性主要强调的是一个表被多个表使用的情况，复用性越高，说明数仓的设计越合理，更多的数据在数仓被复用。规范性主要是指数仓中的表、字段的命名规范统一，相同指标、维度、度量的标识是一致的。

指标是数据加工的结果（也可能是中间结果），指标管理的核心在于确保指标的业务口径、计算逻辑和数据来源的一致，消除指标的二义性。数据开发经常遇到的一个情况是，两个数据产品，看到相同的一个指标，结果不一致，这可能是口径不一致导致的，当然也有可能是数据来源不一致导致的。

质量还包括数据的质量，这里面包括数据的一致性、准确性、及时性以及完整性。数据的一致性，具体表现在集市层相同的指标数据是否一致，维度是否一致，相关指标的趋势是否一致，不同数据源对同一个实体的值是否一致。准确性体现在数值计算的逻辑是否符合预期，数据格式是否正确。曾经我们有过一个深刻的教训，在电商业务中，由于业务侧更新上线后部分 IP 格式有问题，导致流量域、交易域部分指标出现异常波动。由于没有对数据进行质量稽查，问题的排查和定位花费了大量的时间。及时性主要体现在数据产出时延，我们一般通过数仓数据在指定时间（比如 5 点之前）产出完成率来衡量。另外对于实时数据，对时效性要求比较高，我们会拿数据计算延迟来衡量。完整性主要是表记录是否完整，包括记录数是否完整，字段是否完成。

成本是数据中台需要解决的第三个问题，成本包括计算资源成本、存储资源的成本以及人力研发成本。

数据就像手机里面的文件，如果不定时清理，手机存储空间永远不够用。我们经常发现，大数据成本比业务增长还要快，这一方面是由于烟囱式的开发导致的数据重复加工，浪费计算和存储资源，另一方面也是由于没有定时清理，及时将无用的数据和任务下线，导致已经没人看的报表，每天还从几十亿行的原始数据进行计算加工，浪费大量的资源。人力的成本其实跟效率有关系，如果效率得到提升，研发成本也会得到控制。

效率、质量、成本，这三个方面相互联系，我认为这是数据中台要解决的最重要的三个问题。

如何建设数据中台？

接下来我们要讲讲如何建设数据中台。建设数据中台，本质上是要减少数据的重复建设，提高数据的共享能力，做好数据的连接，对应的就是 OneData、OneService 和 OneEntity 三个方法论。OneData 要求数仓所有数据只加工一次，对应到数仓的设计层面，要求有统一的维度，对于明细层数据，相同粒度的度量只加工一次，对于汇总层的数据，相同粒度的指标只存在一份。OneService 是统一查询服务，原先数据开发和应用开发的边界是比较模糊的，哪些逻辑应该是由数据开发完成，哪些应该是由应用开发完成，我们甚至发现有些计算是在一个超大的 Redis 集群里面完成海量数据的加工计算，成本非常大，且不能共享。数据服务划清了数据和应用的边界，数据服务提供的是加工好的指标数据，应用通过数据服务，直接获取计算的结果，强制把公共计算逻辑下沉到数据层面，提高了数据的共享能力。OneEntity 主要是解决数据连接的问题，同一个用户，由于用户是否登录，在同一个模型中，可能存在重复的记录，如何识别两个 ID 是同一个用户，做到所有用户只有唯一的 ID 标识，这个是 OneEntity 要解决的问题。

对于三个方法论，我们的经验是必须通过系统化的方式，将规范沉淀到系统中，确保建设的效果。为了支撑数据中台的建设，我们研发了一套全链路大数据产品，  网易猛犸 6.0，其架构图如下：

全链路大数据产品网易猛犸 6.0 建立在 Hadoop 基础之上，包括 16 个子产品（上图中绿色模块标识部分），覆盖了数据生产、治理的完整链路，本着“简单易用，举重若轻”的产品设计思想，我们采取了“组件式”的产品设计模式，每个产品都聚焦一个典型的场景，业务可以根据自身的需要，选择性的搭配一些产品应用，解决业务当前面临的问题。同时猛犸 6.0 具备可扩展的产品架构，业务方可以基于该产品提供的基础能力，扩展新的产品。

全链路大数据产品网易猛犸 6.0 在大数据开发、任务运维、数据集成等大数据平台的基础上，主要增加了两个板块，一个是 OneData 体系，它是以元数据中心作为基础的，在元数据中心之上提供了 5 个中台相关的产品：数仓设计中心、数据资产中心、数据质量中心、指标系统和数据地图。

数仓设计中心：按照主题域、业务过程，分层的设计方式，以维度建模作为基本理论依据，按照维度、度量设计模型，确保模型、字段有统一的命名规范。
数据资产中心：主要作用是梳理数据资产，基于数据血缘，数据的访问热度，做成本的治理。
数据质量中心：主要是通过丰富的稽核监控规则，对数据进行事后校验，确保问题数据第一时间被发现，避免下游的无效计算，分析数据的影响范围。
指标系统：管理指标的业务口径、计算逻辑和数据来源，通过流程化的方式，建立从指标需求、指标开发、指标发布的全套协作流程。
数据地图：提供的是元数据的快速检索，数据字典、数据血缘、数据特征信息的查询，相当于元数据中心的一个门户。
另外一个板块就是 OneService 体系，对应的就是数据服务。数据服务对外提供 Restful API，屏蔽底层各种数据源，加工好的指标，导出到 Greenplum、MySQL、Redis、HBase 里面进行查询，数据服务将用户访问的 Restful API 转化为底层对各种数据源的访问。数据服务可以认为是数仓的网关。

在数据服务之上，就是应用层，这里可以分为两类，一类是通用性数据应用，包括报表系统、大屏系统、自助分析系统，本身不具备行业属性，任何业务都可以使用；另一类是行业性的数据应用，比如电商的供应链系统、传媒的舆情系统。在我们的数据中台划分中，通用性的数据应用也被划入了中台的范围内，因为中台本质是提供共性能力，对于数据中台，就是提供共享的数据。

数据中台的价值数据中台是一个自上而下的工程，需要投入大量的人力和资源，很多企业想做数据中台，却又不知道如何去衡量数据中台的价值，下面结合网易的实践，给大家一些参考。

消除指标的不一致：在做数据中台之前，指标业务口径不一致，数据来源不一致，计算逻辑不一致，经常是造成同个指标结果不一样的原因。通过指标系统，我们对所有数据产品的指标进行了全面梳理，按照主题域、业务过程进行划分，对指标按照原子指标和派生指标进行拆分，消除冗余指标、无效的指标，明确所有指标的业务口径、计算逻辑和数据来源。通过指标系统，我们可以快速的查询，数据产品上直接引用指标系统的业务口径，在数据产品上，我们完全消除了指标的二义性。
数仓设计水平提升：在做数据中台之前，我们有大量的表没有明确的主题域和业务过程划分，大量汇总层数据直接引用原始数据，ODS 层有大量的任务直接引用，大量 Query 直接查询原始数据。在数据中台建设后，整个数仓水平上了一个台阶，不仅所有数仓维护的非中间表均有明确的主题域和分层，并且完全消除了汇总数据直接引用 ODS 层原始数据的情况，数仓表的复用性显著提高，汇总层 Query 的覆盖率明显提升。
取数效率提升：在做数据中台前，大量的数据发现都是通过人工协作交流的方式进行的，数据理解的准确性、效率都非常低。基于数据地图，我们实现 100% 自助取数，取数效率提升 300%，分析师满意度得到大幅提升。
数据质量的提升：在做数据中台前，数据经常无法按时产出。我们规定每天 6 点前数仓的数据要产出完成，但是往往达不到这样一个要求，出现一个异常，经常被业务方投诉，而排查和定位一个故障，也需要大量的时间，有了数据质量中心后，通过大量的稽核监控规则，我们做到了先于使用数据的人发现数据的问题，并且基于全链路的监控，我们可以知道某个任务异常，影响了哪些指标，并且基于任务的历史运行数据，对故障恢复时间进行预测。
数据成本减少：衡量这个其实是最简单的，直接就看数仓消耗的资源，原先是多少，数据中台建设之后又是多少，当然这里面存在业务增长的情况，我们核算的方法是把单个任务的成本占优化任务时，数仓消耗的当日成本占比，作为衡量指标，我们最终通过下架无用的、低价值的表和任务，为业务节省了 20% 的成本。

实施数据中台的建议

在文章的最后，我想给即将做数据中台，或者正在做数据中台的同学一些建议。

首先要有目标和度量，不管是做质量，还是成本，还是效率，没有目标，没有度量，就很难讲的清楚效果。其次，要通过系统化的方式对规范和方法论进行沉淀。数据中台不是一次性的事情，做质量，稽核监控规则要不断的完善，治理成本，任务和表的优化要持续进行。所以必须要有系统和产品做支撑。

最后，做数据中台必须要实现全链路，各个子产品要相互打通，BI 产品可以引用指标系统的口径定义，任务运维中心任务异常可以追踪到影响了哪个 BI 报表，数据资产必须要知道哪个 BI 报表访问了那个表，才能知道哪个报表的哪个指标消耗了多少资源，计算指标的 ROI。

作者简介：
郭忆，网易杭州研究院大数据专家，网易大数据平台网易猛犸、网易敏捷 BI 产品网易有数负责人。10 年互联网数据研发经验，曾经做过数据库，主导了网易关系数据库服务 RDS 建设；做过推荐工程，负责网易信息流推荐服务；目前主要从事企业级数据中台支撑产品以及通用型数据应用的研发，支撑网易电商、音乐、传媒等业务的大数据建设。