作者：小紅書推薦工程負責人 郭一
小紅書推薦業務架構
首先這個圖上畫了一些比較典型的推薦業務，使用大數據的主要模塊，其中最左邊是線上推薦引擎，一般推薦引擎會分成召回、排序、後排等幾步，在這裡就不細說了。主要是從大數據的角度來說，推薦引擎主要是運用預測模型來預估用戶對每個候選筆記的喜歡程度。根據一定的策略來決定給用戶推薦哪些筆記。推薦模型在運用時需要抓取筆記特徵，這些特徵又會迴流到我們的訓練數據中，來訓練新的模型。推薦引擎返回筆記之後，用戶對筆記的消費行為，包括展示、點擊、點贊等行為，會形成用戶的行為流。這些用戶行為流結合了特徵流，從而產生了模型訓練的數據來迭代模型。結合用戶和筆記的信息之後，就會產生用戶和筆記畫像和推薦業務所用到的一些分析報表。
經過一年多的改造，小紅書在推薦場景中，除了從分析數據到策略這一塊，需要人為參與迭代策略之外，其他的模塊的更新基本上是做到了實時或近實時的進行。
推薦業務的實時計算應用
這裡稍微展開講一下特徵和用戶行為的數據迴流之後的實時計算，以及我們怎麼使用他們產生的數據。在推薦引擎產生特徵流的時候，特徵流因為量特別大，包括了所有推薦返回的筆記，大概有近百篇，以及這些筆記的所有特徵，所以這些特徵總共大概有大幾百個。目前我們的做法是把特徵寫到一個我們自研的高效的kv中緩存幾個小時，然後用戶行為數據是從客戶端打點回流，然後我們就開始了數據流的處理。
我們第一步是把客戶端打點的用戶行為進行歸因和彙總。這裡講一下什麼是歸因和彙總。因為在小紅書的APP上面，客戶端的打點是分頁面的，比如說用戶在首頁推薦中看了筆記並進行了點擊，點擊之後用戶就會跳轉到筆記頁，然後用戶在筆記頁上瀏覽這篇筆記並進行點贊。同時用戶可能會點擊作者的頭像進入作者的個人頁，並在個人頁中關注了作者。歸因是指把這一系列的用戶行為都要算作首頁推薦產生的行為，而不會和其他的業務混起來。因為搜索用戶，在搜索中看到同樣一篇筆記，也可能返回同樣的結果。所以我們要區分用戶的行為到底是由哪一個業務所產生的，這個是歸因。
然後彙總指的是用戶的這一系列行為，關於同一篇筆記，我們會產生一條彙總的記錄，彙總的記錄可以便於後續的分析。然後歸因之後，會有一個實時的單條用戶行為的數據流。而彙總這邊，因為有一個窗口期，所以彙總的數據一般會延遲目前大概是20分鐘左右。當我們產生歸因和彙總的數據流之後，我們就會補充上一些維表的數據，我們會根據用戶筆記來找當時我們推薦產生的特徵，同時我們也會把一些用戶的基礎信息和筆記的基礎信息加到數據流上。這裡面其實主要有4個比較重要的用戶場景，第一個場景是產生分業務的Breakdown的信息，這個主要是能知道某一個用戶在不同的筆記維度，他的點擊率和一些其他的業務指標，同時我也可以知道某一篇筆記針對不同的用戶，它產生的點擊率，這個是我們在實時推薦當中一個比較重要的特徵。另外一個很重要的是我們實時分析的一個寬表，寬表是我們把用戶的信息、筆記信息和用戶筆記交互的彙總信息，都變成了一個多維度的表，進行實時分析，這個後面會更加詳細的和大家講述。然後還有兩個比較重要的，一個是實時訓練的信息，訓練的信息就是我把用戶和筆記交互的信息擴充了，當時排序的時候抓起的特徵，這特徵加上一些我們彙總出來的標籤，就給模型進行訓練來更新模型。然後另外一個就是我所有的彙總信息都會進入離線數據數倉，然後會進行後續的一些分析和報表的處理。
流計算優化—Flink批流一體
然後我這裡講一下我們怎麼運用Flink的一些新功能來優化流計算的過程。這裡面我主要講兩點，其中第一點就是批流一體化。
剛才說了我們把一個用戶的行為根據筆記的行為彙總之後進行分析，這裡的彙總的信息其實很多的，彙總信息當中，除了最簡單的，比如說用戶有沒有點贊收藏這篇筆記，其實還有一些比較複雜的標籤，比如說用戶在筆記頁上停留了多長時間，或者是說這篇筆記之前的點擊是不是一個有效點擊，我們對於某些廣告場景或者有些場景下面，我們需要知道如果用戶點擊之後停留了比如說超過5秒，那麼這個點擊是有效的。那麼像這種複雜的邏輯，我們希望在我們的系統當中只被實現一次，就可以同時運用在實時和批的計算當中。那麼在傳統意義上這點是很難的，因為大多數的實現中，批和流是兩個版本，就是我們在Flink上面，比如說實現了一個版本的有效點擊的定義，我們同時也會需要實現一個離線版本的有效點擊的定義，這個可能是一個SQL寫的版本。那麼小紅書是運用了FLIP-27裡面的一個新的功能，日誌文件是一個批的形式，它可以轉換成一個流的形式，這樣的話我就可以做到代碼意義上的批流統一。
流計算優化—Multi-sink Optimization
那麼還有一個Flink的功能就是一個在Flink 1.11上的Multi-sink Optimization。它的意思是我一份數據會寫到多個數據應用上去，比如我會同時需要做張用戶行為的寬表，同時也生成一份離線的數據。那麼Multi-sink Optimization做的是，你只需要從Kafka裡面讀一次，如果是同一個key的話，他只需要去Lookup一次kv就可以產生多份數據，同時寫到多個sink，這樣可以大大減少我們對Kafka的壓力和對 kv查詢的壓力。
小紅書OLAP典型場景
最後我講一下我們的OLAP場景和阿里雲MaxCompute、Hologres的一個合作。小紅書在推薦業務下面有很多OLAP場景，這裡我講4個比較常見的場景應用，最常見的其實就是根據用戶的實驗組分組進行比較的一個實時分析。因為我們在推薦業務上面需要大量的調整策略或者是更新模型，然後每次調整策略和更新模型我們都會開一個實驗，把用戶放到不同的ABtest裡面來比較用戶的行為。那麼一個用戶其實在推薦當中會同時處於多個實驗，在每一個實驗裡面是屬於一個實驗組，我們按實驗分組做的實驗分析，主要就是把一個實驗拿出來，然後把用戶的行為和彙總數據，根據這個實驗當中的實驗組進行分維度的分析，看看不同的實驗組它的用戶指標有什麼差別。然後這個場景是一個非常常見的場景，但是也是計算量非常大的場景，因為它需要根據用戶的實驗tag進行分組。
然後另外一個場景就是我們小紅書的推薦其實是跑在了多個數據中心上面，不同的數據中心經常有一些變動，比如說是運維的變動，我們要起一個新的服務，或者是我們可能有些新的模型需要在某個計算中心先上線，那麼我們需要一個端到端的方案去驗證不同的數據中心之間的數據是不是一致，用戶在不同數據中心的體驗是不是一樣。這個時候就需要我們根據不同的數據中心進行比較，比較用戶在不同的數據中心當中產生的行為，他們最終的指標是不是一致，同樣我們也用到了我們的模型和代碼的發佈當中。我們會看一個模型發佈或者一份代碼發佈的老版本和新版本，他們產生的用戶的行為的指標對比，看他們是不是一致。同樣我們的OLAP還用在了實時業務指標的告警，如果用戶的點擊率和用戶的點贊數突然有一個大幅的下降，也會觸發我們的實時的告警。
小紅書OLAP數據的規模
在高峰時候我們大概每秒鐘有35萬條用戶行為被記入我們的實時計算當中。然後我們大寬表大概有300個字段，然後我們希望能夠保持兩週多大概15天左右的數據，因為我們在做實驗分析的時候，經常需要看本週和上一週的數據的對比，然後我們大概每天有近千次的查詢。
小紅書+Hologres
我們在7月和阿里雲的MaxComputer和Hologres進行了一個合作。Hologres其實是新一代的智能數倉的解決方案，它能夠把實時和離線的計算都通過一站式的方法來解決。同時它的應用主要可以用在實時大屏、Tableau和數據科學當中，我們研究下來是比較適合我們的推薦場景的。
小紅書Hologres應用場景
Hologres做的事情主要是對離線的數據進行了查詢和加速，然後對離線的數據做表級別的交互查詢響應，他就無須再做從離線把數據搬到實時數倉的這麼一個工作，因為它都在裡面了。整個實時數倉，它是通過搭建用戶洞察體系，實時監控平臺的用戶數據，可以從不同的角度對用戶進行實時診斷，這樣可以幫助實施精細化的運營。這個其實對於我們用戶大寬表來說也是一個非常適合的場景。然後它的實時離線的聯邦計算可以基於實時計算引擎和離線數倉MaxCompute交互分析，實時離線聯邦查詢，構築全鏈路精細化運營。
Hologres VS Clickhouse
在和阿里雲MaxCompute合作之前，我們是自建了Clickhouse的集群，當時我們也是一個很大規模的集群，一共用了1320個core，因為Clickhouse它不是一個計算存儲分離的方案，所以當時我們為了節約成本，只存放了7天的數據，然後因為Clickhouse對於用戶實驗tag這個場景其實沒有很好的優化，所以說我們當時查詢超過三天的數據就會特別慢。因為是個OLAP場景，我們希望每次用戶的查詢能在兩分鐘之內出結果，所以是限制了我們只能查過去三天的數據。同時另外還有一個問題就是Clickhouse對於組件的支持是有些問題的，所以我們沒有在Clickhouse集群上面配置組件，如果上游的數據流有些抖動，數據造成一些重複的情況下，下游的Clickhouse裡面其實會有一些重複的數據。同時我們也是派了專人去運維Clickhouse，然後我們通過調研發現，Clickhouse如果你要做成集群版的話，它的運維成本還是很高的。所以我們在7月份的時候和阿里雲合作，把我們推薦的一個最大的用戶寬表遷移到了MaxCompute和Hologres上面，然後我們在Hologres上面一共是1200個core，因為它是計算存儲的方案，所以1200個core就足夠我們使用了。但是我們在存儲的方面是有更大的需求的，我們一共存了15天的數據，然後因為Hologres對於用戶根據實驗分組這個場景是做了一些比較定製化的優化，所以說我們現在可以輕鬆地查詢7天到15天的數據，在這個根據實驗組分組的場景下面，其查詢的性能與Clickhouse相比是有大幅提升的。Hologres它其實也支持Primary Key，所以我們也是配置了Primary Key，我們在這個場景下面是用了insert or ignore這個方法，然後因為配置了Primary Key，它就天然具有去重的功能，這樣的話我們上游只要保證at least once，下游的數據就不會有重複。 然後因為我們是放在阿里雲上面，所以說是沒有任何的運維的成本。
#附件PDF：
點擊下載》》資料