快手關於海量模型資料處理的實踐
一、模型場景介紹
1.即時大模型
*本文資料具有即時性，不代表即時資料。
快手的模型場景主要是即時的大模型。實時主要體現在社交上。每天都有新用戶上傳1500 萬以上的視頻，每天有億級以上的直播活躍用戶，並且上傳數每年都在同比上漲。
大主要體現在流量規模。快手現在的日活達到了3.87 億，有千億級別的日均曝光，百億級別的日均播放，模型量級非常大，還要保證實時。而快手的核心價值是平等普惠，也就是千萬級的用戶同時在線上時，個人化請求時會推薦不同的內容。
總結起來，資料處理的特點是既大，又要即時。
2、推薦業務複雜
一般的推薦業務架構如上圖所示，在視訊池裡（例如有數千萬的影片）會經過固定的四個階段：
- 召回：從幾千萬的影片召回幾萬或幾千的影片。
- 粗排：透過一個粗排漏斗，選出幾千的影片。
- 精排：幾千的影片又會通過精排，篩選top 幾百的影片。
- 重排：進入重排，給模型評分，做模型校驗。
- 回傳：加上一些機制和多樣化操作，最後選出幾十個結果回傳給用戶，整個漏斗要求非常高。
快手的業務類型比較多樣，主要可以分成大型業務和中小型業務。
大型業務的樣本量級很大，像主站建議一天的樣本可能有千億，儲存能達到p 的等級。迭代主要用流式迭代，即在線迭代特徵和模型，速度會非常快。如果選用批次迭代的話，回溯樣本要30 天，需要的資源是流式迭代的幾十倍，快手大場景下的流量分配又比較多，所以傾向於做在線的流式迭代實驗，速度快，消耗資源量相對也少很多。
中小業務，一天的樣本大約在百億級別，存放大概幾十T。選擇串流迭代會需要頻繁上線迭代，而且流量分配也不夠。這種情況下一般盡量選用批式迭代，此時需要大量層級的計算樣本，例如要回溯至少60 天以上，回溯樣本能達到p 等級。因為對於大模型來說，如果資料量不夠，模型訓練不充分，效果就會隨之下降。所以在這種小的業務場景裡，還是傾向批式迭代，回溯更多天的樣本，讓模型達到更穩定的狀態。在這種場景下面，會傾向批次迭代實驗。
3.推薦模型的資料量
這裡是之前在快手發布的一個萬億級別模型文章裡的截圖，快手是個人化模型，所以參數量非常大。從圖中比較來看，OpenAI 的GPT3 參數量是175B，但快手參數量1900B，已經到兆等級了。主要是因為快手選用的是SIM 長序列模型，需要使用者長期的興趣，然後把該序列輸入到模型中。快手有億級用戶，life-long 興趣需10 萬以上序列，再加上千億級的樣本的疊加，因此參數量非常大，能達到1.9 兆。雖然這1.9 兆參數跟OpenAI 的GPT 3 模型的參數型別不一樣，計算量也不太一樣。但從參數量級來看，快手推薦是非常大的。
4.語言模型的演進
推薦模型跟語言模型緊密相關，一般新模型都會在語言模型上去做迭代，成功之後就會引入推薦模型，例如DN、RNN、Transformer。上圖是亞馬遜3 月時發布的圖，主要介紹了語言模型的一些進展。
可以看到，17 年之前主要是RNN 模型，RNN 模型是按次序去順序遍歷資料後訓練，該模型對平行算力要求並不高，但模型收斂比較複雜，因為可能會出現梯度消失的問題。 2017 年出現Transformer 之後，語言模型突破了原有的限制，可以做並發迭代，所以其算力大規模成長。
圖中的樹分為三個部分：（1）紅線部分是encoder-only 技術，最早是Bert 模型；（2）綠線是encoder-decoder 類型，Google 主要選擇這一類型；（3）藍線主要是open API 裡ChatGPT 選用的類型，這一類模型發展得最好，因為它夠簡單，只需要考慮decoder，運算量小，而且模型效果也會很好。
二、大規模模型資料處理
1、背景-實效性
快手對資料時效性要求很高，使用者看到影片後會回饋到快手的log 收集系統，該使用者的行為會即時地拼接推薦日誌（推薦日誌就是推薦服務落下來的特徵），特徵流加上行為流成為樣本流進入後面的特徵處理，然後進入模型訓練。模型訓練完成後即時更新到線上預估，線上預估會根據模型的更新推薦出最符合用戶需求的一些影片。此連結要求延遲必須要在一秒鐘內，需要盡快將使用者行為回饋到模型裡，所以對於大數據處理的時效性要求是非常高的。
2、大數據量處理
快手有千萬級用戶在線，不考慮行為多樣性的情況下，QPS 至少是千萬級的，如果區分到行為的多樣性，這個組合數量就更爆炸了，高峰期大概每秒需要處理30T 左右的狀態。
業界方案主要是採用Flink 串流框架，但如果直接用Flink 引進state join，在並發幾千的情況下會造成大量的慢節點。因為30T 狀態如果1000 並發的話，需要存30G 的狀態，如果1 萬併發也得存3G。 3G 在1 萬並發下的慢節點的機率會非常大。在這種情況下如果出現慢節點，需要幾個小時來恢復，這對於推薦系統肯定是不能忍受的。
所以快手選擇了一個折中方案，把狀態下沉至高效能儲存上，然後採用無狀態hash join 的方式來做一個即時join 的狀態，只要用戶的行為和特徵都到齊，就立即觸發樣本的下發，這樣就可以保證行為能夠及時地回饋到模型。雖然特徵和行為來的順序不一樣，但透過外部的狀態，再加上Flink 串流框架並行的操作，就能實現大規模高效能的join。
3.複雜特徵計算
在上述處理完成之後，是特徵計算場景，主要有兩種計算，標量計算和向量計算。標量計算類似特徵處理，例如要把某些值求和、求平均。在向量計算裡，會對一批樣本同一列進行一個相同的操作，放在GPU 透過cuda 計算。這樣，透過使用GPU 和CPU 協同的方式實現高效能運算，一些標量操作在CPU 上運算，記憶體存取也會在CPU 上進行，然後傳輸到GPU 上去做高效能的GPU 運算。
為了確保演算法迭代的彈性，採用了DSL 抽象。因為SQL 不能完全描述所有的特徵處理場景。例如有一些在時間視窗的操作，如果透過SQL 去做需要寫一些自訂的UDF，這樣很不利於迭代。所以我們的DSL 是用Python 描述的，使用者可以透過Python 直接呼叫下層的高效執行算子。第一步先寫計算層，使用C++ 實作一些高效率的operator，包含cuda 和CPU 相關的運算也都是透過C++ 函式庫去做的。在runtime 下面採用Flink 的分散式框架加上GNI 的方式去呼叫C++ 的這些算子，以達到高效能、高吞吐的處理。
4.推薦場景特點
推薦場景下有兩個特點，一個是批流一體，另一個是潮汐。
批式研究和線上實驗這兩種場景會需要有批流一體，因為在批場景裡研究特徵或研究模型結構完成之後，需要到在線去做上線，因此需要有一個批流一體的統一描述語言加上統一的執行引擎。使用者在批式上調查，會使用DSL、Hadoop 和Spark 把所有的資料計算出來，做模型迭代。模型迭代成功之後做特徵上線，上線到流式通用特徵處理框架上，或是上線到流式特徵框架特化的一個處理框架上。這裡之所以會分出兩個節點，主要是因為有些特徵是所有模型公用的，所以可能在通用的框架下面，這樣只需要計算一次。而在特化的算子下面則是一些模型所特有的特徵，因此分開處理。但這兩個計算引擎和語言描述其實是一樣的。同樣地，這些通用處理的資料需要落盤到批次場景下。批場景下有很多是基於base 的特徵去迭代，會加入它自己的性價特徵，所以在批次場景下面計算的也是Delta。
上線完之後就會到線上服務，這裡會有一個高效能的儲存和運算庫去承接，這一點在後文中還會講到。在串流場景下，注重的是高吞吐、低延遲和高可用。在批場景下，主要關注高吞吐、高可靠。
另外一個特點就是請求潮汐。上圖是請求潮汐的示意圖（並不是快手的真實流量）。從圖中可以看到，有早高峰和晚高峰兩個高峰。在高峰期需要給足在線的算力，在低高峰期則要把冗餘的算力利用起來。
在這種情況下，快手的大數據處理框架以及線上所有的模組需要針對潮汐的特點，去做雲原生架構的一些改造，例如快速恢復、自動伸縮、快速伸縮。快速伸縮主要是因為在自動伸縮的時候並不能保證是高效的，例如一次自動伸縮需要耗一小時或幾個小時之久，那麼在線的請求在這幾個小時之間會有比較大的損失。
另外，還需要把線上服務的資源池和大數據處理的資源池統一起來，這樣所有資源在低高峰期時可以把冗餘算力給批式場景、大模型預訓練場景或大模型批量預估的場景，使資源得以利用。快手現在所有的架構都在向雲端原生架構演進。
三、大規模模型資料存儲
1、儲存特點
大規模資料儲存的第一個特點就是超低延遲，因為儲存節點儲存的都是狀態，有些運算節點需要很多的狀態資訊才能去計算，所以儲存節點大部分時間都是在葉子節點，而且建議的線上實驗有上千個模組，每一個模組只能給十毫秒以內或最多幾十毫秒的超時時間，因此要確保所有儲存節點都是低延遲、高吞吐並且高可用的。
推薦實驗和推薦服務base 之間有一個互相切換的流程。一般並行的實驗數量非常多，實驗完成之後會去切換成一個在線的base，這樣它所承擔的流量就會非常大。例如在訓練服務base 裡會有召回的base、粗排的base和精排的base，各個base 都需要去承擔千萬級的QPS，而且要提供超高的可靠性。所以在線上儲存部分，大量選用的是全記憶體架構。
其次，快手有超大儲存的需求。前文提到，快手大模型有1.9 兆的參數量，如果換成普通八維的float，需要的儲存也要有64T，而且還有一個全用戶的行為序列，有180T 左右的狀態資訊。如果要採用全內存的存儲，將會需要2000 多台機器。而且所有的狀態都需要在30 分鐘內恢復，因為推薦系統如果超過30 分鐘不恢復，會對線上產生非常大的影響，使用者體驗會很差。
針對上述需求，我們的方案主要有以下幾個：
- 特徵score 的進入：特徵score 可以理解為特徵重要性，即將一些重要性比較低，對預估效果影響也微乎其微的特徵不放在在線存儲上。
- LRU 和LFU 的淘汰：因為是在線的模型，需要保證可靠性，即內存需要維持在一個穩定範圍內，不能一直增長。因此我們將最遠更新的優先淘汰，最先訪問的優先保留。
- NVM 新硬體技術：全記憶體架構的資源消耗也是一個非常大的問題。我們引進了NVM 硬體技術。 NVM 是一個持久化存儲，是Intel 新發布的一個硬件，它會在DR 和SSD 之間，有接近於內存的速度，同時有接近於SSD 的存儲空間，既能兼顧存儲也能兼顧性能。
2、儲存方案-NVM Table
儲存方案是NVM Table，分成異質儲存的三層：實體層提供底層儲存的API，包括NVM 儲存和memory 儲存；中間memory pool 封裝統一的管理功能，把NVM 和memory 的模組都管理起來；上層業務透過memory pool 的一個API 去呼叫下層的NVM 和memory，提供統一的查詢邏輯。
在資料結構佈局方面，memory pool 採用的是block 介面抽象。將NVM 和memory 分成若干不同的、可透過全域統一位址來存取的block，這樣就可以實現zero copy 的存取自由化。對於一些頻繁存取的key，會放到mem-key 上。不常訪問的key 會放在到NVM 上。一些索引的key 會頻繁訪問，但查找到key 之後，其value 在最後要返回給上游的時候才會用到，並且量級較大，所以將value 放到持久化的存儲。 Key 查詢比較多，同時也比較小，所以放在內存，這樣就實現了內存和NVM 的零拷貝技術。這裡的哈希表採用了業界領先的無鎖技術，以減少臨界區的競爭，完成高效儲存。
從NVM Table 的一個場景測試資料可以看出，其網路的極限吞吐與JIRA 是相當的。跨網路存取一般是網路達到極限，所以NVM 頻寬可以完全覆蓋網路頻寬，瓶頸主要在網路上，這樣就能保證NVM 既有成本上的效益，也有大儲存和高吞吐的效益。另一方面，恢復時間也下降了120 倍。最開始恢復T 的資料需要兩個小時，採用NVM 之後只需要2分鐘。
3.儲存方案-強一致性
儲存方面，還有強烈一致性的需求，主要是因為在推薦場景裡也有一些廣告和電商的推薦，需要儲存的副本特別多。因為當一些新的短視頻或新物料進來時，下游所有模組會有一個並發分發，需要保證這些視頻在10 秒內到達所有的推薦服務，且所有推薦服務裡的狀態需要保證一致。否則對於模型的效果影響很大。
我們採用了Raft 協議加BT 的模式。 Raft 協定主要負責選組和同步數據，BT 的模式主要是改造BT 同步的模式，例如在幾千上萬台機器規模下的同步，如果同時用主從同步的話，主節點的出口頻寬可能會是從節點的千倍以上，頻寬就會變成瓶頸，下發的狀態就會非常少，高吞吐和資料同步會受到影響。
我們的方案是分散式的平衡樹分發，建構一個平衡二元樹，把所有主從節點進行組織，每個節點只管有限個從節點，從而保證從主節點同步到葉子節點所需的頻寬不變，但是單節點的頻寬限制為小於等於2，這樣在全域下既能做到一次性，也能做到高效地同步，10 秒內即可將所有視訊狀態分發到每個節點。
四、展望
推薦模型的發展跟語言模型是相關的，從DNN 模型到Wide&Deep，到Transformer，再到SIM 長序列及生成式模型，模型成長了許多倍。除了模型的成長，算力成長也會隨影片的成長和使用者的成長，呈現指數級的上升。從統計數據來看，最近兩年推薦模型的算力成長接近10 倍，我們的方案主要是優化工程架構和新的硬體技術。
生成式模型會帶來計算量的爆炸，因為它是一個token-based 的推薦，每次推薦都需要之前所有的token 作為context，在這種情況下產生的效果才會最好。如果沒有token-based，那麼與算力不會呈指數級增長。因此，建議的壓力，將主要來自狀態存儲的大規模提升，因為目前的推薦模型主要是pointwise 的推薦，對於長序列推薦模型算力也是有限的。如果全部採用深層模型推薦，其狀態儲存將再成長10 倍，挑戰會非常大。因此我們需要透過一些新硬件，例如CXL、NVM 以及新推出的Grace 架構，再加上工程上的優化，例如狀態做差分、傳輸計算等等，來應對未來的挑戰。