大數據驅動下的快手直播系統優(yōu)化案例

寫在前面 ?

大家下午好，我是羅喆，來自快手，過去的一年多我在快手做直播的體驗優(yōu)化相關的工作。今天給大家分享的主題是快手如何在大數據的驅動下來優(yōu)化直播的質量。

加入公司這一年多，公司的注冊用戶和日活每天都刷新峰值，到現在，快手的注冊用戶已經超過 5 億，短視頻數量已經超過了 int32 所能存儲的數字的上限，也就是 21 個億，日活躍用戶數也已經達到 6500 萬，而且還處于高速增長的趨勢之中。

快手的直播業(yè)務 2016 年初上線，我們的直播業(yè)務和別的直播平臺很不一樣，那就是快手的直播是面向普通人的直播，而不是只有網紅大 V；快手的直播內容，也大多是常見的生活場景，非常多樣化，這樣的模式也決定了快手直播需要考慮的業(yè)務場景更復雜。

目前，快手的直播業(yè)務量迅速增長，單個直播間的觀看人數峰值，最高時超過了百萬人。（8 月 7 日，在用戶“MC 天佑”的直播中，快手單個直播間同時在線人數最高超過了 180 萬。）那么，我們是如何在龐大的用戶基數下保證直播的流暢度呢？我將從四個方面進行解析。

快手直播面臨的挑戰(zhàn)與解決方案 ?

?快手直播的特點和挑戰(zhàn)

快手直播有四個顯著的特點，這些特點給快手帶來了機遇，也讓我們面臨著巨大的挑戰(zhàn)：

數據驅動的優(yōu)化方法論

針對線上紛繁復雜的直播體驗問題，快手視頻團隊在實踐過程中總結出了一套數據驅動的優(yōu)化方法論，歸納一下有三點：

首先是區(qū)分痛點，設置優(yōu)先級。把問題分為兩類：可以忍受和不能忍受，不能忍受的諸如播放失敗、綠屏和黑屏等，這種影響功能可用性的問題定位高優(yōu)先級，快速處理；可以忍受的包括卡頓、清晰度、延時等能看但用戶體驗不好的設置普通優(yōu)先級，持續(xù)優(yōu)化。

其次是制定優(yōu)化方案，問題出現后，定制一個合理的優(yōu)化方案，這里可能涉及到多方，有快手需要解決的問題，也有 CDN 服務商需要解決的問題，需要合理的排期保證問題有序解決。

第三步是灰度驗證或 AB 測試，解決問題之后通過觀測全網的數據進行灰度驗證，確保方案是真正有效了之后，才全量上線。

快手直播全鏈路質量監(jiān)控

這套方法論的基礎是數據，那么，快手直播到底用到哪些數據，怎么判斷用戶的播放體驗是否 OK 呢？下面先介紹一下快手的直播系統端到端的處理流程：視音頻信號實時采集，經過預處理和音視頻編碼，封裝發(fā)送到 CDN 源站，播放端從 CDN 邊緣拉到數據，然后進行解碼，經過音視頻同步之后，給觀眾展現出來。

我們在推流端和播放端分別做了非常完善的質量監(jiān)測體系。在推流端，數據的源頭是攝像頭采集到的畫面和麥克風采集到的聲音，不同的機型和系統，攝像頭和麥克風的能力完全不同，所以我們首先對攝像頭的分辨率、幀率、機型等關鍵信息進行收集；

接下來是視頻前處理的過程，比如去噪、美顏、特效等，這些都是非常耗 CPU 和內存資源的操作，所以這個環(huán)節(jié)對 CPU 和內存的占用做了詳細的上報；前處理之后會進行視頻編碼，視頻編碼的質量影響整個視頻的觀看體驗，對視頻編碼器，主要是上報了視頻編碼的客觀質量和編碼器的輸出幀率；音頻數據的采集編碼過程和視頻類似；

