济南网站建设工作室,瑞安专业网站建设,网站建设怎么设置权限,自助建网站的平台 数据库点播成本节省的点其实涉及诸多部分#xff0c;例如#xff1a;CDN、转码、存储等#xff0c;而利用播放器降本却是很多客户比较陌生的部分。火山引擎基于内部支撑抖音集团相关业务的实践#xff0c;播放器恰恰是成本优化中最重要和最为依赖的部分。 火山引擎的视频团队做了… 点播成本节省的点其实涉及诸多部分例如CDN、转码、存储等而利用播放器降本却是很多客户比较陌生的部分。火山引擎基于内部支撑抖音集团相关业务的实践播放器恰恰是成本优化中最重要和最为依赖的部分。 火山引擎的视频团队做了份数据统计在一个很经典的视频业务中我们在2022年至2023年大约1年半的时间里针对这个业务进行了33次成本优化点其中13次是播放器主导的优化其余的有12次也是需要播放器强配合的优化也就是说在这个业务里75%的成本优化是直接或间接由播放器参与可见客户端对成本优化的关键作用。 最终我们在很多实践中也发现通过播放器的优化可以为点播业务节省20%甚至更多的成本本篇内容就将聚焦在播放器层面如何节省成本这一主题。 点播成本构成 在视频点播的成本构成中有很明显的二八原则 CDN带宽成本占绝对的大头80%都是带宽成本其次是存储和转码成本二者占不到20%额外还有一些其他的周边的成本比如日志处理的数据成本、AI处理的成本。 我们可以将成本的优化理解成“置换”在点播的成本优化中就存在2种“置换关系” 第1种置换关系是“成本项之间的置换”指的是「带宽-转码-存储」之间的置换。 上图是H.264升级到H.265编码格式的例子265的压缩率相对比264要优20%-40%所以带宽、存储上265是大幅度减少但是265的计算复杂度要复杂很多所以转码成本大幅度升高。 而这个图不是一个等边三角形带宽成本要远大于转码和存储成本所以这个置换是非常划算的。 第2种置换是“成本和体验的置换”我们一般说是“跷跷板效应 例如 我们增大缓存时长对应体验上「卡顿率」就会降低但是成本会增加 抖音小视频feed流场景我们做预加载这时候首屏感会更顺滑但对应的成本是增加的 降低码率那么体验上感到清晰度变差了而成本就是减少的 跷跷板中间支点是技术我们通常是希望固定体验、降低成本依靠技术来支撑。 所以我们总在说降成本那降的到底是什么呢我们这里用一个很简单的乘法公式来表示 在过去“单价”是非常明显的因素大家往往选择在采购环节尽量的压低单价而“用量”上通常会被认为是无法改变的业务因素。 但“用量”实际上是包含2类一类是正常用量确实是比较难改变的业务因素但另一类是“浪费”是可以被优化的。 所以如何识别出浪费、降低浪费是播放器降本的关键点。 那么造成浪费的因素有哪些呢 例如在视频播放过程中会包括“已播放的数据”和“未播放但已经缓存的数据”如果用户中途离开播放那其中“已缓存的数据”都是浪费了。 所以我们定义“浪费”是“已经缓存了、但不需要的字节数”。 从理想上来说没有浪费是最好的但往往业务中浪费是非常大的大于30%是很常见的。 常见的可能带来的浪费包括了 •未播放离开 •向后拖拽 •切换档位 •清晰度溢出举例很小的手机屏幕播放4K的内容肉眼感知不到清晰度的区别 播放器的成本优化方法 针对上述的浪费我们进行了如下的具体优化方法 1、缓存的浪费 承接上图的播放器缓存示意图如果用户播放过程中离开了那么深灰色是浪费部分。很容易就想到我们减少深灰色的部分的大小比如把播放水位降低1/3也就是图中浅黄色的部分减少掉不去缓存那么浪费就明显的减少了。 这个就是静态水位的思路通过减少缓存水位来减少浪费。 但是静态水位是很难抉择的水位大了浪费多但是水位太小了卡顿就会明显的增加。 这里有个马太效应从原理上缓存的本质是为了对抗网络的抖动的。 网络稳定好时只需要很少的缓存就足够了但是网络好时缓存会填充的很快大部分时间都是饱和的。反之波动大的网络需要更多的水位但总的上限也有限无法提供有效的缓存。 为此我们实现了的动态水位算法我们根据一些因素来动态的决策缓存水位的大小 •1探测用户的网络速度和稳定性对稳定性高、速度快的我们减少缓存对网络速度差、稳定性差的网络就增大缓存这样在网络抖动时就能够有更大的缓存空间使用 •2根据用户的播放行为通过数据分析道视频观看的前期用户离开的比例会更高观看的后期离开的比例就会降低 所以前期的缓存水位小一些后期的缓存水位大一些 •3)还有一些其他的因素但目的是在每次播放时决策出一个尽量合理的缓存水位来平衡卡顿和浪费 决定了缓存水位大小之后还有个细节点就是range请求。 Range是http协议的一个请求头默认是“0-请求” 表示请求完整文件。 左侧的图示意如果是单独发一个“0-请求”那么CDN服务端就会持续的返回整个文件如果在中途断开从服务端视角来说这些数据已经发送过去了无论客户端是否需要都已经计费了就构成了浪费。 在上图我们分成3段来发range请求中途断开时是可以停止掉最后一段那么浪费就大幅度减少了。 同样静态的range是很难抉择的range拆分的太细会引起卡顿的提升range过大了成本节省的效果又不够了。 这里我们引入目标水位的概念就是刚刚讲的动态水位算法所决策出来的水位大小。 播放器Range请求的应遵循两个原则1. 将当前视频尽快缓存到目标水位。2. 控制Range拆分的大小避免太小的Range拆分。 上图是动态水位算法动态range拆分的效果示意图 •横轴代表时间线。 纵轴上图是视频下载的大小蓝色块代表一个range请求下图是缓存的大小橙色的折线表示缓存随着视频文件下载和播放时间的波动情况横着的虚线是目标水位。 我们从左到右分析下目标水位和range的关系 • 看第1条竖着的红线决策出来第一条目标水位1是启播水位启播时的range会略大于后面的2个range • 第2条竖着的红线是判断出一次水位提升有可能是检测到网络波动会提高目标水位到水位2同时做一次略大的range请求来达到目标水位 • 第3条竖着的红线是再次提升目标水位到水位3有可能是因为观看时长增加到阈值判断离开概率较小所以保持高水位 •后续的播放在目标水位3随着时间波动range大小也会稳定些。 从最终效果上看在任意一个时间点离开都能够保障相对合理的浪费。 •我们在不同业务上实践了很多次动态水位动态range的AB实验在体验指标持平或更优的前提下带宽降低8% 2、预加载的浪费 在类似于抖音这种feed流下滑的场景会提前加载好下面的视频能够使滑动更顺畅我们 叫“零首帧”效果里面作用最大的就是预加载。 一般的预加载是固定几个视频每个视频固定的大小。为了得到更好的预加载效果会尽量多、尽量大的做预加载也就构成了浪费。 我们做的“精准预加载策略”在“时机、大小、个数”上做精细化的优化 •1 时机上对预加载也进行切片这样可以区分出来一部分是紧急的 其他是不紧急的。比如图里标记P0的是要最优先下载的然后可以做预加载预加载标记P1的部分然后是当前视频的缓存水位之后可以选择是否要预加载P3的部分。 •2大小上每个视频也会结合视频的长度、头大小、码率等因素计算出来需要预加载的大小 •3个数上按照feed list中的优先级依次预加载后续N个视频动态计算也会结合用户本身的行为比如快速滑动来动态决策。 •我们在不同业务上进行AB实验都能够验证这策略可以有效的提升预加载利用率、降低对应流量成本 3、清晰度的浪费 现在的主干场景是在移动端看视频大家都会有启播选档的策略就是在播放启动时决定所需要的清晰度一般是跟随网速、码率来决策的。 经常大家面临的场景是在竖屏里播放横屏视频时实际上在很窄的一个空间里进行播放 这个时候如果依然使用完整的清晰度那么肉眼是看不出来的清晰的。而且通常情况下小窗播放时用户的主要关注度也并不是画面清晰度所以就产生了实际上的清晰度浪费。 我们对应的解决策略叫 “窄屏低清” 就是识别出来显示区域很窄时播放低清晰度的视频比如360P当需要横屏时再快速的切换为正常的清晰度。这里如果是mp4格式播放需要转码也做些配合支持mp4的帧对齐和平滑切换。 在很多应用中都是很常见的也有常见的小窗播放多个业务的AB实验都能有3%以上的成本收益 另外清晰度上还有个很棒的能力是客户端超分。随着客户端超分能力的优化现在很大一部分机型在客户端向上超分一个档位是完全没问题的耗电可以忽略。 对应节省成本的策略是“降档超分”就是分发的清晰度向下降一档然后再通过客户端超分降主观清晰度补回来。在国内当前的机型条件下大部分业务能够有68%左右的成本收益。 4、异常流量的浪费 我们根据「播放器日志是否可以识别」、「是否是正常流量」把流量分成了4类。 在非常多的业务中会发现第三种情况流量有异常浪费比如有部分视频码率过高可能是没转码或者转码模版用错了。我们开始时会认为“这些都是很明显的失误业务层小心点不就行了么 ”但后来我们做成了单独的异常流量分析模块。我们跟业务尝试分析原因发现业务总是复杂的 比如业务场景很复杂包括短视频、长视频、主页视频、广告视频等等研发的迭代也通常会带来些历史问题并不是所有的人员都需要持续的感知成本只要有一个环节漏掉了那么就可能会造成很大浪费。 这里还有个问题点如果是体验问题或者bug总会有用户保障来及时发现。但成本问题用户基本是无法发现的发现时就比较晚了。 我们是通过端到端的日志分析来发现和避免这些浪费的。原理很简单 1在客户端对日志染色 2cdn日志里记录的区分是否是播放器产生的、是否是我们点播的域名。 3对两头的日志进行比对和分析 不仅如此这里还有个副产物是通过这些日志分析识别到业务真实是被盗链了然后做盗链的治理。 数据挖掘成本优化空间 以上是火山引擎是实际业务服务过程中探索出的优化方案但优化是不是有上限的优化到什么水平可以达到成本和体验的平衡更多的能力是通过数据能力持续的挖掘出来的。 先从结果上来看我们成本优化后通常会有2个报告 1AB实验报告里面会分析对QoE的体验影响多少对成本优化的影响多少比如人均播放时长增加多少成本降低多少。做成本的AB实验依赖一个工具“客户端成本指标”。 2价值回溯文档用于核算真实收益有多少一般发生在完整上量之后比如1个月或2个月后。关键结果叫“万分钟播放成本”这个对应的依赖的工具是“成本评估公式”。 客户端成本指标 这张图从左往右是视频点播的数据流向。想要建设好成本埋点有2个难点 1、成本拟合。因为真实的计费数据是左侧CDN的计费日志在右侧的客户端侧实际上是没有成本数据的所以我们需要把数据缓存层的对成本的埋点尽量的拟合使之尽量的对应到CDN的计费日志。这个过程是非常艰难的我们通过了大量的离线校验。 2、提升可解释率。业务动作比较复杂播放、预加载、拖拽、重播等等举个例子重复播放播放层是记录2遍播放时长的但是因为有缓存真实的网络请求只有1遍。我们想要两份数据尽量对齐、可解释就需要涵盖住尽量所有的业务场景。 我们当前达到了“可解释率达到95%”也就是说比如服务端CDN产生了100Gbps的带宽客户端的日志能够拟合解释清楚95%。 虽然还不到100%但日常来做成本优化、成本归因已经足够了。 下图是成本指标进入AB实验后的结果 核心指标 归因指标 成本数据进入AB实验有什么用呢 1、快速判断客户端的成本变化结果。大部分成本优化的能力都是伴随着策略的不同策略有不同的结果置换关系我们需要通过实验来确定效果。假设没有客户端的成本数据的话我们就需要用不同的CDN域名来实验这是很低效的并且域名带宽的波动也会引起成本的波动。而在客户端成本指标进入了AB实验之后大部分场景都直接看报表数字就可以了 2、机制上可以防蜕化。 业务的产品经理、分析师等角色也日常会关注到实验数据的当成本数据也进入实验后这些角色也可以关注到成本的变化这样就能够防退化了。举例版本升级时只要经历了AB实验就很难有成本退化的问题。 成本评估公式 “成本评估公式” 本质是一种单位成本的衡量方法。 我们叫“万分钟播放成本”分子是点播的IT成本分母是点播视频消费时长。 从技术侧来看分子是“CDN、存储、转码等各种成本的加和”分子是播放的时长。 这个公式很简单但为什么要这么做呢 涉及到成本优化就会跟采购、财务团队打交道采购、财务看到的都是每月的账单业务用量每个月都在上下波动导致账单每个月也都在波动。万分钟播放成本是单位成本就可以刨除掉业务用量的影响因素来衡量成本是否真的优化了。 我们来拆解其中的万分钟CDN成本 万分钟CDN成本的影响因子会涉及到价格、码率、浪费率、带宽流量比。 举一个真实的例子 有个客户反馈成本增加了但是客户自己的业务用量在波动不太好判断是什么情况。我们拆解分析万分钟CDN成本的具体影响因子就发现了万分钟CDN成本确实是涨了11%主因是“码率”涨了8%“浪费率”增加了5%。 总结和展望 建标准 在服务业务的过程中大家经常会面临一个问题 还能再降多少极限是多少 这些问题是很难回答的因为每个业务的场景都不同举例缓存浪费中每个业务的客户中断离开的模型可能都不一样那么建设统一的标准就很难了 火山引擎目前通过3种方式来建设标准 1通过排名获取标杆将类似场景的业务进行排名对齐当前技术做的最好的可以作为一种标准 2离线的实验来模拟我们做了成本的自动化测试平台设计测试case测试出来不同的参数的成本结果是多少最后总结分析出来极限是多少 3通过“理论公式”来推算“标准” 举例通过“视频播放时长、中途离开比例”的关系然后推算出理论的优化空间有多少 做顾问 面对的业务越来越多降本的能力也越来越多时就会遇到效率问题功能这么多应该用哪些每个业务的场景也不一样那么策略参数应该怎么配置呢 万分钟播放成本分析和策略推荐 解决方法是做顾问上图是我们的一个万分钟CDN成本与理想万分钟成本的一个差异分析表我们给计算出了对应的差异然后再给出可以补足差异的策略或功能推荐。 当然这个表只是一个总结概览更多的内容我们会整理成“顾问服务报告”把各个点的差异、业务分析、解决方法与业务逐一的讨论分析。 万分钟播放成本是一个非常简单、容易落地、价值很大的工具大家计算下万分钟播放成本如有调优的诉求非常欢迎来与火山引擎交流。火山引擎视频点播https://www.volcengine.com/product/vod。
