一、前言

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

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

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

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

1、需求分析

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

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

10億 × 10 = 100億

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

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

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

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

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

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

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

100MB × 550 = 55GB

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

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

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

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

1700PB × 3 = 5200PB

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

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

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

2、概要設計

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

圖片

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

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

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

圖片

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

圖片

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

圖片

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

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

3、詳細設計

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

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

（1）視頻存儲系統設計

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

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

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

圖片

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

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

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

（2）性能優化與CDN設計

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

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

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

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

圖片

從圖中可以看出，視頻內容處理器在完成視頻處理后，一方面會將視頻存儲到視頻存儲系統中，另一方面會調用CDN推送服務。CDN推送服務會調用大數據平臺獲取視頻上傳者的活躍粉絲數、粉絲分布區域等數據。若用戶粉絲量超過10萬，則CDN推送服務會根據其粉絲活躍區域將視頻推送到對應區域的CDN服務器上。

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

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

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

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

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

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

圖片

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

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

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

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

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

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

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

a、b兩個過程相輔相成，不斷循環迭代，使得優質特征標簽庫得以持續優化，縮略圖也愈發貼合用戶的喜好。

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

4、總結

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