网易云音乐数仓建设之路原创

嗯，各位小伙伴下午好。就是刚才各位老师他们讲的都是偏硬件或者技术组件的一些工作，那么我这里相对来说，呃，没有那么高深，那么偏上层的一些数据应用的一些，呃呃，一些事情，那么作为管于云音乐mau已经超过一级的，那么我们在这个呃，数仓建设，包括整个数据体系，数据应用怎么来做呢？今天抛砖引玉，跟各位专家做一个交流，那么在正式之前呢，我想做个调研，就是在座的同学有多少是做数仓的或者数据产品应用的，大家举个手示意一下。好，OKOK，那也有将近1/2好的没没做这个的，其实其实也可以听一下，就是因为我们这块，呃，相对来说没有之前各位老师讲的那么那么高深，嗯，那么按照惯例，我还是先简单自我介绍一下，就是我是一八年加入网易，那么最开始呢是做呃，在网易行研从事的数据中台，那么那时候就不单单是云音乐了，那还有传媒呃，新闻呃，其他的一些数据，嗯，然后在一九年年中我加入了网易云音乐，那么负责整个数仓体系的一个建设。

好的，嗯，然后看一下，呃，就是整个云音乐，我当时过来的一个数仓体系的一个背景，就是当时刚过来，因为云乐它的发展很快，它的MMAUDAU增长非常快，所以它整个各个业务其实相对比较独立的，那整个数据呢，它也呃比较少，就是说体系方面啊，包括设计规范方面啊，还有开发规范嘛，大家都是按照自己的理解在做，因为我要快速去支撑我们的业务发展，是贴着业务在做，那么发展到一九年年终，他的整个规模已经到m muu已经到一级了，那如果还是按照之前的那种小米加步枪的方式，那我就最明显的一个一个问题，就是说我要拉通数据的时候，我再上传，要去类似比方说我做to去做短信，在创新业务去去做发展的时候，那就会面临很大的一个问题，我数据拉通不了，我要都要每次都要去进行开发，那这个成本就非常高。

然后在规范上面没有大家在理解，比方这个字段，同样的一个命名，其实他可能后面背后代表的口径是完全不一样的，那也没有一个地方去沉淀落地这样的东西，嗯，那么提出了我们在一九年中开始做整个数据的一个改造，应该说是更更准确来说是一个数仓体系的一个改造，而不是建设，因为之前其实也做了，前呢也做了很多的数据的一些沉淀。呃，然后回到就是我为什么要做这件事情，那么从业务的角度来讲，他是希望我能够呃更高效的，就是最最本质的来说，我还是要降低他的一个数据门使用门槛，还要提升他们的数据利用的一个效果，然后最好能我能我们数据能够驱动它业务增长，对吧？那么呃，数据的消费方，其实我们云乐其实主要是三大块，一个是分析师，那这个比较好理解，因为他要做各种报表，他要出分析报告，他要去去出一些这种给高层做的一些战略决策，那么他们希望的说，我的数据指标一致性是非常非常好的，我看到这个指标就是我望文就能生意，我就知道这个背后代表的是什么口径，那我维度要足够丰富，我的指标要足够多，他能够做一些很多交叉的分析，那对于算法来讲，他要求我数据产出很稳定，嗯，最好是能够实时，然后质量要可信的，然后还能够提供一些。

比较标准化的服务就是API啊，包括我们能够数据能够比较方便的一些同步啊，支撑它的一些高效的迭代，那第三块呢，其实由于互联网这个发展，现在很多产品运营，他们也有写实和能力，或者他们也呃因为分析师的资源，包括我们数据开发的资源其实很紧张，那么他们如果都依赖我们给他们出数，其实他们也很很痛，他们一个产一个产品灵感，可能今天想到他就想明天就去迭代，去去做一些AB去先尝试，那么他们也有这样的数据S，那么他们我们有没有这样的一个产品，或这样的一个数据的一个一个工具提供给他们，说怎么快速的去验证他们一些想法，去迭代他们的一个产品，那么基于这三点我们做的，呃呃，整个数据的一个体系的一些改造。

