基于大數據平臺-實時質量監控平臺的架構設計
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
