这一切都只是摇摆不定的空气:建立支持音频研究的基础设施

正文字数：4153  阅读时长：6分钟

 Klio到底是什么？它有什么作用？让我们从音频本身的问题开始。

文 / David Riordan and Lynn Root

译 / Helen Lyu

原文链接 / https://engineering.atspotify.com/2020/11/04/its-all-just-wiggly-air-building-infrastructure-to-support-audio-research/

我们只是开源Klio——我们的框架，用于为音频和其他媒体处理构建更智能的数据通道。Klio基于Python和Apache Beam，帮助我们的团队更快，更高效地处理Spotify庞大的音乐和播客目录。我们认为，Klio的易用性及其让任何人利用现代云基础架构和工具的能力，有可能在从大型科技公司到大学和图书馆的任何地方，为媒体和ML研究带来新的可能性。

但是现在，我们正在超越自己。Klio到底是什么？它有什么作用？让我们从音频本身的问题开始。

音频的艰难之路

实际上，声音只是摇摆不定的空气。从根本上讲，每首小提琴协奏曲，情歌，狗叫声和knock-knock joke都是空气压缩和振动的结果，当空气在耳朵里移动骨头和毛发时，我们能感觉到空气的压缩和振动。声音是一种看不见的力量，以一种看不见但可以感觉到的方式到达我们身边。这也使音频很难被机器解析：人类可以分辨出发低沉的嗓音，可以跳舞的节拍和嗡嗡的蜜蜂之间的区别。我们也可以教机器听那些差异吗？

机器监听是致力于使计算机理解音频的研究领域，结合了信号处理，音乐信息检索和机器学习方面的专业知识和方法，因此空气中的所有振动产生的数据对工程师来说更有意义。当编码、压缩和存储在计算机上时，只剩下1和0打包到相对较大的二进制文件中。一眼望去，一把吉他独奏看起来就像是在yodel。那么，我们如何开始理解这一切呢？以及其规模呢？

一个是流行的播客，一个是原声吉他。都是摇摆的空气。软件可以帮助处理音频-识别声音，找到每分钟的节拍，分析频率。但是如果是突然之间的呢?如果同时播放6000多万首歌曲又会怎样呢?

当一个问题乘以六千万次

处理大量的大型二进制文件：这个问题在Spotify上变得越来越大。我们每天增加大约40,000首歌曲，并需要定期处理我们的音乐目录（大约6,000万首歌曲），全球多个团队同时进行工作。除了设计规模化和并行化这样的工程问题之外，我们还希望有一种方法能够将处理工作与我们的音频和ML研究团队所做的工作更加紧密地联系在一起。

我们已经在使用Klio的前身Scio构建支持AI和ML作业的复杂数据管道。Scio被证明是一个灵活，可扩展的框架，任何团队都可以使用它来大规模构建更智能的数据管道。通过将大型数据库查询，map filter reduce操作、自然语言处理和ML模型结合起来，团队可以创建更好、更个性化的播放列表，如discoveryweekly、Release Radar等。

因此，Scio创建了一个平台来处理有关音频的大量数据。但是如何处理音频本身呢？

独特的Spotify问题，独特的Spotify解决方案

虽然为2.99亿多用户的库处理元数据是值得让人骄傲的，但它与处理内容本身（Spotify托管并服务于全球的数千万个二进制音频文件）并不相同。最重要的是，基于Java的语言与我们基于Python的音频和ML研究工具之间的接口不佳。

我们知道，如果我们可以建立支持大规模音频处理的数据管道，那么还有许多未知的功能和个性化需要等待解锁。我们只需要一个支持它的框架，并且该框架与我们的研究工具和工程工具都可以很好地协同工作。

在2019年，由数据工程师，ML研究人员和音频专家组成的临时团队概述了创建专门为处理媒体而设计的框架的要求。Scio是成功的典范，但仍只是起点。这个新框架需要支持：

1. 大文件输入/输出：我们希望以流式处理和批处理两种方式，以多种方式转换音频，视频，图像（各种重负荷的二进制媒体文件）。

