2019阿裡雲峰會·上海開發者大會于7月24日盛大開幕，本次峰會與未來世界的開發者們分享開源大資料、IT基礎設施雲化、資料庫、雲原生、物聯網等領域的技術幹貨，共同探讨前沿科技趨勢。本文整理自開源大資料專場中小紅書實時推薦團隊負責人郭一先生的經常演講，将為大家分享小紅書大資料計算平台架構演進。
開源大資料專場PPT下載下傳
以下内容根據演講視訊以及PPT整理而成。
一、實時計算在推薦業務中的場景
1. 線上推薦流程
小紅書線上推薦的流程主要可以分為三步。第一步，從小紅書使用者每天上傳的的筆記池中選出候選集。既通過各種政策從近千萬條的筆記中選出上千個侯選集進行初排。第二步，在模型排序階段給每個筆記打分。小紅書内部使用者的點贊和收藏的給平台帶來的價值做了一套權重的設計，通過預估使用者的點選率CTR，預計點選之後的點贊、收藏和評論的機率進行打分。第三步，在将筆記展示給使用者之前，選擇分數高的筆記，通過各種政策進行多樣性調整。
2. 推薦系統架構
下圖展示了小紅書推薦系統架構，紅顔色表示實時操作，灰色則是離線操作。通過算法推薦之後，使用者和筆記進行互動，産生使用者的曝光、點贊和點選的資訊，這些資訊被收集之後形成使用者筆記畫像，也會成為模型訓練的訓練樣本，産生分析報表。訓練樣本最終生成預測模型，投入線上進行算法推薦，這樣就形成了一個閉環。分析報表則由算法工程師或政策工程師進行分析，調整推薦政策，最後投入線上。
3. 離線批處理
離線批處理流程如下圖所示，在用戶端産生使用者互動和打點，打點好的資料以T+1模式更新使用者筆記畫像，生成報表并生成訓練樣本，最後進行模型訓練和分析。這是小紅書初級版本的離線批處理情況，整個流程都基于Hive進行處理，可以發現整個流程是非常慢的。
4.實時流處理
2018年開始小紅書将離線的pipeline更新成實時的pipeline。使用者一旦産生互動點選，系統會實時維護資料，更新使用者筆記畫像，實時産生訓練樣本，更新模型及生成報表。實時的流處理大大增加了開發效率。實時流處理依賴于Flink，首先使用者的實時互動進入Kafka，借助Flink任務維護使用者筆記畫像，将其傳給線上使用者畫像系統。相對來說，使用者的筆記畫像比較簡單，不會存在過多的狀态。而實時流進行中非常重要的場景是實時歸因，它是小紅書最核心的業務。實時歸因是一個有狀态的場景，實時歸因根據打點資訊産生使用者的行為标簽，所有實時名額和訓練樣本都依賴行為标簽。其中，實時名額放在Click House，資料分析師和政策工程師基于ClickHouse資料進行分析。訓練樣本仍然落到Hive中進行模型訓練。
二、實時歸因
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 中的内容輸出到下遊，進行分析和模型訓練，同時清ValueState。
3. 實際生産需要解決的問題
在實際生産中落地Flink任務需要解決較多的問題。首先是如何對Flink進行叢集管理？上了生産環境之後需要做Checkpoint，将任務持久化。以及非常重要的一點，Backfill。持久化一旦出錯，需要回到過去的某個時間，重新清除錯誤資料并恢複資料。
Flink叢集管理：小紅書選擇将Flink部署在 K8S叢集上。在小紅書看來，K8S或許是将來的趨勢。
Checkpoint & State持久化：Flink 的State 分為兩種，FsStateBackend和RocksDBStateBa
ckend。FsStateBackend支援較小的狀态，但不支援增量的狀态。在實時歸因的場景中有20分鐘的視窗，20分鐘之内發生的所有的狀态會放在記憶體中，定期做持久化。如果要避免這20分鐘的資料丢失，RocksDBStateBackend是較好的選擇，因為RocksDBStateBackend支援增量Checkpoint。
RocksDB調優：具體使用RocksDBStateBackend時依然會遇到調優問題。小紅書在開始測試的時候，Checkpoint頻率設的較短，一分鐘做一次Checkpoint。而RocksDB每次做Checkpoint時都需要把資料從記憶體flash到磁盤上面，Checkpoint做的很頻繁時會産生非常多的小std檔案，RocksDB需要花大量時間和資源去做Compaction，把小檔案和并成大檔案。State本身已經比較大，假如flash不斷做Compaction，磁盤I/O會成為瓶頸，最後導緻産生反壓上遊。另一個問題是使用RocksDBStateBackend會有生成較多的MemTable。如果記憶體沒有配置好，會導緻out of memory，需要重新計算記憶體，調配MemTable，Parallelism和K8S point的記憶體。調優之後任務跑的較為穩定，這時需要把本地磁盤換成高性能的SSD，保證記憶體足夠大。此外，每次做Checkpoint會産生性能損失。小紅書選擇将Checkpoint頻率改成十分鐘，同樣可以滿足生産需求，而且回填10分中的資料隻需要一到兩分鐘。還需要注意調大RocksDB Compaction Threshold，避免頻繁做小檔案的Compaction。
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。
2. 小紅書Flink系統
如下圖，業務方使用小紅書Flink實時流計算平台時，可以選擇資料目的地。比如aws-hive和rex-clickhouse表明資料需要放到Hive和ClickHouse中。然後在Schema中輸入JSON或PB格式資料，平台可以自動識别Schema，同時将資料Schema轉成Flink SQL ETL的指令，自動更新Flink ETL Job的任務。此外，系統會對任務進行監控，監控任務的延遲時間，有無資料丢失，如果延遲過高或有資料丢失則産生報警。
3. 平台小紅書推薦預測模型的演近
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的分布式訓練。