关于机器学习:网易云音乐机器学习平台实践

作者：burness

机器学习平台基础架构

在网易云音乐外部，机器学习平台晚期次要承当着包含音乐举荐、主站搜寻、翻新算法业务在内的外围业务，缓缓地也笼罩包含音视频、NLP 等内容了解业务。机器学习平台基础架构如下，目前我按性能将其形象为四层，本篇文章也会从这四个方面详细描述咱们在各个形象层的具体工作。

资源层: 平台外围能力保障

次要为平台提供资源保障与老本优化的能力，资源保障笼罩了包含算力、存储、通信、租户等各个方面，而老本优化目前咱们采纳虚拟化，提供资源池的动态分配，另外思考到某些业务突发性的大算力需要，资源层可能疾速、无效地从其余团队、平台资源层调取到足够的资源提供给业务应用。本章以 VK 与阿里云 ECI 为例，简述云音乐机器学习平台在资源这块的工作：

Visual Kubelet 资源

目前网易外部有很多资源属于不同的集群来治理，有很多的 k8s 集群，杭研云计算团队开发 kubeMiner 网易跨 kubernetes 集群对立调度零碎，可能动静接入其余闲置集群的资源应用。过来一段时间，云音乐机器学习平台和云计算单干，将大部分 CPU 分布式相干的如图计算、大规模离散和分布式训练，弹性调度至 vk 资源，在 vk 资源保障的同时，可能大大增加同时迭代模型的并行度，晋升业务迭代效率；
平台应用 VK 资源能够简略地了解为内部集群被虚构为 k8s 集群中的虚构节点，并在内部集群变动时更新虚构节点状态，这样就能够间接借助 k8s 本身的调度能力，反对 Pod 调度到内部集群的跨集群调度。

云音乐平台的 CPU 算力工作次要包含图计算、大规模离散和分布式训练三类，波及到 tfjob, mpijob，paddlepaddle 几种工作类型，工作正本之间均须要网络通信，包含跨集群执行 Pod Exec，单正本规格大略在（4c~8c, 12G~20G）之间；然而因资源算力有余，工作的正本数以及同时可运行的工作并行度很低，所以各个训练业务需忍耐长时间的训练和工作执行期待。接入 VK 后，可能充分利用某些集群的闲置算力，多正本、多任务并行地实现训练模型的迭代。

阿里云 ECI

CPU 资源能够通过 kubeMiner 来跨集群调度，然而 GPU 这块，基本上整个团体都比拟缓和，为了避免将来某些时候，须要肯定的 GPU 资源没方法满足。机器学习平台反对了阿里云 ECI 的调度，以相似 VK 的形式在咱们本人的机器学习平台上调度起对应的 GPU 资源，如下是云音乐机器学习平台调用阿里云 ECI 资源，在云音乐机器学习平台上，用户只须要在抉择对应的阿里云 ECI 资源，即可实现对阿里云 ECI 的弹性调度，目前已有突发性业务在相干能力上应用：

底层基座层：根底能力赋能用户

底层基座层是利用资源层转换为根底的能力，比方 通过 spark、hadoop 反对大数据根底能力、通过 flink 反对实时数据处理能力，通过 k8s+docker 反对海量工作的资源调度能力，这其中咱们次要讲下 ceph 在整个平台的应用以及咱们在实际优化中的一些工作。

Ceph

Ceph 作为业界所指的一套分布式存储，在机器学习平台的业务中很多应用，比方在开发工作与调度工作中提供同一套文件系统，不便买通开发与调度环境，多读读写能力不便在分布式工作中同用一套文件系统。当然，从 0 到 1 的接入，很多时候是功能性的需要，开源的 Ceph 存在即满足指标。然而，当越来越多的用户开始应用时，笼罩各种各样的场景，会有不同的需要，这里咱们总结 Ceph 在机器学习平台上的一些待优化点：

