短视频热门教程经过2016年的井喷期，移动视频直播已经进入下半场。 大家的关注点已经从如何搭建完整的直播平台的粗放式成长阶段转向了精细化运营阶段。 如何在巨大流量、复杂应用场景、复杂网络条件下持续优化用户体验，是业界非常关注的话题。 快手拥有5亿注册用户，单个直播间峰值人数已超过180万。 他们在针对海量用户基于大数据技术的首屏和流畅度优化方面做了大量的探索和实践。 快手直播如何设计全链路质量监控方案，如何构建大数据处理管道，如何解决直播跳帧、首屏卡顿优化等问题？ 本文内容充实，全面解读快手直播大数据技术架构和优化实践。
注：本文整理快手软件工程师罗喆在ArchSummit深圳2017上的演讲，原文标题为《大数据驱动的快手直播体验优化》。 有兴趣的读者可以观看罗喆先生的现场演讲视频。
1写在前面
大家下午好，我叫罗哲，来自快手。 最近一年多，我一直在快手直播体验优化工作。 今天我想跟大家分享的话题是快手如何在大数据驱动下优化直播质量。
加入公司一年多来，公司的注册用户和日活跃度每天都再创新高。 截至目前，快手的注册用户已突破5亿，短视频数量也超过了int32可存储的数量上限，即21亿。 日活跃用户数已达6500万，且仍在快速增长。
快手的直播业务是在2016年初推出的，我们的直播业务和其他直播平台有很大的不同。 也就是说，快手的直播是直播普通人的，而不仅仅是网红。 快手的大部分直播内容也很常见。 生活场景非常多样。 这种模式也决定了快手直播需要考虑的业务场景更加复杂。
目前，快手直播业务量正在快速增长，单直播间峰值观看人数最高时超过百万。 （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。 可以清楚地看到整个流程是数据采集→数据缓存→数据分类处理→数据索引/展示。
让我们详细看看这个过程的工作细节。 从快手APP采集数据，经过报表服务器简单处理后，存储在Kafka的Topic中。 Kafka是一个非常可靠的数据队列服务。 只要Kafka有足够多的集群，即使某些机器宕机了，数据也不会丢失； 接下来，Kafka的数据会分为两个处理路径：
快手每天通过该系统处理的直播相关数据量在百亿量级。 所有与直播相关的数据展示和监控都依赖于这整条Pipeline，它必须支持分钟级别的各种业务查询需求。 确保系统平稳运行并不容易。
用户体验质量和服务质量
收集数据并清洗并存储到数据库后，如何分析数据？ 首先，我们将数据可视化的监控分为两类。 一个是用户体验质量（QoE，Quality of Experience），我们将其定义为一种与用户主观感受相关的数据，比如同时直播间数、直播在线人数波动等、直播跳出率等可能是技术问题造成的，也可能是因为直播内容没有达到观众预期，能够综合反映用户对直播体验的主观感受。 而且这些用户体验指标反映了整体趋势。 如果确实出现了技术问题，仅仅依靠这些指标是无法追溯问题根源的。 比如，如果我们发现同时在线观看直播的人数下降了，这只能说明出现了问题。 具体问题出在哪里以及是什么原因造成的？ 我们需要传递第二类指标：服务质量（QoS，Quality of Service）数据。 以供进一步分析。 服务质量数据纯粹客观，反映技术指标。 例如，该图是各个CDN服务商的时间维度的滞后率曲线； QoE指标的波动并不一定是由QoS数据的波动引起的。 QoS数据的波动并不一定会导致QoE数据的变化。 例如，滞后率可能会增加，但在可接受的范围内，同时在线的人数不一定会发生明显变化。
数据可视化监控流程
我们通过分析下图中的“进入房间的人数”和“离开房间的人数”来说明我们如何结合QoE数据和QoS数据进行监控和分析。 首先看QoE数据。 左上角是快手直播间同时在线人数曲线。 直播期间，在线人数出现“下滑”现象。 右下角显示“退出房间人数”曲线，时间为9点30分。 多分出现峰值，说明有大量用户退出房间。 我们推测这里可能出现了一些问题，导致观看人数大幅减少。 这可能是非技术性的。 例如，主持人做了一些观众不喜欢的事情。 导致观众大量流失。 奇怪的是，右上角的“进入房间人数”曲线显示，同一时刻进入房间的人数也出现了峰值。 这次显示虽然有大量用户退出房间，但同时也有大量用户进入房间。 这里我们可以从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也无法将播前10秒调整到快手满意的程度。 因此，统一各CDN的上线数据分发策略成为第二个需要解决的重要问题。
我们设计了统一的上线数据分发策略，让所有的CDN都按照这个计划来执行。 一般来说，该方案遵循三个原则： 1. 发送的数据长度不能超过快手流媒体端接收缓冲区的长度 2. 必须从 GOP（Group of Pictures）开头发送 3. 不可以违反前两点的话，发送尽可能多的数据。 上图展示了根据服务器缓存的不同GOP结构来确定数据传递策略的两个实际案例。 假设快手流媒体端接收缓冲区长度为5秒：
制定统一的启动数据分布策略后，分别在多个CDN上启动灰度，对各个CDN覆盖节点和非覆盖节点的数据进行对比观察，然后逐步扩大灰度范围，直至满刻度已启动，推出。 与优化前的日平均值相比，播出前10秒的跳帧时长从1500ms减少到200ms。
经过上一轮CDN端优化后，观察全网的广播跳帧数据，各CDN的各项指标均保持在同一水平（广播开始后10秒内平均跳帧约为200ms）。 基本可以判断CDN端优化已经到了瓶颈。 客户端能否进一步优化解决最后200ms？ 这里快手采用了慢进快进的方案：多出的200ms在用户无意识的情况下加速播放，并控制缓冲区的大小。 只要将加速度控制在一定范围内，用户基本不会注意到。 正常播放时间为200ms的数据，经过加速后可以快速播放快手怎么买直播间人数，然后恢复正常速度。 这样就保证了不会出现跳帧的现象。 最终的AB TEST数据显示，播出时的跳帧时间完全为0，卡顿情况也得到了明显减少。
解决完播出跳帧问题后，我们再来回顾一下播出跳帧优化的整个流程：
在这整个过程中，我们可以清楚地看到对快手整个数据平台的测试监控和统计的依赖。 无论是评估CDN的质量，还是CDN优化后进行对比测试，或者验证客户端的AB TEST效果，都需要对整个网络进行观察和比较。 只有用数据才能确认优化效果，证明跳帧问题确实得到完美解决。
发表评论