一、前言

短視頻應(yīng)用QuickTok的需求與技術(shù)架構(gòu)詳解

視頻，尤其是短視頻，以其時(shí)長在15分鐘以內(nèi)的精煉形式，成為了移動(dòng)智能終端上拍攝、美化編輯、加特效并實(shí)時(shí)分享的新型視頻形式。短視頻憑借時(shí)間短、信息承載量高等特點(diǎn)，完美契合了當(dāng)下網(wǎng)民的手機(jī)使用習(xí)慣，其用戶流量更是孕育了巨大的商業(yè)機(jī)遇。

在此背景下，我們著手開發(fā)一個(gè)面向全球20億用戶的短視頻應(yīng)用——QuickTok。

相較于其他媒體文件，視頻文件體積較大，這意味著存儲(chǔ)短視頻需要更為龐大的存儲(chǔ)空間，播放時(shí)也需要更高的網(wǎng)絡(luò)帶寬。因此，QuickTok面臨的主要技術(shù)挑戰(zhàn)在于：如何應(yīng)對高并發(fā)用戶訪問時(shí)的網(wǎng)絡(luò)帶寬壓力，以及如何高效存儲(chǔ)海量的短視頻文件。接下來，讓我們深入探討QuickTok的需求與技術(shù)架構(gòu)。

1、需求分析

QuickTok的核心功能需求簡潔明了：用戶能夠輕松上傳、搜索并觀看視頻。在此基礎(chǔ)上，我們將深入剖析其非功能需求的重要性。

QuickTok預(yù)計(jì)將迎來20億用戶的龐大群體，其中日活躍用戶將達(dá)到約10億。若每位用戶日均瀏覽10個(gè)短視頻，那么短視頻的日播放量將驚人地達(dá)到100億次：

10億 × 10 = 100億

進(jìn)一步推算，平均每秒的播放查詢量（QPS）約為11萬次：

100億 ÷ （24小時(shí) × 60分鐘 × 60秒） ≈ 11萬次/秒

這意味著每秒有11萬用戶點(diǎn)擊視頻。假設(shè)用戶平均觀看時(shí)長為5分鐘，那么同時(shí)在線觀看的視頻數(shù)量將高達(dá)3000萬個(gè)：

11萬次/秒 × 5分鐘 × 60秒 = 3000萬

再考慮每個(gè)短視頻平均被播放200次，為了支撐如此龐大的播放量，每秒需上傳的視頻數(shù)量達(dá)到550個(gè)：

11萬次/秒 ÷ 200 = 550個(gè)/秒

鑒于每個(gè)短視頻的平均大小為100MB，每秒上傳至服務(wù)器的數(shù)據(jù)量即為55GB：

100MB × 550 = 55GB

雖然視頻并非在瞬間全部上傳至服務(wù)器，但此估算方法依然有效。

對于每年新增的視頻內(nèi)容，所需的存儲(chǔ)空間高達(dá)1700PB：

55GB × 24小時(shí) × 60分鐘 × 60秒 × 365天 = 1700PB

然而，為了確保視頻數(shù)據(jù)的高度可用性和防止數(shù)據(jù)丟失，QuickTok采用雙副本備份存儲(chǔ)策略，即每個(gè)視頻文件存儲(chǔ)三份。因此，總存儲(chǔ)空間需求躍升至5200PB：

1700PB × 3 = 5200PB

此外，播放視頻所需的總帶寬也極為可觀，達(dá)到88Tb：

11萬次 × 100MB × 8bit = 88Tb

綜上所述，我們需要構(gòu)建的短視頻應(yīng)用需具備每秒上傳550個(gè)視頻文件、處理11萬次播放請求、新增165GB（55GB×3）存儲(chǔ)空間以及支持88Tb總帶寬的高并發(fā)處理能力。這一系統(tǒng)不僅要求高性能，能夠迅速響應(yīng)用戶的上傳和播放需求，還必須確保高可用性，為全球用戶提供7×24小時(shí)的穩(wěn)定服務(wù)。

2、概要設(shè)計(jì)

QuickTok的核心部署模型如圖所示：

圖片