編碼完成之后的數據會進行協議封裝，然后進入碼率自適應模塊，碼率自適應模塊的功能主要是調整輸出碼率以適應用戶的網絡帶寬，在用戶網絡變差的時候，自適應模塊會主動丟棄一些數據以降低對網絡的壓力，推流端的卡頓也主要是發(fā)生在這里，所以在這里對自適應模塊的輸出碼率，丟幀數量，卡頓次數都做了詳盡的統計；數據最后到達到 CDN 服務商的源站，CDN 服務商分配的源站節(jié)點是否合理，是否和用戶在同一地域，同一運營商，都直接影響到用戶的連接質量，所以源站節(jié)點的地理位置和運營商信息，也是對質量評價非常重要的信息。

我們再來看看拉流（播放）端，拉流端整體的流程和推流端是一個反過來的流程，客戶端先經過 DNS 解析，連接到 CDN 的邊緣節(jié)點，和推流端類似，需要對 DNS 解析時間，邊緣節(jié)點的運營商、地理位置、RTT 值等關鍵信息進行采集；從 CDN 邊緣節(jié)點拿到的 http-flv 數據會先經過解封裝送到接收緩沖區(qū)，在這個階段可以對 CDN 服務節(jié)點的首包時間，發(fā)送至接收的端到端延時進行統計；接收緩沖區(qū)的長度決定了拉流端的網絡抗性，這里可以采集到卡頓的次數和時長，緩沖區(qū)本身的長度也是需要監(jiān)控的點；數據從緩沖區(qū)的輸出，會分別進行音頻和視頻的解碼，經過音視頻同步，進入播放環(huán)節(jié)。這里從拉流啟動到播放出第一幀畫面的時間就是首幀時間。

這些復雜的過程在用戶點擊一個直播之后，絕大部分情況下在幾百毫秒以內就會完成，我們也進一步分解了首幀各個環(huán)節(jié)的時間，能夠對它進行深入的分析和優(yōu)化。

直播質量數據處理 Pipeline

在提取了詳細的質量數據之后，接下來就是后端處理的事情了，我將從直播質量數據處理 Pipeline、用戶體驗質量數據 & 服務質量數據、數據可視化監(jiān)測流程三個角度為大家全面解析快手是如何發(fā)現直播當中的問題，以及是如何解決的。

直播質量數據處理流程

下圖是快手現在所使用的直播數據處理 Pipeline，可以很清晰的看到整個流程為數據采集→數據緩存→數據分類處理→數據索引 / 展示。

我們具體看看這個流程的工作細節(jié)，數據從快手 APP 收集，然后經過上報服務器的簡單處理之后，會存到 Kafka 的 Topic 里面，Kafka 是非?？煽康臄祿犃蟹?，只要 Kafka 的機群夠多，即使部分機器宕了數據都不會丟的；接下來，Kafka 的數據會分出兩條處理路徑：

快手每天經過這個系統處理的直播相關的數據，在百億條的量級，直播相關的所有的數據展示和監(jiān)控都依賴于這整個 Pipeline，要在分鐘級要求下，支持各種業(yè)務查詢需求，保證系統的平穩(wěn)運行，是很不容易的。

用戶體驗質量 & 服務質量

采集到了數據并且對數據進行清洗入庫之后，怎么去分析數據呢？首先，我們把數據可視化的監(jiān)測分為兩類，一類是用戶體驗質量（QoE，Quality of Experience），我們把它定義為一種和用戶主觀感受相關的數據，如同時直播房間數、直播同時在線人數、直播跳出率等，這些數據的波動有可能是技術問題導致的，也有可能是因為直播內容不符合觀眾預期，可以綜合反映出用戶對直播體驗的主觀感受。并且，這幾項用戶體驗指標反映的是整體的趨勢，如果真的出現技術性的問題，靠這些指標是無法追蹤問題的源頭的。

舉例來說，如果我們發(fā)現直播同時在線觀看的人數降了，但這只能說明有問題，具體問題在哪里，什么原因導致的需要通過第二類指標：服務質量（QoS， Quality of Service）數據來進一步分析。服務質量數據是純客觀的，反映的是技術性的指標，比如這張示意圖，是一個以時間維度的各 CDN 服務商的卡頓率曲線；QoE 指標的波動未必一定是 QoS 的數據波動導致的，QoS 的數據波動也不是一定會導致 QoE 數據的變化，比如卡頓率可能會上升，但是在可接受的范圍內，同時在線人數不一定會有大的變化。

