网易云音乐数仓建设之路

Posted 过往记忆

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了网易云音乐数仓建设之路相关的知识,希望对你有一定的参考价值。

网易云音乐作为一个MAU已经超过亿级的业务,在数据仓库、数据体系、数据应用建设是怎么做的?在近日举办的“网易数帆技术沙龙”上,网易云音乐数据专家雷剑波就此话题做了全面的分享,介绍了数仓建设的目标,为此建立的一系列规范和机制,如何通过系统保证这些规范和机制的落地,以及取得的效果。

数仓建设痛点与目标

当时整个云音乐数仓体系的背景,因为云音乐的MAU、DAU增长非常快,各个业务其实相对比较独立,整个数据也比较散,就是说体系方面,包括设计规范、开发规范,大家都是按照自己的理解在做,因为要快速去支撑我们的业务发展,是贴着业务在做,发展到2019年年中,它的整个规模,MAU已经到亿级了,如果还是按照之前那种“小米加步枪”的方式,最明显的一个问题,就是创新业务要发展的时候,数据拉通不了,每次都要另行开发,成本非常高。

在规范上面没有一致的理解,同样的一个字段命名,其实它背后代表的口径可能完全不一样,也没有一个地方去沉淀落地这样的东西,我们在19年中开始做整个数仓体系的改造,因为之前其实前台也做了很多的数据沉淀。

为什么要做这件事情,从业务的角度来讲,最本质的是要降低数据使用门槛,还要提升数据利用的效果,最后是数据能够驱动业务增长。

云音乐数据的消费方主要包括三类人,一是分析师,他们要做各种报表,出分析报告,供高层做战略决策参考,他们希望数据指标一致,并且容易看出各个指标背后代表的是什么口径,维度要多样,指标要丰富,还要支持方便的交叉分析。

二是算法,他们要求数据产出稳定,最好能够实时,且质量可信,还能够提供一些标准化的服务(API),数据同步方便,支撑模型高效迭代。

三是产品运营,分析师的资源、数据开发的资源很紧张,如果都依赖我们给他们出数据,他们会很痛苦。一个产品灵感,可能今天或者明天就希望去迭代,去做一些AB测试,我们有没有这样一个产品或一个数据工具提供给他们,让他们快速验证一些想法,去迭代他们的产品?

基于这三个业务目标,我们做整个数据体系的改造,根据我们的现状,总结起来就要做三件事情。

•第一件是要规范化,要制定整个云音乐数据仓库的公共规范,包括开发规范、指标规范,并拉通整个数据仓库的模型,各个业务方不再是各自为战,当他们需要跨业务获取数据时,能够快速定位到从哪里获取。•第二件是共享,算法怎么能够便捷地拿到数据,之前的方式是调我们的文件,这样的问题是数据血缘无法追踪,他们很难管理数据怎么使用,那么我服务化怎么做,才能更高效地支撑他们。•第三件是自助化,我们跟数帆共建了一个easyFetch自助服务,打通了数据配送的最后一公里,让我们产品运营能够直接去使用公共数据资产,去进行一些数据的探索验证。

整个数据体系采用当前业界主流的架构,底层是数据源、日志流量,包括结构化的数据,中间层我们基于网易有数大数据开发及管理平台做的数据中台,上层是数据服务、数据应用。数仓今年的一个重点是做实时计算,把流批打通。整个体系的关键词是希望能做到 “高质量、高稳定、高效率、低成本”

今天我会重点分享两大块内容,第一块是网易云音乐流量数据的治理,第二块是我们怎么来建设数据资产。为什么要讲流量数据治理?因为云音乐作为一个内容型的泛娱乐APP,90%的数据分析、决策都是基于流量来做,所以我们底层埋点数据好不好、规不规范,直接决定了后面数据资产沉淀以及整个数仓体系做得好不好。

流量数据的目标是要做到标准化、自动化,按规范产出数据,同时能够资产化,可以通过easyFetch获取,或者通过我们的数据产品——流量罗盘,比较直观地看我们的流量。

数据资产沉淀,我们希望尽量丰富我们的维度,做更多精细化的东西,在DW层能够基于不同的维度、不同的粒度去做更多的明细和汇总数据。此外还有场景化,像ADS层建设,实现push、短信、私信、投放等全流程的数据贯通。

流量数据治理