用戶上傳視頻時(shí)，請求會(huì)經(jīng)過負(fù)載均衡服務(wù)器和網(wǎng)關(guān)服務(wù)器，最終到達(dá)視頻上傳微服務(wù)。該服務(wù)需完成兩項(xiàng)任務(wù)：一是將上傳文件數(shù)據(jù)流寫入視頻文件暫存服務(wù)器；二是將用戶名、上傳時(shí)間、視頻時(shí)長、視頻標(biāo)題等元數(shù)據(jù)寫入分布式MySQL數(shù)據(jù)庫。

視頻上傳完成后，上傳微服務(wù)會(huì)生成一個(gè)完成消息，并將其寫入消息隊(duì)列服務(wù)器。隨后，視頻內(nèi)容處理器會(huì)消費(fèi)此消息，并從暫存服務(wù)器獲取視頻數(shù)據(jù)進(jìn)行處理。

視頻內(nèi)容處理器是一個(gè)由責(zé)任鏈模式構(gòu)建的管道，視頻將在此管道中依次進(jìn)行內(nèi)容合規(guī)性審查、內(nèi)容重復(fù)性及質(zhì)量審查、內(nèi)容標(biāo)簽生成、視頻縮略圖生成以及統(tǒng)一視頻轉(zhuǎn)碼處理等操作。

圖片

合規(guī)且非重復(fù)的視頻經(jīng)過統(tǒng)一轉(zhuǎn)碼后，將被寫入分布式文件存儲(chǔ)和CDN。至此，視頻上傳處理流程完成，具體時(shí)序圖如下所示：

圖片

以上是對視頻上傳環(huán)節(jié)的設(shè)計(jì)概述。接下來，我們將探討視頻搜索及播放部分的設(shè)計(jì)，即核心部署模型圖中標(biāo)紅的部分：

圖片

視頻搜索引擎會(huì)根據(jù)用戶提交的視頻標(biāo)題、上傳用戶等元數(shù)據(jù)，以及視頻內(nèi)容處理器生成的內(nèi)容標(biāo)簽構(gòu)建倒排索引。用戶搜索時(shí)，系統(tǒng)會(huì)根據(jù)倒排索引檢索符合條件的視頻，并返回結(jié)果列表。結(jié)果列表在App端呈現(xiàn)時(shí)，會(huì)展示視頻縮略圖，以便用戶初步了解視頻內(nèi)容。

用戶點(diǎn)擊縮略圖后，App開始播放視頻。無需下載整個(gè)視頻文件，App以流的方式邊下載邊播放，確保用戶獲得流暢的觀看體驗(yàn)。QuickTok采用MPEG-DASH流媒體傳輸協(xié)議進(jìn)行視頻流傳輸，該協(xié)議具有自適應(yīng)能力且支持HTTP，完美滿足QuickTok的視頻播放需求。

3、詳細(xì)設(shè)計(jì)

為解決QuickTok面臨的兩大挑戰(zhàn)：如何存儲(chǔ)海量視頻文件以及如何解決高并發(fā)視頻播放導(dǎo)致的帶寬壓力，我們的詳細(xì)設(shè)計(jì)將聚焦于視頻存儲(chǔ)系統(tǒng)、性能優(yōu)化與CDN的使用。

此外，“如何生成更吸引用戶的縮略圖”也是提升短視頻應(yīng)用用戶體驗(yàn)的關(guān)鍵問題，因此詳細(xì)設(shè)計(jì)還將涵蓋縮略圖的生成與推薦。

（1）視頻存儲(chǔ)系統(tǒng)設(shè)計(jì)

由需求分析可知，QuickTok每年需新增5200PB的存儲(chǔ)。面對如此海量的存儲(chǔ)需求，“如何存儲(chǔ)視頻文件”成為QuickTok設(shè)計(jì)的重要挑戰(zhàn)之一。雖然我們可以嘗試使用與前述網(wǎng)盤相似的存儲(chǔ)技術(shù)方案，將視頻文件拆分成若干block并使用對象存儲(chǔ)服務(wù)進(jìn)行存儲(chǔ)，但QuickTok最終選擇了另一種方案：使用Hadoop分布式文件系統(tǒng)HDFS進(jìn)行存儲(chǔ)。