2. 可扩展性，可重复性\在线性，效率：当您处理与世界音乐一样大的数据集以及新兴的播客生态系统时，您不需要想一遍又一遍地重做。

3. 研究人员和工程师之间的更紧密合作：转化为对Python（音频处理和ML的通用语言）以及非Python依赖项（例如libsndfile，ffmpeg等）的支持。

简而言之，我们需要一个可以实现音频处理量产的框架。这不仅仅是关于为媒体创建数据管道。它的目的是在Spotify规模上做到这一点，并支持最新的音频和ML研究。让我们首先探讨最后一个需求。

研究人员，工程师和Python：说通用语言的重要性

大约在这个时候，我们注意到我们的研究人员和工程师都开始对阻碍他们的音频工作被采用的障碍感到有点厌倦。音频研究人员正在取得鼓舞人心的突破，但是将新方法集成到运输产品中的成本越来越高。

就像数据和ML工程领域的同行希望提供的帮助一样，这些工程师花费大量时间来照顾用于生产音频处理的几个独特的，定制的系统，这些系统都是为单个团队构建和定制的。换句话说，我们整个公司都有聪明的人从事音频工作，但是我们的世界一流的研究人员和工程师无法一起工作，直到大多数研究被工程师重写。即便如此，所有的工作和努力仍然是孤岛。

解决方案很简单：Python。这是研究的母语，非常适合当前的工程问题。最重要的是，允许每个人都在没有翻译层的情况下发言，这使每个人都可以专注于自己擅长的领域。音频和ML研究人员开始专注于实验和构建前沿的研究工具。工程师开始致力于构建干净，可靠的代码。

什么是Klio？

Klio是一个框架，用于为音频和其他二进制文件构建更智能的数据管道，使您能够大规模生产媒体处理。

1. 流线型apachebeam为研究人员和工程师提供更符合人体工程学的Python原生体验

2. 支持自顶向下和自下而上执行的作业依赖关系图与云处理引擎集成以管理资源和自动扩展生产管道

3. 自定义依赖项的容器化，可简化开发并轻松实现可重复的部署

4. 批处理和流传输管道，可进行连续处理

引擎盖下的Apache Beam，驾驶员座位上有Klio

毫不奇怪，Klio建立在Apache Beam for Python的基础上，同时还旨在为Beam提供更多的Python体验。此外，Klio与传统的Python Beam相比，在媒体处理方面具有多个优势-大大减少了样板代码（平均减少60％），专注于繁重的文件I / O以及在作业依赖项中将多个流作业连接在一起的标准（自上而下和自下而上的执行）。这使团队可以立即专注于编写新的管道，并且知道以后可以轻松扩展和连接它们。

Apache Beam的易用性和精简性意味着我们可以更快地将最先进的音频研究应用于人们的手和耳朵。而且，尽管Klio提供了一种更为独特的方式，默认情况下将Apache Beam用于常见的媒体处理用例，但如果Klio的意见不适合您的用例，它也允许在任何时候使用核心Python Beam。

效率，效率，效率（DRY：不要重复自己）

在开发Klio时，我们决定通过对Spotify的6000万首歌曲目录中的每个曲目进行下采样来对其进行测试-总计超过1亿个音频文件（包括同一首歌曲的多个发行版）。下采样通常是音频分析的第一步，因此它是现实表现的绝佳基准。以前，我们在Spotify上完成这项任务的最快速度是大约三到四个星期。使用Klio，我们可以在六天内完成，并将成本降低了四倍。当您考虑目录中的歌曲数量以及快速增长的播客库时，Klio会对我们的团队和业务产生巨大影响。

有了Klio的流线型框架，管道更加高效和可靠。我们可以在几天内完成需要几周时间的事情。而且，由于工作不必重复(可以递归地创建缺少的依赖项)，因此不必在整个管道中再次运行文件，只需要在最后再应用一次转换。

