基于大数据平台-实时质量监控平台的架构设计
6 个月前
本文是声网首席数据架构师何丰，在ArchSummit全球架构师峰会深圳站，分享的内容《质量实时监控：全球音视频实时传输的关键帧》。
在全球实时音视频传输过程中，为了提供QoE质量保障，需要构建一个稳定可靠的实时数据监测系统，从而能够监测每一次通话。声网是全球首个使用大数据平台做监控和实时保障的通信技术服务商。声网的实时数据监控系统，覆盖了实时通话的全链路，包括端到端传输、用户体验监控，并且每一次通话均可回溯。因此，在构建实时数据监测系统时，面临很多“第一次”。本文包含从数据架构设计、数据收集、分析、还原、预警和使用上的很多实践经验分享。
1. 影响通话质量的因素
1.1 接入质量
一次通话的传输过程，包含很多个环节，每个环节的质量，会对整个服务的质量、乃至用户体验产生巨大影响。下面从一个印度用户与中国用户的通话讲起。在通话发起时，这个印度的用户首先会接入声网的SD-RTN实时虚拟通信网，此时，就产生了第一环节的质量问题：接入质量。影响接入质量的因素有：
最近的接入点
弱网络(2G/3G)
WIFI 信号差
路由器设备问题
企业路由器限制
DNS劫持
小运营商网络
跨运营商接入
这些环节，需要一一针对性的优化。
1.2传输质量
接下来是传输质量。这个印度的用户，如果从Bangalore（班加罗尔，印度南部的城市）接入，到北京会有200ms的迟延；但是Bangalore到新加坡只有100ms，再从新加坡到北京只有60ms，这是非常理想的线路。声网的智能路由会选择从新加坡“绕道”走。此时，这个印度用户获得的体验，就是整体160ms的延迟，而不是200ms。
经过接入优化、路由传输优化，用户会获得非常好的端到端质量，丢包控制在1%，抖动和延迟能够控制在120ms。
但是，即使端到端质量非常好，有的用户看到的画面还是模糊的。这是因为，影响用户体验的除了端到端传输，还有其它因素。
1.3 用户的问题
声网在印度的终端用户，有大量用户使用下图这款手机，官网的售价大概是相当于562元人民币。
这是非常低端的设备，会出现很多中高端设备没有的问题。
声学设计缺陷、制造缺陷，造成严重的回音干扰
机型过热造成对性能的影响，导致画面卡顿甚至卡屏
硬件编解码器能力不同，也会对流畅度产生影响
1.4 软件集成的问题
在软件集成方面也会有问题，比如，开发人员用错API或者软件本身存在BUG。
当我们知道有哪些环节会影响通话质量，那么质量监控系统的功能要求也就呼之欲出了。它要能监控到每一次通话的质量。我们能通过这个系统来定位这个问题是一个个例，还是广泛存在的， 是在哪个环节出了问题。
2. 数据的实时监控
2.1 可感知、可保障
对于声网来说，我们需要对用户的通话体验进行实时监控。包括接入节点质量、路由传输层质量、音视频引擎质量以及用户体验质量。有了这些数据，我们就能够对通话过程进行诊断或者进行事后的深入复盘。声网是全球第一个使用大数据平台做监控和实时保障的通信技术服务商。我们在质量监控方面的目标是让整个通信服务的质量是可感知和可保障的。
2.2 基础网络
这是一个声网数据监控中关于基础网络质量的粗略演示。图中显示的是我们整个大网络SD-RTN的数据中心相互之间的连接的情况。红色说明两个机房之间连接的状态非常差，绿色说明非常好。
2.3 基础服务
这是基础服务的监控情况。声网要保障对98%的用户能够在1秒内完成响应，红色是代表响应时间小于1秒的百分比。
2.4 端到端的监控
这是端到端的监控，测量用户在传输区间的数据，包括延迟、丢包。图中的丢包，是网络优化后的丢包，不是实际的丢包。
2.5 用户体验的监控
最后是用户体验方面的监控，比如直播场景下，根据用户的观感体验所做的监控，观众的卡顿。
2.6 告警
这是我们自己开发的一个APP。声网的服务出现任何不稳定的情况时，通过这个APP都可以接收到告警。拿Hike作为一个例子，我们首先会定义什么叫优质接入，当优质接入的比例低于80%的时候，我们就会触发告警。过了一段时间恢复了，同样会接收到提示。
2.7 个例调查
前文说的是一个整体监控。如果个别用户出现突发状况时，比如网络特别差或者手机特别差。我们需要把整个过程还原出来，调查出是哪个环节出了问题，作为后续质量改进的依据。所以，我们会把所有通话各个层次的工作指标实时收集保存下来，这样就能够用于在线现场分析，或者事后复盘。
这是两个用户在打电话的数据实时监控，图中的数据包含：音频的渲染、视频的渲染、用户上行的丢包、上行的延迟等等信息。
3. 系统架构与挑战
这样一个实时监控体系，包含几百个指标，每个用户的数据都要实时收集、实时分析。所以，我们需要一个稳定的架构来支撑这样的海量数据和运算量。
上图是一个架构简图。我们的用户全球分布，数据会从全球各地输入进来，通过我们SD-RTN网络分布全球的数据中心，收集数据。在中间环节，有一个实时的智能网络，它也是一个分布的接收节点，中间有传感节点，收到数据以后通过最近的线路报到美国的数据中心。
整个监测架构，分为3个系统：实时计算系统、实时存储系统、离线存储系统。实时计算系统用来做数据的实时统计和分析，对异常进行告警。实时存储系统用来把数据进行实时收集，用来支撑实时调查的工具，这里会用到HBase离线存储系统，用作整体的质量分析。
要实现这套系统，首先需要对统计的指标进行清晰定义。下图是一些例子，实际的指标不止于此。
用户数据的收集，尤其是移动设备，面临很多问题和挑战。
UDP不可靠：我们采用UDP进行上报。但是，UDP的传输不可靠，所以我们要实现UDP的响应机制。数据报上去后，是否收到，客户端需要知道。如果没有收到就多报几次。
Best effort传输：如果数据报不上去，现在不报，晚一点再报，但这样就失去了时效性。所以，我们要做到可控的上报。那么，我们就要计算总体的丢失率。
DNS解析问题：早期我们采用DNS的方式选择上报的边缘节点，后来发现效果比较差，比如很多DNS时候解析会超时。
数据协议：有些协议是看起来非常简单，容易调试，但是数据的传输效率比较差，而且不是机器友好的协议，可能在解析的时候要做多种判断。最后我们用Thrift协议。
数据量可控：这是数据上报移动端独有的问题。比如，通话时处在非常差的网络， 2G网络。在带宽不够时，如果还上报大量数据，会影响通话过程。所以，数据量可控就是指，在不同网络状况下分析，什么情况下可以多报数据，什么情况下少报一些数据。
数据实时收集：要对上报的边缘节点做负载均衡，防止雪崩。比如，一个客户突然放量了，用户增长上百万。此时，基础设施的搭建可能赶不上用户量的增长。所以，必须保障数据服务能够可靠稳定的工作，不能因为数据量骤增就全都不工作了。所以，边缘节点还必须要有一些防御性的策略。比如，指定哪些类型的数据在边缘节点就丢掉，不再往数据中心传输。
时间序列数据：我们用HBase做时间序列的存储。因为我们收集的数据特别多，但只有少部分数据会调取，比如100个通话只有一两个通话需要复盘或者调查。这是一个写多读少的场景。大量数据都是搁置的，但是又必须要把它们全部收集起来。所以，要针对写多读少的场景做优化。此外，数据结构也做了优化工作。一开始，是参考宽表的方式，但测试后发现宽表会因为行锁问题，影响到写的速度，后面就改成了高表。同时，时间序列就是时间点，是一个key-value序列，但是rowkey很长， 不加优化存储效率非常低。
目前，这个数据监测系统一天规模是一千亿条数据。并且在随着用户量的增加，逐渐提升。整体监控的延迟性能大概是10s以内，从终端用户体验到接入到大网通话开始到结束，所有的环节我们都能监控起来，所有的通话都可以回溯，任何一通通话出现问题，我们都能找到原因。
引用 https://zhuanlan.zhihu.com/p/27817652
