效能提升30%、埋点线下bug率下降50%，网易云音乐数仓建设之路

数据仓库是当前数据中台体系的核心组件之一，也是网易云音乐数据化运营的发动机，本文总结了 2020 年网易云音乐数据仓库团队的一些核心工作、取得的进展以及相关实践经验，希望对读者有所启发。

2020 年已结束，网易云音乐（以下简称云音乐）数据仓库团队取得了较为满意的成绩，也获得不小的成长。回顾团队过去一整年的工作，我们主要聚焦于两件事：

• 数据交付提效

• 数据质量提升

交付提效

我于 2019 年加入云音乐，当时数仓团队给我的第一印象是忙碌、年轻，这群基本都是 90 后的年轻人每天都会加班，晚一点的甚至会加班到 10 点后，大家每天都在忙碌的处理工单，包括数据报告、数据埋点、临时数据拉取等工作，但这些工作是琐碎的，交付效率也不如意。事实上，大家都意识到，工作可以是琐碎的，但是数据仓库是需要化零为整的，于是，管理层启动了当时数仓的“任督计划”，要构造新的云音乐的数仓数据体系。

数仓数据体系建设，是个很大的工程，包含数据架构、数据模型、数据质量、元数据管理、数据服务等工作，但是大家首当其冲的意识，是要做好数仓建模，也就是数据的通用层抽象，云音乐也不例外，在数据体系建设第一个重点工作便是数仓的通用层数据建模（data modeling）抽象。

音乐数仓的通用层建模规范

这里大家可能会有个疑问：为什么数仓的通用层数据建模会是第一高优的重点工作？这里我讲一个实际例子。2019 年 11 月，我刚来云音乐不到两个月便收到一个需求：业务策划同学希望通过一系列策略运营，最终能促成 look 直播里的主播同时也能成为云音乐主站的高质量创作者（比如 mlog 创作者、电台创作者、DJ、音乐人等等），这意味着在数据层面，look 直播的主播、音乐主站各种角色的创作者必须在数据上是通路的。较为遗憾的是，当时数仓通用层建设不够，很多人与人之间的关系、人的实体标签体系并未建立，所有的工作都需要从 0 开始做，因此，这个需求最终也是集结了当时云音乐所有数仓开发同学、耗时一个多星期才最终完成。所以我当时的想法便是，要快速的整理出云音乐数仓的通用层数据建模规范与方法并落地。

整理的过程细节便是数仓建模的标准流程，这里就不一一展开介绍了。不过最终，我们编写了《云音乐数据仓库建模规范》，并在该规范基础上与负责集团通用基础软件研发的网易数帆（以下简称数帆）团队共同创建了“EasyDesign”数仓模型设计系统，云音乐的数据主题域、主题域之间的关系也明确下来，如下图：

EasyDesign 数仓模型设计系统截图：

基于此数仓通用层建模规范，云音乐的数据资产沉淀开始变得有方向，在半年内，便把大量关于人、物、场景等实体的高频数据资产完成通用化设计并落地，工单需求的开发链路得以缩短、整体交付效率开始改观。

不过，虽然通用层的建设减少了重复性的开发工作，但毕竟是中间层，在针对一线同学的业务需求交付的“最后一公里”仍然存在瓶颈：手工、Excel、报表的交付始终是被动的、要排期的、不那么高效的，我们如何才能更高效的交付呢？甚至让一线的业务用户能自助的获取想要的数据？为解决这个问题，EasyFetch 孕育而生。

自助取数，数据配送的“最后一公里”

EasyFetch 的诞生还是一