最近比較忙，今天韓潤澤又抽時間給大家帶來了小紅書首頁推薦怎么上,小紅書上首頁推薦及熱門方法干貨，以及關于小紅書首頁等等一系列的相關事項，希望各位能認真閱讀。因為，只有這樣才能真正理解和掌握！

本文整理自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，將流計算與機器學習無縫整合實現更智能高效的推薦。

今天就分享到這里吧，希望你看到這篇文章以后能有所啟發，認真、仔細閱讀完小紅書首頁推薦怎么上「詳細講解：小紅書上首頁推薦及熱門方法」，對自己有幫助，麻煩記得點個贊哦！