呃，刚才讲的就是业务目标，那么包括背景，那么我这里总结起来就是我们在数据改体系改造上面要做的三件事情，第一件呢，就是说首先要规范化，就是说我要制定我们整个数云乐的数据仓库的一个公共规范，包括开发规范，包括一些指标定义啊，然后要拉通整个数据仓库的一个模型，就是在不是各个业务方各自为战，我本社区也好，我的平台内容也好，我是要能够拉通的，各自都能够去，当他想要跨业务去要这个数据的时候，他能够快速的去去定位到我从哪里去取这样的东西，然后第二个就是共享，共享这个就是对于算法来讲，他就怎么能够便捷的拿到他的数据，之前的话很多方式他们是调我们的文件，那再一个很大的问题，我学员追踪不到，然后他们很难去管理到他们的数据是怎么来，怎么来使用，那么我我我这个服务化怎么怎么来做，怎么能更。

高效的。支撑到他们那第三点就是自助化之后在这一块呢，我们就跟行研呃共建了一个E，就自助服务，就是打通了整个数据配送的最后一公里，就是让呃我们产品运营能够直接去使用呃我们的公共的数据资产，他们去进行一些嗯数据的一些探索验证，这是我们的目标。呃然后这个架构图，这个其实是跟业内比较通用的，我们现在目前的主流还是做的是单架构，嗯从底层的数据源就是日志流量啊，包括一些结构化数据到上面的，我们基于网页猛马做的数据，呃中间层数据中台，然后在上面的一些数据服务，呃数据应用这一块，然后这一块我们今年重点在做的一些实时计算，包括现在还在跟呃，包括姚老师这边我们在做一些这种实时的，还有P6一体的这一块东西，现在这一块也是我们今年会重点去把流批这一天，呃，就是能够打通的那关键词，就是说我们。

希望能做到高质量、高稳定、高效率、低成本。呃，那今天我会重点分享两大块内容，第一块呢，就是网易的我们云乐的一个流量数据的一个治理，第二块是一个我们建设这个数据，数据资产是怎么来来建设，那么为什么要讲这个流量数据治理呢？这一块是因为云音乐做一个，就是做内容型的泛娱乐的这个 APP90%的我们的。

平常的一些数据的分析，包括他的一个决策都是基于流量在做，那么我们的这个底层的这个买点数据好不好，嗯。规不规范直接决定了我们后面数据资产沉淀，我们整个数仓体系做的好不好，那么在呃直销求会讲，就说为什么要做这个事情，因为它非常痛，那我的目标就是说流量数据自己，我要做到一个标准化，做到一个自动化，就是我能自动产出我要的按规范产出的这些流量的数据，最后还要能够资产化，就是我能够通过Fla也好，包括我们的数据产品，我们最后的这个流量楼盘，他们能够去呃，比较直观的去看一些我们流量的一些东西。

那数据资产沉淀那一块呢，我们就是说能够尽量多的去做我们，呃，丰富我们的一些维度，然后做一些更多精细化的东西，就是在DS层，我能够基于不同的维度，不同的力度去做更多的东西，然后还有第三点就是要场景化，嗯，就是对3ADS层的建设，就是我比方说不同的场景，比方说push啊，短信投放，像这种的全流程的一个贯通。那么首先讲一下流量数据治理这一块，流量数据治理这一块，其实呃，我刚到云约的时候，我试图去去回答几个问题，那第一个就是说原因到底有多少买点，那每个买点的格式是这些KY值有没有地方可以去查。那我怎么去看，说比方说我发现页首页这样的一个数据，我怎么能够快速定位到说它其中的某个模块，今天我的流量是多少，它的来源是在哪里。

然后走了一通，发现找不到这样的东西，然后他是各个团队，可能他埋的点可能是在各个各个人的手里，有Excel管理的，有文档管理的，有问题管理的，没有落系统，那就是格式非常混乱，然后你要去问的话，你就要问各个各个开发。然后质量也非常低下，因为没有人为这个东西负责，就是前端开发，他说我只管我的功能数据，说我把这个数据出了就好了，至于对还是错。只要没人来替我屁股，我我我我不管，然后开发效率，那就那那由于前面那这些情况，那我开发效率也不可能低的，我拉通我怎么拉通呢，对吧，那抗书也会对于业务来讲，他也会很困难，那基于这些痛点，我们呃做了几件事情，嗯，那就是怎么来解这个事情，我们分了三三三点，就是分成事前事中事后，那事前既然你没有规范，大家各自各自干各自的，那我首先我我们怎么来去抽象买点这个这个事情，那对于呃，我们也调研了市面上很多的这种买点的公式，包括呃原先韩言自己做的一些哈佛，但因为作为音乐，他的数据就是链路不长，但是他互相跳的这种这种网状非常多，而且深度非常非常深，就市面上的这种简单的这种买点工具，根本就满足不了我们的这个。