首先讲流量数据治理。刚到云音乐的时候,我试图去回答几个问题,云音乐到底有多少个埋点?每个埋点的格式,这些Key-Value有没有地方可以查?比如首页的数据,我怎么能够快速定位到其中的某个模块,它今天的流量是多少,来源在哪里?我发现找不到这样的东西,各个团队埋的点在各个人的手里,有Excel管理的,有文档管理的,有wiki管理的,没有落系统,格式非常混乱,需要去问各个开发。数据质量也非常低下,因为没有人负责,前端开发只管功能,数据只管产出,不究对错。由于这些情况,没法拉通数据,开发效率也不可能高。看数对于业务来讲也会很困难。

基于这些痛点,我们做了几件事情,分成事前、事中、事后。事前,既然你没有规范,大家各自干各自的,那我们就先去抽象埋点。网易云音乐数据链路不长,但是互相跳的网状非常多,而且非常深,市面上的埋点工具满足不了我们要看那些埋点数据的需求。包括SPM、SCM那一套,因为它本身聚焦电商场景,只要看商品页面就OK了,没有我们要看的一些很深的内容。

所以我们自己抽象了一个埋点规范,借鉴了电商场景下的埋点三要素,在上面叠加一些东西,包括SPM、SCM内容里面的Key-Value怎么定义,比方说我们的一些资源ID应该怎么命名。我们首先把这些东西规范化。怎么来保证这些东西是规范的?我们跟数帆共建了一个easyTracker产品,把埋点录入到系统,系统上面我可以去做一些规则的校验,这样后面生产出来的数据才是干净的。

事中,我们现在推动数据开发和前端开发,要有一个埋点评审的环节,确定埋点设计是否合适,是不是一定要加这个流程。

事后,因为在埋点上线以后数据没法回滚,如果数据有错就只能用错的,所以我们做了一个灰度埋点数据稽核的工作。在灰度期间,比如说放量放了10万的时候,我们看埋点勾兑关系是否OK,如果发现有问题,就不能发布到正式版本上。我们还做了一个叫做流量罗盘的数据产品,easyFetch也上了我们流量数据自助查询。

对于原先的7.0、6.0等老版本,我们人肉去把这些埋点一个个测出来,梳理了将近8000多个埋点,归一化了3000多个坑位,就是说这8000多个点可能是不同版本、不同端打的格式不一样,我们人肉把这些坑位归一化,通过脚本处理实现兼容,基本满足了90%以上的用户的流量查询需求。

对于新增的埋点,有了规范和系统以后,我们可以通过系统的接口实现迭代。因为我们一直track它,可以每周去抓它的埋点定义,通过日志上报以后,两边去结合去配置,通过半自动化的ETL方式,每周迭代我们新上的埋点。这样实现以后,整个DWD的流量加工时长缩小了将近4个小时

最后小结,流量数据治理我们主要做了埋点规范,easyTracker系统的使用,还有数据资产的盘活,包括我们如何快速产出埋点流量,最后反馈给到前端的开发。从数据可以明显看到,我们双端埋点线下bug率都降低了很多,安卓端埋点线下bug率从年初的9.10%下降到年末的4.07%

数据资产沉淀

第二个内容,有了前端的这些流量数据以后,我们怎么做数据资产的沉淀。第一个痛点,刚才提到最开始云音乐整个数据资产是孤岛化的,要跨业务拉通的时候,复用性比较差。

第二个是云音乐每一年都会有一些大版本的迭代,尤其是去年8.0的改版,有一些创新业务的融合,比方说K歌,还有大社区的业务改版,整个业务迭代非常快,在这种情况下,如何尽量保持底层数据的稳定。

第三个是我们的数据交付上面,由于之前的整个开发过程不透明,源头的流量数据比较脏,我们整个产出的数据质量一直被业务方诟病。

基于这三个痛点,我们的目标是构建“OneData”,整个数仓的过程是一个从无序到有序的熵减的过程,一份数据出来是一个口径的,一个出口的,而不是说甲出这个指标,和乙出这个指标出来的数据差很多,否则会引起分析师或者上层的决策的困惑。

今天重点分享我们如何建设数仓。云音乐是围绕参与者和内容构建的一个业务场景的闭环,基于这个特点,云音乐主题域的划分和电商平台不大一样,我们划分了5大主题域。主题域之外,我们又划分了二级主题,平常主要使用的就是二级主题,比方说参与者我们又把它细分成用户、艺人、音乐人,以及To B的一些版权公司,因为做结算也是一件大事。

