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

作者：小紅書推薦工程負(fù)責(zé)人?郭一

小紅書推薦業(yè)務(wù)架構(gòu)

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

推薦業(yè)務(wù)的實(shí)時(shí)計(jì)算應(yīng)用

這里稍微展開講一下特征和用戶行為的數(shù)據(jù)回流之后的實(shí)時(shí)計(jì)算，以及我們怎么使用他們產(chǎn)生的數(shù)據(jù)。在推薦引擎產(chǎn)生特征流的時(shí)候，特征流因?yàn)榱刻貏e大，包括了所有推薦返回的筆記，大概有近百篇，以及這些筆記的所有特征，所以這些特征總共大概有大幾百個(gè)。目前我們的做法是把特征寫到一個(gè)我們自研的高效的kv中緩存幾個(gè)小時(shí)，然后用戶行為數(shù)據(jù)是從客戶端打點(diǎn)回流，然后我們就開始了數(shù)據(jù)流的處理。
我們第一步是把客戶端打點(diǎn)的用戶行為進(jìn)行歸因和匯總。這里講一下什么是歸因和匯總。因?yàn)樵谛〖t書的APP上面，客戶端的打點(diǎn)是分頁面的，比如說用戶在首頁推薦中看了筆記并進(jìn)行了點(diǎn)擊，點(diǎn)擊之后用戶就會跳轉(zhuǎn)到筆記頁，然后用戶在筆記頁上瀏覽這篇筆記并進(jìn)行點(diǎn)贊。同時(shí)用戶可能會點(diǎn)擊作者的頭像進(jìn)入作者的個(gè)人頁，并在個(gè)人頁中關(guān)注了作者。歸因是指把這一系列的用戶行為都要算作首頁推薦產(chǎn)生的行為，而不會和其他的業(yè)務(wù)混起來。因?yàn)樗阉饔脩?#xff0c;在搜索中看到同樣一篇筆記，也可能返回同樣的結(jié)果。所以我們要區(qū)分用戶的行為到底是由哪一個(gè)業(yè)務(wù)所產(chǎn)生的，這個(gè)是歸因。

然后匯總指的是用戶的這一系列行為，關(guān)于同一篇筆記，我們會產(chǎn)生一條匯總的記錄，匯總的記錄可以便于后續(xù)的分析。然后歸因之后，會有一個(gè)實(shí)時(shí)的單條用戶行為的數(shù)據(jù)流。而匯總這邊，因?yàn)橛幸粋€(gè)窗口期，所以匯總的數(shù)據(jù)一般會延遲目前大概是20分鐘左右。當(dāng)我們產(chǎn)生歸因和匯總的數(shù)據(jù)流之后，我們就會補(bǔ)充上一些維表的數(shù)據(jù)，我們會根據(jù)用戶筆記來找當(dāng)時(shí)我們推薦產(chǎn)生的特征，同時(shí)我們也會把一些用戶的基礎(chǔ)信息和筆記的基礎(chǔ)信息加到數(shù)據(jù)流上。這里面其實(shí)主要有4個(gè)比較重要的用戶場景，第一個(gè)場景是產(chǎn)生分業(yè)務(wù)的Breakdown的信息，這個(gè)主要是能知道某一個(gè)用戶在不同的筆記維度，他的點(diǎn)擊率和一些其他的業(yè)務(wù)指標(biāo)，同時(shí)我也可以知道某一篇筆記針對不同的用戶，它產(chǎn)生的點(diǎn)擊率，這個(gè)是我們在實(shí)時(shí)推薦當(dāng)中一個(gè)比較重要的特征。另外一個(gè)很重要的是我們實(shí)時(shí)分析的一個(gè)寬表，寬表是我們把用戶的信息、筆記信息和用戶筆記交互的匯總信息，都變成了一個(gè)多維度的表，進(jìn)行實(shí)時(shí)分析，這個(gè)后面會更加詳細(xì)的和大家講述。然后還有兩個(gè)比較重要的，一個(gè)是實(shí)時(shí)訓(xùn)練的信息，訓(xùn)練的信息就是我把用戶和筆記交互的信息擴(kuò)充了，當(dāng)時(shí)排序的時(shí)候抓起的特征，這特征加上一些我們匯總出來的標(biāo)簽，就給模型進(jìn)行訓(xùn)練來更新模型。然后另外一個(gè)就是我所有的匯總信息都會進(jìn)入離線數(shù)據(jù)數(shù)倉，然后會進(jìn)行后續(xù)的一些分析和報(bào)表的處理。

