AIGC 应用、数据分析等企业 10+ 热门专题课,就在极客时间企业版>>> 了解详情
写点什么

网易数据中台建设实践

  • 2019-11-28
  • 本文字数:5628 字

    阅读完需:约 18 分钟

网易数据中台建设实践

AI 大模型超全落地场景&金融应用实践,8 月 16 - 19 日 FCon x AICon 大会联诀来袭、干货翻倍!

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


数据中台是什么?

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


公众号推荐:

AGI 概念引发热议。那么 AGI 究竟是什么?技术架构来看又包括哪些?AI Agent 如何助力人工智能走向 AGI 时代?现阶段营销、金融、教育、零售、企服等行业场景下,AGI应用程度如何?有哪些典型应用案例了吗?以上问题的回答尽在《中国AGI市场发展研究报告 2024》,欢迎大家扫码关注「AI前线」公众号,回复「AGI」领取。

2019-11-28 09:0711257
用户头像
赵钰莹 InfoQ 主编

发布了 880 篇内容, 共 618.2 次阅读, 收获喜欢 2674 次。

关注

评论 2 条评论

发布
用户头像
讲的很清晰,数据研发方法论太多了。
2020-04-30 16:13
回复
用户头像
谢谢
2019-11-28 17:43
回复
没有更多了
发现更多内容

注入js编程应该知道的一些基础知识,以防混淆造成的错误

Geek_ee6d52

「全栈低代码」时代开启,页面开发/数据处理/复杂逻辑,统统一站搞定!

优秀

低代码 全栈低代码

QCN9074, QCN6274 ,QCN6224- High performance - low power - for wide range of application

wifi6-yiyi

QCN9074 QCN6224

GPTCache:大模型时代的应用缓存

百度开发者中心

人工智能 智能客服 大模型 ChatGPT

Anthropic模型Claude 3 Haiku现已在亚马逊云科技Amazon Bedrock上正式可用

财见

[目标检测]基于YOLOV8的自定义数据集实现水印检测

alexgaoyh

yolov8 ultralytics 自定义数据集 水印识别 模型训练/测试

企业有官网了还有必要做小程序吗?

天津汇柏科技有限公司

软件开发定制

一文带你详解天池电商数据集

阿里云天池

阿里云

一文带你详解天池工业数据集

阿里云天池

阿里云

Walrus 0.6发布:预览资源变更、丰富公有云支持,满足企业多云需求

SEAL安全

开源 云原生 Walrus

iframe自动化革命:颠覆传统网页嵌入的新趋势

测试人

软件测试

CheckBook Pro for mac(优秀的个人理财管理软件) v2.7.29激活版

影影绰绰一往直前

Navicat Charts Viewer for Mac(Navicat图表查看器) v1.2.16激活版

影影绰绰一往直前

零基础入门数据挖掘系列之「建模调参」

阿里云天池

阿里云

「数据分析」之零基础入门数据挖掘

阿里云天池

阿里云

文心一言赋能问卷生成,打造高效问卷调研工具

飞桨PaddlePaddle

json 百度 百度飞桨 开发者说 文心一言

Datawhale 零基础入门数据挖掘-Task1 赛题理解

阿里云天池

阿里云

Python实践:基于Matplotlib实现某产品全年销量数据可视化

华为云开发者联盟

Python 后端 开发 华为云 华为云开发者联盟

如何实现对iframe的自动化测试,一篇文章告诉你

霍格沃兹测试开发学社

FastGPT:大模型应用的新里程碑

百度开发者中心

人工智能 大模型 自然语言理解

研华发布新一轮企业战略框架 迎向AIoT + Edge Computing新机遇

财见

网易数据中台建设实践_服务革新_郭忆_InfoQ精选文章