CHAPTER 14: 《DESIGN YOUTUBE》第14章 《设计YouTube》

发布时间:2024年01月19日

在本章中,你将被要求设计YouTube。这个问题的解决方案是可以应用的到其他面试问题,比如设计一个视频分享平台,比如Netflix和Hulu。YouTube主页如图14-1所示。
在这里插入图片描述
YouTube看起来很简单:内容创作者上传视频,观众点击播放。真的是这样吗简单的?不是真的。在简单的背后隐藏着很多复杂的技术。让我们看看2020年YouTube的一些令人印象深刻的统计数据、人口统计数据和有趣的事实。

  • 月活跃用户总数:20亿。
  • 每天的视频观看数量:50亿。
  • 73%的美国成年人使用YouTube。
  • YouTube上有5000万名创作者。
  • YouTube 2019年全年的广告收入为151亿美元,比2018年增长36%。
  • YouTube占所有移动互联网流量的37%。
  • YouTube有80种不同的语言。

从这些数据中,我们知道YouTube是巨大的,全球性的,并且赚了很多钱。

步骤1 -了解问题并建立设计范围

如图14-1所示,除了观看视频,你还可以在YouTube上做很多事情。为例如,评论、分享或喜欢视频,将视频保存到播放列表,订阅频道等。要在45分钟或60分钟的面试中设计好一切是不可能的。因此,它是重要的是要问问题来缩小范围。
候选人:什么特征是重要的?
面试官:能够上传和观看视频。
候选人:我们需要支持哪些客户?
面试官:移动应用、网络浏览器和智能电视。
候选人:我们有多少日活跃用户?
面试官:500万
应聘者:你们每天花在产品上的平均时间是多少?
面试官:30分钟。
候选人:我们需要支持国际用户吗?
面试官:是的,很大比例的用户是国际用户。
候选人:支持的视频分辨率是多少?
面试官:这个系统可以接受大多数的视频分辨率和格式。
候选人:需要加密吗?
面试官:是的
候选人:对视频的文件大小有要求吗?
面试官:我们的平台专注于中小视频。的最大允许的视频大小为1GB。
候选人:我们可以利用亚马逊提供的一些现有的云基础设施吗?谷歌,还是微软?
面试官:这是一个很好的问题。对大多数人来说,从头开始构建一切都是不现实的公司,建议利用一些现有的云服务。
本章将设计一个具有以下特点的视频流服务。

  • 能够快速上传视频
  • 流畅的视频流;
  • 能够改变视频质量
  • 基础设施成本低
  • 高可用性、可扩展性和可靠性要求
  • 支持的客户端:移动应用、web浏览器和智能电视

后面的包络估计
下面的估计是基于很多假设的,所以沟通很重要和面试官沟通,确保她和你的想法一致。

  • 假设产品拥有500万DAU(日活跃用户)。
  • 用户每天观看5个视频。
  • 10%的用户每天上传1个视频。
  • 假设平均视频大小为300 MB。
  • 每日总存储空间需求:500万* 10% * 300 MB = 150TB
  • CDN成本。
    • 当云CDN提供视频时,您需要为传输出去的数据付费CDN。
    • 使用亚马逊的CDN CloudFront进行成本估算(图14-2)。假设100%的交通服务来自美国。每GB的平均成本是0.02美元。为简单起见,我们只计算视频流的成本。
    • 500万* 5个视频* 0.3GB * 0.02美元= 15万美元/天。

从粗略的成本估计,我们知道从CDN提供视频需要很多钱。即使云提供商愿意为big降低CDN成本客户,成本仍然可观。我们将深入讨论降低CDN成本的方法
在这里插入图片描述

第二步——提出高层次的设计,并获得认可

如前所述,面试官建议利用现有的云服务而不是从头开始。CDN和blob storage是我们的云服务将利用。有些读者可能会问,为什么不自己构建一切?原因列出如下:

  • 系统设计面试不是从头开始。在有限的时间范围内,选择正确的技术做正确的工作比详细解释这项技术的工作原理。例如,提到对象的blob存储存储原始视频就足够了。谈谈具体设计Blob存储可能会过度使用。
  • 构建可扩展的blob存储或CDN是极其复杂和昂贵的。即使是大像Netflix或Facebook这样的公司并不是什么都自己做。Netflix利用亚马逊的云服务[4],Facebook使用Akamai的CDN[5]。

