网易云音乐作为一个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%。

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

数据资产沉淀

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

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

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

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

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

今天重点分享我们如何建设数仓。云音乐是围绕参与者和内容构建的一个业务场景的闭环，基于这个特点，云音乐主题域的划分和电商平台不大一样，我们划分了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天数据可能一个上午就没了，对数据产出影响非常大。

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

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

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

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

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

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

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

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

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

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

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

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

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

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

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

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

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

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

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

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

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

作者简介

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

PPT下载：网易云音乐数仓建设之路 https://sq.163yun.com/resource/download?id=565376740635103232&fileId=565376735706796032
视频回放：网易云音乐数仓建设之路 https://www.bilibili.com/video/BV1To4y1C7i7