要看的些买量，呃买点数据，那那么包括像现在阿里他做的那个SSPMSC那套内容，因为他本身的，呃，像电商这一块，因为他只要看页面产品就是那个商品就OK了，没有很深的，我们还要再去看本身买点的一些内容的东西，所以我们最后我们自己去抽象了我们买点的一个一个规范，我们也借鉴了，呃在在在呃电商的这个场景下的那个买点的三要素，我们在上面再去叠加一些东西，比方说SSPMSCM内内容里面的TY是怎么定义，就是常规的，比方说我们的一些资源ID，我们应该要怎么命名这些东西，首先我们把它规范化掉，那怎么来保证这样的东西是规范呢？我们跟行云去建的一些一个一个check这样的一个呃产品，就是我把这个买点录入到系统，然后系统上面我可以去做一些呃之前规则的一些校验。

第一步就先把这个东西给做掉，那样这样子才会有后面说我我的这个数据生产出来是干净的，那么在适中这一块，因为之前各自为政嘛，就是产品他提的，后面就不管了，开发他他只按你这个文档功能OK就就就没问题了，那么我们现在在推动说比方就产品呃数据开发和呃前端开发，我们要有一个买点评审的环节，就是你这个买点这样的设计，包括OK是不是一定要加，那有这样的一个流程，那第三点呢，是为了降低我们在灰度期间能够发现我们这些买点是不是有有问题的，因为一旦买点上线以后，这个数据你你你你就没法去回滚的，这不像说我我脚本改下去去弄，那就只只能错的数据就错的数据了，买点错的就错了，所以我们在灰度期间，我们就做了一个这种买点数据集合的一个工作。

就就是在灰度期间，比方说他放量只放了10万的时候，我们看这个买点之前勾兑关系O不OK，如果发现有问题，他不能正式版本去上，然后后面呢，我们又做了一个流量罗盘的一个数据产品，呃，包括我们在一赛上面去也去上了我们流量的一些数据的一些自助查询的一些工作，这是我们在整个过程当中做的几件事情。呃，那这个是讲重点的，那原先的那些，呃，就是已经老的，比方说7.06.0版本那些数据怎么办呢？我们人肉去把这些买点一个个测出来，我们这里有几个数字，我们人肉梳理了将近8000多个点，然后规划到了3000多个坑位，就是说这8000多个点可能是不同版本打的格式不一样，嗯，然后不同端它也不一样，实际也不一样，所以我们把做了一个人漏的处理，把这些坑位给规划掉，然后在脚本里面把这些时机通过我们的这个后面的处理给他给兼容掉，那么基本上我们解决了90%以上的这个用户的流量的查询的一些需求。

那新增的这些买点，因为刚才说的我之前是中那些做了以后，然后又有系统去落了以后，我们就可以通过本身的数据的那个那个系统的接口，呃，因为我们1CHECK它，我可以去每周去抓那样的它的买点一个定义，然后通过我日志上报以后，两边去去结合去去配置，通过我们半自动化的这种ET2方式，我每周可以去迭代我们新上的这些这些买点，那么这样实现以后，我们整个DRP的原先的这个这个流量这一块的呃，加工时长也呃将近缩小了四四个小时，这就是我们在呃。

买点规范化之后，然后再加上有系统去规范我们能够得到的这些成果。嗯，这个最后总就是这流量这块的总结，就是说呃，我们做的这这几个点就是买点规范啊，呃他的一个check的系统的一个使用啊，还有呃数据资产的一个盘活，包括我们在怎么去快速的产出我们的呃买点流量，最后我们再反馈回去给到前端的开发，我们从从这个数据也能很明显能看到我们从年初的整个呃双单买点的这个这个这个bug率从年初比方说九点几，现在下单到年底只有四点几，就是从本身的bug率上，我们也能比较直观的能看到我们数据是在往好的方向在走。

那今天那第二个呃分享的就是说我们在有了这个流量，有了前端的这些数据以后，我们做怎么做这个数据资产的沉淀，那这里其实刚才有讲到就是呃最开始呃云月这边的整个数据资产是相对来说是比较孤岛化，就说我要去跨业务去拉通的时候，嗯，复用性是比较差。然后第二个呢，因为音乐它每一年会有一些大版本的改版，尤其是去年还有8.0的改版，然后还有一些创新业务的一些融合，比方说K歌啊，还有。哎，社区的大社区的一个业务改版，就他的整个业务迭代非常快，那么我怎么能够在这种快速的业务迭代情况下，我尽量在底层的这个数据是相对来说稳定的，那第三块就是我们数据交付的上面，因为由由于之前的整个呃。