流計(jì)算優(yōu)化—Flink批流一體

然后我這里講一下我們怎么運(yùn)用Flink的一些新功能來優(yōu)化流計(jì)算的過程。這里面我主要講兩點(diǎn)，其中第一點(diǎn)就是批流一體化。
剛才說了我們把一個(gè)用戶的行為根據(jù)筆記的行為匯總之后進(jìn)行分析，這里的匯總的信息其實(shí)很多的，匯總信息當(dāng)中，除了最簡單的，比如說用戶有沒有點(diǎn)贊收藏這篇筆記，其實(shí)還有一些比較復(fù)雜的標(biāo)簽，比如說用戶在筆記頁上停留了多長時(shí)間，或者是說這篇筆記之前的點(diǎn)擊是不是一個(gè)有效點(diǎn)擊，我們對于某些廣告場景或者有些場景下面，我們需要知道如果用戶點(diǎn)擊之后停留了比如說超過5秒，那么這個(gè)點(diǎn)擊是有效的。那么像這種復(fù)雜的邏輯，我們希望在我們的系統(tǒng)當(dāng)中只被實(shí)現(xiàn)一次，就可以同時(shí)運(yùn)用在實(shí)時(shí)和批的計(jì)算當(dāng)中。那么在傳統(tǒng)意義上這點(diǎn)是很難的，因?yàn)榇蠖鄶?shù)的實(shí)現(xiàn)中，批和流是兩個(gè)版本，就是我們在Flink上面，比如說實(shí)現(xiàn)了一個(gè)版本的有效點(diǎn)擊的定義，我們同時(shí)也會需要實(shí)現(xiàn)一個(gè)離線版本的有效點(diǎn)擊的定義，這個(gè)可能是一個(gè)SQL寫的版本。那么小紅書是運(yùn)用了FLIP-27里面的一個(gè)新的功能，日志文件是一個(gè)批的形式，它可以轉(zhuǎn)換成一個(gè)流的形式，這樣的話我就可以做到代碼意義上的批流統(tǒng)一。

流計(jì)算優(yōu)化—Multi-sink Optimization

那么還有一個(gè)Flink的功能就是一個(gè)在Flink 1.11上的Multi-sink Optimization。它的意思是我一份數(shù)據(jù)會寫到多個(gè)數(shù)據(jù)應(yīng)用上去，比如我會同時(shí)需要做張用戶行為的寬表，同時(shí)也生成一份離線的數(shù)據(jù)。那么Multi-sink Optimization做的是，你只需要從Kafka里面讀一次，如果是同一個(gè)key的話，他只需要去Lookup一次kv就可以產(chǎn)生多份數(shù)據(jù)，同時(shí)寫到多個(gè)sink，這樣可以大大減少我們對Kafka的壓力和對 kv查詢的壓力。

小紅書OLAP典型場景