HDFS非常適合大文件存儲(chǔ)的一次寫入多次讀取場景，完美契合視頻一次上傳多次播放的需求。同時(shí)，HDFS還能自動(dòng)進(jìn)行數(shù)據(jù)備份（缺省配置下每個(gè)文件存儲(chǔ)三份），滿足我們對數(shù)據(jù)存儲(chǔ)高可用性的要求。

由于HDFS適合存儲(chǔ)大文件，大文件能減少磁盤碎片并有利于存儲(chǔ)空間的利用，同時(shí)減輕HDFS NameNode的訪問壓力，因此我們需要將若干個(gè)視頻文件合并成一個(gè)HDFS文件進(jìn)行存儲(chǔ)，并將存儲(chǔ)細(xì)節(jié)記錄到HBase中。

圖片

舉例來說，當(dāng)用戶上傳一個(gè)視頻文件時(shí)，系統(tǒng)會(huì)自動(dòng)生成一個(gè)視頻ID（假設(shè)為123）。視頻內(nèi)容處理器對視頻進(jìn)行處理后，會(huì)調(diào)用視頻文件存儲(chǔ)服務(wù)進(jìn)行存儲(chǔ)。存儲(chǔ)服務(wù)首先通過HDFS創(chuàng)建一個(gè)文件（如/data/videos/clust0/p0/000000001），然后將視頻數(shù)據(jù)順序?qū)懭際DFS。寫入完成后，存儲(chǔ)服務(wù)會(huì)獲取HDFS文件的全路徑名、視頻在HDFS中的偏移量以及文件大小等信息，并將這些信息記錄到HBase中。主鍵為視頻ID（123），value為包含路徑、偏移量和大小等信息的字符串。

若另一個(gè)用戶上傳的視頻ID為456，文件大小為100,000,000B，且緊隨上一個(gè)視頻文件保存在同一個(gè)HDFS文件中，則HBase中會(huì)記錄主鍵為456的條目，value為包含該視頻在HDFS中的路徑、偏移量和大小等信息的字符串。

當(dāng)用戶播放視頻456時(shí)，播放微服務(wù)會(huì)根據(jù)視頻ID在HBase中查找對應(yīng)條目，獲取HDFS文件路徑及偏移量等信息，然后從HDFS文件中指定位置開始讀取數(shù)據(jù)，即可獲取完整的視頻文件數(shù)據(jù)。

（2）性能優(yōu)化與CDN設(shè)計(jì)

如前所述，QuickTok所需的總帶寬高達(dá)88Tb，這是一個(gè)極為龐大的數(shù)字。若僅憑QuickTok自己的數(shù)據(jù)中心來承擔(dān)這一帶寬壓力，將面臨巨大的技術(shù)挑戰(zhàn)和成本支出。因此，我們通過CDN將用戶的網(wǎng)絡(luò)通信請求就近返回，以緩解數(shù)據(jù)中心的帶寬壓力。

當(dāng)用戶請求獲取視頻數(shù)據(jù)流時(shí)，App會(huì)優(yōu)先檢查附近的CDN中是否有所需視頻數(shù)據(jù)。若有，則直接從CDN加載數(shù)據(jù)；若無，才會(huì)從QuickTok數(shù)據(jù)中心獲取視頻數(shù)據(jù)流。

若用戶的大部分請求都能通過CDN得到滿足，則一方面能極大加快用戶請求的響應(yīng)速度，另一方面又能有效減輕數(shù)據(jù)中心的網(wǎng)絡(luò)和硬盤負(fù)載壓力，進(jìn)一步提升應(yīng)用的整體性能。

通常的CDN設(shè)計(jì)是在CDN中沒有用戶請求的數(shù)據(jù)時(shí)進(jìn)行回源操作，即由CDN請求數(shù)據(jù)中心返回所需數(shù)據(jù)并緩存在CDN本地。但QuickTok考慮到了短視頻的特點(diǎn)：大V、網(wǎng)紅等發(fā)布的短視頻會(huì)被更快速、更廣泛地播放。因此，針對粉絲量超過10萬的用戶，QuickTok系統(tǒng)采用主動(dòng)推送至CDN的方法以提高CDN命中率并優(yōu)化用戶體驗(yàn)。

