簡介：?本篇內容主要分三個部分，在第一部分講一下實時計算在推薦業務中的使用場景。第二部分講一下小紅書是怎么使用Flink的一些新的功能。第三部分主要是講一些OLAP的實時分析的場景，以及和阿里云MC-Hologres的合作。

作者：小紅書推薦工程負責人?郭一

小紅書推薦業務架構

首先這個圖上畫了一些比較典型的推薦業務，使用大數據的主要模塊，其中最左邊是線上推薦引擎，一般推薦引擎會分成召回、排序、后排等幾步，在這里就不細說了。主要是從大數據的角度來說，推薦引擎主要是運用預測模型來預估用戶對每個候選筆記的喜歡程度。根據一定的策略來決定給用戶推薦哪些筆記。推薦模型在運用時需要抓取筆記特征，這些特征又會回流到我們的訓練數據中，來訓練新的模型。推薦引擎返回筆記之后，用戶對筆記的消費行為，包括展示、點擊、點贊等行為，會形成用戶的行為流。這些用戶行為流結合了特征流，從而產生了模型訓練的數據來迭代模型。結合用戶和筆記的信息之后，就會產生用戶和筆記畫像和推薦業務所用到的一些分析報表。
經過一年多的改造，小紅書在推薦場景中，除了從分析數據到策略這一塊，需要人為參與迭代策略之外，其他的模塊的更新基本上是做到了實時或近實時的進行。

推薦業務的實時計算應用

這里稍微展開講一下特征和用戶行為的數據回流之后的實時計算，以及我們怎么使用他們產生的數據。在推薦引擎產生特征流的時候，特征流因為量特別大，包括了所有推薦返回的筆記，大概有近百篇，以及這些筆記的所有特征，所以這些特征總共大概有大幾百個。目前我們的做法是把特征寫到一個我們自研的高效的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，下游的數據就不會有重復。 然后因為我們是放在阿里云上面，所以說是沒有任何的運維的成本。

?

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的小红书推荐大数据在阿里云上的实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。