小紅書推薦業務架構
首先這個圖上畫了一些比較典型的推薦業務，使用大數據的主要模塊，其中最左邊是線上推薦引擎，通常推薦引擎會分紅召回、排序、後排等幾步，在這裏就不細說了。主要是從大數據的角度來講，推薦引擎主要是運用預測模型來預估用戶對每一個候選筆記的喜歡程度。根據必定的策略來決定給用戶推薦哪些筆記。推薦模型在運用時須要抓取筆記特徵，這些特徵又會迴流到咱們的訓練數據中，來訓練新的模型。推薦引擎返回筆記以後，用戶對筆記的消費行爲，包括展現、點擊、點贊等行爲，會造成用戶的行爲流。這些用戶行爲流結合了特徵流，從而產生了模型訓練的數據來迭代模型。結合用戶和筆記的信息以後，就會產生用戶和筆記畫像和推薦業務所用到的一些分析報表。
通過一年多的改造，小紅書在推薦場景中，除了從分析數據到策略這一塊，須要人爲參與迭代策略以外，其餘的模塊的更新基本上是作到了實時或近實時的進行。緩存
推薦業務的實時計算應用
這裏稍微展開講一下特徵和用戶行爲的數據迴流以後的實時計算，以及咱們怎麼使用他們產生的數據。在推薦引擎產生特徵流的時候，特徵流由於量特別大，包括了全部推薦返回的筆記，大概有近百篇，以及這些筆記的全部特徵，因此這些特徵總共大概有大幾百個。目前咱們的作法是把特徵寫到一個咱們自研的高效的kv中緩存幾個小時，而後用戶行爲數據是從客戶端打點回流，而後咱們就開始了數據流的處理。
咱們第一步是把客戶端打點的用戶行爲進行歸因和彙總。這裏講一下什麼是歸因和彙總。由於在小紅書的APP上面，客戶端的打點是分頁面的，好比說用戶在首頁推薦中看了筆記並進行了點擊，點擊以後用戶就會跳轉到筆記頁，而後用戶在筆記頁上瀏覽這篇筆記並進行點贊。同時用戶可能會點擊做者的頭像進入做者的我的頁，並在我的頁中關注了做者。歸因是指把這一系列的用戶行爲都要算做首頁推薦產生的行爲，而不會和其餘的業務混起來。由於搜索用戶，在搜索中看到一樣一篇筆記，也可能返回一樣的結果。因此咱們要區分用戶的行爲究竟是由哪個業務所產生的，這個是歸因。微信
而後彙總指的是用戶的這一系列行爲，關於同一篇筆記，咱們會產生一條彙總的記錄，彙總的記錄能夠便於後續的分析。而後歸因以後，會有一個實時的單條用戶行爲的數據流。而彙總這邊，由於有一個窗口期，因此彙總的數據通常會延遲目前大概是20分鐘左右。當咱們產生歸因和彙總的數據流以後，咱們就會補充上一些維表的數據，咱們會根據用戶筆記來找當時咱們推薦產生的特徵，同時咱們也會把一些用戶的基礎信息和筆記的基礎信息加到數據流上。這裏面其實主要有4個比較重要的用戶場景，第一個場景是產生分業務的Breakdown的信息，這個主要是能知道某一個用戶在不一樣的筆記維度，他的點擊率和一些其餘的業務指標，同時我也能夠知道某一篇筆記針對不一樣的用戶，它產生的點擊率，這個是咱們在實時推薦當中一個比較重要的特徵。另一個很重要的是咱們實時分析的一個寬表，寬表是咱們把用戶的信息、筆記信息和用戶筆記交互的彙總信息，都變成了一個多維度的表，進行實時分析，這個後面會更加詳細的和你們講述。而後還有兩個比較重要的，一個是實時訓練的信息，訓練的信息就是我把用戶和筆記交互的信息擴充了，當時排序的時候抓起的特徵，這特徵加上一些咱們彙總出來的標籤，就給模型進行訓練來更新模型。而後另一個就是我全部的彙總信息都會進入離線數據數倉，而後會進行後續的一些分析和報表的處理。架構
流計算優化—Flink批流一體
而後我這裏講一下咱們怎麼運用Flink的一些新功能來優化流計算的過程。這裏面我主要講兩點，其中第一點就是批流一體化。
剛纔說了咱們把一個用戶的行爲根據筆記的行爲彙總以後進行分析，這裏的彙總的信息其實不少的，彙總信息當中，除了最簡單的，好比說用戶有沒有點贊收藏這篇筆記，其實還有一些比較複雜的標籤，好比說用戶在筆記頁上停留了多長時間，或者是說這篇筆記以前的點擊是否是一個有效點擊，咱們對於某些廣告場景或者有些場景下面，咱們須要知道若是用戶點擊以後停留了好比說超過5秒，那麼這個點擊是有效的。那麼像這種複雜的邏輯，咱們但願在咱們的系統當中只被實現一次，就能夠同時運用在實時和批的計算當中。那麼在傳統意義上這點是很難的，由於大多數的實現中，批和流是兩個版本，就是咱們在Flink上面，好比說實現了一個版本的有效點擊的定義，咱們同時也會須要實現一個離線版本的有效點擊的定義，這個多是一個SQL寫的版本。那麼小紅書是運用了FLIP-27裏面的一個新的功能，日誌文件是一個批的形式，它能夠轉換成一個流的形式，這樣的話我就能夠作到代碼意義上的批流統一。app
流計算優化—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，下游的數據就不會有重複。而後由於咱們是放在阿里雲上面，因此說是沒有任何的運維的成本。優化
關注小晨說數據，獲取更多大廠技術乾貨分享，目前已經有4500+粉絲關注了。
回覆「spark」，「flink」，「中臺」，「機器學習」，「用戶畫像」獲取海量學習資料～～～
本文分享自微信公衆號 - 小晨說數據（flink-spark）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。