基于大數(shù)據(jù)平臺(tái)-實(shí)時(shí)質(zhì)量監(jiān)控平臺(tái)的架構(gòu)設(shè)計(jì)
6 個(gè)月前
本文是聲網(wǎng)首席數(shù)據(jù)架構(gòu)師何豐，在A(yíng)rchSummit全球架構(gòu)師峰會(huì)深圳站，分享的內(nèi)容《質(zhì)量實(shí)時(shí)監(jiān)控：全球音視頻實(shí)時(shí)傳輸?shù)年P(guān)鍵幀》。
在全球?qū)崟r(shí)音視頻傳輸過(guò)程中，為了提供QoE質(zhì)量保障，需要構(gòu)建一個(gè)穩(wěn)定可靠的實(shí)時(shí)數(shù)據(jù)監(jiān)測(cè)系統(tǒng)，從而能夠監(jiān)測(cè)每一次通話(huà)。聲網(wǎng)是全球首個(gè)使用大數(shù)據(jù)平臺(tái)做監(jiān)控和實(shí)時(shí)保障的通信技術(shù)服務(wù)商。聲網(wǎng)的實(shí)時(shí)數(shù)據(jù)監(jiān)控系統(tǒng)，覆蓋了實(shí)時(shí)通話(huà)的全鏈路，包括端到端傳輸、用戶(hù)體驗(yàn)監(jiān)控，并且每一次通話(huà)均可回溯。因此，在構(gòu)建實(shí)時(shí)數(shù)據(jù)監(jiān)測(cè)系統(tǒng)時(shí)，面臨很多“第一次”。本文包含從數(shù)據(jù)架構(gòu)設(shè)計(jì)、數(shù)據(jù)收集、分析、還原、預(yù)警和使用上的很多實(shí)踐經(jīng)驗(yàn)分享。
1. 影響通話(huà)質(zhì)量的因素
1.1 接入質(zhì)量
一次通話(huà)的傳輸過(guò)程，包含很多個(gè)環(huán)節(jié)，每個(gè)環(huán)節(jié)的質(zhì)量，會(huì)對(duì)整個(gè)服務(wù)的質(zhì)量、乃至用戶(hù)體驗(yàn)產(chǎn)生巨大影響。下面從一個(gè)印度用戶(hù)與中國(guó)用戶(hù)的通話(huà)講起。在通話(huà)發(fā)起時(shí)，這個(gè)印度的用戶(hù)首先會(huì)接入聲網(wǎng)的SD-RTN實(shí)時(shí)虛擬通信網(wǎng)，此時(shí)，就產(chǎn)生了第一環(huán)節(jié)的質(zhì)量問(wèn)題：接入質(zhì)量。影響接入質(zhì)量的因素有：
最近的接入點(diǎn)
弱網(wǎng)絡(luò)(2G/3G)
WIFI 信號(hào)差
路由器設(shè)備問(wèn)題
企業(yè)路由器限制
DNS劫持
小運(yùn)營(yíng)商網(wǎng)絡(luò)
跨運(yùn)營(yíng)商接入
這些環(huán)節(jié)，需要一一針對(duì)性的優(yōu)化。
1.2傳輸質(zhì)量
接下來(lái)是傳輸質(zhì)量。這個(gè)印度的用戶(hù)，如果從Bangalore（班加羅爾，印度南部的城市）接入，到北京會(huì)有200ms的遲延；但是Bangalore到新加坡只有100ms，再?gòu)男录悠碌奖本┲挥?0ms，這是非常理想的線(xiàn)路。聲網(wǎng)的智能路由會(huì)選擇從新加坡“繞道”走。此時(shí)，這個(gè)印度用戶(hù)獲得的體驗(yàn)，就是整體160ms的延遲，而不是200ms。
經(jīng)過(guò)接入優(yōu)化、路由傳輸優(yōu)化，用戶(hù)會(huì)獲得非常好的端到端質(zhì)量，丟包控制在1%，抖動(dòng)和延遲能夠控制在120ms。
但是，即使端到端質(zhì)量非常好，有的用戶(hù)看到的畫(huà)面還是模糊的。這是因?yàn)?，影響用?hù)體驗(yàn)的除了端到端傳輸，還有其它因素。
1.3 用戶(hù)的問(wèn)題
聲網(wǎng)在印度的終端用戶(hù)，有大量用戶(hù)使用下圖這款手機(jī)，官網(wǎng)的售價(jià)大概是相當(dāng)于562元人民幣。
這是非常低端的設(shè)備，會(huì)出現(xiàn)很多中高端設(shè)備沒(méi)有的問(wèn)題。
聲學(xué)設(shè)計(jì)缺陷、制造缺陷，造成嚴(yán)重的回音干擾
機(jī)型過(guò)熱造成對(duì)性能的影響，導(dǎo)致畫(huà)面卡頓甚至卡屏
硬件編解碼器能力不同，也會(huì)對(duì)流暢度產(chǎn)生影響
1.4 軟件集成的問(wèn)題
在軟件集成方面也會(huì)有問(wèn)題，比如，開(kāi)發(fā)人員用錯(cuò)API或者軟件本身存在BUG。
當(dāng)我們知道有哪些環(huán)節(jié)會(huì)影響通話(huà)質(zhì)量，那么質(zhì)量監(jiān)控系統(tǒng)的功能要求也就呼之欲出了。它要能監(jiān)控到每一次通話(huà)的質(zhì)量。我們能通過(guò)這個(gè)系統(tǒng)來(lái)定位這個(gè)問(wèn)題是一個(gè)個(gè)例，還是廣泛存在的， 是在哪個(gè)環(huán)節(jié)出了問(wèn)題。
2. 數(shù)據(jù)的實(shí)時(shí)監(jiān)控
2.1 可感知、可保障
對(duì)于聲網(wǎng)來(lái)說(shuō)，我們需要對(duì)用戶(hù)的通話(huà)體驗(yàn)進(jìn)行實(shí)時(shí)監(jiān)控。包括接入節(jié)點(diǎn)質(zhì)量、路由傳輸層質(zhì)量、音視頻引擎質(zhì)量以及用戶(hù)體驗(yàn)質(zhì)量。有了這些數(shù)據(jù)，我們就能夠?qū)νㄔ?huà)過(guò)程進(jìn)行診斷或者進(jìn)行事后的深入復(fù)盤(pán)。聲網(wǎng)是全球第一個(gè)使用大數(shù)據(jù)平臺(tái)做監(jiān)控和實(shí)時(shí)保障的通信技術(shù)服務(wù)商。我們?cè)谫|(zhì)量監(jiān)控方面的目標(biāo)是讓整個(gè)通信服務(wù)的質(zhì)量是可感知和可保障的。
2.2 基礎(chǔ)網(wǎng)絡(luò)
這是一個(gè)聲網(wǎng)數(shù)據(jù)監(jiān)控中關(guān)于基礎(chǔ)網(wǎng)絡(luò)質(zhì)量的粗略演示。圖中顯示的是我們整個(gè)大網(wǎng)絡(luò)SD-RTN的數(shù)據(jù)中心相互之間的連接的情況。紅色說(shuō)明兩個(gè)機(jī)房之間連接的狀態(tài)非常差，綠色說(shuō)明非常好。
2.3 基礎(chǔ)服務(wù)
這是基礎(chǔ)服務(wù)的監(jiān)控情況。聲網(wǎng)要保障對(duì)98%的用戶(hù)能夠在1秒內(nèi)完成響應(yīng)，紅色是代表響應(yīng)時(shí)間小于1秒的百分比。
2.4 端到端的監(jiān)控
這是端到端的監(jiān)控，測(cè)量用戶(hù)在傳輸區(qū)間的數(shù)據(jù)，包括延遲、丟包。圖中的丟包，是網(wǎng)絡(luò)優(yōu)化后的丟包，不是實(shí)際的丟包。
2.5 用戶(hù)體驗(yàn)的監(jiān)控
最后是用戶(hù)體驗(yàn)方面的監(jiān)控，比如直播場(chǎng)景下，根據(jù)用戶(hù)的觀(guān)感體驗(yàn)所做的監(jiān)控，觀(guān)眾的卡頓。
2.6 告警
這是我們自己開(kāi)發(fā)的一個(gè)APP。聲網(wǎng)的服務(wù)出現(xiàn)任何不穩(wěn)定的情況時(shí)，通過(guò)這個(gè)APP都可以接收到告警。拿Hike作為一個(gè)例子，我們首先會(huì)定義什么叫優(yōu)質(zhì)接入，當(dāng)優(yōu)質(zhì)接入的比例低于80%的時(shí)候，我們就會(huì)觸發(fā)告警。過(guò)了一段時(shí)間恢復(fù)了，同樣會(huì)接收到提示。
2.7 個(gè)例調(diào)查
前文說(shuō)的是一個(gè)整體監(jiān)控。如果個(gè)別用戶(hù)出現(xiàn)突發(fā)狀況時(shí)，比如網(wǎng)絡(luò)特別差或者手機(jī)特別差。我們需要把整個(gè)過(guò)程還原出來(lái)，調(diào)查出是哪個(gè)環(huán)節(jié)出了問(wèn)題，作為后續(xù)質(zhì)量改進(jìn)的依據(jù)。所以，我們會(huì)把所有通話(huà)各個(gè)層次的工作指標(biāo)實(shí)時(shí)收集保存下來(lái)，這樣就能夠用于在線(xiàn)現(xiàn)場(chǎng)分析，或者事后復(fù)盤(pán)。
這是兩個(gè)用戶(hù)在打電話(huà)的數(shù)據(jù)實(shí)時(shí)監(jiān)控，圖中的數(shù)據(jù)包含：音頻的渲染、視頻的渲染、用戶(hù)上行的丟包、上行的延遲等等信息。
3. 系統(tǒng)架構(gòu)與挑戰(zhàn)
這樣一個(gè)實(shí)時(shí)監(jiān)控體系，包含幾百個(gè)指標(biāo)，每個(gè)用戶(hù)的數(shù)據(jù)都要實(shí)時(shí)收集、實(shí)時(shí)分析。所以，我們需要一個(gè)穩(wěn)定的架構(gòu)來(lái)支撐這樣的海量數(shù)據(jù)和運(yùn)算量。
上圖是一個(gè)架構(gòu)簡(jiǎn)圖。我們的用戶(hù)全球分布，數(shù)據(jù)會(huì)從全球各地輸入進(jìn)來(lái)，通過(guò)我們SD-RTN網(wǎng)絡(luò)分布全球的數(shù)據(jù)中心，收集數(shù)據(jù)。在中間環(huán)節(jié)，有一個(gè)實(shí)時(shí)的智能網(wǎng)絡(luò)，它也是一個(gè)分布的接收節(jié)點(diǎn)，中間有傳感節(jié)點(diǎn)，收到數(shù)據(jù)以后通過(guò)最近的線(xiàn)路報(bào)到美國(guó)的數(shù)據(jù)中心。
整個(gè)監(jiān)測(cè)架構(gòu)，分為3個(gè)系統(tǒng)：實(shí)時(shí)計(jì)算系統(tǒng)、實(shí)時(shí)存儲(chǔ)系統(tǒng)、離線(xiàn)存儲(chǔ)系統(tǒng)。實(shí)時(shí)計(jì)算系統(tǒng)用來(lái)做數(shù)據(jù)的實(shí)時(shí)統(tǒng)計(jì)和分析，對(duì)異常進(jìn)行告警。實(shí)時(shí)存儲(chǔ)系統(tǒng)用來(lái)把數(shù)據(jù)進(jìn)行實(shí)時(shí)收集，用來(lái)支撐實(shí)時(shí)調(diào)查的工具，這里會(huì)用到HBase離線(xiàn)存儲(chǔ)系統(tǒng)，用作整體的質(zhì)量分析。
要實(shí)現(xiàn)這套系統(tǒng)，首先需要對(duì)統(tǒng)計(jì)的指標(biāo)進(jìn)行清晰定義。下圖是一些例子，實(shí)際的指標(biāo)不止于此。
用戶(hù)數(shù)據(jù)的收集，尤其是移動(dòng)設(shè)備，面臨很多問(wèn)題和挑戰(zhàn)。
UDP不可靠：我們采用UDP進(jìn)行上報(bào)。但是，UDP的傳輸不可靠，所以我們要實(shí)現(xiàn)UDP的響應(yīng)機(jī)制。數(shù)據(jù)報(bào)上去后，是否收到，客戶(hù)端需要知道。如果沒(méi)有收到就多報(bào)幾次。
Best effort傳輸：如果數(shù)據(jù)報(bào)不上去，現(xiàn)在不報(bào)，晚一點(diǎn)再報(bào)，但這樣就失去了時(shí)效性。所以，我們要做到可控的上報(bào)。那么，我們就要計(jì)算總體的丟失率。
DNS解析問(wèn)題：早期我們采用DNS的方式選擇上報(bào)的邊緣節(jié)點(diǎn)，后來(lái)發(fā)現(xiàn)效果比較差，比如很多DNS時(shí)候解析會(huì)超時(shí)。
數(shù)據(jù)協(xié)議：有些協(xié)議是看起來(lái)非常簡(jiǎn)單，容易調(diào)試，但是數(shù)據(jù)的傳輸效率比較差，而且不是機(jī)器友好的協(xié)議，可能在解析的時(shí)候要做多種判斷。最后我們用Thrift協(xié)議。
數(shù)據(jù)量可控：這是數(shù)據(jù)上報(bào)移動(dòng)端獨(dú)有的問(wèn)題。比如，通話(huà)時(shí)處在非常差的網(wǎng)絡(luò)， 2G網(wǎng)絡(luò)。在帶寬不夠時(shí)，如果還上報(bào)大量數(shù)據(jù)，會(huì)影響通話(huà)過(guò)程。所以，數(shù)據(jù)量可控就是指，在不同網(wǎng)絡(luò)狀況下分析，什么情況下可以多報(bào)數(shù)據(jù)，什么情況下少報(bào)一些數(shù)據(jù)。
數(shù)據(jù)實(shí)時(shí)收集：要對(duì)上報(bào)的邊緣節(jié)點(diǎn)做負(fù)載均衡，防止雪崩。比如，一個(gè)客戶(hù)突然放量了，用戶(hù)增長(zhǎng)上百萬(wàn)。此時(shí)，基礎(chǔ)設(shè)施的搭建可能趕不上用戶(hù)量的增長(zhǎng)。所以，必須保障數(shù)據(jù)服務(wù)能夠可靠穩(wěn)定的工作，不能因?yàn)閿?shù)據(jù)量驟增就全都不工作了。所以，邊緣節(jié)點(diǎn)還必須要有一些防御性的策略。比如，指定哪些類(lèi)型的數(shù)據(jù)在邊緣節(jié)點(diǎn)就丟掉，不再往數(shù)據(jù)中心傳輸。
時(shí)間序列數(shù)據(jù)：我們用HBase做時(shí)間序列的存儲(chǔ)。因?yàn)槲覀兪占臄?shù)據(jù)特別多，但只有少部分?jǐn)?shù)據(jù)會(huì)調(diào)取，比如100個(gè)通話(huà)只有一兩個(gè)通話(huà)需要復(fù)盤(pán)或者調(diào)查。這是一個(gè)寫(xiě)多讀少的場(chǎng)景。大量數(shù)據(jù)都是擱置的，但是又必須要把它們?nèi)渴占饋?lái)。所以，要針對(duì)寫(xiě)多讀少的場(chǎng)景做優(yōu)化。此外，數(shù)據(jù)結(jié)構(gòu)也做了優(yōu)化工作。一開(kāi)始，是參考寬表的方式，但測(cè)試后發(fā)現(xiàn)寬表會(huì)因?yàn)樾墟i問(wèn)題，影響到寫(xiě)的速度，后面就改成了高表。同時(shí)，時(shí)間序列就是時(shí)間點(diǎn)，是一個(gè)key-value序列，但是rowkey很長(zhǎng)， 不加優(yōu)化存儲(chǔ)效率非常低。
目前，這個(gè)數(shù)據(jù)監(jiān)測(cè)系統(tǒng)一天規(guī)模是一千億條數(shù)據(jù)。并且在隨著用戶(hù)量的增加，逐漸提升。整體監(jiān)控的延遲性能大概是10s以?xún)?nèi)，從終端用戶(hù)體驗(yàn)到接入到大網(wǎng)通話(huà)開(kāi)始到結(jié)束，所有的環(huán)節(jié)我們都能監(jiān)控起來(lái)，所有的通話(huà)都可以回溯，任何一通通話(huà)出現(xiàn)問(wèn)題，我們都能找到原因。
引用 https://zhuanlan.zhihu.com/p/27817652