最后我講一下我們的OLAP場景和阿里云MaxCompute、Hologres的一個(gè)合作。小紅書在推薦業(yè)務(wù)下面有很多OLAP場景，這里我講4個(gè)比較常見的場景應(yīng)用，最常見的其實(shí)就是根據(jù)用戶的實(shí)驗(yàn)組分組進(jìn)行比較的一個(gè)實(shí)時(shí)分析。因?yàn)槲覀冊谕扑]業(yè)務(wù)上面需要大量的調(diào)整策略或者是更新模型，然后每次調(diào)整策略和更新模型我們都會開一個(gè)實(shí)驗(yàn)，把用戶放到不同的ABtest里面來比較用戶的行為。那么一個(gè)用戶其實(shí)在推薦當(dāng)中會同時(shí)處于多個(gè)實(shí)驗(yàn)，在每一個(gè)實(shí)驗(yàn)里面是屬于一個(gè)實(shí)驗(yàn)組，我們按實(shí)驗(yàn)分組做的實(shí)驗(yàn)分析，主要就是把一個(gè)實(shí)驗(yàn)?zāi)贸鰜?#xff0c;然后把用戶的行為和匯總數(shù)據(jù)，根據(jù)這個(gè)實(shí)驗(yàn)當(dāng)中的實(shí)驗(yàn)組進(jìn)行分維度的分析，看看不同的實(shí)驗(yàn)組它的用戶指標(biāo)有什么差別。然后這個(gè)場景是一個(gè)非常常見的場景，但是也是計(jì)算量非常大的場景，因?yàn)樗枰鶕?jù)用戶的實(shí)驗(yàn)tag進(jìn)行分組。
然后另外一個(gè)場景就是我們小紅書的推薦其實(shí)是跑在了多個(gè)數(shù)據(jù)中心上面，不同的數(shù)據(jù)中心經(jīng)常有一些變動，比如說是運(yùn)維的變動，我們要起一個(gè)新的服務(wù)，或者是我們可能有些新的模型需要在某個(gè)計(jì)算中心先上線，那么我們需要一個(gè)端到端的方案去驗(yàn)證不同的數(shù)據(jù)中心之間的數(shù)據(jù)是不是一致，用戶在不同數(shù)據(jù)中心的體驗(yàn)是不是一樣。這個(gè)時(shí)候就需要我們根據(jù)不同的數(shù)據(jù)中心進(jìn)行比較，比較用戶在不同的數(shù)據(jù)中心當(dāng)中產(chǎn)生的行為，他們最終的指標(biāo)是不是一致，同樣我們也用到了我們的模型和代碼的發(fā)布當(dāng)中。我們會看一個(gè)模型發(fā)布或者一份代碼發(fā)布的老版本和新版本，他們產(chǎn)生的用戶的行為的指標(biāo)對比，看他們是不是一致。同樣我們的OLAP還用在了實(shí)時(shí)業(yè)務(wù)指標(biāo)的告警，如果用戶的點(diǎn)擊率和用戶的點(diǎn)贊數(shù)突然有一個(gè)大幅的下降，也會觸發(fā)我們的實(shí)時(shí)的告警。

小紅書OLAP數(shù)據(jù)的規(guī)模

在高峰時(shí)候我們大概每秒鐘有35萬條用戶行為被記入我們的實(shí)時(shí)計(jì)算當(dāng)中。然后我們大寬表大概有300個(gè)字段，然后我們希望能夠保持兩周多大概15天左右的數(shù)據(jù)，因?yàn)槲覀冊谧鰧?shí)驗(yàn)分析的時(shí)候，經(jīng)常需要看本周和上一周的數(shù)據(jù)的對比，然后我們大概每天有近千次的查詢。

小紅書+Hologres

我們在7月和阿里云的MaxComputer和Hologres進(jìn)行了一個(gè)合作。Hologres其實(shí)是新一代的智能數(shù)倉的解決方案，它能夠把實(shí)時(shí)和離線的計(jì)算都通過一站式的方法來解決。同時(shí)它的應(yīng)用主要可以用在實(shí)時(shí)大屏、Tableau和數(shù)據(jù)科學(xué)當(dāng)中，我們研究下來是比較適合我們的推薦場景的。

小紅書Hologres應(yīng)用場景

