B站Up主上传质量调优实践
Up主上傳的大量優(yōu)質視頻內容使得bilibili（B站）深受年輕用戶的喜愛。bilibili視頻云高級研發(fā)經(jīng)理 唐君行在LiveVideoStack線上交流分享中詳細介紹了B站為提供更流暢、穩(wěn)定用戶體驗，努力優(yōu)化上傳系統(tǒng)架構，建立質量體系以及質量調優(yōu)中的實踐經(jīng)驗。
文 / Json（唐君行）
整理 / LiveVideoStack
直播回放：
https://www.baijiayun.com/web/playback/index?classid=19012252228433&token=oxx9-k_ZrxvhKKZLIMQ5hscti3kMCPTn5jjVy0_0ZBG_6qrsbCBq-khAVqheOz1TCqdH1zJ1Si0
大家好，我是來自bilibili（B站）的Json，目前主要負責bilibili的視頻上傳、存儲、點播CDN建設與架構演進。在進入B站之前我主要負責系統(tǒng)架構設計與數(shù)據(jù)驅動研發(fā)，同樣這也是我非常擅長的領域。
我將從以上幾個方面為大家分享B站上傳調優(yōu)實踐的具體內容：兩三年前，B站服務器有限的承載能力使得用戶上傳視頻失敗的狀況時有發(fā)生，這也是我剛加入B站時希望通過調整系統(tǒng)架構努力優(yōu)化的方面；同時這樣一個基于數(shù)據(jù)優(yōu)化的項目，需要建立正確的優(yōu)化指標與質量優(yōu)化方案，借助數(shù)據(jù)的力量驅動整個平臺的開發(fā)，使得用戶能夠在B站收獲流暢穩(wěn)定的使用體驗。
?
1.?系統(tǒng)架構
?
上圖展示的是B站的用戶創(chuàng)作中心，用戶上傳到B站的視頻文件體積較大，質量較高。初期我們僅開發(fā)了通過PC（網(wǎng)頁端）上傳文件的功能。視頻體積較大是我們的優(yōu)化工作帶中的主要挑戰(zhàn)，因為只有所有分片都上傳成功，一個視頻文件才算被上傳成功。
B站為了確保內容的高質量，僅有答對一定數(shù)量題目的Up主才能獲取上傳視頻的資格，這就使得上傳至B站的視頻內容多為平均體積在400MB左右的優(yōu)質長視頻；雖然采取了這種設置一定門檻的上傳機制，但我們的日上傳量依舊保持在15萬左右并且維持著年100%的增長，這也就是為什么在未來我們希望在鞏固現(xiàn)有網(wǎng)頁版上傳服務的同時繼續(xù)開發(fā)Android、iOS、PC客戶端的上傳功能，方便用戶隨時隨地上傳高質量視頻內容。
作為上傳系統(tǒng)的關鍵組件，存儲部分的架構并不復雜。我們使用一臺節(jié)點服務器處理數(shù)據(jù)提供服務，當用戶將視頻文件成功上傳至此服務器時，視頻文件在服務器后端會經(jīng)過一系列系統(tǒng)處理，并在主機之間多次交換數(shù)據(jù)，其傳輸協(xié)議與溝通方式更像一個運維系統(tǒng)，比較原始，我們將其重構為一個帶有網(wǎng)關的系統(tǒng)，改進原先每開始一種新業(yè)務就需新分配一批服務器的機制，使用網(wǎng)關的匯集功能可大大降低在配置域名與接入新業(yè)務等運維工作的壓力與成本，并將節(jié)省下來的時間資源運用于優(yōu)化工作。
除此之外，我們將統(tǒng)一存儲升級為可以分Bucket配置不同參數(shù)且與業(yè)務無關的通用對象存儲，其承接了B站的UGC、PGC、音頻、短視頻的上傳、處理與回源等工作；同時，使用此上傳、存儲體系統(tǒng)一的方案可有效減少文件在系統(tǒng)間轉移產生的IO。
隨著B站的不斷發(fā)展，從一開始投入大量資源至業(yè)務發(fā)展到現(xiàn)在逐漸專注于內容與資源的分享與呈現(xiàn)，B站不斷嘗試將主要精力從與業(yè)務相關的內容剝離出并投入優(yōu)化工作，基于此網(wǎng)關統(tǒng)一所有業(yè)務的通訊協(xié)議從而進一步簡化存儲架構。
?
我們基于OpenResty搭建了B站的上傳系統(tǒng)。初期B站的上傳系統(tǒng)基于PHP搭建，雖然PHP并沒有明顯缺陷，但由于其還需搭建Nginx才能正常工作，因此相對于OpenResty這樣可直接在Nginx中讀取與合并上傳文件分片的架構，PHP并不是我們的首選項。使用OpenResty的同時，對外發(fā)起Gap請求的次數(shù)也更多，同樣也支持用戶從網(wǎng)站獲取視頻數(shù)據(jù)的高性能模式。純粹從編程語言層面來講 ，以上是OpenResty在網(wǎng)關層面的作用之一。就我目前的體驗來看，OpenResty并不輸給其他語言：我們的視頻云中包括大量基于OpenResty架構的技術棧，而CDN、存儲系統(tǒng)與直播系統(tǒng)也基于OpenResty實現(xiàn)，推薦大家使用OpenResty。
?
一般大公司會使用OpenResty重寫相應模塊以應對高并發(fā)場景，實際來說我們可在一些高I/O場景中使用OpenResty。雖然Node.js與Go也可實現(xiàn)異步I/O但其需要開發(fā)者編寫大量的回調，而OpenResty能夠借助同步代碼實現(xiàn)異步I/O；相對于需要大量時間精力應對高并發(fā)場景的Python與PHP，OpenResty可極大提高開發(fā)效率。除此之外，Nginx本身也扮演著網(wǎng)關與業(yè)務服務的角色，可明顯簡化架構；OpenResty也可直接訪問Nginx的ClientBody且不存在語言框架的損耗，如果是其他語言則需在CGI層通過上行Buffer將ClientBody傳至所用語言中，并且需要一定轉化如Python需要WSGI轉化；最后，Lua較高的開發(fā)效率也能幫助開發(fā)者盡可能實現(xiàn)最佳開發(fā)效果。
?
上圖展示了存儲系統(tǒng)的整體架構，其主要分為以下三個模塊：網(wǎng)關、Meta數(shù)據(jù)庫與存儲。用戶的訪問請求首先經(jīng)由網(wǎng)關處理，網(wǎng)關繼而讀取Meta數(shù)據(jù)庫中一部分符合請求存儲位置的數(shù)據(jù)，隨后存儲會將網(wǎng)絡流依次通過圖中的路徑5與路徑6傳輸至客戶端。這樣一個簡單的存儲架構自然而然會受到許多需要重構小部分存儲減小內容存儲風險的公司的青睞。
?
我們選擇S3作為上傳協(xié)議。在早期上傳協(xié)議的選型過程中我們研究了國內許多互聯(lián)網(wǎng)公司的選型策略，其實國內的大部分互聯(lián)網(wǎng)公司所采取的上傳協(xié)議都類似于亞馬遜的S3協(xié)議，因此我們在構建B站的上傳存儲系統(tǒng)時直接使用了亞馬遜的這一協(xié)議，其優(yōu)勢不僅在于亞馬遜的上傳協(xié)議本身就很完善，更在于我們可直接復用亞馬遜S3生態(tài)中的大量組件。無論是在分片上傳、分片大小、并行數(shù)量還是在其他我們能想到的可用于關鍵技術上的優(yōu)化，通過長期的實踐與探索亞馬遜已將其一一實現(xiàn)，不得不說這明顯降低了我們的開發(fā)難度與工作壓力。
S3上傳協(xié)議的整體流程如上圖展示：首先，初始化過程會在服務端為用戶分配一定空間，隨后來自客戶端的數(shù)據(jù)會通過并行上傳發(fā)送至服務端；在這里我們考慮優(yōu)化整個上傳過程，為提升上傳速度與上傳體驗我們使用并行上傳的方式分片傳輸數(shù)據(jù)；在這些數(shù)據(jù)被存儲于服務端時，客戶端會生成與并行傳輸相關的會話，此會話會被服務端讀取從而將所有分片正確合并。
?
S3上傳協(xié)議共需三個請求：用于分配上傳空間的Uploads、用于并行上傳的Put與用于合并完整文件的Post-complete。其中Put用于并行上傳，并行上傳時分片大小可自己定義，分片的順序則通過PartNumber標示；在合并文件時服務端根據(jù)PartNumber所標示的不同順序正確組合所有分片合并生成完整文件并在最后進行校驗從而確保合并完整文件的正確無誤。
?
上圖展示的便是整個上傳系統(tǒng)與后續(xù)工作的簡化架構。首先，客戶端會請求上傳調度，其實如果按照中心存儲架構重構來說上傳調度并非必要流程，這里設計上傳調度的目的是便于后續(xù)優(yōu)化工作的進行：上傳調度可為客戶端分配用于將數(shù)據(jù)上傳至CDN的不同地址與不同上傳模式。緊接著在客戶端請求完成調度并將數(shù)據(jù)上傳至存儲之后，存儲會產生一條可驅動視頻處理流程的消息，從而啟動轉碼、截圖、審核、分發(fā)等一系列圍繞存儲進行的流程。與此同時，存儲會接受所有上傳分片并產生相應日志，這些日志會被傳輸至日志中心并呈現(xiàn)給負責分析的運維人員或作為可優(yōu)化上傳調度過程提升用戶體驗的信息使用。
2.??建立指標
?
擁有上傳架構之后，我們需要建立完善的指標體系。音視頻行業(yè)有與播放相關的首幀、卡頓率等用于表征用戶播放體驗的指標參數(shù)。我們可憑借這些指標反映出的動態(tài)變化規(guī)律對用戶的多方面體驗做出優(yōu)化。對于上傳過程而言，大家比較容易想到的與用戶上傳體驗相關的指標，首先就是分片上傳的瞬時速度——瞬時速度決定數(shù)據(jù)上傳的耗時，耗時越短用戶體驗越優(yōu)秀；但瞬時速度的計算非常復雜，且無法明確幫助我們實現(xiàn)期待的優(yōu)化目標。慢速比也是十分關鍵的指標之一，但慢速比不但不滿足線性相關關系，同樣難以幫助我們實現(xiàn)優(yōu)化目標。瞬時速度與慢速比并不能很好體現(xiàn)用戶上傳體驗的優(yōu)劣，我們希望建立一些能夠幫助我們實現(xiàn)優(yōu)化目標的指標，且計算過程相對簡單，允許我們通過數(shù)據(jù)盡可能詳細量化優(yōu)化所帶來的用戶體驗的變動。經(jīng)過不斷探索我們將全局均速與成功率作為評價用戶上傳體驗的兩項關鍵指標——全局均速的定義是使用一個用戶所上傳文件的體積除以上傳時間得到的一個以兆每秒為單位的物理量，成功率則是用戶完成上傳的次數(shù)除以用戶發(fā)起上傳的次數(shù)，而后將結果乘以100%。通過長時間的實踐，我們可以說此兩項指標能夠客觀準確地反映出用戶上傳體驗的優(yōu)劣程度。
?
數(shù)據(jù)閉環(huán)值得我們在優(yōu)化過程中重點關注。將用戶反饋與上述指標體系中的關鍵數(shù)據(jù)相結合，我們便能得到有助于優(yōu)化整個上傳系統(tǒng)的關鍵參考信息，從而得到調試所需的最佳技巧方案。比如我們需要從多家CDN中選出合適的作為接入服務商，那么就可根據(jù)比較各家方案的全局均速與成功率判斷第三方CDN的上傳質量。這里需要強調的是，有些可以明顯提升傳輸速度的優(yōu)化方案會降低傳輸成功率，這就使得我們在對比時一定要綜合考慮這兩項指標；而像分片體積、并發(fā)數(shù)、重試次數(shù)等對上傳成功率造成影響的參數(shù)，就需要我們通過建立abtest數(shù)據(jù)閉環(huán)納入考量。
除了上述內容，比較不同平臺的上傳質量同樣至關重要。初期B站僅有Web端上傳，使用手機與PC訪問Web端上傳同樣的文件，PC端的成功率明顯高于移動端。我們需要在比較不同平臺上傳質量時盡可能規(guī)避由平臺限制造成的影響因素，從而得到傳輸鏈路本身對用戶上傳體驗的影響。
3.?質量優(yōu)化
3.1 鏈路層面優(yōu)化
?
鏈路層面的優(yōu)化至關重要，其中不可或缺的條件便是CDN。初期我們的方案是接入多家上傳CDN，但多家CDN良莠不齊，對用戶體驗的影響也存在差異；隨后我們通過調研發(fā)現(xiàn)許多大公司會選擇通過建立BGP直連或CDN節(jié)點加速的方式傳輸數(shù)據(jù)，而這兩種方案對邊遠地區(qū)或小規(guī)模運營商的支持并不完善；ab對比上傳指標同樣是鏈路層面優(yōu)化的一項重要參考，但最后我們明確了將選用節(jié)點數(shù)較多的CDN運營商作為數(shù)據(jù)上傳技術支持的思路，CDN公司所提供的節(jié)點數(shù)量直接決定了數(shù)據(jù)上傳的質量。
3.2 客戶端選線VS服務端選線
?
身處不同地區(qū)的用戶如何選擇最佳傳輸路線？客戶端選線與服務端選線哪一個是最佳方案？這些都是值得我們研究探索的命題。服務端優(yōu)化的思路之一是我們可通過在服務端建立數(shù)據(jù)庫并記錄某一地區(qū)用戶的上傳質量為這一地區(qū)分配優(yōu)選CDN，但在實際應用中，相對于隨機分配路線的策略，此方案并未收獲令人滿意的性能與質量提升；通過進一步探索我們發(fā)現(xiàn)，客戶端在上傳前對線路進行探測能夠有助于實現(xiàn)較高傳輸質量。具體思路是在數(shù)據(jù)上傳前先借助小范圍客戶端進行一次簡單的包探測并與預設方案進行比較從而得到最佳優(yōu)化方案。
?
使用電信網(wǎng)絡的用戶易被上下行寬帶不對等的問題所困擾，鑒于此我們與電信運營商進行交涉，通過IP庫檢測電信用戶并為其打開電信上傳限制，通過上述優(yōu)化可使電信用戶的上傳速率提升10倍左右。
3.3 JSSDK優(yōu)化
?
對于JSSDK的優(yōu)化主要是通過將多文件并發(fā)的策略改為文件內分片并發(fā)實現(xiàn)，前者相當于多個文件同時占用一個上行總帶寬，造成的結果是三個文件的上傳均十分緩慢；而后者則可明顯提升文件傳輸效率。
?
支持將數(shù)據(jù)上傳到第三方存儲可以說是我們?yōu)橛脩舫浞挚紤]而設計的一項優(yōu)化，來源于客戶端的數(shù)據(jù)會先被上傳至第三方存儲并通知原站將其從第三方存儲拉取回原站存儲，這樣的好處在于可以讓一些身處距離較遠如海外等不方便直連原站存儲的用戶享受到近距離節(jié)點用戶的上傳體驗，例如將原先海外客戶端與國內直連改成國外客戶端將視頻先上傳至如亞馬遜等第三方海外節(jié)點，而后國內原站存儲再從第三方海外節(jié)點拉取視頻數(shù)據(jù)，用較低成本實現(xiàn)良好傳輸效果。
3.4 跨會話上傳控制
?
通過大數(shù)據(jù)我們發(fā)現(xiàn)周末上傳成功率下降明顯，從用戶行為的角度分析其原因在于周末Up主人均上傳稿件數(shù)量增多，很多用戶會選擇打開兩個甚至多個播放器進行并發(fā)上傳，這對帶寬資源的占據(jù)是顯而易見的。為應對此情況我們使用js的LocalStorage實現(xiàn)鎖，實現(xiàn)了將周末視頻文件的上傳成功率相較于工作日時期提升1%左右的優(yōu)化。
?
2018年我們上線了移動端上傳服務，其中的一項關鍵優(yōu)化在于服務端下發(fā)參數(shù)以便于數(shù)據(jù)驅動優(yōu)化。移動端與Web端最大的區(qū)別在于移動端的發(fā)版代價更大，通過上報網(wǎng)絡環(huán)境與主機型號等得到服務端的下發(fā)參數(shù)，利用數(shù)據(jù)驅動優(yōu)化，從而將發(fā)版代價巨大的移動端場景轉換為與Web瀏覽器類似的一種易于服務端與數(shù)據(jù)驅動優(yōu)化的場景，從而通過調整不同參數(shù)實現(xiàn)移動端的最佳上傳服務。相對于基于無線網(wǎng)或寬帶網(wǎng)絡等環(huán)境與質量較高的Web瀏覽器端，基于移動網(wǎng)絡的手機移動端可能無法提供傳輸所需的高質量網(wǎng)絡環(huán)境，面對這種情況我們會根據(jù)網(wǎng)絡環(huán)境的不同為移動端匹配最合適的節(jié)點，優(yōu)選并發(fā)數(shù)、分片體積、重試次數(shù)與間隔等，確保移動端用戶上傳體驗的一致性。
4.?總結與成果
?
通過重構系統(tǒng)、建立指標體系、優(yōu)化指標與明確達成目標等一系列舉措，我們得以將上傳成功率從最初的的85%提升至94%，同時實現(xiàn)平均速度提升4倍，實現(xiàn)用戶相關投訴0記錄的優(yōu)化成果，與此同時我們是業(yè)界少有的能夠較好支持網(wǎng)頁端并行上傳的視頻平臺。
?
關于未來我們探索的方向，我們希望借助QUIC上傳優(yōu)化移動端的上傳體驗，并為實現(xiàn)動態(tài)切換上傳線路而不斷努力以達成高可用與更佳的體驗優(yōu)化。
點擊【閱讀原文】或掃描圖中二維碼了解更多LiveVideoStackCon 2019 上海 音視頻技術大會 講師信息。
超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生總結
以上是生活随笔為你收集整理的B站Up主上传质量调优实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 2019年低延迟直播技术展望
- 下一篇： QUIC DataChannels的第一