这个开发过程的不透明，包括呃流量的这个数据的，呃源头数据的比较脏，我们整个呃产出的数据质量其实一直被业务方诟病，那基于这三个痛点，我们做了哪些事情呢？呃，这个是目标，那这个我就。我整个数仓我接受的过程肯定是希望说我从无序到有序是一个删减的过程，我能够一份数据出来是一个口径的，我看到是一个出口的，而不是说呃，这个同学出出出这个指标，那个同学出这个指标出来的数据差很多，那这个对于他们分析师或者上层的决策会就会引起很大的一个呃，Confuse。呃，那重点讲一下我们在呃过来以后怎么来建设这个呃素差，嗯，音乐它是因为围绕着整个参与者和内容在构建的一个业务场景的一个闭环，那基于这个特点，我们划分主题域的时候，可能像跟电商可能会不大一样，我们划了五大主题域，那主题域之外我们又画了二级主题，那其实平常会用到主要是二级主题会比较多。嗯，比方说在参与者我们又把它细分成用户、艺人、音乐人，包括一些To B的，我们一些版权公司，因为做结算，这也是一块很大的一个一个事情。那服务器产品这一块，我们又把内容分成了UGC跟PGC的内容，因音乐可能最大的一块是曲库歌曲这一块，那它是一个PGC的内容，那现在也在主推一些视频的，短视频的一些，包括嗯，之前音乐最最火的评论，这些是UGC的内容，那么这一块也是一个很丰富的一个数据的，呃，源头，然后在业务过程。

像这一块我们最最多的关注的是一些呃交易营收呃社交互动，比方说一些点赞评论，我哪些用户互动的比较多，然后还有日资流量它的它的呃流量分发好不好，还有一些营销活动，对，然后主要是这这几块，然后在层次划分这一块，其实就基本上是跟业界呃大同小异的分到ods层，D达D层，D答S层和ADS层，那么在DDS这一层呢，我们把呃稍微拆细了一点，会把轻度汇总和重度汇总，我们会呃相对来说会有一些比较明确的一些定义，就是轻度汇总我们会尽量把一些退化为还有维度能够保留在这里，那重度会基于轻度汇总去往上去叠加加工，而不是直接去依赖达地层去去去产出数据，那么白选这一层，我们就是尽量把一些呃，比如说像用户啊，一些资源的一些东西，我们贯穿整个呃中间层的呃建设。

小平。嗯，这个是整个我们呃云业这个流啊，呃这个可能看不大清楚，我们就是在最底层，我们各个呃业务过程的一些事实表，在低答地层这一层，我们把所有东西都给保留下来，那在D答S这一层我们会分，比方说呃，当实体在那个单用户加单实体的一种方式，会往上去聚一个滴答S，然后在滴答，呃在当时体这块我们又会一条线往上去聚，那这块是在整个业务发展过程当中走，不断给摸索出来的，其实最开始我们都是笼统的就是大用户要当时提这种方式方式去做，但是后来发现其实很多满足不了业务，那都要从DD去层去出，那这个呃产出效率就会非常非常低，嗯就DS这一层的建设，就是最开始我们建的比较不好，呃，随着业务的迭代，随着这个看书的，嗯，需求会从不同角度发展，以后我们在D单这一层，我们不断在在做后这个东西。

那么在模型构建的原则上面，我们就是说尽量是能够高内具低和常复用，那么其实这一块我们也看了很多坑，最开始就是我们在做D答层的时候，我们很多都是从D答滴答直接往上去，呃，尤其像一些这种历史累积，像有些这种30天的这种汇总，那对于如果体量不大的数据，比方说我们现在创新业务这种新一天只有几十万的这种dau的，那那都没问题，你回溯一个月，我可能一个小时之内就能跑出来，但对于云月，他一天的日资量是千亿级的，你一旦如果这个东西你的你的数据跑错，或者口径要调整，我我做的耦合性非常强的话，你跑30天数据可能就一个上午就没了，那对数据产出影响非常大。

包括整个运行方式的一个结构，就是这种增量和历史累积的这种全量怎么来拆，这也是我们在呃他了很多坑，或者说很多选A教训以后不断的我们就右边这这这一摞的一个一个示意图啊，就是把这个给给给给呃抽象出来了，就是我们最开始我们从ODS层到DS层，这个没什么好讲的，因为D层就一些明细的一些事实，那到DS的时候，我们首先做一些轻度汇总，就轻度汇总我们会尽量的保留。

