联通视频直播经过2016年的井喷期，早已步入下半场，你们的关注点早已从怎样建立健全的直播平台的粗放下降阶段，转到精细化营运阶段。怎样在巨大的流量、复杂的应用场景、复杂的网路条件下，持续优化用户体验，是业界非常关注的话题。快手拥有5亿注册用户，单个直播间人数峰值早已超过180万，她们针对海量用户，基于大数据技术，在首屏和流畅度优化上做了大量的探求与实践。快手直播是怎样设计全链路质量监控方案、如何搭建大数据处理Pipeline、如何解决播出跳帧、首屏卡顿优化等问题的？本文干货满满，全面揭秘快手直播大数据技术构架与优化实践。
注：文章整理了快手软件工程师罗喆在ArchSummit上海2017上的讲演，原题为《快手在大数据驱动下的直播体验优化》，感兴趣的读者可移步观看罗喆老师现场讲演视频。
1写在上面
你们早晨好，我是罗喆，来自快手，过去的一年多我在快手做直播的体验优化相关的工作。明天给你们分享的主题是快手怎样在大数据的驱动出来优化直播的质量。
加入公司这一年多，公司的注册用户和日活每天都刷新峰值，到如今，快手的注册用户早已超过5亿，短视频数目早已超过了int32所能储存的数字的上限，也就是21个亿，日活跃用户数也早已达到6500万，并且还处于高速下降的趋势之中。
快手的直播业务2016年初上线，我们的直播业务和别的直播平台很不一样，那就是快手的直播是面向普通人的直播，而不是只有网红大V；快手的直播内容，也大多是常见的生活场景，十分多元化，这样的模式也决定了快手直播须要考虑的业务场景更复杂。
目前，快手的直播业务量迅速下降，单个直播间的观看人数峰值，最高时超过了百万人。（8月7日，在用户“MC天佑”的直播中，快手单个直播间同时在线人数最高超过了180万。）这么，我们是怎样在庞大的用户基数下保证直播的流畅度呢？我将从四个方面进行解析。
2快手直播面临的挑战与解决方案
快手直播的特性和挑战
快手直播有四个明显的特征，这种特性给快手带来了机遇，也让我们面临着巨大的挑战：
数据驱动的优化方式论
针对线上错综复杂的直播体验问题，快手视频团队在实践过程中总结出了一套数据驱动的优化方式论，归纳一下有三点：
首先是分辨痛点，设置优先级。把问题分为两类：可以忍受和不能忍受，不能忍受的例如播放失败、绿屏和闪屏等，这些影响功能可用性的问题定位高优先级，快速处理；可以忍受的包括卡顿、清晰度、延时等能看但用户体验不好的设置普通优先级，持续优化。
其次是制订优化方案，问题出现后，订制一个合理的优化方案，这儿可能涉及到多方，有快手须要解决的问题，也有CDN服务商须要解决的问题，须要合理的排期保证问题有序解决。
第三步是灰度验证或AB测试，解决问题然后通过观测全网的数据进行灰度验证，确保方案是真正有效了以后，才全量上线。
快手直播全链路质量监控
这套方式论的基础是数据，这么，快手直播究竟用到什么数据，如何判定用户的播放体验是否OK呢？下边先介绍一下快手的直播系统端到端的处理流程：视音频讯号实时采集，经过预处理和音视频编码，封装发送到CDN源站，播放端从CDN边沿拉到数据，之后进行解码，经过音视频同步以后，给听众诠释下来。
我们在推流端和播放端分别做了特别建立的质量检测体系。在推流端，数据的源头是摄像头采集到的画面和耳机采集到的声音，不同的型号和系统，摄像头和耳机的能力完全不同，所以我们首先对摄像头的帧率、帧率、机型等关键信息进行搜集；接出来是视频前处理的过程，例如去噪、美颜、特效等，这种都是十分耗CPU和显存资源的操作，所以这个环节对CPU和显存的占用做了详尽的上报；前处理过后会进行视频编码，视频编码的质量影响整个视频的观看体验，对视频编码器，主要是上报了视频编码的客观质量和编码器的输出码率；音频数据的采集编码过程和视频类似；编码完成以后的数据会进行合同封装，之后步入分辨率自适应模块，分辨率自适应模块的功能主要是调整输出信噪比以适应用户的网路带宽，在用户网路变差的时侯，自适应模块会主动扔掉一些数据以减少对网路的压力，推流端的卡顿也主要是发生在这儿，所以在这儿对自适应模块的输出信噪比，丢帧数目，卡顿次数都做了详细的统计；数据最后到达到CDN服务商的源站，CDN服务商分配的源站节点是否合理，是否和用户在同一地域，同一营运商，都直接影响到用户的联接质量，所以源站节点的地理位置和营运商信息，也是对质量评价十分重要的信息。
我们再来看看拉流（播放）端，拉流端整体的流程和推流端是一个反过来的流程，顾客端先经过DNS解析，联接到CDN的边沿节点，和推流端类似，须要对DNS解析时间，边沿节点的营运商、地理位置、RTT值等关键信息进行采集；从CDN边沿节点领到的http-flv数据会先经过解封装送到接收缓冲区，在这个阶段可以对CDN服务节点的首包时间，发送至接收的端到端延时进行统计；接收缓冲区的宽度决定了拉流端的网路抗性，这儿可以采集到卡顿的次数和时长，缓冲区本身的宽度也是须要监控的点；数据从缓冲区的输出，会分别进行音频和视频的解码，经过音视频同步，步入播放环节。这儿从拉流启动到播放出第一帧画面的时间就是首帧时间。
这种复杂的过程在用户点击一个直播以后，绝大部份情况下在几百纳秒以内才会完成，我们也进一步分解了首帧各个环节的时间，才能对它进行深入的剖析和优化。
3直播质量数据处理Pipeline
在提取了详尽的质量数据然后，接出来就是前端处理的事情了，我将从直播质量数据处理Pipeline、用户体验质量数据&服务质量数据、数据可视化检测流程三个角度为你们全面解析快手是怎样发觉直播当中的问题，以及是怎样解决的。
直播质量数据处理流程
右图是快手现今所使用的直播数据处理Pipeline，可以很清晰的看见整个流程为数据采集→数据缓存→数据分类处理→数据索引/展示。
我们具体瞧瞧这个流程的工作细节，数据从快手APP搜集，之后经过上报服务器的简单处理过后，会存到Kafka的Topic上面，Kafka是十分可靠的数据队列服务，只要Kafka的机群够多，虽然部份机器宕了数据都不会丢的；接出来，Kafka的数据会分出两条处理路径：
快手每晚经过这个系统处理的直播相关的数据，在百亿条的量级，直播相关的所有的数据展示和监控都依赖于这整个Pipeline，要在分钟级要求下，支持各类业务查询需求，保证系统的平稳运行，是很不容易的。
用户体验质量&服务质量
采集到了数据而且对数据进行清洗入库以后，如何去剖析数据呢？首先，我们把数据可视化的检测分为两类，一类是用户体验质量（QoE，QualityofExperience），我们把它定义为一种和用户主观体会相关的数据，就像时直播卧室数、直播同时在线人数、直播跳出率等，这种数据的波动有可能是技术问题引起的，也有可能是由于直播内容不符合听众预期，可以综合反映出用户对直播体验的主观体会。而且，这几项用户体验指标反映的是整体的趋势，假如真的出现技术性的问题，靠这种指标是难以追踪问题的源头的。举例来说，假如我们发觉直播同时在线观看的人数降了，但这只能说明有问题，具体问题在那里，哪些诱因引起的须要通过第二类指标：服务质量（QoS，QualityofService）数据来进一步剖析。服务质量数据是纯客观的，反映的是技术性的指标，例如这张示意图，是一个以时间维度的各CDN服务商的卡顿率曲线；QoE指标的波动未必一定是QoS的数据波动造成的，QoS的数据波动也不是一定会造成QoE数据的变化，例如卡顿率可能会上升，并且在可接受的范围内，同时在线人数不一定会有大的变化。
数据可视化检测流程
我们以右图的“进入卧室人数”和“退出屋子人数”分析，说明一下我们是怎样做联合QoE数据和QoS数据进行检测和剖析的。首先瞧瞧QoE数据，左上角是快手某次直播卧室的同时在线人数曲线，在直播过程中在线人数有一个“掉坑”的现象，右下角的“退出屋子人数”曲线显示在九点三十多分有一个峰值，说明有大量用户退出屋子，我们猜测这儿可能发生了个别问题引起了观看人数的大量降低，有可能是非技术性的，例如主播做了一件事情听众们不太喜欢，会引起听众大量流失。奇怪的是，右上角的“进入卧室人数”曲线显示，步入屋子在同样时刻也有一个峰值，这个时侯说明其实有大量用户退出了屋子，而且同时也大量的步入了该屋子。这儿我们可以通过QoE数据得出一些推论，这一次听众大量退出，应当不是因为直播内容引起的，而是快手的直播服务有问题引起的，由于听众大量退出同时也大量步入，是由于听众认为重新打开直播可能可以解决问题，退出直播并不是由于她们不再想看这个直播了。
为了否认这个判定，我们观测QoS数据曲线。图上两条曲线是所有CDN节点步入屋子人数曲线和退出屋子曲线，可以看见在用户大量退出的时侯，基本上各个CDN节点就会有大量的退出和步入，而不是只有少数节点才有这个行为，这样就可以进一步判定应当不是某些拉流节点的问题的问题，极有可能是主播推流发生了问题。以后我们联合CDN把主播的录象和推流曲线领到以后，基本上可以推断主播当时的网路发生了晃动，造成短暂的卡顿，然后又立即恢复，短暂的卡顿引起听众大量退出直播间。
从这个事例我们可以看出QoE的指标是一个综合评判指标，它很直观，尽管并不能直接对应到QoS服务质量指标，但我们可以通过它来全局监控，判定是技术还是内容诱因出现了体验问题，假若是技术缘由，我们再去详尽的查看QoS指标的时侯就可以查出问题的症结。
4直播系统优化案例
接出来，我将通过播出跳帧优化和httpDNS首屏优化两个反例，以实例说明怎样借助大数据做直播系统调优。
拉流端播出的过程
拉流端播出的过程，如上面所述，主要是联接CDN节点拉取数据，数据的解码、渲染这几个步骤。CDN的边沿节点通常还会缓存一部份数据，以便拉流端在任何时刻开始拉流都能拉到数据。为了让用户尽可能的播放流畅，CDN会尽量的向用户多发一些数据，有时侯甚至超过播放端拉流的缓冲区，超过的这部份数据会导致的明显问题是，假如照单全收而且依照正常的速率播，会造成直播延时减小，互动疗效变差。业界公认的互动直播延时标准是大于5秒钟，超过5秒评论礼物互动疗效都会变差。为此我们须要在保证延后的前提下，尽量减短首屏，提升流畅度。
如上图，拉流端接收缓冲区宽度通常等同于延时，我们把它的厚度设置为5s，假如CDN下发的数据小于了接收缓冲区的宽度，假定超过的部份是4秒，这么假如不做任何处理，正常播放的延时是5秒加4秒等于9秒，9秒的延时在直播过程中基本上没办法做评论或则交互，体验很差。于是我们一开始尝试从顾客端来单独解决这超出的部份数据引起的问题。
我们尝试了两种的解决办法：直接快进和跳帧，直接快进的方案就是将超过的部份数据快速的播放过去，视频和声音都被加速播放了，这个方案上线以后很快就收到了用户的投诉，怀疑快手的直播是假直播，真正的直播如何会出现“快进”的现象；之后我们更改了方案，将超出的部份数据直接跳过不进行播放，而且这又带来了新的问题，直接跳帧会造成用户的声音和画面出现突变，主播可能从画面的右侧忽然出现在画面的左侧，体验也不是挺好。其实，只在顾客端做优化难以做到体验的最优。
首播跳帧优化
因为造成这个问题的真正缘由是CDN下发数据过多造成的，为了做到最优的体验，必须和CDN联合优化。这时，快手的多CDN策略带来一个新的问题：各家CDN播出下发数据的策略完全不同，在播出时下发的数据宽度都不一样，很难定量的评价哪一家CDN做的更好一些。
于是制订统一的评价标准成为第一个要解决问题，这儿快手使用“开播前10秒跳帧时长”作为评判CDN下发数据宽度的标准，具体是指拉流端播放的前10秒内遗弃数据的总时长。
在制订统一的评价标准以后，通过线上数据观察各家CDN的跳帧指标，尝试让各CDN优化自己的指标，尽量接近最优的那一家。并且因为各CDN的播出策略都大不相同，可配置参数也完全不一样，不同的CDN之间很难做到数据完全一致。并且即便是指标最优的CDN也难以将上映前10s调整时四胡整到让快手满意的程度。于是，统一各家CDN播出数据下发策略成为第二个要解决的重要问题。
我们设计了一套统一的播出数据下发策略，让各家CDN都根据这个方案来实现。该方案总的来说秉持三个原则：1.下发数据宽度不能超过快手拉流端接受缓冲区宽度2.必须从一个GOP（GroupofPictures）的开始下发3.在不违反上面两点的情况下，下发尽可能多的数据。上图是两个依据服务端缓存的不同GOP结构，决定下发数据策略的实际case，假定快手拉流端接收缓冲区宽度是5秒：
制订了统一的播出数据下发策略以后，在多家CDN分别上线灰度，对比观察各家CDN覆盖节点和未覆盖节点的数据，之后逐渐扩大灰度范围直到全量上线。对比优化前的日均值，播出前10s跳帧时长从1500ms增加至200ms。
经过上一轮的CDN端优化过后，观察全网的播出跳帧数据，各家CDN的指标保持在相同的水平（播出10秒平均跳帧200ms左右），基本可以判定CDN端的优化早已到了困局，顾客端能够进一步优化解决掉最后的200ms呢？这儿快手使用了平缓快进的方案：将多余的200ms在用户无感知的情况下，进行加速播放，控制缓冲区的大小。只要将加速程度控制在一定范围内，用户基本是没有察觉的，而正常播放时长为200ms的数据，经过加速，能很快的播放完，然后就恢复成正常速率播放，这样就保证了不会再有跳帧的现象，最后的ABTEST数据显示播出跳帧时长完全为0，而卡顿情况也有比较显著的减少。
在解决了播出跳帧的问题以后，我们来回顾一下播出跳帧优化的整个过程：
在这整个过程中可以显著见到对快手整个数据平台的测试监控和统计的依赖，无论是评价CDN的质量，还是CDN优化后的对比测试，顾客端的ABTEST疗效验证，都须要观察对比全网的数据，才会确认优化疗效，证明确实完美解决了跳帧问题。
