共计 2968 个字符，预计需要花费 8 分钟才能阅读完成。
作者：石烁
摘 要 ：在大数据开发畛域，大家都会被一个问题困扰：调度工作提早，而后被老板、被业务“灵魂拷问”。本文将从问题挑战、指标掂量、口头计划、成绩展现、后续布局五个方面开展，详述网易云音乐在全链路基线治理的实际。
一、问题挑战
基线治理前，咱们的基线运维存在较多的问题，有两个数字很能阐明问题：
（1）月均匀起夜天数达 80% 以上。为什么会这么多呢，有很多因素，例如运维范畴不清晰、基线挂载没有束缚、集群资源缓和等等。
（2）基线产出工夫较迟，常常无奈在下班前产出，月均匀破线时长将近十小时。
要进行全链路基线治理，面临的挑战也很大，次要来自 3 方面：
- 工作多：千亿级日志量，万级任务数，如何收敛在可控的范畴，如何在出错后，能较快的重跑完？
- 资源紧：凌晨资源水位 95% 以上，没有任何的 buffer 预留，也没有弹性资源可用；
- 要求高：显微镜下工作，以 MUSE 产品为例，上百 BD，每天下班就看数据，他们的 KPI 考核就以 MUSE 的数据为准。
二、指标掂量
全链路基线治理的价值，总结起来次要有 4 个方面：
- 服务于管理层，让管理层第一工夫能查看公司的经营数据。
- 面向 C 端的业务数据，可能稳固、及时的让用户更敌对的应用。
- 可能建设数据开发团队的研发口碑和影响力。
- 晋升咱们数据开发同学的运维幸福度，进而晋升组织的稳定性。
那么咱们用什么指标来掂量咱们的指标呢？咱们提出了两个数字来牵引：
- 98%：全年可用天数达到 98% 以上，即服务不达标天数全年不超过 7 天。
- 基线工夫：外围 SLA 基线产出工夫需满足业务要求。
三、口头计划
3.1 整体计划
基于上述问题挑战的分析，咱们对该问题的解题思路拆成 3 个方面：
- 平台基建：俗话说：“根基不牢，地动山摇”，首先要解决的就是平台基建，例如如何掂量咱们的集群资源是否饱和、咱们的队列如何管控、产品性能如何反对等等。
- 工作运维：全链路上，哪些工作是卡点？超长高耗资源工作是什么起因？哪些工作须要高保障？
- 组织流程：有没有规范的运维 SOP？跨团队的合作机制如何建设？出问题后，如何无效的跟踪以及防止再次发生？
用 3 个词演绎，就是稳基建、优工作、定规范。
3.2 稳基建
基建这块，咱们梳理了存在的问题：（1）队列应用不明确：总共拆分了几十个队列，没有明确的应用标准；（2）资源监控靠教训，无通用指标掂量；（3）集群 Namenode 压力大，负载高；（4）资源管控弱，遇到突发状况无奈保障高优工作优先获取资源。
针对上述问题，咱们施行了如下的解决方案：
- 集群稳定性建设：联结杭研，对负载高的 Namenode 集群进行 DB 拆分，迁徙上百张表；同时欠缺集群的监控，例如 nvme 盘夯住主动监控修复，dn/nn/hive 等节点监控优化疾速发现问题。
- 集群资源数字化：实现了一个高牢靠的资源应用模型，为集群资源管理员提供具体的数字化指标，以此能够疾速判断以后集群的资源应用状况，解决以后集群资源分配不合理的状况。
- 产品化：通过产品层面晋升资源的应用效率，比方产品性能反对按工作优先级获取队列资源，产品层面实现自助剖析 & 补数性能凌晨禁用或有限度应用。
- 队列资源应用领导倡议：制订队列的资源应用标准，明确各个队列的作用，管控队列应用，布局高中低级队列。
3.3 优工作
针对云音乐体量大、业务多、团队广的数据工作特点，咱们在这块做的工作次要有：
- 外围 ETL 引入流式解决，按小时预聚合数据，这样 1 小时内实现流量日工作批跑。
- 工作优化：如 hive、spark2 版本升级至 spark3，队列调整、sql 革新等等。
- 买通表、工作、基线间的血缘关系，优化工作的调度工夫，缩小工作依赖错漏配。
- 指标的异样监控，咱们除了传统的 dqc 外，还引入机器学习模型，解决云音乐 DAU 这类指标具备周期性、假日因素的监控难点。
其中，spark 降级失去了杭研同学的贴身服务，获得了比拟好的成绩，hive 降级到 spark3 实现大几百个工作的革新，节俭 60% 资源。spark2 降级 spark3，实现将近千个工作的革新，整体性能晋升 52%，文件数量缩小 69%。
指标的异样监控，引入的机器学习模型，咱们次要交融了 Holtwinter、XGBoost 算法，相比 dqc 的监控，咱们在 DAU 这个指标上，召回率晋升 74%，准确率晋升 40%，正确率晋升 20%；同时这里还有一个很大的作用是，它能感知业务的动静趋势性变动，而且部署也很简略，配置化接入。在产品层面，咱们也正在联结杭研产研同学，将该能力集成到数据品质核心。
3.4 定规范
在定规范方面，次要从两方面登程：运维的范畴和运维标准。基于这两点，咱们开展了如下的工作：
- 以外围产品 + 外围报表为载体，划定外围 SLA 运维基线 + 数仓两头基线，值班运维的范畴从原先的上万个工作缩减到千级任务数。
- 明确任务责任人，解决之前事不关己高高挂起的问题，依照业务线划分，工具 + 人肉并行的形式将无归属的工作归属到责任人。
- 制订基线挂载准则，明确约束条件、各角色职责等。
- 制订规范的运维 SOP，严格运维军规和奖惩机制；同时跟杭研建设数据运维交警队，多动作保障异常情况的及时处理。
- 建设官网运维消防群，第一工夫告诉问题和解决停顿，解决信息传递不够高效，业务体感差的问题。
- 与杭研、平安中台、前端等达成对立意见，引入 QA 作为公正的第三方，对立牵头解决问题的复盘和归因，确保问题的收敛。
四、成绩展现
我的项目成绩这块，次要分为业务成绩、技术成绩、产品成绩三方面。
业务成绩，目前咱们的外围基线凌晨就能跑完，均匀告警天数降落 60%，外围基线破线次数 0，实现全年可用天数 98% 以上的指标。
技术成绩，咱们的《机器学习模型在云音乐指标异动预测的利用实际》荣获了网易团体 2022 年度技术大会 - 开源引入奖。同时，咱们的集群资源数字化，通过计算出正当的弹性资源，确保集群服务或者工作呈现相干稳定或异样的状况下，不会造成大量工作提早、外围基线破线等景象；其次依据资源的平安水位，为扩缩容提供量化的数据指标；最初集群、队列、工作资源透明化后，能够进步整体的资源利用率，降低成本。
产品层面，在杭研的鼎力支持下，实现了队列资源的歪斜、自助取数主动查杀等性能，无效的晋升了咱们的资源利用率。
五、后续布局
咱们将从产品、零碎、业务、机制四个方面持续全链路基线治理的工作。
产品层面，咱们将引入 DataOps，加强工作的代码主动稽核能力，从开发、上线、审批全流程做管控。优化基线预警，通过检测基线上任务调度工夫、依赖设置等，判断是否有优化空间或者异样，并做提醒或告警。
零碎层面，优化资源监控，反对基于 Label 级别展现调配的物理 CPU、虚构 CPU、内存等系统资源总量以及指定时段的理论 CPU、虚构 CPU、内存使用量。同时在工作级的资源应用上，对配置的资源做合理性评估，进而提供优化倡议。
业务层面，晋升内容级监控覆盖率、准确度；买通线上服务的血统，笼罩线上服务的工作。
机制欠缺，联结分析师、数据产品等团队，确定报表、数据产品的下线以及对应历史工作下线流程。
写在最初，治理是一件久久为功的事件，上述更多的是从方法论的角度在讲这件事，然而治理其实更考验执行，须要一直修炼内功，把事件做细，把细事做透。
本文公布自网易云音乐技术团队，文章未经受权禁止任何模式的转载。咱们长年招收各类技术岗位，如果你筹备换工作，又恰好喜爱云音乐，那就退出咱们 mailto:staff.musicrecruit@ser…。