呃，尽可能多的业业务可能会用到的一些维度，那这个时候我们的维度属性我们不会进往里面去去筛，这样就减少我们存储成本，那在DS这一层再往下就是先偏重度，重度汇总的时候，我们会往几个方向去去去走，做后这个d design一个呢，就是往内容当时体，所谓内容当时体我们就说的一些资源类的，比方说我们的歌曲视频，呃，Mo评论，那在大体上面我们去做一些指标的具体的加工，然后再往这边还要看用户，因为我们这边经常会看用户的一些行为，那会往用户的这个角度说，用户挂在用户当实体上面的一些指标是有哪些，然后再往上到ADS层做一些大宽表的时候，我们把这些用户本身的维表属性，包括内容的属性，再合进去分成一个整个大框表，那这种大框表的话就是给分析师或者说呃，产品运营。

来讲，他们就很很好用，因为他不用关心我底层的细节是什么，他只要是最后看出我这大框标里面，他要的指标，他要的维度有就OK了，嗯，这样它的一个好处就是，呃，我们在加工的时候，我们会把这些增量表，存量表，在调度的时候，我们还会给他说这种，比如说1728的这种表，我们单独一个流，那历史累计的，呃，我们单独一个流，这样在做数据回刷，回刷的时候，一期28我可以并行去跑，那历累计，因为我要每天去回滚，每天往往上累的，那这种就只能创新，那这样就会把整个资源会会给拆开，那同理加到1728的话，这种人数啊，次数啊，我们可以一次性去少少这个底层的分区，因为对大数据量的话，你一旦多少几天的分区，他可能跑的数据量就会慢很多，甚至倾斜的情况也会经常经常发生，这就在我们在整个建设过程当中遇到的很多的坑。

然后在第二点呢，就是我们在，呃真正去落地之前，我们也做了很多规范的一个落地，呃，这个也是依托了网一出方，就是韩研这边这个他们上线的的模型设计中心啊，嗯，这个东西比较好的一点就是说，因为规范，规范这个东西，我嘴上说说很好很好，说我要怎么做调度，我我这个字段我要怎么命名，我这个这个媒体主要怎么做，那嘴上说这很好说，包括文档也好录，但我怎么在正式的一个环境当中去，大家去遵守这样的一个规范，那就需要有系统去支撑了，那么我们在那个模型设计中心的，就是大家在去上线一个中间层模型的时候，必须是要走这个模型设计中心去上面去注册登记，它是属于是什么域的，它每个字段的命名，我们也会做一些规范，做一些这个强强强规则校验，然后要嗯，自身的模型是去评审，评审以后才会，呃，再再去建表去走。

那个流的一个建设。就是我们做了很多规范，那这些规范也一呃这里可能80%在这个模型设计中心已经落地的这样的一个规范。呃，还有一点就是经常会出现，之前经常会出现用我们的这个脚本呃，随意更改，因为也没有人去check，或者说呃没有权限去做控制，然后尤其些新新的这个呃模型上线的时候，大家比较随意上就上了，然后发现可能过了几天发现下游数据看我靠不对，或者说我我我我这个差异值还蛮大的，那可能我上游根本就没有做任何的这个这个数据测试，那么这个呃书发那边他提供的一个测试中心，就是一个test，他常规的一些这种空值啊，然后数据的波动啊，提供这种这种简单的这种校验是不需要去配的，你跑完以后你直接扔进去，他会告诉你说这个字段你的控制占比是多少，你的最大最小值是多少，像这种你就一搂一眼就OK了，你就能看到这样的问题，这是最最基础的，那么如果是要复杂一点的，需要一些高级关系的，那这种就是自己在那个那个那个中心里面去。

去配自己的脚本，根据自己的一个经验去去测，那至少呃有这个东西以后，你可以减少一些很low的一些问题的问题的发生，那同时我们也会在呃流程协作中心里面，就是你上线之前必须是要通过呃评审验收以后才能够上到生产调度环境，这样就是把测试环境跟生产环境进行了一次隔离。呃，这个是我呃讲的是我们社区的一个业务实践，就是我们可以看到我们从最左边的流量的这个数据过来，然后我们在呃滴答地这一层，我们做了各种社交互动的流量的一些业务的一个测试表，嗯，然后再往滴答层，我们先做了一些清度汇总，比如说点赞、分享、评论、播放，我们把这个作品合在一起的，因为对于下一个来讲，他会经常看，先说我这个点赞的来源是什么，我的播放的来源是什么，那么呃。