从总体上看,这个系统由三个部分组成(图14-3)。
在这里插入图片描述
客户端:你可以在你的电脑、手机和智能电视上观看YouTube。
CDN:视频存储在CDN中。当你按下播放键时,视频就会从CDN流式传输过来。
API服务器:除了视频流,其他所有内容都要通过API服务器。这包括feed推荐,生成视频上传URL,更新元数据库和缓存,用户注册等。
在问答环节,面试官表现出了对以下两个方面的兴趣:

  • 视频上传流程
  • 视频流;

我们将探索它们每一个的高级设计。
视频回传流程
视频上传的总体设计如图14-4所示
在这里插入图片描述
它由以下几个部分组成:

  • 用户:用户在电脑、手机或智能设备上观看YouTube电视。
  • 负载均衡器:负载均衡器将请求均匀地分发到API服务器。
  • API服务器:除了视频流之外,所有用户请求都要经过API服务器。
  • 元数据数据库:视频元数据存储在元数据数据库中。它被分片并复制到满足性能和高可用性需求。
  • 元数据缓存:为了更好的性能,将视频元数据和用户对象进行缓存。
  • 原始存储:使用blob存储系统存储原始视频。的引用维基百科关于blob存储的描述是:“一个二进制大对象(blob)是一个二进制大对象在数据库管理系统[6]中作为单一实体存储的二进制数据的集合。
  • 编码转换服务器:视频编码转换也称为视频编码。这是一个过程将视频格式转换为其他格式(MPEG, HLS等),这提供了最好的视频流可能适用于不同的设备和带宽能力。
  • 转换编码存储(Transcoded storage):它是一个blob存储,存储转换编码后的视频文件。
  • CDN:视频缓存在CDN中。当你点击播放按钮时,视频就会流式播放从CDN。
  • 完成队列:它是一个消息队列,存储关于视频转码的信息完成事件。
  • 完成处理程序(Completion handler):包含一组从完成队列并更新元数据缓存和数据库。

现在我们已经单独理解了每个组件,让我们来看看视频是如何进行的上传流程工作。该流程被分解为两个并行运行的进程。

  • a.上传实际视频。
  • b.更新视频元数据。元数据包含关于视频URL、大小、分辨率、格式、用户信息等。

流程a:上传真实的视频
在这里插入图片描述
实际视频上传过程如图14-5所示。解释如下:

  1. 视频被上传至原始存储。
  2. 编码转换服务器从原始存储中获取视频并开始编码转换。
  3. 代码转换完成后,将并行执行以下两个步骤。
    4. 3 a。转码视频被发送到转码存储。
    5. 3 b。代码转换完成事件在完成队列中排队。
  4. 转码后的视频分发到CDN。
  5. 责任。Completion handler包含一组持续拉取事件数据的worker从队列中。
    3 b.1.a。和3 b.1.b。完成处理程序更新元数据数据库和缓存视频转码完成。
  6. API服务器通知客户端视频已成功上传并准备就绪流媒体。

流程b:更新元数据
当文件被上传到原始存储时,客户端并行地向更新视频元数据,如图14-6所示。请求包含视频元数据,包括文件名、大小、格式等。API服务器更新元数据缓存和数据库。
在这里插入图片描述
视频流
每当你在YouTube上观看视频时,它通常会立即开始流媒体播放不要等到整个视频下载完毕。下载意味着整个视频复制到你的设备,而流式意味着你的设备持续接收视频来自远程源视频的流。当你观看流媒体视频时,你的客户端会加载一个每次少量的数据,以便您可以立即和连续观看视频。

在讨论视频流之前,让我们先来看一个重要的概念:
流协议。这是控制视频流数据传输的标准方法。受欢迎的
流协议包括:

  • MPEG-DASH。MPEG代表“移动图片专家组”,DASH代表“移动图片专家组”“HTTP上的动态自适应流”。
  • 苹果HLS。HLS是“HTTP直播”的缩写。
  • 微软平滑流媒体(Microsoft Smooth Streaming);
  • Adobe HTTP动态流(HDS);

