游戏直播,电竞直播,手游直播,lol直播,英雄联盟直播,dnf直播,cf直播,绝地求生直播,王者荣耀直播,游戏直播,赛事直播,美女直播,户外直播,二次元直播,斗鱼直播,英雄联盟,绝地求生,和平精英移动视频直播经过2016年的井喷期，已经进入下半场，大家的关注点已经从如何构建完善的直播平台的粗放增长阶段，转入精细化运营阶段。如何在巨大的流量、复杂的应用场景、复杂的网络条件下，持续优化用户体验，是业界十分关注的线亿注册用户，单个直播间人数峰值已经超过180万，他们针对海量用户，基于大数据技术，在首屏和流畅度优化上做了大量的探索与实践。快手直播是如何设计全链路质量监控方案、如何搭建大数据处理Pipeline 、如何解决开播跳帧、首屏卡顿优化等问题的？本文干货满满，全面解密快手直播大数据技术架构与优化实践。

　　《视频直播技术干货(一)：揭秘百万级粉丝互动的Facebook实时视频直播》《视频直播技术干货(二)：P2P技术如何将实时视频直播带宽降低75%？》《视频直播技术干货(三)：实时直播答题系统的实现思路与技术难点分享》《视频直播技术干货(四)：首次披露快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》（* 本文）《视频直播技术干货(五)：七牛云使用QUIC协议实现实时视频直播0卡顿》《视频直播技术干货(六)：新浪微博实时直播答题的百万高并发架构实践》《视频直播技术干货(七)：实时视频直播首屏耗时400ms内的优化实践》《视频直播技术干货(八)：淘宝高清、低延时的实时视频直播技术解密》《视频直播技术干货(九)：千万级直播系统后端架构设计的方方面面》《视频直播技术干货(十)：一文读懂主流视频直播系统的推拉流架构、传输协议等》《视频直播技术干货(十一)：超低延时视频直播技术的演进之路》《视频直播技术干货(十二)：从入门到放弃，快速学习Android端直播技术》《视频直播技术干货(十三)：B站实时视频直播技术实践和音视频知识入门》

　　一是随着直播业务的不断发展，用户对直播的体验要求越来越高，需要做精细的人群优化；二是快手主要是面向普通人的直播，场景丰富真实，也带来一些问题，比如用户的网络情况非常复杂；三是用户基数大，直播的流量巨大，为了业务的稳定性，必须采用多家供应商CDN，也带来了管理和业务上的复杂性；四是不同场景的直播要求不一，我们需要在不同的场景下面对清晰or流畅、首屏秒开or低延时这样的矛盾选择。这样的业务特性下就会带来体验问题多样化、不同CDN之间的需求协调周期长，以及网络环境复杂多变的问题。

　　在推流端，数据的源头是摄像头采集到的画面和麦克风采集到的声音，不同的机型和系统，摄像头和麦克风的能力完全不同，所以我们首先对摄像头的分辨率、帧率、机型等关键信息进行收集；接下来是视频前处理的过程，比如去噪、美颜、特效等，这些都是非常耗CPU和内存资源的操作，所以这个环节对CPU和内存的占用做了详细的上报；前处理之后会进行视频编码，视频编码的质量影响整个视频的观看体验，对视频编码器，主要是上报了视频编码的客观质量和编码器的输出帧率；音频数据的采集编码过程和视频类似；编码完成之后的数据会进行协议封装，然后进入码率自适应模块，码率自适应模块的功能主要是调整输出码率以适应用户的网络带宽，在用户网络变差的时候，自适应模块会主动丢弃一些数据以降低对网络的压力，推流端的卡顿也主要是发生在这里，所以在这里对自适应模块的输出码率，丢帧数量，卡顿次数都做了详尽的统计；数据最后到达到CDN服务商的源站，CDN服务商分配的源站节点是否合理，是否和用户在同一地域，同一运营商，都直接影响到用户的连接质量，所以源站节点的地理位置和运营商信息，也是对质量评价非常重要的信息。

　　客户端先经过DNS解析，连接到CDN的边缘节点，和推流端类似，需要对DNS解析时间，边缘节点的运营商、地理位置、RTT值等关键信息进行采集；从CDN边缘节点拿到的http-flv数据会先经过解封装送到接收缓冲区，在这个阶段可以对CDN服务节点的首包时间，发送至接收的端到端延时进行统计；接收缓冲区的长度决定了拉流端的网络抗性，这里可以采集到卡顿的次数和时长，缓冲区本身的长度也是需要监控的点；数据从缓冲区输出，会分别进行音频和视频的解码，经过音视频同步，进入播放环节。这里从拉流启动到播放出第一帧画面的时间就是首帧时间。

