作者：郭一
整理：董黎明
本文整理自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，将流計算與機器學習無縫整合實作更智能高效的推薦。