Hologres做的事情主要是對離線的數(shù)據(jù)進(jìn)行了查詢和加速，然后對離線的數(shù)據(jù)做表級別的交互查詢響應(yīng)，他就無須再做從離線把數(shù)據(jù)搬到實(shí)時(shí)數(shù)倉的這么一個(gè)工作，因?yàn)樗荚诶锩媪恕Ｕ麄€(gè)實(shí)時(shí)數(shù)倉，它是通過搭建用戶洞察體系，實(shí)時(shí)監(jiān)控平臺的用戶數(shù)據(jù)，可以從不同的角度對用戶進(jìn)行實(shí)時(shí)診斷，這樣可以幫助實(shí)施精細(xì)化的運(yùn)營。這個(gè)其實(shí)對于我們用戶大寬表來說也是一個(gè)非常適合的場景。然后它的實(shí)時(shí)離線的聯(lián)邦計(jì)算可以基于實(shí)時(shí)計(jì)算引擎和離線數(shù)倉MaxCompute交互分析，實(shí)時(shí)離線聯(lián)邦查詢，構(gòu)筑全鏈路精細(xì)化運(yùn)營。

Hologres VS? Clickhouse

在和阿里云MaxCompute合作之前，我們是自建了Clickhouse的集群，當(dāng)時(shí)我們也是一個(gè)很大規(guī)模的集群，一共用了1320個(gè)core，因?yàn)镃lickhouse它不是一個(gè)計(jì)算存儲分離的方案，所以當(dāng)時(shí)我們?yōu)榱斯?jié)約成本，只存放了7天的數(shù)據(jù)，然后因?yàn)镃lickhouse對于用戶實(shí)驗(yàn)tag這個(gè)場景其實(shí)沒有很好的優(yōu)化，所以說我們當(dāng)時(shí)查詢超過三天的數(shù)據(jù)就會特別慢。因?yàn)槭莻€(gè)OLAP場景，我們希望每次用戶的查詢能在兩分鐘之內(nèi)出結(jié)果，所以是限制了我們只能查過去三天的數(shù)據(jù)。同時(shí)另外還有一個(gè)問題就是Clickhouse對于組件的支持是有些問題的，所以我們沒有在Clickhouse集群上面配置組件，如果上游的數(shù)據(jù)流有些抖動，數(shù)據(jù)造成一些重復(fù)的情況下，下游的Clickhouse里面其實(shí)會有一些重復(fù)的數(shù)據(jù)。同時(shí)我們也是派了專人去運(yùn)維Clickhouse，然后我們通過調(diào)研發(fā)現(xiàn)，Clickhouse如果你要做成集群版的話，它的運(yùn)維成本還是很高的。所以我們在7月份的時(shí)候和阿里云合作，把我們推薦的一個(gè)最大的用戶寬表遷移到了MaxCompute和Hologres上面，然后我們在Hologres上面一共是1200個(gè)core，因?yàn)樗怯?jì)算存儲的方案，所以1200個(gè)core就足夠我們使用了。但是我們在存儲的方面是有更大的需求的，我們一共存了15天的數(shù)據(jù)，然后因?yàn)镠ologres對于用戶根據(jù)實(shí)驗(yàn)分組這個(gè)場景是做了一些比較定制化的優(yōu)化，所以說我們現(xiàn)在可以輕松地查詢7天到15天的數(shù)據(jù)，在這個(gè)根據(jù)實(shí)驗(yàn)組分組的場景下面，其查詢的性能與Clickhouse相比是有大幅提升的。Hologres它其實(shí)也支持Primary Key，所以我們也是配置了Primary Key，我們在這個(gè)場景下面是用了insert or ignore這個(gè)方法，然后因?yàn)榕渲昧薖rimary Key，它就天然具有去重的功能，這樣的話我們上游只要保證at least once，下游的數(shù)據(jù)就不會有重復(fù)。 然后因?yàn)槲覀兪欠旁诎⒗镌粕厦?#xff0c;所以說是沒有任何的運(yùn)維的成本。

?

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。