服务及产品,我们又把内容分成了UGC跟PGC的内容,云音乐最大的内容是歌曲,它是一个PGC的内容,现在也在主推一些视频、短视频的内容,包括之前云音乐最火的评论,这些是UGC的内容,这也是一个很丰富的数据的源头。

在业务过程,我们最关注的是交易营收、社交互动,比方说点赞、评论,哪些用户互动的比较多,还有流量分发好不好,以及营销活动。

层次划分跟业界大同小异,包括ODS层、DWD层、DWS层和ADS层。在DWS层,我们稍微拆细了一点,轻度汇总和重度汇总会有相对明确的定义,轻度汇总我们会尽量保留一些维度,重度会基于轻度汇总去往上去叠加加工,而不是直接依赖DWD产出数据。

DIM层,我们尽量把一些像用户、资源的东西贯穿整个中间层的建设。

整个架构,在最底层是各个业务过程的一些事实表,在DWD层我们把所有东西都给保留下来。在DWS层我们会分,比方说单用户+单实体的一种方式往上去聚一个DWS,在单实体这块,我们又会一条线往上去聚,这块是在整个业务发展过程当中不断摸索出来的,最开始我们都是笼统的单用户+单实体这种方式去做,但是后来发现满足不了业务需求,都要从DWD层出数据,产出效率非常低。

DWS层我们最开始建得比较薄,随着业务的迭代,看数的需求从不同角度发展,我们在DWS这一层才不断做厚。

在模型构建的原则上面,我们说尽量是能够高内聚、低耦合、强复用。其实这一块我们也趟了很多坑,最开始我们做DWS层的时候,都是从DWD直接往上聚,尤其像一些历史累积数据,如30天的汇总。对于体量不大的创新业务,比如一天只有几十万DAU的,回溯一个月的数据可能一个小时之内就能跑出来。但对于云音乐,它一天的日志量是千亿级的,一旦数据跑错或者口径要调整,耦合性非常强的话,跑30天数据可能一个上午就没了,对数据产出影响非常大。

还有整个运营方式的解耦,即增量和历史累积的全量怎么拆,我们经历很多血泪教训以后,把上图右边的示意图给抽象出来了。最开始我们从ODS层到DWD层,这没什么好讲的,因为DWD就是一些明细的事实。到DWS的时候,我们首先做一些轻度汇总,这种轻度汇总我们会尽量保留业务可能会用到的一些维度,但不保留维度属性,这样减少我们存储的成本。

在DWS层往下偏重度汇总的时候,我们会往几个方向去做厚DWS,一个是内容单实体,也就是一些资源类的,如歌曲、视频、mlog评论,再上面去做一些指标的聚合加工。一个是用户单实体,因为我们经常会看用户的一些行为,会往用户单实体上面挂一些指标。再往上到ADS层做一些大宽表的时候,我们再把这些内容、用户本身的维表属性合进去,生成整个大宽表。这种大宽表对分析师或者说产品运营来说很友好,他们不用关心底层的细节,只要上面有他们要的指标、维度就可以了

这样拆的一个好处,我们在加工的时候,增量表调度的时候,如1/7/28的表我们单独一个flow流,历史累计的单独做一个辅助流,这样在做数据回溯的时候,1/7/28我们可以并行去跑,历史累积的,因为需要每天去回溯、累计,就只能串行,这样就会把整个资源给拆开,同时像1/7/28日的指标,我们可以一次性去扫底层的分区,因为对大数据量,你一旦多几天的分区,它可能跑得慢很多,甚至倾斜的情况也会发生。这就我们在整个建设过程当中遇到的很多坑。

第二点就是我们在真正落地之前,我们也做了很多规范的落地,这也是依托了网易数帆上线的模型设计中心。因为规范这个东西,我要怎么做调度,字段要怎么命名,指标要怎么做,嘴上很好说,文档也好落,但是怎么在一个正式的环境当中让大家去遵守这个规范,就需要有系统去支撑。

有了模型设计中心,我们上线一个中间层模型的时候,必须要通过这个模型设计中心去注册登记,它是属于是什么域的,每个字段的命名,我们也会做一些规范,做一些强规则校验,然后要资深的模型师去评审,通过以后才会建表,走flow流的建设。我们做了很多规范,80%的规范已经在这个模型设计中心落地。