• 数据安全性是机器学习平台重中之重性能，尽管 CephFS 反对多正本存储，但当呈现误删等行为时，CephFS 就无能为力了；为避免此类事变产生，要求 CephFS 有回收站性能；
• 集群有大量存储服务器，如果这些服务器均采纳纯机械盘，那么性能可能不太够，如果均采纳纯 SSD，那么老本可能会比拟高，因而冀望应用 SSD 做日志盘，机械盘做数据盘这一混部逻辑，并基于此做相应的性能优化；
• 作为对立开发环境，便随着大量的代码编译、日志读写、样本下载，这要求 CephFS 既能有较高的吞吐量，又能疾速解决大量小文件。

针对这些相干的问题，咱们联结团体的数帆存储团队，在 Ceph 上做了比拟多的优化：

改良一：设计并实现基于 CephFS 的防误删零碎

以后 CephFS 原生零碎是没有回收站这一性能的，这也就意味着一旦用户删除了文件，那么就再也无奈找回该文件了。家喻户晓，数据是一个企业和团队最有价值的有形外围资产，有价值的数据一旦受到损坏，对一个企业和团队来说很可能是灭顶之灾。2020 年，某上市公司的数据遭员工删除，导致其股价大跌，市值蒸发几十亿港元，更重大的是，合作伙伴对其信赖降到了冰点，其后续业绩也受到了微小打击。
因而，如何保障数据的可靠性是一个关键问题。然而，CephFS 这一开源明星存储产品恰好短少了这一环。防误删性能作为数帆存储团队与云音乐共建我的项目中的重点被提上了日程。通过团队的攻坚，最终实现了回收站这一防误删性能。

新开发的回收站在 CephFS 中初始化了 trashbin 目录，并将用户的 unlink/rmdir 申请通过后端转换成了 rename 申请，rename 的目的地就是 trashbin 目录。保障了业务应用习惯的一致性和无感。回收站放弃逾期定期清理的机制。复原上，通过构建回收站内相干文件的目录树，而后 rename 回收站内的文件至指标地位来进行复原。

改良二：混合存储系统的性能优化

通过长时间察看剖析机器学习平台 io 状态，发现经常性存在短时间的压力突增状况。对于用户来说，其最关注的就是 老本 以及AI 工作训练时长（存储 IO 时延敏感）。而目前：对于公司内外部用户，如果是谋求性能的用户，数帆存储团队提供基于全闪存盘的存储系统；如果是谋求老本的用户，数帆存储团队这边提供基于全机械盘的存储系统。这里咱们提供一种兼具老本与性能的存储系统计划，

该架构也算是业界较罕用的架构之一，然而有一个问题制约该混部架构的倒退，即间接基于 Ceph 社区原生代码应用该架构，性能只比纯机械盘的集群好一倍不到。因而，数帆存储团队对 Ceph 代码进行了深度剖析与革新，最终攻克了影响性能的两个要害瓶颈点：重耗时模块影响上下文以及重耗时模块在 IO 外围门路，如下图标红所示：

通过数帆存储团队的性能优化之后，该混部零碎性能相较于社区原生版本有了显著晋升，在资源短缺的状况下，IO 时延以及 IOPS 等性能指标有七八倍的晋升，当资源有余且达到限流后，性能也有一倍以上的晋升。

改良三：设计并实现了基于 CephFS 的全方位性能优化

CephFS 作为根本的分布式存储，简略易用是劣势，然而在很多场景下存在着性能问题：比方业务代码、数据管理、源码编译造成的卡顿、提早过高；比方用户删除海量数据目录耗时十分久，有时候甚至要达到数天；比方因多用户分布式写模型导致的共享卡顿问题。这些问题重大影响着用户的应用体验。因而，数帆存储团队对性能问题进行了深入研究与改良，除了下面提到的在混合盘场景下的性能优化，咱们在 CephFS 元数据拜访以及大文件删除等多方面都进行了性能优化。

