一、前言

短視頻應用QuickTok的需求與技術架構詳解

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

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

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

1、需求分析

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

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

10億 × 10 = 100億

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

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

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

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

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

11萬次/秒 ÷ 200 = 550個/秒

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

100MB × 550 = 55GB

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

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

55GB × 24小時 × 60分鐘 × 60秒 × 365天 = 1700PB

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

1700PB × 3 = 5200PB

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

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

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

2、概要設計

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

圖片

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

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

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

圖片

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

圖片

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

圖片

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

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

3、詳細設計

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

此外，“如何生成更吸引用戶的縮略圖”也是提升短視頻應用用戶體驗的關鍵問題，因此詳細設計還將涵蓋縮略圖的生成與推薦。

（1）視頻存儲系統(tǒng)設計

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

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

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

圖片

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

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

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

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

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

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

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

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

圖片

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

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

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

（3）縮略圖生成與推薦設計

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

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

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

圖片

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

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

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

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

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

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

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

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

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

4、總結

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