zoukankan      html  css  js  c++  java
  • 网易云音乐音视频算法的 Serverless 探索之路

    作者:廖祥俐
    策划:望宸
    审核&校对:潇航
    编辑&排版:雯燕

    网易云音乐最初的音视频技术大多都应用在曲库的数据处理上,基于音视频算法服务化的经验,云音乐曲库团队与音视频算法团队一起协作,一起共建了网易云音乐音视频算法处理平台,为整个云音乐提供统一的音视频算法处理平台。本文将分享我们如何通过 Serverless 技术去优化我们整个音视频处理平台。

    本文将从三个部分向大家介绍:

    1. 现状:音视频技术在网易云音乐的应用情况,引入 Serverless 技术之前遇到的问题;

    2. 选型:调研 Serverless 方案时的考虑点;

    3. 落地和展望:我们进行了哪些改造,最终的落地效果和未来规划。

    现状

    作为一家以音乐为主体的公司,音视频技术被广泛应用于网易云音乐的众多业务场景里,为了更形象的让大家感受到,这里列举了 5 个常见的场景:

    1.png

    1. 默认情况下,用户听到的是我们采用音频转码算法预先转好的标准化码率的音质,但由于流量有限或自身对于音质更高的要求,想要切换到差一些或更好的音质。

    2. 用户可以使用云音乐 APP 里面的听歌识曲功能去识别环境中的音乐,这背后使用到了音频指纹提取及识别技术。

    3. 在平台上的一些 VIP 歌曲,为了能给用户更好的试听体验,我们会做副歌检测,让试听直接定位到高潮片段,这里用到了副歌检测算法。

    4. 在云音乐的 K 歌场景里,我们需要对音频的音高进行展示并辅助打分,这里我们用到了音高生成算法去完善 K 歌的基础数据。

    5. 为了更好的满足云音乐平台上,小语种用户的听歌体验,我们为日语、粤语等提供了音译歌词,这里用到了自动罗马音的算法。

    从上面的场景可以看到,音视频技术被广泛应用于云音乐的不同场景里面,发挥了重要的作用。

    从我们的音视频技术做一个简单划分,可以分为三大类:分析理解、加工处理、创作生产,这些一部分是以端上 SDK 的方式,在端上进行处理;而更多的部分,是通过算法工程化的方式,采用后端集群部署管理,以服务的形式提供通用的音视频能力,而这部分是我们今天分享的重点。

    音视频算法的服务化部署工作中,需要了解很多相关音视频算法的特点,如部署环境、执行时间、能否支持并发处理等,随着我们落地算法的增加,我们总结了以下规律:

    2.png

    1. 算法的执行时间长:执行时间往往与原始音频的时长成正比,云音乐很多场景下音频、视频的时长 Range 范围是很大的,基于这个特点,我们在执行单元的设计上,往往都采用异步化的模式。

    2. 音视频算法具有多语言特性:云音乐的算法包括了 C++、Python 等语言,对接环境上下文会带来极大的困扰,为了解决这个问题,我们采用标准化约定及镜像交付的方式,解耦各类环境准备的工作,所以后续对于能否支持镜像部署,会成为我们技术选型的一个重点考察。

    3. 弹性的诉求正在变大:云音乐平台的歌曲,从我入职时候的 500w,到现在在线超过 6000w,增量 vs 存量的 gap 越来越大,当我们快速实施一个算法时,不仅要考虑增量的接入,更要考虑存量的快速处理,所以在系统设计中,会单独把执行单元的最小粒度剥离出来,便于快速的扩容。

    基于我们对工程化的理解,及音视频算法处理的特点,云音乐的音视频处理平台的整体架构如下:

    3.png

    对于不同音视频算法处理的共同部分,我们做了统一的设计,包括算法处理的可视化、监控、快速试用和处理数据统计等,对于资源的分配也设计了统一可配置的管理模式,让整个系统的公共部分可以尽可能抽象并复用。

    整个音视频算法处理平台最关键的,也是今天的分享重点,是执行单元的交互与设计。云音乐通过统一的对接标准、采用镜像交付的方式,解决了很多对接和部署上的效率问题。针对资源的使用,由于我们不断有新算法、存量/增量服务的存在,在上云之前,用的是内部私有云云主机申请/回收、内容容器化的方式。

    为了更好的描述云音乐执行单元的运行流程,我们将它更细化下,如下图所示:

    4.png

    通过消息队列去解耦了执行单元与其他系统的交互,在执行单元内部,我们通过控制消息队列的并发度去适配不同并发性能的算法,尽量控制执行单元的主要工作仅用于算法的计算,这样最终在系统扩容的时候,我们能够做到最小粒度的扩容。

    在这个模式下,我们落地了 60 多种音视频算法,尤其是在近一年来,服务化的算法占到了一半,这些算法向云音乐 100+ 的业务场景提供了服务能力。但更复杂的算法、更多的业务场景,对我们的服务化效率、运维部署和弹性能力都提出了更高的要求,在我们上云之前,在内部已经用到了 1000 台以上不同规格的云主机及物理机。

    选型

    随着业务场景和算法复杂度的增加,虽然通过了很多方式去简化了内部业务场景、算法等的对接,但越来越多夹杂存量、增量处理的算法,不同流量的业务场景规模,以及不同业务场景可能会复用同一类算法的,让我们在处理机器资源的时间,远比我们在开发的时间更多。

    这个也促使我们开始去考虑更多的方式方法,去解决我们遇到的问题,最直接的有三个痛点。

    5.png

    第一个是存量和增量的差异变大,和新算法落地的增多,我们花在处理存量和增量的资源协调时间越来越多;其次是随着算法复杂度的增高,我们在申请/采购机器的时候,需要关注机器的整体规格、利用率等;最后是,我们希望存量的处理能够加快,在处理存量的时候有足够大的资源,在海量音视频数据处理时候,能够压缩存量与增量不一致的时间。总的来讲,我们希望能够有足够大规模的弹性资源,让音视频算法服务不用再多去关注机器管理。

    然而,实际改造不仅仅是关注最终服务能力,还需要综合考虑投入的 ROI。具体来看:

    • 成本:包含两方面,改造的实施成本和计算资源的成本。前者可以结合具体方案进行评估,得到所需投入的人日,此外,改造后在未来的灵活拓展性,也是我们需要考虑的点。后者可以通过云厂商官方给出的费用计算模型,结合我们的执行数据,估算出来。我们在成本方面的选型关键是,在改造成本能够接受的情况下,未来的 IT 成本不会大额的增加。

    • 运行环境的支持:前面提到过,云音乐的运行环境比较多样化,是以镜像交付的方式进行部署的;团队内部都有相对完善的 CICD 支持,这个要求未来的升级、部署事务,例如规格配置上,是否能够简化开发人员对于机器等的关注。我们希望在改造后,不需要在此类事项上花费过多的时间和精力,更多的关注算法执行本身。

    • 弹性能力:除了云厂商提供的计算资源池的规模,我们还会关注弹性算力的启动速度,是否能够对固定场景进行实例预留,以及是否提供更符合业务诉求的灵活弹性能力,以更好的支持业务的发展。

    这些其实都符合 Serverless 的定义,构建和运行应用程序都不需要对服务器进行管理、弹性能力出众等。综合以上的考量,我们选择了公有云函数计算的方式,它能直观的映射我们目前的计算执行过程,同时也能满足后续想尝试通过 Schema 进行算法的编排。下面我会重点分享下引入函数计算 FC 的过程。

    落地

    我们在一周内快速试用了函数计算 FC,然而一个完整的、高可靠的架构,需要考虑更多的因素。因此我们的改造重点是只把算力任务通过函数计算 FC 弹出去,系统在整体的对外输入输出上仍保持不变,并且系统拥有流量控制能力,能够在遇到特殊情况时,降级到私有云进行处理,保障系统的高可靠性,具体的架构改造如下图所示:

    6.png

    云音乐的开发环境与函数计算的适配是改造的重点,我们重点针对部署、监控和混合云支持进行了改造。部署上,我们充分应用了函数计算在 CICD 上的支持及镜像部署的支持,实现了镜像的自动化拉取;在监控设计上,一方面利用云上的监控报警功能,另一方面把它转化为我们内部已有监控系统的参数,让整体的开发运维处理能够维持一致性,最后是从代码设计上,考虑能够兼容混合云部署的实现,最终完成了我们音视频处理平台的 Serverless 改造。

    从函数计算的计费策略上,我们可以看到,有三大因素在影响最终费用,内存的规格、触发计算的次数,以及公网出流量的费用。直接从技术架构上看,大家可能更关注前两者,实际上流量费用也是一笔不小的费用,这个对于我们来讲,也是关注的一个重点。

    我们根据函数计算的费用特性,在存储体系仍然使用网易私有云的情况下,在第一阶段,首先选取的是公网出流量比较少的音视频算法。关于公网出流量比较少,我举个例子,对音频进行特征提取,如一个音频进去,提取一个 256 维的数组,获取的结果就只是一个 256 维数组,它是远远小于音频自身的流量,因此出公网的流量费用会比较少。

    在引入函数计算的第一阶段,特征提取类的算法得到了 10 倍速的提升;稀疏类的算法,可以理解为日常使用率很低的算法,在成本上得到了极大的节约。除此之外,通过函数计算的镜像缓存加速能力,优化了我们节点的启动速度,让所有的服务拉起可以在秒级完成。这些工作,降低了算法运维处理中大量的运维成本,让我们能够更聚焦关注在算法及业务自身。

    7.png

    上方右边这幅图是云音乐其中一个算法的运行示例,可以看到,我们在弹性上的变化范围是非常大的,而函数计算很好的满足了这个诉求。

    未来,我们希望能够更进一步通过 Serverless 技术去解放我们在运维上的人力投入,并将从存储上进行尝试,进而解决公网出流量的问题,让更多场景的音视频算法可以自然的实现;其次,随着算法复杂度的进一步提升,使得计算资源上使用的更加复杂,希望通过 GPU 实例来优化计算过程;最后,在云音乐的业务场景中,实时音视频处理的场景也越来越多,同样的,它也有明显的高峰、低谷的波动特点,我们希望沉淀更多的 Serverless 服务使用经验,最终助力云音乐实时音视频技术的发展。

    作者:廖祥俐,2015年加入网易云音乐,云音乐曲库研发负责人。

    了解更多相关信息,请扫描下方二维码或搜索微信号(AlibabaCloud888)添加云原生小助手!获取更多相关资讯!

    二维码.png

  • 相关阅读:
    BZOJ5212 ZJOI2018历史(LCT)
    BZOJ5127 数据校验
    253. Meeting Rooms II
    311. Sparse Matrix Multiplication
    254. Factor Combinations
    250. Count Univalue Subtrees
    259. 3Sum Smaller
    156. Binary Tree Upside Down
    360. Sort Transformed Array
    348. Design Tic-Tac-Toe
  • 原文地址:https://www.cnblogs.com/alisystemsoftware/p/15530828.html
Copyright © 2011-2022 走看看