1. 在大目录删除方面：咱们开发了大目录异步删除性能：用户在日常业务中，常常会遇到须要删除大目录状况。这些目录个别蕴含几千万个文件，总容量在数个 TB 级别。当初用户的惯例形式是应用 Linux 下的 rm -rf 命令，整个过程耗时十分久，有时甚至超过 24 小时，重大影响应用体验。因而，用户心愿能提供一种疾速删除指定目录的性能，且能够承受应用定制化接口。基于此，咱们开发了大目录异步删除性能，这样使得大目录的删除对用户来说能够秒级实现；
2. 在大文件 IO 方面：咱们优化了大文件写性能，最终使得写带宽能够晋升一倍以上，写延时能够降落一倍以上，具体性能指标如下；
3. 在优化用户开发环境 git 和 make 编译等都很慢方面：用户在容器源码目录中应用 git status 十分慢，耗时数十秒以上，同时，应用 make 编译等操作也异样慢，基于该问题，杭州存储组对该问题进行了粗疏剖析：通过 strace 跟踪简略的 git status 命令发现，流程中蕴含了大量的 stat, lstat, fstat, getdents 等元数据操作，单个 syscall 的申请时延个别在百 us 级别，然而数千个（对于 Ceph 源码我的项目，大略有 4K 个）申请叠加之后，造成了达到秒级的时延，用户感触显著。横向比照本地文件系统（xfs，ext4），通常每个 syscall 的申请时延要低一个数量级（十 us 级别），因而整体速度快很多。进一步剖析发现，延时次要耗费在 FUSE 的内核模块与用户态交互上，即便在元数据全缓存的状况下，每个 syscall 耗时仍然比内核态文件系统高了一个数量级。接下来数帆存储团队通过把用户态服务转化为内核服务后，性能失去了数十倍的晋升，解决了用户卡顿的这一体验；
4. 元数据申请时延方面：剖析发现，用户的很多申请时延较高起因是 open，stat 等元数据申请时延较高，因而，基于该问题咱们采纳了多元数据节点的计划，最终使得元数据的均匀拜访时延能够降落一倍以上；

利用框架层：笼罩大部分机器学习业务的工具能力

利用框架层次要承当业务落地业务时，应用的框架能力，比方家喻户晓的 TensorFlow 框架、分布式训练任务能力、大规模图神经网络能力等等，本章将从 TensorFlow 资源迁徙与大规模图神经网络两块工作讲述团队这块的工作：

TensorFlow 与资源迁徙

思考到算力资源的有余，在 2021 年，咱们洽购了一批新的算力，A100 的机器，也遇到了一些问题：

1. 资源与社区：

   • A100 等新显卡仅反对 CUDA11，官网不反对 CUDA10，而官网 TensorFlow 只有最新版本 2.4 以上版本反对 CUDA11，而当初音乐用的比拟多的 TF1.X，源码编译无奈解决跨版本问题，Nvidia 社区仅奉献 Nvidia-TensorFlow 反对 CUDA11；
   • TensorFlow 版本间差别较大，TF1.X 与 TF2.X，TF2.4.0 以下与 TF2.4.0 以上差别很大；
   • TensorFlow1.X 的社区相干问题，如环境、性能，Google 官网不予反对；

2. 音乐外部机器学习基础架构：

   • RTRS 目前仅反对 TF1.14，目前针对 TF1.X，Google 不反对 CUDA11，Nvidia 官网出了 Nvidia-TensorFlow1.15 来反对，然而这种并不属于官网版本，外部代码更改太多，危险较大；
   • 针对目前各个业务组内保护的 Java jni 模型推理的状况，如果须要应用新硬件进行模型训练，须要反对至多 CUDA11 的对应的 TF 版本（2.4 以上）；
   • 模型训练侧代码，目前版本为 TF1.12-TF1.14 之间；

基于这样的背景，咱们实现机器学习平台 TF2.6 版本的全流程反对，从样本读写、模型训练、模型线上推理，全面反对 TF2.6，具体的事项包含：

