网站平台开通微信支付,保健品企业网站,厦门做网站seo的,网页设计代码模板免费Java全能学习面试指南#xff1a;https://javaxiaobear.cn 短视频#xff08;short video#xff09;通常时长在 15 分钟以内#xff0c;主要是在移动智能终端上进行拍摄、美化编辑或加特效#xff0c;并可以在网络社交平台上进行实时分享的一种新型视频形式。短视频具有时… Java全能学习面试指南https://javaxiaobear.cn 短视频short video通常时长在 15 分钟以内主要是在移动智能终端上进行拍摄、美化编辑或加特效并可以在网络社交平台上进行实时分享的一种新型视频形式。短视频具有时间短、信息承载量高等特点更符合当下网民手机使用行为习惯短视频的用户流量创造了巨大的商机。
我们准备开发一个面向全球用户的短视频应用用户总量预计 20 亿应用名称QuickTok。
视频文件和其他媒体文件相比会更大一点这就意味着存储短视频文件需要更大的存储空间播放短视频也需要更多的网络带宽。因此QuickTok 的主要技术挑战是如何应对高并发用户访问时的网络带宽压力以及如何存储海量的短视频文件。接下来我们就来看
看 QuickTok 的需求与技术架构。
1、需求分析
QuickTok 的核心功能需求非常简单用户上传视频、搜索视频、观看视频。我们将主要分析非功能需求。
QuickTok 预计用户总量为 20 亿日活用户约 10 亿每个用户平均每天浏览 10 个短视频由此可以预估短视频日播放量为 100 亿
10亿 × 10 100亿
平均播放 QPS 为 11 万 / 秒
100亿 ÷ 24 × 60 × 60 ≈ 11万/秒
每秒 11 万用户点击视频假设用户平均观看 5 分钟那么同时在观看的视频数就是
11万/秒 × 5 × 60秒 3千万
假设每个短视频的平均播放次数 200 次那么为了支撑这样体量的播放量平均需要每秒上传视频数
11万/秒 ÷ 200 550/秒
每个短视频平均大小 100MB每秒上传至服务器的文件大小为
100MB × 550 55GB
视频虽然不是一秒内上传至服务器的但是这样计算依然没有问题。
每年新增视频需要的存储空间
55GB × 60 × 60 × 24 × 365 1700PB
事实上为了保证视频数据的高可用不会因为硬盘损坏导致数据丢失视频文件需要备份存储QuickTok 采用双副本的备份存储策略也就是每个视频文件存储三份需要的总存储空间
1700PB × 3 5200PB
而播放视频需要的总带宽 11万 × 100MB × 8bit 88Tb
因此我们需要设计的短视频应用是一个每秒上传 550 个视频文件、11 万次播放、新增165GB 存储以及 88Tb 总带宽的高并发应用系统。这个系统呢需要是高性能的能迅速响应用户的上传和播放操作也需要是高可用的能面向全球用户提供 7 * 24 小时稳定的服
务。
2、概要设计
QuickTok 的核心部署模型如下图 用户上传视频时上传请求会通过负载均衡服务器和网关服务器到达视频上传微服务。
视频上传微服务需要做两件事一是把上传文件数据流写入视频文件暂存服务器二是把用户名、上传时间、视频时长、视频标题等视频元数据写入分布式 MySQL 数据库。
视频文件上传完成后视频上传微服务会生成一个视频上传完成消息并将其写入到消息队列服务器。视频内容处理器将消费这个上传完成消息并根据消息内容从视频文件暂存服务器获取视频文件数据进行处理。
视频内容处理器是一个由责任链模式构建起来的管道。在这个管道中视频将会被顺序进行内容合规性审查、内容重复性及质量审查、内容标签生成、视频缩略图生成、统一视频转码处理等操作如下图 合规且非重复的视频会经过统一转码最终被写入分布式文件存储和 CDN。这样视频上传处理就完成了具体时序图如下 以上就是对视频上传环节的设计接下来我们将讨论对视频搜索及播放部分的设计即核心部署模型图中标红的部分如下 视频搜索引擎会根据用户提交的视频标题、上传用户等元数据以及视频内容处理器生成的内容标签构建倒排索引。当用户搜索视频时系统会根据倒排索引来检索符合条件的视频并返回结果列表。结果列表在 App 端向用户呈现时会将此前视频内容处理器生成的
缩略图展现给用户使用户对视频内容有个初步而直观的感受。
当用户点击缩略图时App 开始播放视频。App 并不需要下载完整个视频文件才开始播放而是以流的方式一边下载视频数据一边播放使用户尽量减少等待获得良好的观看体验。QuickTok 使用 MPEG–DASH 流媒体传输协议进行视频流传输因为这个协议具有自适应能力而且支持 HTTP可以应对 QuickTok 的视频播放需求。
3、详细设计
为解决 QuickTok 的两个重要问题如何存储海量视频文件如何解决高并发视频播放导致的带宽压力详细设计将关注视频存储系统、性能优化与 CDN。
此外“如何生成更吸引用户的缩略图”是短视频应用用户体验的一个关键问题详细设计也会关注缩略图生成与推荐的设计实现
1、视频存储系统设计
由需求分析可知QuickTok 每年新增 5200PB 的存储。因此“如何存储海量视频文件”就是 QuickTok 设计的重要挑战之一。对此我们可以尝试与前一篇提到的网盘相同的存储技术方案将视频文件拆分成若干 block使用对象存储服务进行存储。
但 QuickTok 最终采用了另一种存储方案即使用 Hadoop 分布式文件系统 HDFS 进行存储。HDFS 适合大文件存储的一次写入多次读取的场景满足视频一次上传多次播放的需求同时它还可以自动进行数据备份缺省配置下每个文件存储三份也满足我们关于数据存储高可用的需求。
HDFS 适合存储大文件大文件减少磁盘碎片更有利于存储空间的利用同时 HDFNameNode 的访问压力也更小所以我们需要把若干个视频文件合并成一个 HDFS 文件进行存储并将存储相关的细节记录到 HBase 中。 举个例子当用户上传一个视频文件系统会自动生成一个视频 ID这里假设这个 ID 是123。视频内容处理器先对视频进行一系列处理再调用视频文件存储服务来进行存储。
存储服务首先通过 HDFS 创建一个文件比如 /data/videos/clust0/p0/000000001然后将视频文件数据顺序写入到 HDFS 中。写完后存储服务就可以得到这个 HDFS 文件的全路径名 (/data/videos/clust0/p0/000000001)、视频文件在 HDFS 中的偏移量 0、文件大小 99,000,000B
然后视频文件存储服务再将这些信息记录到 HBase 中主键就是视频 ID123value就是 path:/data/videos/clust0/p0/000000001, offset:0, size:99,000,000。
假设另一个用户上传的视频 ID 为 456文件大小 100,000,000B紧随着上一个视频文件也保存到同一个 HDFS 文件中。那么 HBase 中就可以记录主键 456valuepath:/data/videos/clust0/p0/000000001, offset:99,000,000,size:100,000,000。
当其他用户播放视频 456 时播放微服务根据主键 ID 在 HBase 中查找 value 值得到HDFS 文件路径 /data/videos/clust0/p0/000000001从该文件 99,000,000 偏移位置开始读取 100,000,000Byte 数据就是视频 ID 456 完整的文件数据了。
2、性能优化与 CDN 设计
我们前面分析过QuickTok 需要的总带宽是 88Tb这是一个非常巨大的数字。如果单纯靠 QuickTok 自己的数据中心来承担这个带宽压力技术挑战和成本都非常巨大。只有通过 CDN 将用户的网络通信请求就近返回才能缓解数据中心的带宽压力。
App 请求获取视频数据流的时候会优先检查离自己比较近的 CDN 中是否有视频数据。如果有直接从 CDN 加载数据如果没有才会从 QuickTok 数据中心获取视频数据流。
如果用户的大部分请求都可以通过 CDN 返回那么一方面可以极大加快用户请求的响应速度另一方面又可以较大缓解数据中心的网络和硬盘负载压力进一步提升应用整体的性能。
通常的 CDN 设计是在 CDN 中没有用户请求的数据时进行回源即由 CDN 请求数据中心返回需要的数据然后缓存在 CDN 本地。
但 QuickTok 考虑到了短视频的特点大 V、网红们发布的短视频会被更快速、更广泛地播放。因此针对粉丝量超过 10 万的用户系统将采用主动推送 CDN 的方法以提高CDN 的命中率优化用户体验如图 从图中可以看出视频内容处理器进行完视频处理后一方面会将视频存储到前面说过的视频存储系统中另一方面又会调用 CDN 推送服务。然后CDN 推送服务将调用大数据平台获取视频上传者的活跃粉丝数、粉丝分布区域等数据。如果是 10 万粉丝以上的用户发布了短视频CDN 推送服务会根据其粉丝活跃的区域将视频推送到对应区域的 CDN服务器上。
短视频的完播率通常不足 30%所以 QuickTok 也不需要将完整视频推送到 CDN只需要根据视频发布者的历史播放记录计算其完播率和播放期望进度然后将短视频切分成若干 chunk将部分 chunk 推送到 CDN 即可。
业界一般共识视频应用 CDN 处理的带宽大约占总带宽的 95% 以上也就是说通过合理使用 CDNQuickTok 数据中心需要处理的带宽压力不到 4Tb。
3、缩略图生成与推荐设计
用户可以通过 App 主页、搜索结果页、视频推荐页等页面看到视频列表其中每个视频都需要有个缩略图。用户点击缩略图就开始播放视频。
缩略图通常是由视频的某一帧画面缩略而生成的。事实上缩略图的选择会极大地影响用户点击、播放视频的意愿。一个 10 分钟的视频大约包含 3 万帧画面选择哪一帧画面才能使用户点击视频的可能性最大以及针对不同的用户分类是否选择不同的缩略图会产生更高的点击率
我们需要通过大数据平台的机器学习引擎来完成缩略图的生成和推荐如下图 缩略图的生成和推荐可以分为两个具体过程
实时在线的缩略图推荐过程 a利用离线机器学习生成优质缩略图的过程 b。
a 过程中用户通过搜索引擎搜索视频搜索引擎产生搜索结果视频列表后根据视频 ID从缩略图存储中获取对应的缩略图。
但是一个视频可能对应很多个缩略图如果想要显示最吸引当前用户的那个搜索引擎就需要调用 QuickTok 大数据平台的缩略图推荐引擎进行推荐。
推荐引擎可以获取当前用户的偏好特征标签以及视频对应的多个缩略图特征使用XGboost 算法训练好的模型将用户特征标签和缩略图特征进行匹配然后返回最有可能被当前用户点击的缩略图 ID。搜索引擎再按照 ID将对应的缩略图构建到搜索结果页面返回给用户。
用户浏览搜索结果列表点击某些缩略图进行播放。App 应用会将用户的浏览与点击数据发送给 QuickTok 大数据平台这样就进入了利用机器学习来生成优质缩略图的过程 b。
机器学习系统获取到了海量用户的浏览和点击数据同时获取每个缩略图的特征。一方面机器可以学习到哪些特征的缩略图更容易获得用户点击从而生成优质缩略图特征标签库另一方面机器还可以学习到每个用户自身更偏好的图像特征标签供前面提到的推荐引擎使用。
有了机器学习系统的加持视频内容处理器就可以使用优质特征标签库来处理上传的视频内容抽取符合优质特征的帧进而生成缩略图。
以上的 a、b 两个过程不断循环迭代系统就可以不断优化优质特征标签库不断使缩略图更符合用户喜好。
那最开始没有特征库的时候怎么办呢视频内容处理器可以使用随机的办法抽取一些帧作为缩略图进行冷启动。机器学习再从这些随机抽取的缩略图上开始学习从而进入循环优化过程。
4、总结
我们在缩略图生成部分使用了大数据和机器学习的一些技术如果你不熟悉可能会觉得有点困难。但是现在人工智能和机器学习几乎是稍具规模的互联网系统的标配架构师作为整个系统的设计者、技术负责人可能对算法的细节无法做出具体的优化但是对于算法在整个架构中的作用、相关数据的处理和流转必须非常熟悉才能设计出满足业务需要的架构方案。