數據可視化監(jiān)測流程

我們以下圖的“進入房間人數”和“退出房間人數”分析，說明一下我們是怎么做聯合 QoE 數據和 QoS 數據進行監(jiān)測和分析的。首先看看 QoE 數據，左上角是快手某次直播房間的同時在線人數曲線，在直播過程中在線人數有一個“掉坑”的現象，右下角的“退出房間人數”曲線顯示在九點三十多分有一個峰值，說明有大量用戶退出房間，我們推測這里可能發(fā)生了某些問題導致了觀看人數的大量減少，有可能是非技術性的，比如主播做了一件事情觀眾們不太喜歡，會導致觀眾大量流失。奇怪的是，右上角的“進入房間人數”曲線顯示，進入房間在同樣時刻也有一個峰值，這個時候說明雖然有大量用戶退出了房間，但是同時也大量的進入了該房間。這里我們可以通過 QoE 數據得出一些結論，這一次觀眾大量退出，應該不是由于直播內容導致的，而是快手的直播服務有問題導致的，因為觀眾大量退出同時也大量進入，是因為觀眾覺得重新打開直播可能可以解決問題，退出直播并不是因為他們不再想看這個直播了 。

為了證實這個判斷，我們觀測 QoS 數據曲線。圖上兩條曲線是所有 CDN 節(jié)點進入房間人數曲線和退出房間曲線，可以看到在用戶大量退出的時候，基本上各個 CDN 節(jié)點都會有大量的退出和進入，而不是只有少數節(jié)點才有這個行為，這樣就可以進一步判斷應該不是個別拉流節(jié)點的問題的問題，極有可能是主播推流發(fā)生了問題。之后我們聯合 CDN 把主播的錄像和推流曲線拿到之后，基本上可以斷定主播當時的網絡發(fā)生了抖動，導致短暫的卡頓，之后又立刻恢復，短暫的卡頓導致觀眾大量退出直播間。

從這個例子我們可以看出 QoE 的指標是一個綜合衡量指標，它很直觀，雖然并不能直接對應到 QoS 服務質量指標，但我們可以通過它來全局監(jiān)控，判斷是技術還是內容原因出現了體驗問題，如果是技術原因，我們再去詳細的查看 QoS 指標的時候就可以查出問題的根源。

直播系統優(yōu)化案例

接下來，我將通過開播跳幀優(yōu)化和 httpDNS 首屏優(yōu)化兩個例子，以實例說明如何利用大數據做直播系統調優(yōu)。

拉流端開播的過程

拉流端開播的過程，如前面所述，主要是連接 CDN 節(jié)點拉取數據，數據的解碼、渲染這幾個步驟。CDN 的邊緣節(jié)點一般都會緩存一部分數據，便于拉流端在任何時刻開始拉流都能拉到數據。為了讓用戶盡可能的播放流暢，CDN 會盡量的向用戶多發(fā)一些數據，有時候甚至超過播放端拉流的緩沖區(qū)，超過的這部分數據會造成的顯著問題是，如果照單全收并且按照正常的速度播，會導致直播延時增大，互動效果變差。業(yè)界公認的互動直播延時標準是小于 5 秒鐘，超過 5 秒評論禮物互動效果就會變差。因此我們需要在保證延遲的前提下，盡量縮短首屏，提高流暢度。

如上圖，拉流端接收緩沖區(qū)長度一般等同于延時，我們把它的長度設置為 5s，如果 CDN 下發(fā)的數據大于了接收緩沖區(qū)的長度，假設超過的部分是 4 秒，那么如果不做任何處理，正常播放的延時是 5 秒加 4 秒等于 9 秒，9 秒的延時在直播過程中基本上沒辦法做評論或者交互，體驗很差。于是我們一開始嘗試從客戶端來單獨解決這超出的部分數據導致的問題。

