【王喆-推薦系統】前沿篇-(task3)流處理平臺Flink：實時推薦

學習總結

（1）Flink 是最具代表性的批流一體的大數據平臺。特點：讓批處理和流處理共用一套代碼，從而既能批量處理已落盤的數據，又能直接處理實時數據流。

（2）Flink 提高推薦系統實時性：用戶數據進入數據流，

即進入數據消息隊列后，會被分割成一定時長的時間窗口，之后 Flink 會按照順序來依次處理每個時間窗口內的數據，計算出推薦系統需要的特征

。這個處理是直接在實時數據流上進行的，所以相比原來基于 Spark 的批處理過程，實時性有了大幅提高。

（3）Flink的實時性實踐：利用 Flink 我們可以實時地獲取到用戶剛剛評價過的電影，然后通過實時更新用戶 Embedding，就可以實現 SparrowRecsys 的實時推薦了。

文章目錄

學習總結

一、實時性是影響推薦系統效果的關鍵因素

二、批流一體的數據處理體系

2.1 傳統批處理大數據架構

2.2 流處理大數據架構

2.3 同具批處理、流處理優勢的Flink

三、Flink如何處理數據流

3.1 數據流

3.2 窗口

四、Flink 數據流處理實踐

五、作業

六、課后答疑

Reference

栗子：2020年雙十一，阿里基于 Flink，實現了數據的批流一體處理，每秒能夠處理 40 億條的巨量數據。這也是業界首次在這么大規模的數據洪峰之上，實現數據流的實時處理。實時數據流處理功能的實現，讓阿里的推薦系統引擎能夠在雙 11 期間做出更快速的反應，實時抓住用戶的興趣，給出更準確的推薦。

帶著三個問題進行學習：

為什么說實時性是影響推薦系統效果的關鍵因素？

到底什么是批流一體的數據處理體系？

業界流行的 Flink 到底是怎么實現數據流處理的？

一、實時性是影響推薦系統效果的關鍵因素

ex：小明在刷抖音的足球視頻，接著會繼續推薦出相關視頻，如果推薦系統沒有實時抓住用戶的興趣點，推薦大媽廣場舞的視頻，小明可能會對該產品失去興趣哈哈。

二、批流一體的數據處理體系

2.1 傳統批處理大數據架構

數據處理中，無論是數據的預處理，還是特征工程，大部分是在 Spark 平臺上完成的。

Spark 平臺的特點：它處理的數據都是已經落盤的數據。即這些數據要么是在硬盤上，要么是在分布式的文件系統上，然后才會被批量地載入到 Spark 平臺上進行運算處理，這種批量處理大數據的架構就叫做批處理大數據架構（整體架構圖如下圖所示）。

批處理架構的特點：慢，數據從產生到落盤，再到被 Spark 平臺重新讀取處理，往往要經歷幾十分鐘甚至幾小時的延遲。如果推薦系統是建立在這樣的數據處理架構上，很難實時地抓住用戶的新興趣點。

2.2 流處理大數據架構

流處理大數據架構：在數據產生之后就立馬處理它，而不是等到它落盤后再重新處理它；

即在數據產生后就直接對數據流進行處理

的架構。

它和批處理大數據架構相比，不僅用流處理平臺替換掉了分布式批處理 Map Reduce 計算平臺，而且在數據源與計算平臺之間，也不再有存儲系統這一層。這就大大提高了數據處理的速度，讓數據的延遲可以降低到幾分鐘級別，甚至一分鐘以內，這也讓實時推薦成為了可能。

缺點：由于流處理平臺是對數據流進行直接處理，它沒有辦法進行長時間段的歷史數據的全量處理，這就讓流處理平臺無法應用在歷史特征的提取，模型的訓練樣本生成這樣非常重要的領域。

2.3 同具批處理、流處理優勢的Flink

批流一體的大數據架構最重要的特點，就是在流處理架構的基礎上添加了數據重播的功能。

數據重播功能：指的是在數據落盤之后，還可以

利用流處理平臺同樣的代碼，進行落盤數據的處理

，這就相當于進行了一遍重播。這樣就實現了離線環境下的數據批處理。而且由于流處理和批處理使用的是一套代碼，因此完美保證了代碼維護的一致性，是近乎完美的數據流解決方案。

很少公司實現這套方案的原因：有兩大難點

大批成熟的互聯網公司已經在 Spark 等批處理平臺上，構建起了整套的數據體系，要想完全遷移到批流一體的數據體系上，有著非常沉重的技術負擔。

批流一體的解決方案還很理想化，因為我們在實際處理特征的時候，很難讓批處理和流處理完全共享一套代碼。

ex：在流處理中可以很方便地計算出點擊量、曝光量這類方便累計的指標，但如果遇到比較復雜的特征，像是用戶過去一個月的平均訪問時長，用戶觀看視頻的進度百分比等等，這些指標就很難在流處理中計算得到了。這是因為計算這類特征所需的數據時間跨度大，計算復雜，流處理難以實現。

小結：對待流處理平臺，取其所長。

具體點：在需要實時計算的地方發揮它的長處，但也沒有必要過于理想主義，強調一切應用都應該批流一體，這反而會為我們增加過多的技術負擔。

三、Flink如何處理數據流

Flink 中兩個最重要的概念，數據流（DataStream）和窗口（Window）。

3.1 數據流

數據流其實就是消息隊列，從網站、APP 這些客戶端中產生的數據，被發送到服務器端的時候，就是一個數據消息隊列，而流處理平臺就是要對這個消息隊列進行實時處理。