圖片

從圖中可以看出，視頻內(nèi)容處理器在完成視頻處理后，一方面會(huì)將視頻存儲(chǔ)到視頻存儲(chǔ)系統(tǒng)中，另一方面會(huì)調(diào)用CDN推送服務(wù)。CDN推送服務(wù)會(huì)調(diào)用大數(shù)據(jù)平臺獲取視頻上傳者的活躍粉絲數(shù)、粉絲分布區(qū)域等數(shù)據(jù)。若用戶粉絲量超過10萬，則CDN推送服務(wù)會(huì)根據(jù)其粉絲活躍區(qū)域?qū)⒁曨l推送到對應(yīng)區(qū)域的CDN服務(wù)器上。

鑒于短視頻的完播率通常不足30%，QuickTok無需將完整視頻推送到CDN。相反，我們會(huì)根據(jù)視頻發(fā)布者的歷史播放記錄計(jì)算其完播率和播放期望進(jìn)度，然后將短視頻切分成若干chunk，并將部分chunk推送到CDN即可。

業(yè)界普遍認(rèn)為，視頻應(yīng)用CDN處理的帶寬占總帶寬的95%以上。這意味著通過合理使用CDN，QuickTok數(shù)據(jù)中心需要處理的帶寬壓力將降至不到4Tb。

（3）縮略圖生成與推薦設(shè)計(jì)

用戶可以在App主頁、搜索結(jié)果頁、視頻推薦頁等頁面看到視頻列表，每個(gè)視頻都配備有縮略圖。用戶點(diǎn)擊縮略圖即可開始播放視頻。

縮略圖通常由視頻的某一幀畫面縮略而成。事實(shí)上，縮略圖的選擇會(huì)極大地影響用戶點(diǎn)擊和播放視頻的意愿。一個(gè)10分鐘的視頻大約包含3萬幀畫面，那么選擇哪一幀畫面才能最大化用戶點(diǎn)擊視頻的可能性呢？此外，針對不同用戶分類是否選擇不同的縮略圖會(huì)產(chǎn)生更高的點(diǎn)擊率呢？

為了解答這些問題，我們需要借助大數(shù)據(jù)平臺的機(jī)器學(xué)習(xí)引擎來完成縮略圖的生成和推薦。

圖片

縮略圖的生成和推薦可以分為兩個(gè)具體過程：實(shí)時(shí)在線的縮略圖推薦過程a和利用離線機(jī)器學(xué)習(xí)生成優(yōu)質(zhì)縮略圖的過程b。

在過程a中，用戶通過搜索引擎搜索視頻后，搜索引擎會(huì)生成搜索結(jié)果視頻列表，并根據(jù)視頻ID從縮略圖存儲(chǔ)中獲取對應(yīng)的縮略圖。然而，一個(gè)視頻可能對應(yīng)多個(gè)縮略圖。為了顯示最吸引當(dāng)前用戶的那個(gè)縮略圖，搜索引擎需要調(diào)用QuickTok大數(shù)據(jù)平臺的縮略圖推薦引擎進(jìn)行推薦。推薦引擎會(huì)獲取當(dāng)前用戶的偏好特征標(biāo)簽以及視頻對應(yīng)的多個(gè)

在過程a中，用戶借助搜索引擎尋找視頻內(nèi)容。當(dāng)搜索引擎呈現(xiàn)出搜索結(jié)果視頻列表后，它會(huì)根據(jù)視頻ID，從縮略圖存儲(chǔ)系統(tǒng)中精準(zhǔn)地獲取對應(yīng)的縮略圖。

