小紅書發表筆記如何被推薦「小紅書筆記怎么才能被推薦」

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

作者 | 郭一整理 | 董黎明

本文授權轉自：https://mp.weixin.qq.com/s/lkuD_Wxtr1XbtrlwTbYusw

實時計算在推薦業務中的場線上推薦流程

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

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

2. 推薦系統架構

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

3. 離線批處理

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

4. 實時流處理

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

實時歸因1. 實時歸因數據

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

2. 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。

3. 實際生產需要解決的問題

在實際生產中落地 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 實時流計算平臺1. 小紅書實時流計算平臺及周邊生態

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

2. 小紅書 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，將流計算與機器學習無縫整合實現更智能高效的推薦。