一、数据背景
首先来介绍一下业务背景和数据现状。
云音乐在过去九年中发布过九款独立的产品，包括国内产品和海外产品。国内产品除了大家熟知的网易云音乐之外，还有五款社交类型的产品。海外主要打造了三款社交类型的产品。所有产品的数据支撑都在数仓开发部门。
从数据角度来看，在过去的八九年中，做过一系列的重构和迭代工作，在这个背景下，我们从多个角度对数据现状进行了分析：
（1）在规模上，目前承载的产品有九个，线上正在调度的任务有 2 万个以上，表数量有 5 万多张。目前我们在猛犸数据开发平台上制作申请的项目有 12 个，数据方面直接触达的用户群体有 600 个以上。
（2）成本方面，日存储量有 80 多 PB，存储费用在 19 万以上，计算方面日常调度的任务成本是 27 万。
（3）质量方面，之前在核心时段的资源水位是非常高的，在 95% 以上，对整体基线运维造成了比较大的风险。初期队列的使用也比较混乱，使用的姿势也是各式各样的，为数据运维带来了比较大的困难。
（4）效率上，由于历史原因，有大量任务跑在 Hive 和 Spark2 引擎上，存在着资源效率，以及小文件等问题。另外，由于前期数仓建设内容推广覆盖的不到位，存在大量的任务直接去读 ODS 原表，特别是对于日志数据存在大量的小需求，耗费资源。
（5）环境方面，目前国内我们有五套 Hadoop 集群，海外包括 AWS 和阿里云。
总体来讲，目前数据面临的问题是：体量大、环境杂、缺规范和资源浪费。
二、治理思路
接下来介绍在上述数据背景下，我们是如何去明确治理方向的。
首先，从技术视角来看，在大数据体制下，数据内容的分布情况如上图所示。文件都是存储在 Hadoop 集群的 HDFS 文件系统中；在 HDFS 文件系统之上，我们会建立一系列 Hive 库和表来管理数据；数据开发会在上面进行模型设计和数据分层设计；再往上则是数据处理方面的内容，包括任务调度、执行引擎等。
随着业务的快速发展，数仓的不断迭代， 每块内容可能或者必然存在着哪些问题：
（1）在数据保障方面，存在大量任务仍然运行在 Hive 和 Spark2 引擎上，存储、计算、小文件问题都存在较大提升空间。
（2）在模型设计合理性上，存在依赖混乱、使用姿势暴力粗糙和库表大量闲置的问题，造成资源的过度浪费，影响改造重构的效率。
（3）缺乏管理规范，数据库扩展不受限制，用途不详，同时建表方式凌乱，存在大量不规范表，为之后的移交和管理工作带来了较大困扰。
（4）缺乏有效的管理监控内容，导致出现了大量的系统级无效文件和数据级无效文件，直接影响了 Hadoop 集群的稳定性。
在明确了具体的治理方向之后，我们要做的就是如何在这些方向找到具体的治理内容。
（1）首先，我们在 HDFS 文件上定义了游离 HDFS 文件的概念，这种文件存在于 Hadoop 系统里面，但是没有任何的表或者任务去直接使用它。要定位这种文件，就要用到 HDFS 元数据信息；
（2）其次，针对库表的使用现状，我们需要用到库表元数据信息，对现有的库表进行梳理；
（3）另外，在模型设计合理性方面，我们引入了三度指标的概念，通过三度指标去衡量整个模型建设的健康度，而三度指标的计算需要用到数据血缘的信息；
（4）最后，在任务调度方面有着较大的提升空间，我们要对任务进行梳理，需要用到全局的任务执行元数据信息。
所有的问题都指向了同一个方向，就是我们要获取到完整准确的元数据信息，只有这样才能进行有效的数据治理。
三、治理方案
这一章节将介绍我们的治理方案。
从元数据出发，首先是从猛犸平台上获得了比较完备的元数据信息，包括表的元数据信息，以及任务的元数据信息。基于这些元素信息进行数据建模，在 CDM 层产出了比较丰富的模型，可以从各种视角看到整个资产的情况，以及模型设计健康度的情况，可以从平台的视角来看我们整个平台的变化情况，也可以按数据使用团队去看不同团队在使用过程中的成本情况。整个元数据建模支撑了云音乐的整个数据治理体系。
上图描述了整个云音乐数据治理体系的内容，基于元数据建模，数据治理事项包括：建监控、定规范、搭工具、做治理。前三个动作都是为了做治理而去做准备，同时在做治理的过程中也会去反哺前三项，做治理的过程中也可以逐步丰富规范内容，同时也可以进一步沉淀和落地监控及工具。
整个治理过程遵循的治理原则为：治理有依据，权责有归属，机制可持续，效果可回收，方法可沉淀。
四、治理实践
在前文提到的治理原则中，权责有归属和机制可持续是在整个治理事项推进过程中的两个技能点，只有明确了这两个内容，在后面的推动中才能够更加顺畅的进行。因此在治理实践中，首先要做的就是权责有归属。
1、权责有归属
所有的数据、表和任务都应该有具体的责任人对其负责，这样在发现问题时才能找到具体的人去进行处理。目前在权责有归属这部分做了三件事情：ODS 任务和表的归属操作、离职人员任务和表的归属操作，以及项目账号表的归属治理。
2、机制可持续
在推进过程中，面临的问题是具体要做的治理事项需要覆盖到不同的团队或者不同的部门去执行，而且每个具体事项的治理动作也是多元化的，不同业务团队以及不同人的认知以及能力、精力的投入都是不一样。因此，我们统一建立了一个通用的推进机制，以及一个通用的治理原则。
在推进机制方面，我们建立了一个专项机制，明确治理内容以及相应的价值。在治理过程中，我们会把做要做的具体动作进行公示，比如邮件公示或者群公示的方式，公示之后才进行下一个操作。操作之后如果发现问题，可以进行回滚操作。
治理原则为：
（1）“源头”干净，保证源头数据治理干净。
（2）“复杂”二八，对于复杂的情况，保证通过较少的投入获得更高的收益。
（3）“稳定”保障，尽可能保证线上的稳定。
3、具体实践
（1）HDFS 层面-游离 HDFS 文件治理
首先针对前文中提到的游离文件问题，我们通过行业给到的表元数据信息以及文件的元数据信息进行匹配和关联，定位出游离文件，再根据游离文件中的审计信息去判断这些文件是不是真正的无效文件。我们目前达到的效果是下线存储达到 7P 以上的逻辑存储，清理掉的文件数量在 450 万以上，为 Hadoop 元数据释放了比较大的压力。
（2）库表层面-库治理
在数据库方面，目前数据服务的角色是非常多的，除了数仓、算法、数据产品之外，还有业务服务端、广告和安全中台等等。由于之前我们对数据库的管控不是很到位，导致存在非常多的库，有很多库的用法也不透明，一些库的作用不明确，还有一些库不合规。在这种情况下，我们进行了一系列的数据库治理操作，最后把数据库审批权限进行回收。
（3）库表层面-表治理
在表治理方面也进行了许多的实践，包括临时表治理专项、生命周期治理规范、巨型表治理专项和 A/B test 治理专项。
（4）模型设计层面-“三度”指标治理
在模型设计层面，制定了“三度”指标治理方案，包括健康度、价值度和进度指标。其中健康度包括复用率和穿透率，价值度包括资产规范率和资产引用率，进度指标包括覆盖率和闲置率。
覆盖率和闲置率是针对 ods 表利用率的一个衡量。通过对 ods 层表的治理可以进一步提升覆盖率，降低闲置率。这个过程中我们可以下线大量的无效 ods 表以及相应的任务。
复用率和穿透率是用来反馈我们 cdm 层表引用健康度情况，目前通过一系列的治理。复用率已经由 30% 提升到了 60%，穿透率由 20% 下降到了 10%。
资产规范率和资产引用率是针对我们 cdm 层表的规范化情况的一个衡量，这两个指标我们是保持在 85% 以上，并且通过一系列的规范落地，指标会逐步提升。
通过三度指标的一个治理，可以清理掉大量无效的任务和表，在存储资源和计算资源上可以减少不少成本。
（5）数据处理层面-计算治理
计算治理当前阶段主要是针对计算引擎升级做治理。
云音乐集群是在 2021 年年中上线了 Spark3 执行引擎，经过大半年的使用，我们确实在 Spark3 上体验到了非常棒的效果，杭研的数科同学也在 Spark3 上进一步做了大量的优化，例如 AQE 增强优化、zorder 功能以及 shuffle 阶段采用 zstd 压缩算法。为了能够更好的兼容升级过程，杭研也在 Spark 引擎上内置了大量优化参数。当前 Spark3 引擎在计算资源、存储资源、小文件问题上获得了大幅的提升。在这个背景下我们在 2022 年 Q2 阶段开始任务迁移至 Spark3 的专项。涉及的迁移事项有：
（1）Hive 迁移 Spark3。
（2）Spark2 版本的 SQL 任务迁移至 Spark3。
（3）核心任务和高成本任务的 Spark3+zorder+gzip 升级。
（4）Spark 工程任务迁移 Spark3 的专项。
每一项在节省资源上都获得了巨大的提升。
五、治理成果
1、成本收益
通过数据治理，我们取得了一系列的成果。
（1）首先，在存储方面，一年可以节省 2500 万人民币，累计下线存储 30P+，占整体存储的 30%，同时放缓了表的增速，从日增 170T 下降至 55T。
（2）其次，是在计算资源上的节省，通过一系列任务的治理，在核心任务执行过程中可以节约 30% 的资源，集群的稳定性也得到了一定的提升。
（3）在临时表和无效表的治理方面，减少了 25000 张表，表的数量由原来的 5.5W 下降到 3W。
2、治理资产沉淀-治理大盘
在整个治理过程中我们也将方法论和治理思路沉淀了一系列的可视化监控看板和治理跟进工具，确保整个治理事情是有序进行并且过程可控的。
沉淀的治理大盘，包括：数据资产沙盘、“三度”指标概览、计存费用沙盘和治理效果看板。
3、治理资产沉淀-治理跟进工具
同时，针对每一项治理，我们都有产出一些治理跟进工具，包括：个人指标治理报告、临时表治理报告、复用率治理列表和推荐归属治理监控等。
4、数仓开发规范沉淀
治理过程中我们也逐步丰富了我们的数据开发规范。包括：数据库使用规范、临时表建表规范、任务节点命名规范、队列使用规范、任务上线规范和数据下线流程规范。
六、未来规划
数据治理是一个长期而且持续要做的事情，如何在治理的过程中达到更好的效果，我们一直秉持着一个治理理念：从分散到集约、从被动到主动到自动、从经验到智能。
整个治理动作分为三部分，包括：事前、事中和事后。事前可以进行预防性治理，推广数据白皮书使用等；事中实现各类治理监控指标工具落地，及时发现问题并反馈；事后可以治理指引报告，给出治理理由、治理方案，也可以提供更便捷有效的治理工具。
