全链路的数据收集，分析，才能精准的定位问题，并制定方案改进。本文来自快手流媒体大数据平台架构师罗喆在LiveVideoStackCon热身分享上的分享，他会在10月19-20日的LiveVideoStackCon上分享更详细和完整的内容。
文 / 罗喆
整理 / LiveVideoStack
直播回放：
https://www.baijiayun.com/web/playback/index?classid=18073150147056&session_id=201808020&token=GqnbiUX1y4lt681rrJ0J_RVM5yFl6dFS4sB52SAekvWq3jsp5ES4O8ykX8qRNLttvr5OwSoF9BcKp0fXMnVKLQ
今天的主要内容分为以下几个部分：
1，快手业务简介
2，用户体验（QoE）监测指标简介
3，直播质量（QoS）指标介绍
4，直播QoE-QoS指标联合分析
5，短视频大数据体系简介和预告
一， 快手业务简介
快手的主要业务就是短视频和直播，上图是一些快手的直播截图，从这些图片中可以看出快手平台的内容比较具有生活气息，场景十分丰富，有室内有户外，有游戏有吃播，因此从技术的角度来看，我们主要需要解决用户地域分布广、网络环境复杂、手机机型复杂、业务场景丰富等挑战。面对海量的用户，复杂的场景，我们选择通过建立全面的数据监测体系，实时感知用户的体验问题，从而提出有针对性的优化策略，并且评估优化的收益。在实践中，我们总结了一系列用户体验（QoE）、服务质量（QoS）相关指标，研究了它们之间的区别和联系，对于体验优化有指导性作用，在此分享一下我们的相关经验，希望对从事相关工作的同学们能有帮助。
二， 直播的用户体验（QoE，Quality of Experience）监测指标简介
简单介绍一下QoE（Quality of Experience）用户体验指标，QoE指标的设计理念是为了更贴近用户的真实感受，收集的是用户的行为数据，主要是用来衡量用户的主观体验，比如直播卡顿了，多少用户会选择离开当前直播间。与之对应，技术服务质量指标（QoS，Quality of Service），主要反映的是客观指标，如发生了多少次卡顿。如上图所示，是四个典型QoE指标的示例。
首先，次均观看时长和在线人数会反映用户的行为，从图中可以看出，次均观看时长和在线人数两条曲线在晚高峰时段的时候会迅速达到峰值，而在白天一直处于一个比较平稳的增长状态。这个增长趋势是用户行为导致的，因为用户在晚上的时候更有时间刷短视频和观看直播，所以次均观看时长和在线人数都会上涨。这个跟服务质量也会有关系，在晚高峰的时候如果卡顿严重，可能会引起曲线下行，但总体上来说，服务质量指标在这里所占的权重并不是决定性的。
下面来看完播率和用户评论卡顿数，完播率的定义是完整的观看完一个短视频的比例，用户评论卡顿数的定义是直播间里观众给主播发送内容是”卡”或同义评论的数量。完播率评价的是，用户是否看完一个短视频。用户评论卡顿数是用户很直观的一个真实反馈，当他觉得这个直播间卡了，他会要强烈的抱怨一下，这反应了用户的真实体验。在影响这两个指标的因素中，技术服务质量的权重就会比较大。完播率涉及到因素主要包括推荐给用户的视频是不是他喜欢看的，以及整个播放过程是不是流畅，这些与具体的技术服务指标都有较强相关性。用户评论卡顿数的波动有可能因为直播的过程中有某些因素影响到了直播，比如说网络抖动，主播机器卡了或者商业CDN的服务质量下滑等等，这些都会导致用户观看卡顿，而这些都是技术服务质量。这四个QoE指标，能比较完整的说明QoE指标和用户体验相关，也和QoS相关，但是QoS在不同的QoE指标所占的权重是不一样的，有的指标用户行为的权重会大一些，有的指标QoS权重会大一些。
对于快手来说，QoE是重要的监测指标，但如果要找到影响QoE的因素，还需要通过QoS来监测。
三， 直播技术服务质量（QoS，Quality of Service）指标介绍
QoS指标用于衡量系统中，客观发生的质量相关事件，是技术优化的主要目标。从技术角度出发的优化，均以QoS为目标，如卡顿率，首屏时间等。下面介绍一下快手的QoS指标设计思路。
1， 直播完整流程
首先一起看一下直播业务的完整流程，可以分为三块：推流端，传输CDN和播放端。
2， 主播端采集数据
制订QoS指标之前，需要先采集比较详细的打点数据，在主播端，采集架构图从左往右，首先是摄像头和麦克风的采集，之后是去噪，美颜和特效等前处理算法，这些技术模块非常消耗CPU和机器的内存，为了监控性能，需要对这个过程中的帧率、CPU和内存占用做详细的上报。之后进入编码环节，这里我们同样会监控帧率，除此之外，我们也会采样上报编码器的客观质量数据，便于线上做大规模质量调优。在传输环节，我们会统计主播端的卡顿次数，记录收流源站服务器的IP、地理位置等详细信息。
3， 播放端采集数据
播放端的采集数据，采集过程是主播端的逆序过程。我们会详细记录拉流节点信息，细分的首屏时间，接收缓冲区信息，卡顿，码率、解码帧率等，在播放失败的时候，也会上报错误信息和原因。
4， 直播QoS指标
采集到了数据之后，怎么把它转换成一个监测指标呢？数据必须汇聚成一些对用户体验有关键影响的指标才能进行观测，下面按照直播的流程介绍每个核心QoS指标。
首先，在主播端，评价主播端的推流性能是通过直接计算主播的推流卡顿，主播端最容易发生问题就是网络抖动导致卡顿。在观众端，首先是通过计算黑屏率评估拉流可用性，黑屏指用户完全看不到直播的画面，即整个直播观看不可用。
当用户看到画面后，需要评估开播过程的性能，整个开播过程是否是流畅的，这里主要用首帧时间来评估。
拉流开播之后，用户可能会持续观看一段时间，通过在拉流端上报卡顿次数和卡顿时长来计算整体的卡顿率，作为稳定播放期间性能的评估指标。卡顿率的定义就是给定时间窗口内，发生过卡顿的观看行为数量除以总的观看行为数量。
除了性能之外还有稳定性，拉流端还有一种场景是可能它因为某些原因导致断线了，断了之后用户会自动重连，通过统计重连次数观测稳定性。
从推流端到拉流端的整个全流程都用这五个核心的指标来监控大盘的情况。
5， 分析维度
有了核心的QoS指标，还需要了解从哪些维度上来分析这些指标，下面介绍一下分析这些指标的维度。
首先，第一个维度是省份，即地域，也就是空间的维度，因为推流和拉流CDN服务商的资源分布是按大省或者大区来部署的，所以选择省份作为关键的地域上的维度来观测QoS至标。
运营商ISP，CDN，终端类型，网络类型，客户端版本都是在分析问题时常见的维度。
有一个特殊的维度是直播房间，单个房间的观看卡顿率，主播有没有推流卡顿也是经常需要用到的QoS信息。
剩下的还有很多细分的维度都是业务相关的，这里就不一一列举了。这么多的维度之后，如果不进行聚合，用于数据分析和监控很不方便。必须通过OLAP维度聚合模块，将维度进行一定程度上的聚合。
目前智能监控主要是看省份，ISP和CDN三个维度聚合的结果，用这个来做线上的报警，参考历史同期的数据，做同比和环比的监测。此外，这些维度聚合之后进入到数据可视化模块，数据可以很方便的做多样的可视化和多维度的分析，这里主要是离线的业务分析。
四， 直播QoE-QoS指标联合分析
刚才介绍直播的QoE和QoS指标的数据采集，计算方法和观测的维度。接下来举例介绍，QoE和QoS指标到底是有什么关联？
这个截图是快手真实的业务数据的截图，横轴是卡顿率，纵轴是播放时长，可以明显的看到这个曲线的趋势是随着卡顿率的上涨，播放时长快速的下降。实际情况中，只要数据规模足够大，不管从任何维度观测，这两个指标的关系，基本上都符合这样的规律。这个规律也很容易理解，当直播观看变得很卡的时候，用户继续观看的动力下降，很多人会选择退出直播间。
接下来，看一个具体例子，这是一个单房间的卡顿监控数据：
上图的第一条曲线，这个是某直播房间的用户评论中出现卡顿的数量，刚才在介绍QoE指标的时候也专门提到过这个指标，是用户主观感受的直接反馈。在17点58分的时间点上，这个指标突然的上涨，应该是在这个时候用户大量的感觉到卡顿了，这个时候需要立刻去查和它相关的QoS指标：单个房间的拉流卡顿率。
首先要判断是不是由于QoS指标出现了问题导致的QoE指标波动。比如说主播在直播打王者荣耀，但他的手机连接王者荣耀的服务器卡了会使整个游戏画面变得比较卡，从而导致直播看上去比较卡，这个时候用户的QoE指标会发生变化，但直播的QoS指标都是正常的，所以在发生QoE指标变化的时候，一般是先看和它直接相关的QoS指标是不是真的有问题。这个例子，在同样时间点，这个房间的拉流卡顿率也大幅度的上涨，可以判断是服务质量出了问题。
进一步分析，由于有大量用户拉流卡顿，我们推测，很有可能是跟主播推流卡顿有关，那么我们看下第三张图，主播端推流监控数据，这两条曲线分别是推流的帧率和码率，在同样的时间点，可以看到是主播推流码率大幅度下降了，此时，观众端卡顿率上升且QoE指标评论卡顿数也大幅度的上升。这个时候，就已经定位问题应该是主播的网络发生了一些抖动，推流码率大幅度的下降，观众端感受到的卡顿大幅度上升。
这是一个QoE指标和QoS指标关联的例子，也展示了平时跟进具体问题的方法：重点监控QoE和核心的QoS指标，在QoE的指标发生问题的时候，立刻快速的找到和它直接相关的QoS的指标，判断是不是服务质量真的出现问题。
但是这个例子还有一个很有意思的地方，这个直播同样的时间点，观察另外一个QoE指标：观看人数
图中的第一条曲线，是观看人数曲线，对比下面的两条曲线，和上图一样，是两个QoS指标。可以看到，在主播推流发生卡顿的时刻，观看人数这个QoE直播只是略有下降，并没有像评论卡顿数指标那样出现大幅的变化。
这个现象说明，用户虽然纷纷抱怨直播卡，但是他们并没有离开直播房间，还是继续停留在直播房间里面。这个情况完全违背了之前介绍的，卡顿率影响观看时长的规律。卡顿率高了，但是大部分观众还是愿意继续观看。
QoE与QoS指标之间的关系，在大规模数据集下，规律是非常稳定的，但是在分析具体问题的时候，情况往往会发生变化，因为实际会影响QoE指标的因素太多，QoS指标只是其中一个因素，在QoS指标在短时间下降，没有差到无法忍受的情况下，直播间的内容和氛围，粉丝群体区别，主播个人号召力，都会更显著影响QoE。
五， 短视频业务
接下来简单介绍一下快手的短视频业务，也为十月份的LVS大会做一个预告。这里主要是简单讲下短视频业务和直播到底有什么不一样？主要从内容生产，传输，观看来对比：
首先，短视频会涉及到比较复杂的内容生产流程，导入、拍摄、剪辑，可以叠加魔法表情、特效滤镜，比直播要复杂很多。其次是在分发过程中，短视频可以做更灵活的策略，如多CDN调度，预加载，CDN预热之类的策略，监控起来也会有很多不一样的QoS、QoE指标，如慢速比、播放完成率等。
在观看端，短视频的特点是观看时长、下载时长很短，高频，快手一个短视频默认只有7秒，下载时长可能只有1-2秒，而且是一下到底的体验。用户对于偶尔出现的卡顿，会更加敏感。
正因为短视频的业务，比直播要更复杂一些，因此我们在制订QoE和QoS指标时候，遇到了很多困难。第一，短视频的功能繁多，流程复杂；第二，涉及模块多，包括上传模块，转码模块，CDN的各种复杂策略，全链路的监控难度比较大；第三，要平衡清晰度和流畅度，成本之间的矛盾关系，因此QoE和QoS的指标制定起来，挑战更大。
在十月份LVS大会正式的演讲中，我将会给大家详细分享，快手团队是如何解决这些困难，制定出符合短视频业务需求的QoE和QoS指标，并利用这些指标指导体验优化的。希望感兴趣的同学能够积极报名参会。
六， Q&A
Q1: 码率自适应做在编码之后，如何实现自适应过程？
A: 我们实现码率自适应，主要是通过预测可用发送带宽，并且在带宽发生变化时，反向反馈给编码器，使之及时调整输出码率，从而实现码率自适应。
Q2: 发送端到接收端的延时是如何统计的？
A: 这个是我们的一个技术特性，可以大概提一下是将一些特殊信息写在视频流里面，通过这些特殊信息，在播放端就可以判断，它和主播之间的延迟是多少。
Q3: 主播端和拉流端的Buffer长度是怎样确定的？
A: 其实主播端没有一个buffer的强行限制，直播端会在buffer到一定长度进行丢帧，在拉流端，我们将Buffer长度限制在5秒，为了控制延时的大小。
Q4: 卡顿时长的过滤是在服务器端，还是在客户端？
A: 这些值的过滤都是在服务器端做。
Q5: 那么主播推流端的GoP大小恒定的，还是个动态变化的？
A: 动态变化，根据场景设置，但不会超过一个限定值。
