沙井网站开发,东莞专业网,我想做个门户网站怎么做,免费制作网站服务器简介#xff1a; 网易云音乐最初的音视频技术大多都应用在曲库的数据处理上#xff0c;基于音视频算法服务化的经验#xff0c;云音乐曲库团队与音视频算法团队一起协作#xff0c;一起共建了网易云音乐音视频算法处理平台#xff0c;为整个云音乐提供统一的音视频算法处理…简介 网易云音乐最初的音视频技术大多都应用在曲库的数据处理上基于音视频算法服务化的经验云音乐曲库团队与音视频算法团队一起协作一起共建了网易云音乐音视频算法处理平台为整个云音乐提供统一的音视频算法处理平台。本文将分享我们如何通过 Serverless 技术去优化我们整个音视频处理平台。
作者廖祥俐 策划望宸
网易云音乐最初的音视频技术大多都应用在曲库的数据处理上基于音视频算法服务化的经验云音乐曲库团队与音视频算法团队一起协作一起共建了网易云音乐音视频算法处理平台为整个云音乐提供统一的音视频算法处理平台。本文将分享我们如何通过 Serverless 技术去优化我们整个音视频处理平台。
本文将从三个部分向大家介绍
现状音视频技术在网易云音乐的应用情况引入 Serverless 技术之前遇到的问题选型调研 Serverless 方案时的考虑点落地和展望我们进行了哪些改造最终的落地效果和未来规划。
现状
作为一家以音乐为主体的公司音视频技术被广泛应用于网易云音乐的众多业务场景里为了更形象的让大家感受到这里列举了 5 个常见的场景 默认情况下用户听到的是我们采用音频转码算法预先转好的标准化码率的音质但由于流量有限或自身对于音质更高的要求想要切换到差一些或更好的音质。 用户可以使用云音乐 APP 里面的听歌识曲功能去识别环境中的音乐这背后使用到了音频指纹提取及识别技术。 在平台上的一些 VIP 歌曲为了能给用户更好的试听体验我们会做副歌检测让试听直接定位到高潮片段这里用到了副歌检测算法。 在云音乐的 K 歌场景里我们需要对音频的音高进行展示并辅助打分这里我们用到了音高生成算法去完善 K 歌的基础数据。 为了更好的满足云音乐平台上小语种用户的听歌体验我们为日语、粤语等提供了音译歌词这里用到了自动罗马音的算法。
从上面的场景可以看到音视频技术被广泛应用于云音乐的不同场景里面发挥了重要的作用。
从我们的音视频技术做一个简单划分可以分为三大类分析理解、加工处理、创作生产这些一部分是以端上 SDK 的方式在端上进行处理而更多的部分是通过算法工程化的方式采用后端集群部署管理以服务的形式提供通用的音视频能力而这部分是我们今天分享的重点。
音视频算法的服务化部署工作中需要了解很多相关音视频算法的特点如部署环境、执行时间、能否支持并发处理等随着我们落地算法的增加我们总结了以下规律 算法的执行时间长执行时间往往与原始音频的时长成正比云音乐很多场景下音频、视频的时长 Range 范围是很大的基于这个特点我们在执行单元的设计上往往都采用异步化的模式。 音视频算法具有多语言特性云音乐的算法包括了 C、Python 等语言对接环境上下文会带来极大的困扰为了解决这个问题我们采用标准化约定及镜像交付的方式解耦各类环境准备的工作所以后续对于能否支持镜像部署会成为我们技术选型的一个重点考察。 弹性的诉求正在变大云音乐平台的歌曲从我入职时候的 500w到现在在线超过 6000w增量 vs 存量的 gap 越来越大当我们快速实施一个算法时不仅要考虑增量的接入更要考虑存量的快速处理所以在系统设计中会单独把执行单元的最小粒度剥离出来便于快速的扩容。
基于我们对工程化的理解及音视频算法处理的特点云音乐的音视频处理平台的整体架构如下 对于不同音视频算法处理的共同部分我们做了统一的设计包括算法处理的可视化、监控、快速试用和处理数据统计等对于资源的分配也设计了统一可配置的管理模式让整个系统的公共部分可以尽可能抽象并复用。
整个音视频算法处理平台最关键的也是今天的分享重点是执行单元的交互与设计。云音乐通过统一的对接标准、采用镜像交付的方式解决了很多对接和部署上的效率问题。针对资源的使用由于我们不断有新算法、存量/增量服务的存在在上云之前用的是内部私有云云主机申请/回收、内容容器化的方式。
为了更好的描述云音乐执行单元的运行流程我们将它更细化下如下图所示 通过消息队列去解耦了执行单元与其他系统的交互在执行单元内部我们通过控制消息队列的并发度去适配不同并发性能的算法尽量控制执行单元的主要工作仅用于算法的计算这样最终在系统扩容的时候我们能够做到最小粒度的扩容。
在这个模式下我们落地了 60 多种音视频算法尤其是在近一年来服务化的算法占到了一半这些算法向云音乐 100 的业务场景提供了服务能力。但更复杂的算法、更多的业务场景对我们的服务化效率、运维部署和弹性能力都提出了更高的要求在我们上云之前在内部已经用到了 1000 台以上不同规格的云主机及物理机。
选型
随着业务场景和算法复杂度的增加虽然通过了很多方式去简化了内部业务场景、算法等的对接但越来越多夹杂存量、增量处理的算法不同流量的业务场景规模以及不同业务场景可能会复用同一类算法的让我们在处理机器资源的时间远比我们在开发的时间更多。
这个也促使我们开始去考虑更多的方式方法去解决我们遇到的问题最直接的有三个痛点。 第一个是存量和增量的差异变大和新算法落地的增多我们花在处理存量和增量的资源协调时间越来越多其次是随着算法复杂度的增高我们在申请/采购机器的时候需要关注机器的整体规格、利用率等最后是我们希望存量的处理能够加快在处理存量的时候有足够大的资源在海量音视频数据处理时候能够压缩存量与增量不一致的时间。总的来讲我们希望能够有足够大规模的弹性资源让音视频算法服务不用再多去关注机器管理。
然而实际改造不仅仅是关注最终服务能力还需要综合考虑投入的 ROI。具体来看
成本包含两方面改造的实施成本和计算资源的成本。前者可以结合具体方案进行评估得到所需投入的人日此外改造后在未来的灵活拓展性也是我们需要考虑的点。后者可以通过云厂商官方给出的费用计算模型结合我们的执行数据估算出来。我们在成本方面的选型关键是在改造成本能够接受的情况下未来的 IT 成本不会大额的增加。运行环境的支持前面提到过云音乐的运行环境比较多样化是以镜像交付的方式进行部署的团队内部都有相对完善的 CICD 支持这个要求未来的升级、部署事务例如规格配置上是否能够简化开发人员对于机器等的关注。我们希望在改造后不需要在此类事项上花费过多的时间和精力更多的关注算法执行本身。弹性能力除了云厂商提供的计算资源池的规模我们还会关注弹性算力的启动速度是否能够对固定场景进行实例预留以及是否提供更符合业务诉求的灵活弹性能力以更好的支持业务的发展。
这些其实都符合 Serverless 的定义构建和运行应用程序都不需要对服务器进行管理、弹性能力出众等。综合以上的考量我们选择了公有云函数计算的方式它能直观的映射我们目前的计算执行过程同时也能满足后续想尝试通过 Schema 进行算法的编排。下面我会重点分享下引入函数计算 FC 的过程。
落地
我们在一周内快速试用了函数计算 FC然而一个完整的、高可靠的架构需要考虑更多的因素。因此我们的改造重点是只把算力任务通过函数计算 FC 弹出去系统在整体的对外输入输出上仍保持不变并且系统拥有流量控制能力能够在遇到特殊情况时降级到私有云进行处理保障系统的高可靠性具体的架构改造如下图所示 云音乐的开发环境与函数计算的适配是改造的重点我们重点针对部署、监控和混合云支持进行了改造。部署上我们充分应用了函数计算在 CICD 上的支持及镜像部署的支持实现了镜像的自动化拉取在监控设计上一方面利用云上的监控报警功能另一方面把它转化为我们内部已有监控系统的参数让整体的开发运维处理能够维持一致性最后是从代码设计上考虑能够兼容混合云部署的实现最终完成了我们音视频处理平台的 Serverless 改造。
从函数计算的计费策略上我们可以看到有三大因素在影响最终费用内存的规格、触发计算的次数以及公网出流量的费用。直接从技术架构上看大家可能更关注前两者实际上流量费用也是一笔不小的费用这个对于我们来讲也是关注的一个重点。
我们根据函数计算的费用特性在存储体系仍然使用网易私有云的情况下在第一阶段首先选取的是公网出流量比较少的音视频算法。关于公网出流量比较少我举个例子对音频进行特征提取如一个音频进去提取一个 256 维的数组获取的结果就只是一个 256 维数组它是远远小于音频自身的流量因此出公网的流量费用会比较少。
在引入函数计算的第一阶段特征提取类的算法得到了 10 倍速的提升稀疏类的算法可以理解为日常使用率很低的算法在成本上得到了极大的节约。除此之外通过函数计算的镜像缓存加速能力优化了我们节点的启动速度让所有的服务拉起可以在秒级完成。这些工作降低了算法运维处理中大量的运维成本让我们能够更聚焦关注在算法及业务自身。 上方右边这幅图是云音乐其中一个算法的运行示例可以看到我们在弹性上的变化范围是非常大的而函数计算很好的满足了这个诉求。
未来我们希望能够更进一步通过 Serverless 技术去解放我们在运维上的人力投入并将从存储上进行尝试进而解决公网出流量的问题让更多场景的音视频算法可以自然的实现其次随着算法复杂度的进一步提升使得计算资源上使用的更加复杂希望通过 GPU 实例来优化计算过程最后在云音乐的业务场景中实时音视频处理的场景也越来越多同样的它也有明显的高峰、低谷的波动特点我们希望沉淀更多的 Serverless 服务使用经验最终助力云音乐实时音视频技术的发展。
作者廖祥俐2015年加入网易云音乐云音乐曲库研发负责人。
原文链接 本文为阿里云原创内容未经允许不得转载。