我們嘗試了兩種的解決辦法：直接快進和跳幀，直接快進的方案就是將超過的部分數據快速的播放過去，視頻和聲音都被加速播放了，這個方案上線之后很快就收到了用戶的投訴，懷疑快手的直播是假直播，真正的直播怎么會出現“快進”的現象；然后我們修改了方案，將超出的部分數據直接跳過不進行播放，但是這又帶來了新的問題，直接跳幀會導致用戶的聲音和畫面出現突變，主播可能從畫面的左邊突然出現在畫面的右邊，體驗也不是很好?？傊?，只在客戶端做優(yōu)化無法做到體驗的最優(yōu)。

開播跳幀優(yōu)化

由于導致這個問題的真正原因是 CDN 下發(fā)數據過多導致的，為了做到最優(yōu)的體驗，必須和 CDN 聯合優(yōu)化。這時，快手的多 CDN 策略帶來一個新的問題：各家 CDN 開播下發(fā)數據的策略完全不同， 在開播時下發(fā)的數據長度都不一樣，很難定量的評價哪一家 CDN 做的更好一些。

于是制定統一的評價標準成為第一個要解決問題，這里快手使用“開播前 10 秒跳幀時長”作為衡量 CDN 下發(fā)數據長度的標準，具體是指拉流端播放的前 10 秒內丟棄數據的總時長。

在制定統一的評價標準之后，通過線上數據觀察各家 CDN 的跳幀指標，嘗試讓各 CDN 優(yōu)化自己的指標，盡量接近最優(yōu)的那一家。但是由于各 CDN 的開播策略都大不相同，可配置參數也完全不一樣，不同的 CDN 之間很難做到數據完全一致。而且即使是指標最優(yōu)的 CDN 也無法將開播前 10s 調整時長調整到讓快手滿意的程度。于是，統一各家 CDN 開播數據下發(fā)策略成為第二個要解決的重要問題。

我們設計了一套統一的開播數據下發(fā)策略，讓各家 CDN 都按照這個方案來實現。該方案總的來說遵循三個原則：1. 下發(fā)數據長度不能超過快手拉流端接受緩沖區(qū)長度 2. 必須從一個 GOP（Group of Pictures）的開始下發(fā) 3. 在不違背前面兩點的情況下，下發(fā)盡可能多的數據。上圖是兩個根據服務端緩存的不同 GOP 結構，決定下發(fā)數據策略的實際 case，假設快手拉流端接收緩沖區(qū)長度是 5 秒：

制定了統一的開播數據下發(fā)策略之后，在多家 CDN 分別上線灰度，對比觀察各家 CDN 覆蓋節(jié)點和未覆蓋節(jié)點的數據，然后逐步擴大灰度范圍直至全量上線。對比優(yōu)化前的日均值，開播前 10s 跳幀時長從 1500ms 降低至 200ms。

經過上一輪的 CDN 端優(yōu)化之后，觀察全網的開播跳幀數據，各家 CDN 的指標保持在相同的水平（開播 10 秒平均跳幀 200ms 左右），基本可以判斷 CDN 端的優(yōu)化已經到了瓶頸，客戶端能否進一步優(yōu)化解決掉最后的 200ms 呢？這里快手使用了緩慢快進的方案：將多余的 200ms 在用戶無感知的情況下，進行加速播放，控制緩沖區(qū)的大小。只要將加速程度控制在一定范圍內，用戶基本是沒有察覺的，而正常播放時長為 200ms 的數據，經過加速，能很快的播放完，之后就恢復成正常速度播放，這樣就保證了不會再有跳幀的現象，最后的 AB TEST 數據顯示開播跳幀時長完全為 0，而卡頓情況也有比較明顯的降低。

在解決了開播跳幀的問題之后，我們來回顧一下開播跳幀優(yōu)化的整個過程：

