在本章中,你将被要求设计YouTube。这个问题的解决方案是可以应用的到其他面试问题,比如设计一个视频分享平台,比如Netflix和Hulu。YouTube主页如图14-1所示。
YouTube看起来很简单:内容创作者上传视频,观众点击播放。真的是这样吗简单的?不是真的。在简单的背后隐藏着很多复杂的技术。让我们看看2020年YouTube的一些令人印象深刻的统计数据、人口统计数据和有趣的事实。
从这些数据中,我们知道YouTube是巨大的,全球性的,并且赚了很多钱。
如图14-1所示,除了观看视频,你还可以在YouTube上做很多事情。为例如,评论、分享或喜欢视频,将视频保存到播放列表,订阅频道等。要在45分钟或60分钟的面试中设计好一切是不可能的。因此,它是重要的是要问问题来缩小范围。
候选人:什么特征是重要的?
面试官:能够上传和观看视频。
候选人:我们需要支持哪些客户?
面试官:移动应用、网络浏览器和智能电视。
候选人:我们有多少日活跃用户?
面试官:500万
应聘者:你们每天花在产品上的平均时间是多少?
面试官:30分钟。
候选人:我们需要支持国际用户吗?
面试官:是的,很大比例的用户是国际用户。
候选人:支持的视频分辨率是多少?
面试官:这个系统可以接受大多数的视频分辨率和格式。
候选人:需要加密吗?
面试官:是的
候选人:对视频的文件大小有要求吗?
面试官:我们的平台专注于中小视频。的最大允许的视频大小为1GB。
候选人:我们可以利用亚马逊提供的一些现有的云基础设施吗?谷歌,还是微软?
面试官:这是一个很好的问题。对大多数人来说,从头开始构建一切都是不现实的公司,建议利用一些现有的云服务。
本章将设计一个具有以下特点的视频流服务。
后面的包络估计
下面的估计是基于很多假设的,所以沟通很重要和面试官沟通,确保她和你的想法一致。
从粗略的成本估计,我们知道从CDN提供视频需要很多钱。即使云提供商愿意为big降低CDN成本客户,成本仍然可观。我们将深入讨论降低CDN成本的方法
如前所述,面试官建议利用现有的云服务而不是从头开始。CDN和blob storage是我们的云服务将利用。有些读者可能会问,为什么不自己构建一切?原因列出如下:
从总体上看,这个系统由三个部分组成(图14-3)。
客户端:你可以在你的电脑、手机和智能电视上观看YouTube。
CDN:视频存储在CDN中。当你按下播放键时,视频就会从CDN流式传输过来。
API服务器:除了视频流,其他所有内容都要通过API服务器。这包括feed推荐,生成视频上传URL,更新元数据库和缓存,用户注册等。
在问答环节,面试官表现出了对以下两个方面的兴趣:
我们将探索它们每一个的高级设计。
视频回传流程
视频上传的总体设计如图14-4所示
它由以下几个部分组成:
现在我们已经单独理解了每个组件,让我们来看看视频是如何进行的上传流程工作。该流程被分解为两个并行运行的进程。
流程a:上传真实的视频
实际视频上传过程如图14-5所示。解释如下:
流程b:更新元数据
当文件被上传到原始存储时,客户端并行地向更新视频元数据,如图14-6所示。请求包含视频元数据,包括文件名、大小、格式等。API服务器更新元数据缓存和数据库。
视频流
每当你在YouTube上观看视频时,它通常会立即开始流媒体播放不要等到整个视频下载完毕。下载意味着整个视频复制到你的设备,而流式意味着你的设备持续接收视频来自远程源视频的流。当你观看流媒体视频时,你的客户端会加载一个每次少量的数据,以便您可以立即和连续观看视频。
在讨论视频流之前,让我们先来看一个重要的概念:
流协议。这是控制视频流数据传输的标准方法。受欢迎的
流协议包括:
你不需要完全理解甚至记住这些流协议的名称它们是需要特定领域知识的底层细节。重要的是
了解不同的流协议支持不同的视频编码和回放的球员。当我们设计视频流服务时,我们必须选择正确的流协议来支持我们的用例。要了解更多关于流协议的信息,请点击这里优秀的文章[7]。
视频直接从CDN传输。离你最近的边缘服务器将提供视频。因此,延迟很小。图14-7展示了视频的高
级设计流媒体。
在高层设计中,整个系统分为两部分:视频上传流程以及视频流。在本节中,我们将使用important对这两个流程进行优化优化并引入错误处理机制。
视频转码
当你录制视频时,设备(通常是手机或相机)会给视频文件a某些格式。如果您希望视频在其他设备上流畅地播放,则视频必须被编码成兼容的比特率和格式。比特率是比特被处理的速率随着时间的推移。更高的比特率通常意味着更高的视频质量。需要高比特率流更强的处理能力和更快的网速。
视频转码很重要,原因如下。
有很多种编码格式;然而,它们大多数包含两部分:
有向无环图(DAG)模型
视频转码计算量大且耗时。此外,不同的内容创作者可能有不同的视频处理需求。例如,一些内容创建者要求在他们的视频顶部添加水印,有些还提供缩略图还有一些上传高清视频,而另一些则不上传。
为了支持不同的视频处理流水线并保持高度的并行性,这是非常重要的添加一些抽象级别,让客户端程序员定义要执行的任务。为例如,Facebook的流媒体视频引擎使用有向无环图(DAG)编程模型,它将任务按阶段定义,以便它们可以顺序执行或平行[8]。在我们的设计中,我们采用类似的DAG模型来实现灵活性和并行性。图14-8表示了视频转码的DAG
在图14-8中,原始视频分为视频、音频和元数据。这里有一些可以应用在视频文件上的任务:
DAG调度程序
DAG调度器将DAG图分割为任务的阶段,并将它们放入任务队列在资源管理器中。图14-15展示了DAG调度器如何工作的一个例子。
如图14-15所示,原始视频被分为三个阶段:阶段1:视频、音频、和元数据。在第二阶段,视频文件进一步分为两个任务:视频编码和缩略图。音频文件需要音频编码作为第二阶段任务的一部分。
资源管理器
资源管理器负责管理资源分配的效率。它包含3个队列和一个task scheduler,如图14-17所示。
任务的工人
任务工作者运行在DAG中定义的任务。可以运行不同的任务worker如图14-19所示。
临时存储
此处使用了多种存储系统。存储系统的选择取决于以下因素数据类型、数据大小、访问频率、数据寿命等。例如,元数据经常出现由worker访问,数据量通常较小。因此,在内存中缓存元数据是好主意。对于视频或音频数据,我们将它们放在blob存储中。临时存储中的数据在相应的视频处理完成后释放。
编码的视频
编码视频是编码管道的最终输出。下面是输出的例子:funny_720p.mp4。
系统优化
在这一点上,你应该很好地了解视频上传流程,视频流数据流和视频转码。接下来,我们将优化系统,包括速度、安全和节省成本。
速度优化:视频上传并行化
整体上传视频效率很低。我们可以通过将视频分成更小的块GOP对齐方式如图14-22所示。
这允许在上一个上传失败时快速恢复上传。分割a的工作客户端可以实现GOP格式的视频文件上传,提高上传速度,如图所示图14-23
速度优化:上传中心靠近用户
另一种提高上传速度的方法是在全国建立多个上传中心全局(如图14-24所示)。美国人可以上传视频到北美中国的人们可以上传视频到亚洲上传中心。为了实现我们使用CDN作为上传中心。
速度优化:处处并行
实现低延迟需要认真的努力。另一个优化是构建一个松散的耦合系统,使高度并行。
我们的设计需要一些修改以实现高度并行。让我们放大这个流程视频如何从原始存储传输到CDN。流程如图所示14-25,这表明输出取决于上一步的输入。这种依赖性使得并行变得困难。
为了使系统更加松耦合,我们引入了消息队列,如图所示14日至26日。让我们用一个例子来解释消息队列如何使系统变得更松散耦合的。
安全优化:保护您的视频
许多内容制作者不愿将视频发布到网上,因为他们害怕原创视频将被窃取。为了保护受版权保护的视频,我们可以采用以下三种方法之一安全选项:
CDN是我们系统的一个重要组成部分。它确保了全球范围内的快速视频传输。然而,从信封计算的背面来看,我们知道CDN的开销尤其大当数据量较大时。我们怎样才能降低成本?
之前的研究表明,YouTube视频流遵循长尾分布[11][12]。这意味着一些流行视频被频繁访问,但许多其他视频很少或没有被访问观众。基于这个观察,我们实现了一些优化:
错误处理
对于一个大型系统,系统误差是不可避免的。构建一个高度容错的系统在系统中,我们必须优雅地处理错误,并快速地从错误中恢复。两种类型的错误存在:
每个系统组件的典型错误都包含在以下脚本中:
本章介绍了视频流服务的架构设计,例如YouTube。如果面试结束时还有额外的时间,下面是几点:
扩展API层:因为API服务器是无状态的,所以很容易扩展API层水平。
恭喜你走到了这一步!现在给自己一点鼓励吧。好工作!\
参考资料
[1] YouTube的数字:https://www.omnicoreagency.com/youtube-statistics/
[2] 2019 YouTube人口统计数据:
https://blog.hubspot.com/marketing/youtube-demographics
[3]云前定价:https://aws.amazon.com/cloudfront/pricing/
[4] Netflix在AWS上:https://aws.amazon.com/solutions/case-studies/netflix/
[5] Akamai主页:https://www.akamai.com/
[6]二进制大对象:https://en.wikipedia.org/wiki/Binary_large_object
[7]以下是您需要了解的流协议:
https://www.dacast.com/blog/streaming-protocols/
[8] SVE: Facebook规模的分布式视频处理:
https://www.cs.princeton.edu/~wlloyd/papers/sve-sosp17.pdf
[9]微博视频处理架构:
https://www.upyun.com/opentalk/399.html
[10]委派访问与共享访问签名:
https://docs.microsoft.com/en-us/rest/api/storageservices/delegate-access-with-shared-access 签名
YouTube早期员工的[11]YouTube可扩展性演讲:https://www.youtube.com/watch?
v = w5WVu624fY8
[12]理解互联网短视频分享的特点:一个基于youtube的
测量研究。https://arxiv.org/pdf/0707.3670.pdf
Open Connect的[13]内容流行度:
https://netflixtechblog.com/content-popularity-for-open-connect-b86d56f613b