如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据
第二个内容，有了前端的这些流量数据以后，我们怎么做数据资产的沉淀。第一个痛点，刚才提到最开始云音乐整个数据资产是孤岛化的，要跨业务拉通的时候，复用性比较差。
第二个是云音乐每一年都会有一些大版本的迭代，尤其是去年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