在這整個過程中可以明顯看到對快手整個數據平臺的測試監(jiān)控和統計的依賴，無論是評價 CDN 的質量，還是 CDN 優(yōu)化后的對比測試，客戶端的 AB TEST 效果驗證，都需要觀察對比全網的數據，才能確認優(yōu)化效果，證明確實完美解決了跳幀問題。

httpDNS 首屏優(yōu)化

我們要分享的第二個優(yōu)化點是首屏的優(yōu)化，首屏的整個過程，大致可以分為下圖的這六個步驟，快手對各步驟的耗時做了詳盡的分析，分析結果顯示，DNS 解析其中是最耗時的環(huán)節(jié)，因此要降低首屏時間，必須先降低 DNS 解析時間。

傳統的 DNS 解析（業(yè)界統稱 localDNS 方案）的過程很簡單。整個過程如下圖，APP 向所在網絡運營商的 DNS Server 發(fā)起域名解析的請求，而運營商 DNS Server 會向 CDN 的 GSLB 系統發(fā)起遞歸查詢，GSLB 通過運營 DNS Server 所屬 IP 地址判斷查詢來自于哪個運營商和地理位置，然后返回若干合適的 CDN 邊緣節(jié)點 IP 給它。這個過程中，APP 和 CDN 之間隔了運營商 DNS Server 這一層，CDN 在分配節(jié)點的時候其實沒有辦法獲取任何 APP 的信息。為了解決傳統 localDNS 調度不精確，容易被劫持等缺點，近年業(yè)界起興起了另一種方案 httpDNS。其原理是 APP 通過 HTTP 協議直接調用 CDN 提供的 httpsDNS API，獲取一組合適的邊緣節(jié)點 IP。這兩種方案互有優(yōu)劣：

localDNS 和 httpDNS 各有優(yōu)劣，而且都有一定的失敗率，為了提升 DNS 解析的成功率，快手的 DNS 解析方案是 localDNS 和 httpDNS 結合使用。

為了結合 localDNS 和 httpDNS 的優(yōu)點，并且考慮到解析返回的多個 CDN 邊緣節(jié)點的優(yōu)選，快手設計了獨特的 DNS 解析方案：

于是我們對 IP 優(yōu)選方案進行了進一步優(yōu)化，測速后并不是直接選用結果最優(yōu)的那一個，而是在測試結果可以接受的一定范圍內進行隨機挑選，這樣就避免了大量用戶都聚集到少數節(jié)點，導致節(jié)點負載不均衡：

對這個優(yōu)化方案進行 AB TEST，質量數據完全符合預期：

首屏時間下降了 30%，卡頓也有明顯改善，節(jié)點優(yōu)選的策略使得連接失敗率也下降了 2 個百分點！一個為了優(yōu)化首屏而提出的策略，對多個指標都有如此明顯的正向影響，是我們一開始沒有預料到的。

挑戰(zhàn)與規(guī)劃

快手的直播業(yè)務現在還處于高速發(fā)展之中，對流媒體大數據分析平臺也提出了新的挑戰(zhàn)：

為了應對這些挑戰(zhàn)，我們會持續(xù)加強投入，完善數據方面的核心能力。

在大數據平臺之上，從整個直播體驗優(yōu)化層面來看，為了真正做到用戶體驗的端到端可控，我們需要有能力深入所有環(huán)節(jié)監(jiān)測和調優(yōu)，因此快手將建設核心技術能力作為下一步優(yōu)化的基礎：

寫在最后

快手的直播業(yè)務仍在高速增長，用戶數量快速的上漲對服務質量有更高的要求，流媒體大數據平臺是各項視頻業(yè)務的一個基礎平臺，需要提供完善且穩(wěn)定的數據收集，數據處理，數據監(jiān)控，數據分析等服務。為了應對業(yè)務挑戰(zhàn)，我們會持續(xù)擴充完善數據基礎架構，擴張相關技術團隊，歡迎更多有大數據平臺實戰(zhàn)經驗，對流媒體大數據分析和優(yōu)化感興趣的牛人加入快手的視頻技術團隊。相信在未來，快手的流媒體大數據平臺能更好的服務用戶，達成快手記錄世界的愿景。

生成海報

免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。