1. 机器学习平台反对 TF2.6 以及 Nvidia TF1.15 两套框架来适配 Cuda11；
2. 思考到单 A100 性能极强，在大部分业务的模型训练中无奈充分发挥其性能。因此，咱们抉择将一张 A100 切分成更小的算力单元，须要具体理解的能够关注 nvidia mig 介绍，能够大大晋升平台整体的吞吐率；
3. mig 的益处，可能大大地晋升平台整体的吞吐率，然而 A100 通过虚拟化之后，显卡实例的调度以及相干的监控也是平台比较复杂的工作；
4. 离线训练降级到较高版本之后，推理框架也须要降级，保障兼容 TF1.x 与 TF2.x 的框架产生的模型；

通过实现上述事项，在实现 A100 MIG 能力的反对之后，整体从训练速度、推理革新后的数据来看，大大超出预期，离线工作咱们应用新显卡 1 / 3 的算力能够在惯例的工作老版本算力上均匀有 40% 以上的训练速度晋升，最高有 170% 以上的晋升，而线上推理性能，通过适配 2.6 的 TensorFlow 版本，在保障齐全兼容 TF1.X 的线上版本的同时，取得 20% 以上的推理性能晋升。在 A100 切分实例上，咱们目前提供 2g-10gb、3g-20gb、4g-40gb 三类显卡实例，笼罩平台日常的工作类型，其余指标如稳定性均大大超过老版本算力。

大规模图神经网络

随着从传统音乐工具软件到音乐内容社区的转变，云音乐依靠音乐主站业务，衍生大量翻新业务，如直播、播客、K 歌等。翻新业务既是时机也为举荐算法同学带来了挑战：用户在翻新业务中的行为稠密，冷启动景象显著；即便是老业务也面临着如下问题：

• 如何为新用户无效散发内容；
• 将新内容无效分发给用户；

咱们基于飞桨图学习框架 PGL，应用全站用户行为数据构建用户的隐向量表征，刻画用户之间的隐性关系，提供个性化召回、类似开掘、lookalike 等性能；在实践中，咱们遇到了各种难点挑战：

• 难点一：存在多种行为对象、行为类型，用户行为数据量大，近五亿节点（蕴含用户、歌曲、mlog、播客等），数百亿条边的数据规模；
• 难点二：模型训练难，模型自身参数量微小，须要大量算力资源来保障模型的训练；
• 难点三：在企业界，落地像图神经网络这类技术时，须要综合思考老本与收益，其中老本次要包含两个方面：架构革新老本与计算资源老本；

为解决这些难点，咱们基于网易云音乐机器学习平台落地了以下具体的技术计划：

1. GraphService 提供相似于图数据库，基于海量的弱终端资源，提供巨图存储与采样的服务、通过巨图数据加载优化策略，满足不同规模模型以及不同采样办法；
2. 通过 k8s MPI-Operator 实现了超大规模图存储与采样，是实现通用构图计划可用易用必要的根底组件；
3. 整合 k8s TF-Operator 与 MPI-Operator 解决模型分布式训练中的图存储、采样与分布式模型计算的问题；
4. 通过 k8s VK 资源与 cephfs 实现计算存储资源弹性扩容
   训练过程会耗费大量计算存储资源，训练完结，这些资源就会闲置，通过 cephfs 实现存储资源动静扩缩容；通过 virtual-kubelet 等闲置计算资源引入机器学习平台，实现弹性扩容，按需计费，大大减少大规模分布式工作的训练老本；

性能层：化零为整与化整为零的艺术

性能层次要是机器学习平台做为一处机器学习基础设施，去反对整个机器学习过程的全生命周期，在云音乐，一个规范的机器学习流，次要包含四个局部：

1. 数据样本服务；
2. 特色算子开发与配置开发；
3. 模型训练与离线评估；
4. 模型服务开发与部署、继续更新；

