小紅書如何實現高效推薦？解密背後的大數據計算平臺架構

做者：郭一
整理：董黎明

本文整理自2019阿里雲峯會·上海開發者大會開源大數據專場中小紅書實時推薦團隊負責人郭一先生現場分享。小紅書做爲生活分享類社區，目前有8500萬用戶，年同比增加爲300%，大約天天有30億條筆記在發現首頁進行展現。推薦是小紅書很是核心且重要的場景之一，本文主要分享在推薦業務場景中小紅書的實時計算應用。

實時計算在推薦業務中的場景

線上推薦流程

小紅書線上推薦的流程主要能夠分爲三步。第一步，從小紅書用戶天天上傳的的筆記池中選出候選集，即經過各類策略從近千萬條的筆記中選出上千個侯選集進行初排。第二步，在模型排序階段給每一個筆記打分，根據小紅書用戶的點贊和收藏行爲給平臺帶來的價值設計了一套權重的評估體系，經過預估用戶的點擊率，評估點擊以後的點贊、收藏和評論等的機率進行打分。第三步，在將筆記展現給用戶以前，選擇分數高的筆記，經過各類策略進行多樣性調整。

在此模型中最核心的點擊率、點贊數、收藏、評論等都是經過機器學習模型訓練對用戶各項行爲的預估並給出相應分數。

推薦系統架構

在小紅書線上推薦過程的背後是一套完整的從線上到線下的推薦系統，下圖展現了小紅書推薦系統架構，紅色表示實時操做，灰色則是離線操做。經過算法推薦以後，用戶和筆記進行交互，產生用戶的曝光、點贊和點擊的信息，這些信息被收集造成用戶筆記畫像，也會成爲模型訓練的訓練樣本，產生分析報表。訓練樣本最終生成預測模型，投入線上進行算法推薦，如此就造成了一個閉環，其中分析報表則由算法工程師或策略工程師進行分析，調整推薦策略，最後再投入到線上推薦中。

離線批處理

離線批處理流程以下圖所示，以前的處理流程是在客戶端產生用戶交互和打點，打點好的數據放入數倉中，以T+1模式更新用戶筆記畫像，生成報表並生成訓練樣本，最後進行模型訓練和分析。小紅書初級版本的離線批處理狀況，整個流程都基於Hive進行處理，處理流程較慢，沒法知足業務需求。

實時流處理

2018年開始小紅書將離線的pipeline升級爲實時的pipeline，用戶一旦產生交互點擊，系統會實時維護數據，更新用戶筆記畫像，實時產生訓練樣本，更新模型及生成報表。實時的流處理大大提升了開發效率，同時實時流處理依賴於Flink。在實時流中，首先用戶的實時交互進入Kafka，藉助Flink任務維護用戶筆記畫像，將其傳給線上用戶畫像系統。相對來講，用戶的筆記畫像比較簡單，不會存在過多的狀態，而實時流處理中很是重要的場景是實時歸因，這也是小紅書最核心的業務。實時歸因是一個有狀態的場景，根據打點信息產生用戶的行爲標籤，全部實時指標和訓練樣本都依賴行爲標籤，其中，實時指標放在Click House，數據分析師和策略工程師基於ClickHouse數據進行分析，訓練樣本仍然落到Hive中進行模型訓練，同時在線學習系統中會將訓練樣本落到Kafka，進行實時模型訓練。

實時歸因

實時歸因數據

實時歸因將筆記推薦給用戶後會產生曝光，隨即產生打點信息，用戶筆記的每一次曝光、點擊、查看和回退都會被記錄下來。以下圖所示，四次曝光的用戶行爲會產生四個筆記曝光。若是用戶點擊第二篇筆記，則產生第二篇筆記的點擊信息，點贊會產生點讚的打點信息；若是用戶回退就會顯示用戶在第二篇筆記停留了20秒。實時歸因會生成兩份數據，第一份是點擊模型的數據標籤，在下圖中，第一篇筆記和第三篇筆記沒有點擊，第二篇筆記和第四篇筆記有點擊，這類數據對於訓練點擊模型相當重要。一樣，點贊模型須要點擊筆記數據，好比用戶點擊了第二篇筆記併發生點贊，反之點擊了第四篇筆記但沒有點贊，時長模型須要點擊以後停留的時間數據。以上提到的數據須要與上下文關聯，產生一組數據，做爲模型分析和模型訓練的原始數據。

Flink Job - Session Labeler

小紅書在處理實時歸因原始數據時應用了Flink任務。從Kafka Source中讀數據再寫到另一個Kafka Sink。Key（user_id和note_id）根據用戶筆記和是否發生曝光和點擊分爲兩個Session，Session使用Process Function API處理記錄，每條記錄都會記錄曝光的Session和點擊的Session。Session有20分鐘的定長窗口，即在收到用戶行爲曝光或者點擊以後，開20分鐘的窗口查看是否這期間會發生曝光、點擊、點贊或者停留了多少時間。Session中有狀態信息，好比發生點擊並點贊，系統維護用戶在狀態中停留的時間，檢查點擊是否有效等。Flink窗口結束時，須要將Session State中的內容輸出到下游，進行分析和模型訓練，同時清除ValueState。

實際生產須要解決的問題

在實際生產中落地Flink任務須要解決較多的問題。首先是如何對Flink進行集羣管理，上了生產環境以後須要作Checkpoint，將任務持久化，尤爲須要注意的一點是Backfill，持久化一旦出錯，須要回到過去的某個時間，從新清除錯誤數據並恢復數據。