你不需要完全理解甚至记住这些流协议的名称它们是需要特定领域知识的底层细节。重要的是
了解不同的流协议支持不同的视频编码和回放的球员。当我们设计视频流服务时,我们必须选择正确的流协议来支持我们的用例。要了解更多关于流协议的信息,请点击这里优秀的文章[7]。

视频直接从CDN传输。离你最近的边缘服务器将提供视频。因此,延迟很小。图14-7展示了视频的高
级设计流媒体。
在这里插入图片描述

步骤3 -深入设计

在高层设计中,整个系统分为两部分:视频上传流程以及视频流。在本节中,我们将使用important对这两个流程进行优化优化并引入错误处理机制。
视频转码
当你录制视频时,设备(通常是手机或相机)会给视频文件a某些格式。如果您希望视频在其他设备上流畅地播放,则视频必须被编码成兼容的比特率和格式。比特率是比特被处理的速率随着时间的推移。更高的比特率通常意味着更高的视频质量。需要高比特率流更强的处理能力和更快的网速。

视频转码很重要,原因如下。

  • 原始视频占用大量存储空间。一小时的高清视频以每秒60帧的速度记录可能会占用几百GB的空间。
  • 许多设备和浏览器只支持某些类型的视频格式。因此,它是出于兼容性的原因,将视频编码为不同的格式很重要。
  • 为了确保用户观看高质量的视频,同时保持流畅的播放,它是一个这是一个向拥有高网络带宽的用户提供高分辨率视频的好主意以及向带宽低的用户提供分辨率较低的视频。
  • 网络状况可能会发生变化,特别是在移动设备上。确保视频是连续播放,可根据网络自动或手动切换视频质量条件对于流畅的用户体验至关重要。

有很多种编码格式;然而,它们大多数包含两部分:

  • 容器(Container):类似于一个篮子,包含视频文件、音频和元数据。你可以通过文件扩展名告诉容器格式,例如。avi、。mov或。mp4。
  • 编解码器(Codecs):压缩和解压缩算法,目的是压缩视频尺寸同时保留视频质量。最常用的视频编解码器是H.264、VP9和HEVC。

有向无环图(DAG)模型
视频转码计算量大且耗时。此外,不同的内容创作者可能有不同的视频处理需求。例如,一些内容创建者要求在他们的视频顶部添加水印,有些还提供缩略图还有一些上传高清视频,而另一些则不上传。

为了支持不同的视频处理流水线并保持高度的并行性,这是非常重要的添加一些抽象级别,让客户端程序员定义要执行的任务。为例如,Facebook的流媒体视频引擎使用有向无环图(DAG)编程模型,它将任务按阶段定义,以便它们可以顺序执行或平行[8]。在我们的设计中,我们采用类似的DAG模型来实现灵活性和并行性。图14-8表示了视频转码的DAG
在这里插入图片描述
在图14-8中,原始视频分为视频、音频和元数据。这里有一些可以应用在视频文件上的任务:

  • 检查:确保视频质量良好,无畸形。
  • 视频编码:视频被转换以支持不同的分辨率、编解码器、比特率、等。图14-9展示了一个视频编码文件的例子。
  • 缩略图。缩略图可以由用户上传,也可以由这个系统。
  • 水印:覆盖在视频上的图像包含识别信息关于你的视频。
    在这里插入图片描述
    视频转码体系结构
    所提出的利用云服务的视频转码架构如图所示图14-10。
    在这里插入图片描述
    该架构有六个主要组成部分:预处理器,DAG调度器,资源管理器,任务工作者、临时存储和编码视频作为输出。让我们仔细看看每个组件。
    预处理器
    在这里插入图片描述
    预处理器有4个职责。
  1. 视频分割。视频流被分割或进一步分割为更小的图片组(GOP)。
    对齐。GOP是按特定顺序排列的一组/块的帧。每个块都是一个
    独立可玩单元,通常只有几秒的长度。
  2. 一些旧的移动设备或浏览器可能不支持视频分割。预处理分割
    共和党联盟为老客户制作的视频。
  3. DAG的一代。处理器根据配置文件客户端生成DAG
    程序员编写。图14-12是一个简化的DAG表示,它有2个节点和
    1优势:
    在这里插入图片描述
    这种DAG表示形式是从下面两个配置文件中生成的(图14-13):
    在这里插入图片描述
  4. 缓存数据。预处理器是分割视频的缓存。为了更好的可靠性,使用
    预处理器将GOPs和元数据存储在临时存储器中。如果视频编码失败,则
    系统可以使用持久化的数据进行重试操作。

