网易云音乐数据全链路基线治理实践

石烁 2023-12-12 10:44:00

在大数据开发领域，大家都会被一个问题困扰：调度任务延迟，然后被老板、被业务“灵魂拷问”。本文将从问题挑战、目标衡量、行动方案、成果展示、后续规划五个方面展开，详述网易云音乐在全链路基线治理的实践。

一、问题挑战

基线治理前，我们的基线运维存在较多的问题，有两个数字很能说明问题：

月平均起夜天数达80%以上。为什么会这么多呢？有很多因素，例如运维范围不清晰、基线挂载没有约束、集群资源紧张等。

基线产出时间较迟，经常无法在上班前产出，月平均破线时长将近十小时。

要进行全链路基线治理，面临的挑战也很大，主要来自三方面：

任务多：千亿级日志量，万级任务数，如何收敛在可控的范围，如何在出错后，能较快的重跑完？
资源紧：凌晨资源水位95%以上，没有任何的 buffer 预留，也没有弹性资源可用；
要求高：显微镜下工作，以 MUSE 产品为例，上百 BD，每天上班就看数据，他们的 KPI 考核就以 MUSE 的数据为准。

二、目标衡量

全链路基线治理的价值，总结起来主要有4个方面：

服务于管理层，让管理层第一时间能查看公司的经营数据。
面向 C 端的业务数据，能够稳定、及时的让用户更友好的使用。
能够建立数据开发团队的研发口碑和影响力。
提升我们数据开发同学的运维幸福度，进而提升组织的稳定性。

那么我们用什么指标来衡量我们的目标呢？我们提出了两个数字来牵引：

98%：全年可用天数达到98%以上，即服务不达标天数全年不超过7天。
基线时间：核心 SLA 基线产出时间需满足业务要求。

三、行动方案

1.整体方案

基于上述问题挑战的剖析，我们对该问题的解题思路拆成3个方面：

平台基建：俗话说：“根基不牢，地动山摇”，首先要解决的就是平台基建，例如如何衡量我们的集群资源是否饱和、我们的队列如何管控、产品功能如何支持等等。
任务运维：全链路上，哪些任务是卡点？超长高耗资源任务是什么原因？哪些任务需要高保障？
组织流程：有没有标准的运维SOP？跨团队的协作机制如何建立？出问题后，如何有效的跟踪以及避免再次发生？

用3个词归纳，就是稳基建、优任务、定标准。

2.稳基建

基建这块，我们梳理了存在的问题：

队列使用不明确：总共拆分了几十个队列，没有明确的使用规范；
资源监控靠经验，无通用指标衡量；
集群 Namenode 压力大，负载高；
资源管控弱：遇到突发情况无法保障高优任务优先获取资源。

针对上述问题，我们实施了如下的解决方案：

集群稳定性建设：联合杭研，对负载高的 Namenode 集群进行 DB 拆分，迁移上百张表；同时完善集群的监控，例如 nvme 盘夯住自动监控修复，dn/nn/hive 等节点监控优化快速发现问题。

集群资源数字化：实现了一个高可靠的资源使用模型，为集群资源管理员提供具体的数字化指标，以此可以快速判断当前集群的资源使用情况，解决当前集群资源分配不合理的情况。

产品化：通过产品层面提升资源的使用效率，比如产品功能支持按任务优先级获取队列资源，产品层面实现自助分析&补数功能凌晨禁用或有限度使用。

队列资源使用指导建议：制定队列的资源使用规范，明确各个队列的作用，管控队列使用，规划高中低级队列。

3.优任务

针对云音乐体量大、业务多、团队广的数据任务特点，我们在这块做的工作主要有：

核心 ETL 引入流式处理，按小时预聚合数据，这样1小时内完成流量日任务批跑。

任务优化：如 hive、spark2 版本升级至 spark3 ，队列调整、sql 改造等。

打通表、任务、基线间的血缘关系，优化任务的调度时间，减少任务依赖错漏配。

指标的异常监控，我们除了传统的 dqc 外，还引入机器学习模型，解决云音乐 DAU 这类指标具有周期性、假日因素的监控难点。

其中，spark 升级得到了杭研同学的贴身服务，取得了比较好的成果，hive 升级到 spark3 完成大几百个任务的改造，节省60%资源。spark2 升级 spark3，完成将近千个任务的改造，整体性能提升52%，文件数量减少69%。

指标的异常监控，引入的机器学习模型，我们主要融合了 Holtwinter、XGBoost 算法，相比 dqc 的监控，我们在 DAU 这个指标上，召回率提升74%，准确率提升40%，正确率提升20%；同时这里还有一个很大的作用是，它能感知业务的动态趋势性变化，而且部署也很简单，配置化接入。在产品层面，我们也正在联合杭研产研同学，将该能力集成到数据质量中心。

4.定标准

在定标准方面，主要从两方面出发：运维的范围和运维规范。基于这两点，我们展开了如下的工作：

以核心产品+核心报表为载体，划定核心 SLA 运维基线+数仓中间基线，值班运维的范围从原先的上万个任务缩减到千级任务数。

明确任务责任人，解决之前事不关己高高挂起的问题，按照业务线划分，工具+人肉并行的方式将无归属的任务归属到责任人。

制定基线挂载原则，明确约束条件、各角色职责等。

制定标准的运维 SOP ，严格运维军规和奖惩机制；同时跟杭研建立数据运维交警队，多举措保证异常情况的及时处理。

建立官方运维消防群，第一时间通知问题和处理进展，解决信息传递不够高效，业务体感差的问题。

四、成果展示

项目成果这块，主要分为业务成果、技术成果、产品成果三方面。

业务成果，目前我们的核心基线凌晨就能跑完，平均告警天数下降60%，核心基线破线次数0，完成全年可用天数98%以上的目标。

技术成果，我们的《机器学习模型在云音乐指标异动预测的应用实践》荣获了网易集团2022年度技术大会-开源引入奖。同时，我们的集群资源数字化，通过计算出合理的弹性资源，确保集群服务或者任务出现相关波动或异常的情况下，不会造成大量任务延迟、核心基线破线等现象；其次根据资源的安全水位，为扩缩容提供量化的数据指标；最后集群、队列、任务资源透明化后，可以提高整体的资源利用率，降低成本。