　　第一条是实时路径，数据先经过Flink的清洗，写入Elastic Search集群，使用Kibana做数据可视化。这条路径主要是服务于实时数据分析、报表展示和监控报警，延迟控制在分钟级别，数据只保存数周；另外一条是传统的批处理路径，数据先经过Hadoop集群的定期处理，注入放到Hive数据库。这是一个典型的非实时数据处理系统，延迟是小时级别的，还没有办法做到分钟级，或者秒级的实时，这条路径主要是用来处理当天的、或者当月的海量数据，最后输出一些非实时的报表。比如说一天的卡顿情况、一个月、几个月的卡顿曲线这样的数据，数据是全量保存数年的。

　　一类是用户体验质量（QoE，Quality of Experience），我们把它定义为一种和用户主观感受相关的数据，如同时直播房间数、直播同时在线人数、直播跳出率等，这些数据的波动有可能是技术问题导致的，也有可能是因为直播内容不符合观众预期，可以综合反映出用户对直播体验的主观感受。并且，这几项用户体验指标反映的是整体的趋势，如果真的出现技术性的问题，靠这些指标是无法追踪问题的源头的。举例来说，如果我们发现直播同时在线观看的人数降了，但这只能说明有问题，具体问题在哪里，什么原因导致的则需要通过第二类指标；第二类指标：服务质量（QoS， Quality of Service）数据来进一步分析。服务质量数据是纯客观的，反映的是技术性的指标，比如下面这张示意图，是一个以时间维度的各CDN服务商的卡顿率曲线；QoE指标的波动未必一定是QoS的数据波动导致的，QoS的数据波动也不是一定会导致QoE数据的变化，比如卡顿率可能会上升，但是在可接受的范围内，同时在线人数不一定会有大的变化。

　　统一评价标准。我们使用了多家厂商的CDN服务，为了能公平的衡量各家的开播下发数据的长度，也为了能观察后续的优化效果，快手设计了一个统一的可以定量统计的指标：开播前10s跳帧时长；统一CDN端策略。在统一评价标准之后，快手的方案是统一各家CDN的数据下发策略，这个策略由快手来统一设计，让各家CDN实现，随后做灰度测试和对比，通过数据来分析CDN实现效果。通过这一步，将1500ms的延时优化到200ms；客户端进一步优化。经过上一步的优化之后，开播跳帧长度并没有完全消除，而CDN端的优化手段有限，这时再尝试客户端优化掉最后的200ms。我们选择在客户端实施缓慢快进方案，让用户察觉不到播放速度的变化，但是快速的把这200ms消耗掉，通过AB TEST观察数据，然后全量上线。

　　1.localDNS的优势在于运营商的DNS Server数量较少，对CDN GSLB来说，定位运营商的DNS Server的信息比较容易，虽然粒度比较粗，但大致区域运营商判断还是准确的。2.传统的localDNS解析方式依赖于系统的DNS解析机制，系统一般都有内部缓存导致解析时间不可控，httpDNS方案直接绕开系统DNS解析机制，可以在用户观看直播前就提前解析好节点ip，在真正开播的时候能完全省掉DNS解析时间。当然，localDNS也可以通过自己调用底层解析接口的方式实现域名预解析。3. httpDNS的方案是由APP直接调用CDN的API，请求没有经过运营商中转，可以绕过DNS劫持设备，因此能够有效的防止运营商劫持域名。4. APP直接调用CDN的httpDNS API还有一个好处是CDN能直接获取到APP的出口ip，节点的分配可以做到更加准确合理。问题是在多出口小运营商的情况下，去CDN httpDNS服务器的出口很可能是从电信联通租用的线路，容易误判，而localDNS由于是运营商地区粒度的，反而更容易判断出用户所属运营商。

　　1. 应用启动，TTL到期，网络切换，前后台切换的时机，通过localDNS和httpDNS分别获取到ip列表；2. 对ip分别进行测速，选择测速结果最好的ip作为拉流节点；3. 在用户真正开始拉流时，直接连接之前已经准备好的节点ip，完全省掉DNS解析时间。我们很快上线这个方案进行了AB TEST，但是结果却并不如预期，使用了新的DNS策略的用户，卡顿上升，观看时长下降，似乎节点优选并没有起到有应有的作用。通过进一步观察数据，发现使用新DNS策略的用户，集中从少数测速结果最优的节点拉流，导致这些节点负载过高，拉流质量反而下降。于是我们对IP优选方案进行了进一步优化，测速后并不是直接选用结果最优的那一个，而是在测试结果可以接受的一定范围内进行随机挑选，这样就避免了大量用户都聚集到少数节点，导致的节点负载不均衡。