DAG调度程序
在这里插入图片描述
DAG调度器将DAG图分割为任务的阶段,并将它们放入任务队列在资源管理器中。图14-15展示了DAG调度器如何工作的一个例子。
在这里插入图片描述
如图14-15所示,原始视频被分为三个阶段:阶段1:视频、音频、和元数据。在第二阶段,视频文件进一步分为两个任务:视频编码和缩略图。音频文件需要音频编码作为第二阶段任务的一部分。
资源管理器
在这里插入图片描述
资源管理器负责管理资源分配的效率。它包含3个队列和一个task scheduler,如图14-17所示。

  • 任务队列(Task queue):它是一个优先级队列,包含要执行的任务。
  • 工作队列:包含工作进程利用率信息的优先队列。
  • 正在运行的队列:它包含当前正在运行的任务和工作进程的信息的任务。
  • 任务调度器:它选择最优的任务/worker,并通知选中的任务worker执行任务。
    在这里插入图片描述资源管理器的工作原理如下:
  • 任务调度器从任务队列获取优先级最高的进程。
  • 任务调度器从worker队列中获取最优的worker来运行任务。
  • 任务调度器通知选中的任务worker运行该任务。
  • 任务调度器绑定任务/worker信息,并将其放入正在运行的队列。
  • 任务完成后,任务调度器将该任务从运行队列移除。

任务的工人
在这里插入图片描述
任务工作者运行在DAG中定义的任务。可以运行不同的任务worker如图14-19所示。
在这里插入图片描述
临时存储
在这里插入图片描述
此处使用了多种存储系统。存储系统的选择取决于以下因素数据类型、数据大小、访问频率、数据寿命等。例如,元数据经常出现由worker访问,数据量通常较小。因此,在内存中缓存元数据是好主意。对于视频或音频数据,我们将它们放在blob存储中。临时存储中的数据在相应的视频处理完成后释放。
编码的视频
在这里插入图片描述
编码视频是编码管道的最终输出。下面是输出的例子:funny_720p.mp4。
系统优化
在这一点上,你应该很好地了解视频上传流程,视频流数据流和视频转码。接下来,我们将优化系统,包括速度、安全和节省成本。
速度优化:视频上传并行化
整体上传视频效率很低。我们可以通过将视频分成更小的块GOP对齐方式如图14-22所示。
在这里插入图片描述
这允许在上一个上传失败时快速恢复上传。分割a的工作客户端可以实现GOP格式的视频文件上传,提高上传速度,如图所示图14-23在这里插入图片描述
速度优化:上传中心靠近用户
另一种提高上传速度的方法是在全国建立多个上传中心全局(如图14-24所示)。美国人可以上传视频到北美中国的人们可以上传视频到亚洲上传中心。为了实现我们使用CDN作为上传中心。
在这里插入图片描述
速度优化:处处并行
实现低延迟需要认真的努力。另一个优化是构建一个松散的耦合系统,使高度并行。

我们的设计需要一些修改以实现高度并行。让我们放大这个流程视频如何从原始存储传输到CDN。流程如图所示14-25,这表明输出取决于上一步的输入。这种依赖性使得并行变得困难。
在这里插入图片描述
为了使系统更加松耦合,我们引入了消息队列,如图所示14日至26日。让我们用一个例子来解释消息队列如何使系统变得更松散耦合的。

  • 在引入消息队列之前,编码模块必须等待的输出下载模块。
  • 引入消息队列后,编码模块不需要等待下载模块的输出。如果消息队列中有事件,则编码模块可以并行执行这些任务。
    在这里插入图片描述
    安全优化:预签名上传URL
    安全是任何产品最重要的方面之一。确保仅授权用户将视频上传到正确的位置,我们引入了如图14-27所示的预签名url。
    在这里插入图片描述
    更新上传流程如下:
  1. 客户端向API服务器发出HTTP请求以获取预签名URL赋予URL中标识的对象访问权限。术语预签名URL用于向Amazon S3上传文件。其他云服务提供商可能会使用不同的名称。例如,微软Azure blob storage支持相同的功能,但是称之为“共享访问签名”[10]。
  2. API服务器以预签名URL作为响应。
  3. 客户端收到响应后,使用预先签名的URL上传视频。

