移动视频直播经过 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，Quality of Experience），我们把它定义为一种和用户主观体会相关的数据，如同时直播卧室数、直播同时在线人数、直播跳出率等，这些数据的波动有可能是技术问题引起的，也有可能是因为直播内容不符合听众预期，可以综合反映出用户对直播体验的主观体会。并且，这几项用户体验指标反映的是整体的趋势，如果真的出现技术性的问题，靠这种指标是难以追踪问题的源头的。举例来说，如果我们发觉直播同时在线观看的人数降了，但这只能说明有问题，具体问题在那里，什么缘由造成的须要通过第二类指标：服务质量（QoS， Quality of Service）数据来进一步剖析。服务质量数据是纯客观的，反映的是技术性的指标，比如这张示意图，是一个以时间维度的各 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（Group of Pictures）的开始下发 3. 在不违反上面两点的情况下，下发尽可能多的数据。上图是两个按照服务端缓存的不同 GOP 结构，决定下发数据策略的实际 case，假设快手拉流端接收缓冲区宽度是 5 秒：
制定了统一的播出数据下发策略以后，在多家 CDN 分别上线灰度，对比观察各家 CDN 覆盖节点和未覆盖节点的数据，然后逐渐扩大灰度范围直到全量上线。对比优化前的日均值，开播前 10s 跳帧时长从 1500ms 降低至 200ms。
经过上一轮的 CDN 端优化过后，观察全网的播出跳帧数据，各家 CDN 的指标保持在相同的水平（开播 10 秒平均跳帧 200ms 左右），基本可以判定 CDN 端的优化早已到了困局，客户端能够进一步优化解决掉最后的 200ms 呢？这里快手使用了平缓快进的方案：将多余的 200ms 在用户无感知的情况下，进行加速播放，控制缓冲区的大小。只要将加速程度控制在一定范围内，用户基本是没有察觉的，而正常播放时长为 200ms 的数据，经过加速，能很快的播放完，之后就恢复成正常速率播放，这样就保证了不会再有跳帧的现象，最后的 AB TEST 数据显示播出跳帧时长完全为 0，而卡顿情况也有比较显著的减少。
在解决了播出跳帧的问题以后，我们来回顾一下播出跳帧优化的整个过程：
在这整个过程中可以显著见到对快手整个数据平台的测试监控和统计的依赖，无论是评价 CDN 的质量，还是 CDN 优化后的对比测试，客户端的 AB TEST 效果验证，都须要观察对比全网的数据，才能确认优化疗效，证明确实完美解决了跳帧问题。