Flink集羣管理：小紅書選擇將Flink部署在 K8s集羣上，在小紅書看來，K8S或許是將來的趨勢之一。

Checkpoint & State持久化：Flink 的State 分爲兩種，FsStateBackend和RocksDBStateBackend。FsStateBackend支持較小的狀態，但不支持增量的狀態。在實時歸因的場景中有20分鐘的窗口，20分鐘以內發生的全部的狀態會放在內存中，按期作持久化。若是要避免這20分鐘的數據丟失，RocksDBStateBackend是更好的選擇，由於RocksDBStateBackend支持增量Checkpoint。

RocksDB調優：具體使用RocksDBStateBackend時依然會遇到調優問題。小紅書在開始測試時，Checkpoint頻率設置較短，一分鐘作一次Checkpoint，而RocksDB每次作Checkpoint時都須要將數據從內存flash到磁盤中，Checkpoint頻率較高時會產生很是多的小std文件，RocksDB須要花大量時間和資源去作整合，將小文件合併爲大文件。State自己已經比較大，假如flash持續Compaction，磁盤I/O將會成爲瓶頸，最後致使產生反壓上游。

另外一個問題是使用RocksDBStateBackend會有生成較多的MemTable，若是內存沒有配置好，會致使out of memory，須要從新計算內存，調配MemTable，Parallelism和K8s point的內存。調優以後任務運行較爲穩定，這時須要把本地磁盤換成高性能的SSD，保證內存有足夠的空間。

此外，每次作Checkpoint都會產生性能損失。小紅書選擇將Checkpoint頻率改爲十分鐘，一樣能夠知足生產需求，並且回填10分鐘的數據只須要一到兩分鐘，須要注意的是調大RocksDB Compaction Threshold，避免頻繁進行小文件的合併。

Backfill：回填是生產中常見的場景，實際生產中若是開發者寫錯代碼致使數據錯誤，則須要刪除錯誤數據，從新跑正確代碼回填正確的數據；另外，若是本來只有點贊功能，會產生新的回填場景，分析用戶點贊是否爲有效點贊或者對其作簡單的邏輯恢復都須要Backfill。Backfill很是依賴Flink對Hive的支持，小紅書一直以來的數據都存放在Hive上，因此很是期待Flink 1.9版本性能的提升，尤爲對Hive的支持的提高和對批的支持的增強。

Red Flink實時流計算平臺

小紅書實時流計算平臺及周邊生態

小紅書推薦系統是一個流計算的平臺，同時涉及周邊的生態。以下圖所示，最右邊是數據接入的模塊，支持從客戶端接入數據，同時後端的服務提供LogSDK的模塊幫助業務直接接入實時計算的平臺。紅色模塊是流計算平臺中正在開發的模塊，好比，Canal經過事務的數據庫日誌直接將訂單流對接到數據平臺，系統自動分析數據Schema，一旦Schema發生變化，自動重啓相應Flink任務。左下角是基於Flink 1.8作的開發，在此基礎上根據業務須要增長了Latency監控，便於分析Flink堵塞的Operator，同時將Latency監控直接接入到系統中。小紅書基於Flink的SQL也進行了開發，實現了不一樣的connector，好比ClickHouse、Hbase、Kafka等，目前這套平臺支持的業務除了實時歸因的場景外，還有數據ETL、實時Spam、實時DAU，包括咱們正在開發的實時RGMV大促看板都是基於此平臺搭建的。

小紅書Flink系統

下圖爲系統的部分截圖，左邊爲業務方使用小紅書Flink實時流計算平臺時，能夠選擇數據目的地，好比aws-hive和rex-clickhouse代表數據須要放到Hive和ClickHouse中。而後在Schema中輸入JSON或PB格式數據，平臺能夠自動識別Schema，同時將數據Schema轉成Flink SQL ETL的命令，自動更新Flink ETL Job的任務。此外，系統會對任務進行監控，監控任務的延遲時間、有無數據丟失，若是延遲太高或有數據丟失則產生報警及報警的級別。

平臺小紅書推薦預測模型的演近

• 9個行爲的預測模型 (click, hide, like, fav, comment, share, follow, …)
• Click模型規模： 5億樣本/天， 1T數據/天

上面簡單介紹了小紅書的實時計算平臺，另一部分就是TensorFlow和Machine Learning。2018年12月，小紅書的推薦預測模型只是很是簡單的Spark上的GBDT模型。後期在GBDT模型上加了LR層，後來還引入了Deep和Wide。到2019年7月，小紅書推薦預測模型已經演化到了GBDT + Sparse D&W的模型。小紅書主要有9個預測任務，包括click、hide、like、fav、comment、share以及follow等。其中，Click是小紅書最大的模型，一天大概產生5億的樣本進行模型訓練，數據量達到1T/天。

目前小紅書的Red ML模型基於KubeFlow，在小紅書開始作ML模型時，KubeFlow在開源社區中比較受歡迎，並且TFJob能夠支持TensorFlow的分佈式訓練。

總結與展望

小紅書從去年年末開始作推薦系統，系統的搭建既依賴開源社區，也擁抱開源社區。整個實時計算平臺的搭建都是基於Flink，也十分期待Flink 1.9 的新功能對於Hive 和批的支持；AI是目前小紅書比較強的需求，包括模型訓練算力、效率等很是敏感，也會持續關注社區相關技術；後期但願可以融合Flink與AI，將流計算與機器學習無縫整合實現更智能高效的推薦。