网易数据中台建设实践

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

 

数据中台是什么?

从 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 建设;做过推荐工程,负责网易信息流推荐服务;目前主要从事企业级数据中台支撑产品以及通用型数据应用的研发,支撑网易电商、音乐、传媒等业务的大数据建设。

posted @ 2019-12-10 15:02  网易数帆  阅读(1418)  评论(0编辑  收藏  举报