下圖所示：來自三個用戶的數據，其中一個一個紫色的點就是一條條數據，所有紫色的點按時間排列就形成了一個消息隊列。

3.2 窗口

Flink 會怎么處理這個消息隊列里的數據呢？

隨著時間的流失，按照時間窗口來依次處理每個時間窗口內的數據。

比如圖 4 中的數據流就被分割成了 5 個時間窗口，每個窗口的長度假設是 5 分鐘，這意味著每積攢夠 5 分鐘的數據，Flink 就會把緩存在內存中的這 5 分鐘數據進行一次批處理。這樣，我們就可以算出數據流中涉及物品的最新 CTR，并且根據用戶最新點擊的物品來更新用戶的興趣向量，記錄特定物品曝光給用戶的次數等等。

除了上面例子中的固定窗口以外，Flink 還提供了多種不同的窗口類型，滑動窗口（Sliding Window）也是經常會用到的。

滑動窗口的特點是在兩個窗口之間留有重疊的部分，Flink 在移動窗口的時候，不是移動 window size 這個長度，而是

移動 window slide 這個長度，window slide 的長度要小于 window size

。因此，窗口內部的數據不僅包含了數據流中新進入的 window slide 長度的數據，還包含了上一個窗口的老數據，這部分數據的長度是 window size-window slide。

問：滑動窗口這種方式有什么用呢？

答：它最典型的用處就是做一些數據的 JOIN 操作。比如我們往往需要通過 JOIN 連接一個物品的曝光數據和點擊數據，以此來計算 CTR，但是注意

曝光數據肯定是在點擊數據之前到達 Flink 的

。

那如果在分窗的時候，恰好把曝光數據和點擊數據分割在了兩個窗口怎么辦呢？那點擊數據就不可能找到相應的曝光數據了。這個時候，只要我們使用滑動窗口，這個問題就迎刃而解了。因為兩個窗口重疊的部分給我們留了足夠的余量來進行數據 JOIN，避免數據的遺漏。

除了固定窗口和滑動窗口，Flink 還提供了更豐富的窗口操作，比如基于會話的 Session Window，全局性的 Global Window。

除此之外，Flink 還具有數據流 JOIN，狀態保存特性 state 等眾多非常有價值的操作，想繼續學習可以參考 Flink 的官方文檔 。本次task只要清楚

Flink 的核心概念數據流和時間窗口

就可以了，因為它反映了流處理平臺最核心的特點。

四、Flink 數據流處理實踐

在 SparrowRecsys 項目上利用 Flink 實現一個特征更新的應用。

因為沒有真實的數據流環境，所以我們可以利用 MoviesLens 的 ratings 表來模擬一個用戶評分的數據流，然后基于這個數據流，利用 Flink 的時間窗口操作，來實時地提取出用戶最近的評分電影，以此來反映用戶的興趣。

（詳細代碼：com.sparrowrecsys.nearline.flink.RealTimeFeature）。

（1）首先定義了一個評分的數據流 ratingStream，然后在處理 ratingStream 的時候，是把 userId 作為 key 進行處理。

（2）接著，又利用到了兩個函數 timeWindow 和 reduce。利用 timeWindow 函數，我們可以把處理的時間窗口設置成 1s，再利用 reduce 函數，把每個時間窗口到期時觸發的操作設置好。

（3）在完成了 reduce 操作后，我們再觸發 addSink 函數中添加的操作，進行數據存儲、特征更新等操作。

DataStream ratingStream = inputStream.map(Rating::new); ratingStream.keyBy(rating -> rating.userId) .timeWindow(Time.seconds(1)) .reduce( (ReduceFunction) (rating, t1) -> { if (rating.timestamp.compareTo(t1.timestamp) > 0){ return rating; }else{ return t1; } } ).addSink(new SinkFunction() { @Override public void invoke(Rating value, Context context) { System.out.println("userId:" + value.userId + "\tlatestMovieId:" + value.latestMovieId); } });

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

問：怎么把用戶最近的高分電影評價歷史，實時反映到推薦結果上？

答：我們的用戶 Embedding 是通過平均用戶的高分電影 Embedding 得到的，我們只需要在得到新的高分電影后，實時地更新用戶 Embedding 就可以了，然后在推薦過程中，用戶的推薦列表自然會發生實時的變化。這就是 SparrowRecsys 基于 Flink 的實時推薦過程。

五、作業

（1）實時性是不是對所有推薦系統都非常重要？比如對于抖音、快手這類短視頻應用，還有優酷、Netflix 這類長視頻應用，實時性對哪個更重要一些？為什么？

答：短視頻應用的實時性要求更高！因為相同時間內，短視頻用戶的單視頻停留周期短、場景更換頻繁，用戶興趣反饋信息更多；

（2）Flink 要加強的往往是數據的實時性，特征的實時性，你覺得模型訓練的實時性重要嗎？模型訓練的實時性發揮的作用和特征實時性有什么不同呢？

常說的推薦實時=7特征實時+3模型實時，都很重要！特征實時推薦是加強當前用戶關注話題（現在、個別），模型訓練實時推薦加強的用戶未來關注的話題（下次、整體）。業界常見的做法，基于用戶特征實時變化的推薦（熱周期-用戶活躍期），至于模型訓練（或強化學習）放在冷周期（用戶睡眠期）。

六、課后答疑

Reference

（1）https://github.com/wzhe06/Reco-papers

（2）《深度學習推薦系統實戰》，王喆

（3）flink官方文檔：https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/dev/datastream/operators/windows/

Flink 推薦系統

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。