还有一点,之前经常会出现脚本随意更改,因为没有人去check或者说没有权限去做控制。尤其是新模型上线比较随意,可能过几天才发现数据不对,因为上游可能根本没有做任何数据测试。对此数帆提供了一个测试中心easyTest,常规的空值、数据波动,这些不需要配置,跑完以后系统会直接告诉我们字段的空值占比是多少,最大、最小值是多少,看一眼就能发现有无问题。

复杂一点的,需要勾稽关系的,可以自己在测试中心配置脚本,根据经验去测试。有这个系统以后,我们可以减少一些低级问题发生。

同时我们还有一个流程协作中心,确保必须通过评审验收以后才能够上到生产调度环境,这样把测试环境跟生产环境进行隔离。

我们社区的一个业务实践,流量数据从最左边过来,我们在DWD层做了各种社交互动的事实表,在DWS层我们做一些轻度汇总,把点赞、分享、评论、播放合在一起,因为下游会经常看点赞的来源是什么,播放的来源是什么,通常要锚定某个点,我们这边主要锚地播放,就是说播放是从哪个页面来的,至于后面的点赞、分享、评论也是锚定播放来,所以我们把这几个社交互动的行为放在一张表里面了。

再往后我们把历史累计指标拆出来,减少数据调度的困难,最后生成一张mlog大宽表,这样分析师和产品运营只需要关心这张表。

通过这样的改造,我们整个数据的产出提前了三个小时,口径也统一了,之前因为点赞、分享自己做一套归因,和播放的不一样,需要另外去查。另外,easyFetch的使用率也是非常高的。

有了这些数据资产,怎么触达我们的用户(即产品运营和分析师),让他们知道我们有了这些东西,并且来使用这样的东西?这就是为什么我们要跟数帆共建easyFetch的自助服务产品。

这个自助服务对于数据开发来讲,只要类似配报表一样的工作,把模型灌进去,字段配上去,就可以用了,难点不在于技术,而是在于怎么培养我们的用户习惯。因为之前资源充足的时候,产品运营习惯于给分析师、给数据开发提需求,轻松地获取他的数据。

为此我们做了很多的工作,从高层到下面的开发,我们做了很多沟通、培训,组建了专用群,进行一对一的辅导,还做了一些措施:针对系统上已存在的数据,相关的需求我们往后排,因为你不愿意使用我们已经生产好的数据,而且使用能力的习得成本也不高。

通过这些措施,到2020年底我们整个UV、PV的使用量还是很高的,easyFetch现在用户量已经达到400多,周UV已经达到180多个, 周PV是7000多个。如果不考虑重复调用,这就是7000多个需求。如果没有这个系统,我们100个人,1个人做7个需求,一周也只能支撑700个需求。

有了这样的一款产品,我们整个数据交互方式改变了很多,而且用户可以自由地去探索他们自己要的一些数据,校验自己的想法。回顾一下我们数据资产沉淀的工作,第一个就是建规范,第二个是立机制,第三个是数据资产,第四个是服务化,通过这么几轮的下来,形成整个云音乐的数据体系,包括我们数据产品不断扩充,今年和2020比在2019年之前,整个数据使用体验上面的改进非常多。

接下来我们还会重点往数据实时化做一些尝试,尤其在流批一体这一块也是和数帆去共建,这一诉求主要来自算法,他们特别希望能拿到分钟级或者小时级的数据去做模型训练,因为现在天级的数据给到他们,像歌曲推荐、搜索模型训练的效果会打很大的折扣,他们希望我们在这一块能够给到更多的支撑。我的分享就到这里,感谢各位。

作者简介

雷剑波,网易云音乐数据专家,长期从事大数据开发、数仓体系建设,聚焦模型设计、数据规范、数据应用、数据治理等方向。目前主要负责网易云音乐主App的数仓体系架构和数据埋点体系升级等工作。

PPT下载:网易云音乐数仓建设之路 https://sq.163yun.com/resource/download?id=565376740635103232&fileId=565376735706796032

视频回放:网易云音乐数仓建设之路 https://www.bilibili.com/video/BV1To4y1C7i7

以上是关于网易云音乐数仓建设之路的主要内容,如果未能解决你的问题,请参考以下文章

进击的 Flink:网易云音乐实时数仓建设实践

实时数仓系列-网易云音乐基于 Flink + Kafka 的实时数仓建设实践

网易云音乐实时数仓2.0进阶之路

网易云音乐实时数仓2.0进阶之路

网易云音乐的消息队列改造之路

网易云音乐工程师,亲自揭晓消息队列改造之路! | 技术头条