安全优化:保护您的视频
许多内容制作者不愿将视频发布到网上,因为他们害怕原创视频将被窃取。为了保护受版权保护的视频,我们可以采用以下三种方法之一安全选项:

  • 数字版权管理(DRM)系统:苹果有三大DRM系统FairPlay,谷歌Widevine和Microsoft PlayReady。
  • AES加密:支持对视频进行加密,并配置授权策略。的加密后的视频播放后解密。这确保了只有授权用户可以观看加密视频。
  • 视觉水印:这是一个覆盖在视频上的图像为您的视频识别信息。它可以是你的公司标志或公司名称。节约成本的优化

CDN是我们系统的一个重要组成部分。它确保了全球范围内的快速视频传输。然而,从信封计算的背面来看,我们知道CDN的开销尤其大当数据量较大时。我们怎样才能降低成本?

之前的研究表明,YouTube视频流遵循长尾分布[11][12]。这意味着一些流行视频被频繁访问,但许多其他视频很少或没有被访问观众。基于这个观察,我们实现了一些优化:

  1. 只提供最流行的视频从CDN和其他视频从我们的高容量存储视频服务器(图14-28)。
  2. 在这里插入图片描述
  3. 对于不太流行的内容,我们可能不需要存储许多编码视频版本。短
    视频可以按需编码。
  4. 有些视频只在某些地区流行。没有必要分发这些
    其他地区的视频。
  5. 像Netflix一样建立你自己的CDN,并与互联网服务提供商(isp)合作。构建CDN是一个巨大的项目;然而,这对于大数据流来说是有意义的公司。ISP可以是Comcast、AT&T、Verizon或其他互联网提供商。互联网服务提供商是位于世界各地,离用户很近。通过与isp合作,你可以做到改善观看体验,降低带宽费用。所有这些优化都是基于内容流行度、用户访问模式、视频大小等。它在进行任何优化之前,分析历史查看模式非常重要。这里有关于这个主题的一些有趣的文章:[12][13]。

错误处理
对于一个大型系统,系统误差是不可避免的。构建一个高度容错的系统在系统中,我们必须优雅地处理错误,并快速地从错误中恢复。两种类型的错误存在:

  • 可恢复的错误。对于可恢复的错误,如视频段转码失败一般的想法是重试操作几次。如果任务继续失败,则系统认为它是不可恢复的,它返回一个正确的错误码给客户端。
  • 不可恢复的错误。对于不可恢复的错误,例如格式不正确的视频格式系统停止运行与视频相关的任务并返回正确的错误码给客户。

每个系统组件的典型错误都包含在以下脚本中:

  • 上传错误:重试几次。拆分视频错误:如果旧版本的客户端不能通过GOP对齐拆分视频,则整个视频被传递到服务器。分割视频的工作在服务器端完成。
  • 代码转换错误:重试。
  • 预处理器错误:重新生成DAG图。
  • DAG调度器错误:重新调度任务。
  • 资源管理器队列down:使用副本。
  • 任务worker down:在新的worker上重试该任务。
  • API服务器宕机:API服务器是无状态的,因此请求将被定向到不同的API服务器。
  • 元数据缓存服务器宕机:数据复制多次。如果一个节点宕机,你仍然可以访问其他节点来获取数据。我们可以启动一个新的缓存服务器换掉死去的那个。
  • 元数据数据库服务器宕机:
    • Master down。如果master down了,提升其中一个slave作为新的slave的主人。
    • Slave down。如果一个奴隶坏了,你可以用另一个奴隶读和带启动另一个数据库服务器来替换失效的那个。

步骤4 -打包

本章介绍了视频流服务的架构设计,例如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

文章来源:https://blog.csdn.net/weixin_43178103/article/details/135699860
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。