而通过整合机器学习流中笼罩的各个局部的不同零碎，端到端机器学习平台目标是为了更高效、不便的为算法开发以及相干的用户提供各种能力的反对。而在外围工作之外，机器学习平台也会抽离局部阶段的能力，为包含通过模型服务、模型共享等相干工作提供局部组件的反对；接下来会别离从端到端机器学习平台与 ModelZoo 两个我的项目来分享咱们在这块的工作：

端到端机器学习平台：化零为整

端对端机器学习平台是通过机器学习平台，形象出一套可能买通样本解决、特色存取、线上服务开发、代码 / 数据版本控制系统、线上服务零碎推送、abtest 零碎标准化流程，形象出相应地接口，为各个机器学习子系统集成至机器学习平台，复用包含容器化、零碎互联、弹性资源、监控等外围能力。端对端机器学习平台目标的愿景是提供一种以模型为核心的机器学习开发范式，通过元数据中心，将整个生命周期的相干元数据关联至模型工作，以模型的视角去串联整个机器学习生命周期的各个阶段。为了达到这个目标，咱们在以下几个方面实现相应的工作：

样本服务

数据样本收集与预处理，次要波及大数据系统的对接，晚期而言，数据样本的开发并没有相干的零碎反对，业务同学本人写 Spark、Flink 工作，进行样本收集、荡涤、预处理等过程。因此，联通零碎，仅须要机器学习平台自身反对用户开发样本工作的联通，音乐外部业务上游次要应用两局部的数据开发平台：猛犸与自研的 Pandora 与 Magina，在机器学习平台上，反对工作级别的依赖，同时思考到其余工作的多样性，咱们在每一个容器中，提供大数据框架的接入能力，反对 Spark、Flink、Hadoop 等根底框架。
而通过一段时间的迭代之后，咱们通过束缚规范的特色应用形式，基于网易云音乐根底的存储套件 Datahub，提供一套规范的 FeatureStore。在此基础上，标准化业务的样本生成逻辑，用户仅需批改少部分的样本生成模板中的逻辑，即可实现一个标准化的业务样本服务，为用户提供实时、离线的样本生成能力。

特色算子开发与配置开发

特色算子开发与配置开发，是一个规范的机器学习流程必须的过程，也是比较复杂的过程，是样本服务的前置逻辑。在云音乐，线上推理框架，简称 RTRS，形象出专门的特色解决模块，提供给用户开发特色算子、应用特色算子生成的逻辑。

用户在原始数据处理时通过特色计算 DSL 语音配置已有算子或者自定义特色解决逻辑，编译成相应地 feature_extractor 包，在线上服务或者样本服务里应用，提供给模型引擎与训练任务应用，具体详情可关注云音乐预估零碎建设与实际这篇文章。

模型服务开发与部署

目前网易云音乐线上的外围业务，次要应用模型服务框架是 RTRS，RTRS 底层基于 C ++ 开发的，而 C ++ 的相干利用开发，存在两个比拟麻烦的中央：

1. 开发环境：总所周知，机器学习相干离线与线上操作系统不匹配，如何以一种比拟优雅的形式提供用户模型开发同时也反对服务开发的能力？网易云音乐机器学习平台底层基于 K8S+docker，提供定制化的操作系统；
2. 依赖库、框架的共享：在进行 rtrs 服务的开发时，环境中须要集成一些公共的依赖，比方框架代码、第三方依赖库等等，通过机器学习提供的对立的分布式存储，只须要挂载指定的公共 pvc，即可满足相干需要；

模型的部署可简略辨别为两个过程：

1. 首次模型的部署：首次模型的局部比较复杂，波及到线上资源申请、环境装置配置等流程，并且在首次模型部署时，须要对立拉取 RTRS 服务框架，通过载入业务自定义逻辑 so 包以及模型、配置、数据文件，提供根底的模型服务能力；
2. 模型、配置、数据的更新：在首次模型部署之后，因为工夫漂移、特色漂移以及种种其余起因，咱们会收集足够多的训练样本从新训练模型或者更新咱们的配置、词典等数据文件，这个时候，咱们通常不是从新公布模型推理服务，而且去动静更新模型、配置、包含词典在内的数据文件等等；

