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

作者 | 郭一整理 | 董黎明

本文授權(quán)轉(zhuǎn)自：https://mp.weixin.qq.com/s/lkuD_Wxtr1XbtrlwTbYusw

實時計算在推薦業(yè)務(wù)中的場線上推薦流程

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

在此模型中最核心的點擊率、點贊數(shù)、收藏、評論等都是通過機器學(xué)習(xí)模型訓(xùn)練對用戶各項行為的預(yù)估并給出相應(yīng)分數(shù)。

2. 推薦系統(tǒng)架構(gòu)

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

3. 離線批處理

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

4. 實時流處理

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

實時歸因1. 實時歸因數(shù)據(jù)

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

2. Flink Job – Session Labeler

小紅書在處理實時歸因原始數(shù)據(jù)時應(yīng)用了 Flink 任務(wù)。從 Kafka Source 中讀數(shù)據(jù)再寫到另外一個 Kafka Sink。Key（user_id和note_id）根據(jù)用戶筆記和是否發(fā)生曝光和點擊分為兩個 Session，Session 使用 Process Function API 處理記錄，每條記錄都會記錄曝光的Session和點擊的 Session。Session 有20分鐘的定長窗口，即在收到用戶行為曝光或者點擊之后，開20分鐘的窗口查看是否這期間會發(fā)生曝光、點擊、點贊或者停留了多少時間。Session 中有狀態(tài)信息，比如發(fā)生點擊并點贊，系統(tǒng)維護用戶在狀態(tài)中停留的時間，檢查點擊是否有效等。Flink 窗口結(jié)束時，需要將 Session State 中的內(nèi)容輸出到下游，進行分析和模型訓(xùn)練，同時清除 ValueState。

3. 實際生產(chǎn)需要解決的問題

在實際生產(chǎn)中落地 Flink 任務(wù)需要解決較多的問題。首先是如何對 Flink 進行集群管理，上了生產(chǎn)環(huán)境之后需要做 Checkpoint，將任務(wù)持久化，尤其需要注意的一點是 Backfill，持久化一旦出錯，需要回到過去的某個時間，重新清除錯誤數(shù)據(jù)并恢復(fù)數(shù)據(jù)。

Flink 集群管理：小紅書選擇將 Flink 部署在 K8S 集群上，在小紅書看來，K8S 或許是未來的趨勢之一。Checkpoint & State 持久化：Flink 的 State 分為兩種，F(xiàn)sStateBackend 和 RocksDBStateBackend。FsStateBackend 支持較小的狀態(tài)，但不支持增量的狀態(tài)。在實時歸因的場景中有20分鐘的窗口，20分鐘之內(nèi)發(fā)生的所有的狀態(tài)會放在內(nèi)存中，定期做持久化。如果要避免這20分鐘的數(shù)據(jù)丟失，RocksDBStateBackend 是更好的選擇，因為 RocksDBStateBackend 支持增量 Checkpoint。RocksDB 調(diào)優(yōu)：具體使用 RocksDBStateBackend 時依然會遇到調(diào)優(yōu)問題。小紅書在開始測試時， Checkpoint 頻率設(shè)置較短，一分鐘做一次 Checkpoint，而 RocksDB 每次做 Checkpoint 時都需要將數(shù)據(jù)從內(nèi)存 flash 到磁盤中，Checkpoint 頻率較高時會產(chǎn)生非常多的小 std 文件，RocksDB 需要花大量時間和資源去做整合，將小文件合并為大文件。State 本身已經(jīng)比較大，假如 flash 持續(xù) Compaction，磁盤 I/O 將會成為瓶頸，最后導(dǎo)致產(chǎn)生反壓上游。

另一個問題是使用 RocksDBStateBackend 會有生成較多的 MemTable，如果內(nèi)存沒有配置好，會導(dǎo)致 out of memory，需要重新計算內(nèi)存，調(diào)配 MemTable，Parallelism 和 K8s point 的內(nèi)存。調(diào)優(yōu)之后任務(wù)運行較為穩(wěn)定，這時需要把本地磁盤換成高性能的 SSD，保證內(nèi)存有足夠的空間。

此外，每次做 Checkpoint 都會產(chǎn)生性能損失。小紅書選擇將 Checkpoint 頻率改成十分鐘，同樣可以滿足生產(chǎn)需求，而且回填10分鐘的數(shù)據(jù)只需要一到兩分鐘，需要注意的是調(diào)大 RocksDB Compaction Threshold，避免頻繁進行小文件的合并。

Backfill：回填是生產(chǎn)中常見的場景，實際生產(chǎn)中如果開發(fā)者寫錯代碼導(dǎo)致數(shù)據(jù)錯誤，則需要刪除錯誤數(shù)據(jù)，重新跑正確代碼回填正確的數(shù)據(jù)；另外，如果原本只有點贊功能，會產(chǎn)生新的回填場景，分析用戶點贊是否為有效點贊或者對其做簡單的邏輯恢復(fù)都需要 Backfill。Backfill 非常依賴 Flink 對 Hive 的支持，小紅書一直以來的數(shù)據(jù)都存放在 Hive 上，所以非常期待 Flink 1.9 版本性能的提高，尤其對 Hive 的支持的提升和對批的支持的加強。Red Flink 實時流計算平臺1. 小紅書實時流計算平臺及周邊生態(tài)

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

2. 小紅書 Flink 系統(tǒng)

下圖為系統(tǒng)的部分截圖，左邊為業(yè)務(wù)方使用小紅書 Flink 實時流計算平臺時，可以選擇數(shù)據(jù)目的地，比如 aws-hive 和 rex-clickhouse 表明數(shù)據(jù)需要放到 Hive 和 ClickHouse 中。然后在 Schema 中輸入 JSON 或 PB 格式數(shù)據(jù)，平臺可以自動識別 Schema，同時將數(shù)據(jù) Schema 轉(zhuǎn)成 Flink SQL ETL 的命令，自動更新 Flink ETL Job 的任務(wù)。此外，系統(tǒng)會對任務(wù)進行監(jiān)控，監(jiān)控任務(wù)的延遲時間、有無數(shù)據(jù)丟失，如果延遲過高或有數(shù)據(jù)丟失則產(chǎn)生報警及報警的級別。

平臺小紅書推薦預(yù)測模型的演進9個行為的預(yù)測模型 (click, hide, like, fav, comment, share, follow, …)Click 模型規(guī)模：5億樣本/天， 1T 數(shù)據(jù)/天

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

目前小紅書的 Red ML 模型基于 KubeFlow，在小紅書開始做 ML 模型時，KubeFlow 在開源社區(qū)中比較受歡迎，而且 TFJob 可以支持 TensorFlow 的分布式訓(xùn)練。

總結(jié)與展望

小紅書從去年年底開始做推薦系統(tǒng)，系統(tǒng)的搭建既依賴開源社區(qū)，也擁抱開源社區(qū)。整個實時計算平臺的搭建都是基于 Flink，也十分期待 Flink 1.9 的新功能對于 Hive 和批的支持；AI 是目前小紅書比較強的需求，包括模型訓(xùn)練算力、效率等非常敏感，也會持續(xù)關(guān)注社區(qū)相關(guān)技術(shù)；后期希望能夠融合 Flink 與 AI，將流計算與機器學(xué)習(xí)無縫整合實現(xiàn)更智能高效的推薦。