小紅書推薦工程負責人 郭一
本篇内容主要分三個部分，在第一部分講一下實時計算在推薦業務中的使用場景。第二部分講一下小紅書是怎麼使用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場景和阿裡雲MaxCompute、Hologres的一個合作。小紅書在推薦業務下面有很多OLAP場景，這裡我講4個比較常見的場景應用，最常見的其實就是根據使用者的實驗組分組進行比較的一個實時分析。因為我們在推薦業務上面需要大量的調整政策或者是更新模型，然後每次調整政策和更新模型我們都會開一個實驗，把使用者放到不同的ABtest裡面來比較使用者的行為。那麼一個使用者其實在推薦當中會同時處于多個實驗，在每一個實驗裡面是屬于一個實驗組，我們按實驗分組做的實驗分析，主要就是把一個實驗拿出來，然後把使用者的行為和彙總資料，根據這個實驗當中的實驗組進行分次元的分析，看看不同的實驗組它的使用者名額有什麼差别。然後這個場景是一個非常常見的場景，但是也是計算量非常大的場景，因為它需要根據使用者的實驗tag進行分組。
然後另外一個場景就是我們小紅書的推薦其實是跑在了多個資料中心上面，不同的資料中心經常有一些變動，比如說是運維的變動，我們要起一個新的服務，或者是我們可能有些新的模型需要在某個計算中心先上線，那麼我們需要一個端到端的方案去驗證不同的資料中心之間的資料是不是一緻，使用者在不同資料中心的體驗是不是一樣。這個時候就需要我們根據不同的資料中心進行比較，比較使用者在不同的資料中心當中産生的行為，他們最終的名額是不是一緻，同樣我們也用到了我們的模型和代碼的釋出當中。我們會看一個模型釋出或者一份代碼釋出的老版本和新版本，他們産生的使用者的行為的名額對比，看他們是不是一緻。同樣我們的OLAP還用在了實時業務名額的告警，如果使用者的點選率和使用者的點贊數突然有一個大幅的下降，也會觸發我們的實時的告警。
在高峰時候我們大概每秒鐘有35萬條使用者行為被記入我們的實時計算當中。然後我們大寬表大概有300個字段，然後我們希望能夠保持兩周多大概15天左右的資料，因為我們在做實驗分析的時候，經常需要看本周和上一周的資料的對比，然後我們大概每天有近千次的查詢。
小紅書+Hologres
我們在7月和阿裡雲的MaxComputer和Hologres進行了一個合作。Hologres其實是新一代的智能數倉的解決方案，它能夠把實時和離線的計算都通過一站式的方法來解決。同時它的應用主要可以用在實時大屏、Tableau和資料科學當中，我們研究下來是比較适合我們的推薦場景的。
Hologres做的事情主要是對離線的資料進行了查詢和加速，然後對離線的資料做表級别的互動查詢響應，他就無須再做從離線把資料搬到實時數倉的這麼一個工作，因為它都在裡面了。整個實時數倉，它是通過搭建使用者洞察體系，實時監控平台的使用者資料，可以從不同的角度對使用者進行實時診斷，這樣可以幫助實施精細化的營運。這個其實對于我們使用者大寬表來說也是一個非常适合的場景。然後它的實時離線的聯邦計算可以基于實時計算引擎和離線數倉MaxCompute互動分析，實時離線聯邦查詢，構築全鍊路精細化營運。
在和阿裡雲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，下遊的資料就不會有重複。 然後因為我們是放在阿裡雲上面，是以說是沒有任何的運維的成本。
謝謝大家！
更多大資料客戶實戰案例：
https://developer.aliyun.com/article/772449