而机器学习平台通过标准化的模型推送组件，适配 RTRS 的模型部署以及线上服务的更新。

端对端机器学习平台的收益

缩小用户参加，晋升效率
端对端机器学习平台将外围业务的次要流程通过模型关联在一起，以模型为核心视角，可能无效地利用上下游的根本信息，比方在样本特色，能够通过复用样本服务中生成的特色 schema 的信息，缩小在模型训练、模型推理时的特色输出局部的开发，能大大减少相干的开发工作，通过咱们在某些业务的试验，可能将业务从 0 开发的过程破费的工夫从周级别到天级别。

机器学习流程可视化与生命周期数据跟踪
端对端机器学习平台通过对立的元数据中心，将各个阶段的元数据对立治理，提供机器学习流程可视化能力：
并且通过各个阶段标准化的元数据接入，可能无效踪机器学习过程各个阶段的生命周期数据以及资源应用状况，如样本应用特色、样本拼接工作的资源应用状况、模型最终上线的各个特色解决形式、模型训练的超参等等：

ModelZoo：化整为零

业务背景

下图是对各个公司的机器学习业务模型上线占用工夫的一个考察数据的阐明，大部分的数据科学家、算法工程师在模型上线上破费过多的工夫：

ModelZoo 性能分层

合乎咱们在云音乐外部业务落地的认知，而除了后面咱们探讨的端到端的标准化的外围业务的解决方案，云音乐外部一些算法团队也会对其中的某些性能组件，有很强的需要，比方咱们的通用模型服务，用户心愿通过易用、高效地部署形式去构建可在理论场景中应用的通用模型，这个就是 ModelZoo 的由来，在这个之上，咱们心愿后续通用模型能在流程上买通再训练、微调，将能公开的已部署的模型，间接提供给有需要的业务方，Model 的根底性能分层如下：

• 资源层：资源层笼罩机器学习平台所有工作资源，包含 GPU、VK 资源、阿里云 ECI 资源；
• 算法层：笼罩包含 CV、NLP、以及其余有通用能力须要的能力模块如 faiss 分布式能力；
• 交付层：次要包含 SDK、接口两种交付形式，其中 SDK 模块用于提供给算法集成开发过程的场景应用，接口用于无算法集成的场景下应用，提供用户自定义模型接口构建、接口提供服务等外围性能；
• 工作层：提供包含推理、微调、重训等外围性能，通过 SDK 性能、接口性能提供；

ModelZoo 停顿

ModelZoo 到目前为止，咱们的工作大略在这几方面：

1. 通过 K8S 反对 Serveless 的能力，应用适合的镜像如 TF Serving、TorchServe，即可对模型做通用的模型服务；
2. 基于机器学习平台开，集成在模型部署组件中，提供组件部署通用模型推理的服务；
3. 通过咱们交付的组件，用户仅须要通过指定模型包（包含部署的一些根底元信息），来部署相应的服务。如果须要额定的前后解决，也反对在 torchserve 中自定义前后解决的逻辑；
4. 在镜像层通过引入 mkl 编译的镜像、调整 session 线程数等外围参数，在高 qps 场景上，rt 缩小 30%；
5. 调研 openvino、triton，目前因为业务已满足需要以及人力需要，暂无进一步投入，有相干教训的欢送分享；

总结

以上就是网易云音乐机器学习平台的过来的一些工作，回顾一下，咱们别离从“资源层”、“底层框架层”、“利用框架层”、“性能层”来分享相干的局部工作以及停顿，机器学习平台因为笼罩的面很宽泛，工作看起来比拟芜杂，笼罩各种不同的技术栈，并且各项工作的挑战与指标都不一样，还是很有意思的。

本文公布自网易云音乐技术团队，文章未经受权禁止任何模式的转载。咱们长年招收各类技术岗位，如果你筹备换工作，又恰好喜爱云音乐，那就退出咱们 staff.musicrecruit@service.ne…。