经常情况下说，我肯定是锚定某个点，呃，比方说我们这边主要是锚定播放，就说这个这个这个。播放是从哪个页面来的？那至于后面的点赞、分享、评论，也是铆定这个播放来，所以我们把这几个社交互动的行为就放在一张表里面了。呃，再往后我们先重度的，包括一些历史累积的，我们就往往再再拆出来，这样就减少我们这个，呃，数据调度的这种困难。

最后再生成一张m log的一个大康表，这样的就是我往赛去去逛的时候，他们只要去关心这张表的东西就OK了，那通过这样的一个改造的话，我们整个数据的产出，呃，提前了三个小时，然后整个口径也都统一掉了，之前因为比方说点赞分享，他自己做一套这个归因，那经常会出现说跟播放不一样，那你要又要去查。然后在使用上面，我们也能很明显的看到说我们这个使用率是非常高的。呃，那最后讲一下，就说有了这些数据资产，我怎么来触达我的用户，呃，所谓用户就说我们是内部的两个产品运营分析师，怎么来触达他们，怎么让他们知道说我们有的这些东西，或者他们怎么来使用这样的东西，这就是我们跟行业去做的一的这个这个产品，嗯，这个自助服务呢，就是嗯，我们对于数据开发来讲，我们只要类似推报表一样，呃一样的事情。

把模型灌进去，然后自动配上去，他们就可以用了，那难点不在于说技术，而是说怎么培养我们的用户习惯，因为之前的产品运营可能更多的是只要资源充足，给分析师提需求，给数据开发提需求，给到他的数据，那他会会很轻松，对吧？那么当资源不足的时候，他们怎么来用这些东西，我们怎么培养他的习惯，那么我们做了很多的呃培训，然后包括一些从高层到我们呃下面开发，我们跟他们做了很多沟通，做了很多培训，包括群号，我们呃进行一对一的一些辅导，嗯还还做了一些措施，就是说他如果要走我们数据开发的这个排期，我们可能会往后排，就是如果这上面有这样数据，你不去，你不去用，那不好意思，我们这种需求我们只能往后排，因为你你不愿意去去用我们已经生产好的东西，而且这个使用的成本也不是说你没法没法习得的，所以通过这样的呃一些方式的处理以后，我们整个呃一些赛使用，可以说从这个数据上也比较明显能看到我们从年初上线到年底，呃，整个UVPV的使用量还是蛮高的，我们现在整个最后可以看一下我们最后整个。

说这个的使用，我们现在呃，用户量已经达到400多，可以差不多现在说呃。云约的1/3的用户已经开了这个账号了，那么我们UV已经一周已经达到180多个，那PV就是7000多个，那什么概念，就是说如果他们没有这个东西，呃，如果是不考虑他说重复调用，那就是7000多个需求，如果7000多个需求我们100个人，一个人七个。

一周也就只能支撑700个需求，那么有这样的一个一款产品，那我的整个数据交付方式可以说是是改变的非常多，而且他们可以自由的去探索他们自己要的一些数据，因为他提一个想法，可能只是他瞬间的一个想法，那写到纸上给到我们可能已经又变掉了，那如果有这样的一个工具给到他们，他们自己可以去探索，去校验，呃这个是最后一页，是说我们刚才自是服务讲，我们回顾一下，就是我们做的工作，第一个就是建规范，第二个是呃立机制，第三个是陈列资产，呃，那通过这么一轮，呃，第四点就是我们的这个服务化，呃那么通过这么几轮的这个下来，呃，整个云音乐的整个数据体系，呃，包括我们数据产品的一些，呃，不断扩充，呃，可以说是今年20202021年比在2019年，包括之前的整个数据使用是。

体验上面是要好的非常多，那么当然我们在接下去上我这PPT可能没写，接下去我们可能还会往数据实时化这一块会去做一些尝试，尤其在PT这一块，也是在行业去共建，因为这块的诉求主要是在于呃算法这边，因为算法对数据的实时性要求特别高，他们特别希望说我能够至少能够到分钟级或者小时级这样的数据给到他们去做模型训练，因为现在的这种天级的数据给到他们，嗯，像歌曲推荐啊，呃搜索啊，对于他们的这个模型训练其实效果会打很大的折扣，那么希望我们在嗯这一块能够给到他们一些更多的支撑，就是我们接下去可能今年重点会呃做的一块工作。好的，那我的分享就到这里，感谢各位。