您会在Klio的整个实施过程中找到这些优化。Klio管道通过避免重复处理已处理的音频来改善处理时间和成本。而且该框架是自以为是和固执己见的–鼓励工程师和研究人员编写专注于一件事的管道，例如查找歌曲的所有节拍的时间戳或测量歌曲的响度。通过创建可重复使用的构建块，Klio使研究人员可以在以前的研究基础上更轻松地构建并创建管道图，从而实现诸如无限播放列表（针对当前情绪进行优化）、内部工具（帮助自动审查新内容）等功能，以及强大的数据，为每个用户个性化的Spotify体验。

规模，可重复性和云。无需基础团队

Klio可以在本地运行，但它确实在云中闪耀-并且已经为此做好了准备。为了实现我们在Spotify上需要的大规模处理和可重复性，Klio充分利用了现代云基础架构的最佳组成部分（如可管理资源以自动缩放生产管道）和工具（如容器化，以便于部署）的最佳部分。

Klio被设计为与云无关，而底层的Apache Beam项目被设计为可在任何数据工作流引擎上运行工作负载。目前，它已配置为可与Google Cloud Platform一起使用，但我们欢迎您为帮助Klio在AWS，Azure或其他基础架构上运行而做出的贡献。

需要注意的一件事：Beam Python的当前限制阻止了它在所有引擎上使用其所有功能，但是随着Apache Beam扩展了与这些引擎的底层兼容性，我们希望与Apache Flink和Apache Spark的兼容性增加。使用Klio的Direct Runner在Amazon AWS和S3上测试Klio的初步工作也已完成。

我们认为这种云集成（基础架构即服务）可以释放生产瓶颈，并鼓励试验。工程团队可以依靠Klio来标准化媒体处理-使用他们已经熟悉的数据处理和监视工具-而不是从头开始创建架构。Klio能够自动调整生产流水线以处理可变的工作负载，这让工程师们能够专注于下一件事，而不是不断地调整工作负载。

从唱歌到海豚歌：开放与伟大的未知

不到两年前，Klio开始作为概念证明。它是出于必要而发明的，目的是克服我们内部面临的挑战。但是即使从一开始，它就是为了自由免费和开源软件而构建的。

正如我们在Backstage（用于构建开发人员门户的开放平台）中看到的那样，Spotify致力于提供开源和开发人员的体验。我们希望使工程师的生活更轻松，以便他们可以专注于打造出奇妙的事物。因此，我们很高兴看到Klio不仅可以帮助他人并促进音频/媒体研究，而且还可以从他人的贡献中学到什么以及Klio如何发展。

在Klio之前和之后，Spotify一直在进行这种大型音频分析近十年，每周、每天和流媒体的基础上提取和转换我们目录中的曲目。音频分析算法通过其独特的属性（如《纽约时报》的互动式文章中对此进行了说明），内部工具（例如我们的自动内容审核筛选器）来为音频特征API提供动力，以对歌曲进行指纹识别。以及特定于市场的功能，例如我们在日本的“一起唱歌”功能，当将歌曲上传到目录中以创建人们可以一起唱歌的交互式版本时，该功能会将人声与乐器分开。

但是正如我们在开源Backstage时所看到的那样，开源社区将提出我们从未梦想过的用例。而且，由于Klio使任何人（不仅仅是大型科技公司）都能大规模进行这种繁重的媒体处理，因此我们特别好奇地看到学术界和研究机构将以此为基础。（海豚语：有人吗？）

因此，感谢Klio团队以及多年来使用Klio或为Klio的发展做出贡献的每个人（包括其兄弟框架Scio）。并感谢所有现在阅读本文并为将来的发展做出贡献的人们。这是只有Spotify才能制造的产品。我们现在更自豪的是，它就在那里，让全世界分享。

LiveVideoStackCon 2020 SFO（线上峰会）正在进行时

现场临时购票用户需等待权限开通后才能观看

您可以联系小秘书（13520771810）

LiveVideoStackCon 2020 美国旧金山站

北京时间：2020年12月11日-12月13日

点击【阅读原文】访问直播页面