導語 | 看點信息流每天爲億級用戶提供海量實時推薦服務，除了大併發/低延遲/高性能等傳統架構挑戰以外，還有哪些推薦系統特有的架構挑戰難題，又是如何解決的？本文是對騰訊看點獨立端推薦研發中心總監——彭默在雲＋社區沙龍online的分享整理，希望與大家一同交流。
一、看點信息流
在 QQ 瀏覽器的主頁可以看到騰訊看點的信息流，信息流有三種形態：小視頻、短視頻、圖文，屬於業界信息流最主要的形態。目前瀏覽器用戶破億，點擊曝光等相關流水每日有百億左右，機器數接近萬級。
二、看點信息流基本架構和挑戰
信息流已經發展很多年了，架構層面都是大同小異。一個信息流系統分爲最底部的數據層，包括了倒排/特徵/用戶模型；數據層上面是召回，召回有隱式召回、顯式召回等。
顯式召回會根據興趣點、主題運行，隱式召回是根據相似度召回，也有基於圖像的召回，如 UCF、ICF 和 RNN 的召回。召回的品類非常豐富，它們構成了整個召回層。
召回數據非常多，在數量較多的情況下需要粗排。粗篩注重性價比，召回十萬的量級需要進行篩選再傳遞到精排，再進行篩選。精排特徵更豐富、算法模型更復雜。
最上面是展控，拿到數據以後要進行多樣性處理以及人工干預策略，再返回最後的十幾條結果給用戶。
另外一條數據流就是，用戶的點擊和曝光數據流上傳到後臺，計算出物品特徵，刻畫用戶畫像。
從架構層面看，做什麼事情對推薦系統效果有提升呢？首先是特徵系統的實時性。因爲推薦系統在選擇時，是基於內容之間進行 PK，PK 非常重要的一點是內容的特徵實時生成，就像一個人的代謝越快就越健康。
比如，一條內容的 CTR 一分鐘之內就得到反饋，和一個小時之後才反饋有着極大差別，這是對實時性的挑戰。
再舉一個用戶模型例子，在信息流中進行瀏覽，不點擊與亞馬遜有關的文章，這一次不點擊的行爲在下一次刷新就可以反饋出來，這是對用戶模型的要求，是大型信息流的標配。
內容服務和索引服務指在網上出現突發事件，新文章進入平臺時，把內容入庫。這裏有一系列的流程，比如人工審覈、NLP 打分、排重等等處理後，進入倒排能夠被召回，進而線上進行曝光，這就是內容入庫的實時性。
關於計算力，看點信息流的內容池是千萬級別的，現在召回層能夠做到十萬級，平臺能把召回做到萬級、精排做到千級，擴大召回計算量也可以提升系統的效果。
計算力首先是大家都通用的辦法，那怎麼樣去並行計算？十萬條的結果可以拆成十個一萬條進行運算，但需要想一個問題，是不是並行度越高越好？其實不是的，要注意大扇出的問題。
傳統後臺的優化要求，是看代碼、架構上如何進行優化，也就是性能優化。而另一塊容易被忽略的，是如何做用戶內容曝光過濾，這個功能看似簡單，實行起來卻容易碰到不少問題，下文也會詳細的介紹。
怎麼樣提升開發效率？這個概念比較泛，首先有兩點，一是算法跟架構如何分離，算法只負責訓練模型、設計算法、設計特徵，代碼由架構來寫，現在業界沒有團隊可以做得到。
推薦系統召回有一百多條線路的召回，有這麼多人負責這麼多召回嗎？這也是不可能完成的事情，一百個召回如何提高開發效率也是重點需要解決的問題。
三、特徵系統
對於推薦系統，特徵越多算法效果越好，比如 CTR 包括全局 CTR、策略 CTR 等，分有有很多的維度。
其次是特徵系統的線上挑戰非常大，以我們系統爲例，每秒鐘的峯值達到千億個特徵，換算成流量每秒能達到 TB 級。特徵實時生成，特徵 CTR 在用戶點擊曝光後可以很快反饋到線上物品特徵中，做到高併發、高吞吐情況下秒級返回。
這裏還牽扯到命中率，特徵系統設計的方案較多是用多級緩存、文件行同步的。而我們方案比較特別，各個服務在使用特徵時，通過 API、lib 庫的方式調用，只需要查就可以了，特徵數據已經通過後端的特徵計算好，push 到各個機器上面。
另外一個問題就是，這樣做對內存的要求特別高。我們有着千萬級內容，單機存不下全部內容的特徵，所以需要做優化。
因爲對物品的計算是分片式，所以特徵也是可以做到分片式的，這樣單機對內存的消耗就可以控制；第二是這樣做可以減少很多的跨網絡調用，每秒 TB 級的傳輸，換成本地查就可以規避掉。
要保證低時延、更新快、命中率高，其實就看各家物品情況取折中方案，怎麼樣達到一個合理的平衡。
四、用戶模型
用戶點什麼、不點什麼，下一刷要反饋出來，怎麼做到準和快？
用戶畫像有三個窗口，一是 T+1 的窗口，今天以前的行爲，二是當天的行爲，最近點了兩百條又是一個窗口，所以需要完整的窗口描述用戶的行爲。
二是打分運算，用模型進行打分，很多團隊是通過人工經驗進行擬合的。
三是要考慮用戶換機，換了一個手機後用戶畫像如何遷移過去，也要考慮外部的畫像，比如類似 BAT 公司不止一個產品，其他的產品用戶畫像也可以拿來用，這是畫像系統需要考慮的一個地方。
具有挑戰的地方首先是長期畫像 T+1 的處理。我們每天需要處理百億級的流水，處理對時間上什麼要求呢？第二天零點開始到第二天的五、六點這個區間，用戶訪問逐步上來了，留給我們時間是 4 到 5 個小時，假如機器夠多就能很快處理完，一般處理分幾個步驟：
首先是對數據進行預處理，進行不同特徵的計算，最關鍵是要把畫像 Base 導入一個存儲中去，然後交給業務流程處理。
二是機器夠不夠多，機器多的話可以直接並行計算，速度很快。而最重要的是一些壓縮的應用、業務邏輯角度而言如何進行剪枝，有些用戶興趣點非常多，是不是所有都要，這裏需要考慮性價比。
把時間縮短兩倍，基本上就可以滿足 12 點到 4 點的要求了。畫像處理後進行生成是用 LR 模型，用戶上一刷的點擊反饋得非常快，還會外部流水進行融入，三是實時進行的打分，這是線上的流程。
五、online learning
線上樣本如何拼接，模型如何訓練和分發？
第一是騰訊內部有個分佈式學習框架叫無量，我們團隊做的工作是將樣本拼接進行優化，最早是通過 hive 小時級拼接，後來通過實時進行拼接，落樣本的時候需要進行時間窗的等待。
爲什麼要這樣做？因爲用戶不一定實時點，樣本上報之後會成爲負樣本，而用戶點擊後上傳會變成正樣本。時間窗取多少要具體分析，控制在半小時以內，有些產品用戶點擊得比較快可以取快一些，這是自己設置的過程。
第二是模型更新，可以實現增量更新的，最早也定爲全量更新，後來改成分鐘級的定時增量+小時級全量更新，這裏面模型是怎麼發佈到機器上去的？騰訊內部有個容達系統，專門解決文件發佈問題。
索引服務 - 高性能 內容入庫實時生效 滿足多種推薦業務需求
我們在最早做推薦系統的時候也調研過索引，因爲它是整個系統裏的最底層組件，原因如下：
第一，一個用戶有很多興趣點，兩三百個興趣點很正常，併發量每天會有千億次的查詢，它的速度要非常快。
第二，突然插入內容時，如何快速的在線上生效。之前也跟 ES 組件做對比 ，首先是基於索引長度 ，索引拉鍊非常長，主題的拉鍊也非常長，需要有能力支持長鏈。
第三，需要能支持曝光過濾。因爲用戶的曝光過濾每層都不能少，如果在最後一層十幾條一起做，會讓很多已經曝光的內容佔了坑，導致整個系統效果變差。所以從最下面的索引層就要開始做曝光歷史過濾，這個跟業務耦合比較緊密，是不可避免要做的。
第四，拉鍊長，必然要做截斷，這就牽扯到排序的問題，是其他組件無法支持的。
內容的時效性很重要，內容改變之後線上必然需要多個索引去做多個 AB Test，比如時效性的需求要上線，如何去做自動化的 Test 是比較難的。
我們從自研索引處理，設計上並不複雜，通過 hash 後面掛鏈表的形式進行處理。考慮到整個物品數量是千萬級，基本單機可以扛下。方法是單機多部署，這樣的話，線上性能表現也比較好，非常穩定一直沒有線上事故。
六、高並行大扇出 - 召回條數擴大的
如何擴大單位條數，基本上大家都會把召回數目進行分片處理，把它分發到不同的進程或者線程處理。
此時關鍵的地方在於要考慮扇出的問題，併發化程度是否越高越好？不一定，也要考慮整體耗時和最慢響應包、分片和集羣的數，並行數越高損失概率越大。
關於大量服務做的數據對比，如上圖所示。
七、性能優化 - 減少50%的耗時
性能優化方面，整體性能優化是線上累積時減少了將近 50% 的耗時，目前推薦後端耗時要在 500 毫秒以下，如果不做優化，會飆升到一秒，這樣的系統基本處於不可用的狀態。
歸納首先是架構層面儘量用分佈式並行，儘量做並行計算；二是很多計算可以統一起來打分；三是很多在線計算是可以改進的，每次上來之後用戶特徵不一樣，計算的話可以用近線計算，相關特徵不會有變化是它的優化點。
後臺架構的功能是 cache 如何提升系統性能，如何緩存一些打分結果，精排結果是不是可以進行緩存等等。
機房部署方面，我們分四地進行異地部署，每地之間、機房之間的延時較高，如何推動運維把機房儘量部署到一個交換機上，這些都是需要不斷優化的。
而系統公用組件後面許多無謂的開銷，需要把整個調用鏈縮短。系統裏有很多全量的計算，一些很明顯的問題、UCF，後面是用了計算方法從全量計算變成 top K 計算，可以極大的提升系統性能。
關於代碼級的優化，GCC 一個新版本的升級，大部分是因爲內層的優化、C++ 新的特性應用、數據結構的優化。而如何減少日誌的無效 IO，協議裏面訓練化和反訓練化的開銷如何減少，推薦鏈路非常長，協議也存在這樣問題。
怎樣優化代碼邏輯？舉個例子，在展控層特別多的邏輯情況下，算法同學不一定可以把算法代碼寫好，最近拿到的一百毫秒優化就是架構同學做的，重構代碼後耗時的確下降了。
這裏要保證無 diff，如果打分值被改變了，這裏引入了一些 Bug，影響了推薦系統的效果，所以我們的代碼都要求做無 diff 測試。
八、用戶曝光內容過濾
做用戶過濾基本都會採用布隆過濾器，一是信息流容忍誤殺，概率比較小用戶沒什麼感知；二是基於 hash 可以省內存，速度快，用戶歷史過濾變成一個庫，全鏈路都可以過濾；三是根據用戶的刷新速度動態調整過濾塊的大小，不能專門給用戶一個塊，但塊大小等級分佈還可以根據動態變化，動態變化更新可以更省內存。
分佈式跨地域用戶曝光歷史線上有什麼問題呢？用戶歷史過濾的場景是：用戶上一刷曝光十條，下一刷把十條過濾掉，上一刷和下一刷時間間隔短，我們的用戶歷史部署在騰訊的 KV 組件中，數據有變化的要先寫到主再同步到備。
所以到了晚上流量特別高的時候，機房之間延遲較大，用戶兩刷間隔短的情況就會出現重複，所以我們會本地就存一倆份解決。
但是推薦系統多地容災部署，用戶有一定概率切換到異地，因爲是考慮容災做的，所以要考慮用戶不同機房之間遷移的情況。
通過一致性的 hash+版本號機制保證同步過濾數據一致，通過這樣的設計重複率降低了一個數量級，基本上解決了高峯期重複的問題。
推薦系統裏有一個特點，上文講的曝光用戶是基於後臺曝光，真實的曝光很多內容是後臺曝光了，但用戶沒有看到的。
可能沒有看到過的內容反而是質量非常高、打分非常高的內容，如果有辦法把這些內容撈回來，重新召回推薦，這肯定對系統提升有幫助，我們也通過真實的曝光修正後臺曝光，對點擊效果的提升也很大。
提升召回開發率
關於開發效率的提升，算法跟架構的分離目前來看還不是特別理想的狀態，線上有特別多的召回，一百多路召回不可能做到每個人都做專門的召回，還要考慮開發效率問題。
於是我們設計了一個默認的召回打分模型，它有幾個特點：以前召回的不要自己打分了，全部由 PE 完成，PE 進行召回初篩，物理的離線計算對物品出差結果再做精細化的計算精度更高，對計算結果拆成兩個做，把整個計算流程分佈式並行計算，能夠提升計算量，15 毫秒就可以完成十萬量級的文檔預測，效果提升也比較明顯。
Q&A
Q：用戶曝光歷史過濾具體是怎麼做的？
A：原理是布隆過濾器，一般而言是做信息流的標配的方案。布隆過濾器線上如何用，第一點如何設計過濾器更加省內存，二是分佈式場景，考慮過濾器的內容如何同步，三是真實曝光修正後臺曝光，這樣可以提升業務效果
Q：bloomfilter是redis保存的嗎？
A：對。
Q：看點用戶訪問是規律的嗎？
A：是規律的，會有早高峯和晚高峯，早高峯是 9 點，晚上是 8~10 點。
Q：看點用戶的併發訪問是規律的麼，如何處理資源彈性的問題？
A：坦白說這是運維同學要做的，我們底層 RPC 通訊框架本身就要支持自動的伸縮，自動伸縮無外乎留一定的閾值上限，自動觸發擴容，調用服務無感知這是屬於基礎組件同學需要考慮的問題。
Q：如何動態擴容過濾器？
A：剛開始我們對用戶部署多少也不知道，對一個用戶的摸索情況，一個用戶 1M、2M，用戶刷的多，就可以多分配，類似 vector 的內容機制。
Q：索引服務用的是 DCache 嗎？
A：對。
Q：索引能用es存儲嗎？效率會不會很低？
A：用什麼保存都無關，問題是怎麼做同步，跟場景，兩刷之間非常快，就有這樣的問題。
Q：新用戶如何推薦？
A：用戶維度就是去拿額外的數據，內容維度就是新熱。
Q：信息流推薦裏怎麼利用用戶搜索畫像呢？
A：把搜索直接作爲一個特徵，交給模型去學
Q：索引服務如何做到無鎖，併發寫怎麼解決？
A：採用無鎖的數據結構，整個索引只有單個寫，沒有併發寫。
Q：召回推薦什麼時候觸發？
A：用戶請求主 feed 就會觸發
Q：推薦系統的架構如何保證時延要求呢？
A：架構層面優化和代碼層面的優化。
Q：索引服務使用 golang 寫能扛？
A：應該是可以的，語言層面的開銷差別不會太大，我們線上就已經 2ms，如果差別能差幾毫秒呢，應該是影響不大。
Q：有刪索引的場景嗎？
A：當然有，但是隻刪正排(快照) 不刪倒排。
Q：統一的打分服務如何處理不同召回的個性化需求？
A：不是所有召回都必須接 PE 召回之間會看 unique 價值來保證個性化需求。