然而，值得注意的是，一個(gè)視頻往往與多個(gè)縮略圖相關(guān)聯(lián)。為了展示最能吸引當(dāng)前用戶的縮略圖，搜索引擎巧妙地調(diào)用了QuickTok大數(shù)據(jù)平臺中的縮略圖推薦引擎。這一推薦引擎具備強(qiáng)大的功能，它能捕獲當(dāng)前用戶的偏好特征標(biāo)簽，同時(shí)掌握視頻對應(yīng)的多個(gè)縮略圖的特征。借助已經(jīng)通過XGboost算法精心訓(xùn)練的模型，推薦引擎能夠精準(zhǔn)地將用戶特征標(biāo)簽與縮略圖特征進(jìn)行匹配，從而挑選出最可能被當(dāng)前用戶點(diǎn)擊的縮略圖ID。隨后，搜索引擎依據(jù)這個(gè)ID，將相應(yīng)的縮略圖巧妙地融入搜索結(jié)果頁面，呈現(xiàn)給用戶。

當(dāng)用戶瀏覽搜索結(jié)果列表，并點(diǎn)擊某些縮略圖進(jìn)行播放時(shí)，App應(yīng)用會(huì)實(shí)時(shí)地將用戶的瀏覽與點(diǎn)擊數(shù)據(jù)反饋給QuickTok大數(shù)據(jù)平臺，這標(biāo)志著過程b——利用機(jī)器學(xué)習(xí)生成優(yōu)質(zhì)縮略圖的開始。

機(jī)器學(xué)習(xí)系統(tǒng)如饑似渴地吸收著海量用戶的瀏覽和點(diǎn)擊數(shù)據(jù)，同時(shí)，它也細(xì)致地捕捉著每個(gè)縮略圖的特征。一方面，通過不斷學(xué)習(xí)，機(jī)器能夠洞察出哪些特征的縮略圖更容易贏得用戶的點(diǎn)擊，進(jìn)而構(gòu)建出一個(gè)優(yōu)質(zhì)縮略圖特征標(biāo)簽庫；另一方面，機(jī)器還能精準(zhǔn)地捕捉到每個(gè)用戶獨(dú)特的圖像偏好特征標(biāo)簽，為之前的推薦引擎提供有力的支持。

有了機(jī)器學(xué)習(xí)系統(tǒng)的強(qiáng)大助力，視頻內(nèi)容處理器便能游刃有余地運(yùn)用優(yōu)質(zhì)特征標(biāo)簽庫來處理上傳的視頻內(nèi)容。它精準(zhǔn)地抽取符合優(yōu)質(zhì)特征的幀，進(jìn)而生成引人入勝的縮略圖。

a、b兩個(gè)過程相輔相成，不斷循環(huán)迭代，使得優(yōu)質(zhì)特征標(biāo)簽庫得以持續(xù)優(yōu)化，縮略圖也愈發(fā)貼合用戶的喜好。

那么，在最初缺乏特征庫的情況下，我們又該如何應(yīng)對呢？此時(shí)，視頻內(nèi)容處理器會(huì)采取一種巧妙的隨機(jī)策略，抽取一些幀作為縮略圖，以此實(shí)現(xiàn)冷啟動(dòng)。隨后，機(jī)器學(xué)習(xí)系統(tǒng)會(huì)從這些隨機(jī)抽取的縮略圖中汲取知識，從而開啟循環(huán)優(yōu)化的旅程。

4、總結(jié)

在縮略圖生成的環(huán)節(jié)，我們?nèi)谌肓舜髷?shù)據(jù)與機(jī)器學(xué)習(xí)的先進(jìn)技術(shù)。對于初次接觸的朋友來說，這或許會(huì)帶來一定的挑戰(zhàn)。但如今，人工智能與機(jī)器學(xué)習(xí)已成為眾多頗具規(guī)模的互聯(lián)網(wǎng)系統(tǒng)中不可或缺的一部分。作為整個(gè)系統(tǒng)的規(guī)劃者與技術(shù)領(lǐng)航者，架構(gòu)師或許無法深入到算法的每一個(gè)細(xì)微之處進(jìn)行優(yōu)化，但對于算法在整體架構(gòu)中的核心作用、相關(guān)數(shù)據(jù)的處理流程與傳輸機(jī)制，他們必須了如指掌。只有這樣，才能設(shè)計(jì)出真正貼合業(yè)務(wù)需求、高效穩(wěn)健的架構(gòu)方案。