微博基於 Flink 的機器學習實踐

關於微博

微博 2008 年上線，是目前國內比較主流的社交媒體平臺，擁有 2。22 億日活使用者和 5。16 億月活使用者，為使用者提供線上創作、分享和發現優質內容的服務；目前微博的大規模機器學習平臺可以支援千億引數和百萬 QPS。

微博機器學習平臺 （ WML ） 總覽

接下來介紹一下微博機器學習平臺，即 WML 的總覽；機器學習平臺 （ WML ） 為 CTR、多媒體等各類機器學習和深度學習演算法提供從樣本處理、模型訓練、服務部署到模型預估的一站式服務。

1。 總覽

上方是 WML 的一個整體架構圖，共分為六層，從下至上依次介紹：

叢集層：包含離線計算叢集、線上計算叢集和高效能計算叢集；

排程層：包含自研的 WeiBox （ 提供使用通用的介面將任務提交到不同叢集的能力 ）、Weiflow （ 提供將任務間的依賴關係處理好、組成 DAG 工作流的能力 ），以及常見的排程引擎 Yarn 和 K8s；

計算平臺層：包含自研的 WeiLearn （ 提供給使用者在該平臺做業務開發的能力 ），以及 Hadoop/Spark 離線計算平臺、Flink/Storm 線上計算平臺和 Tensorflow 機器學習平臺；

模型訓練層：目前支援 LR、GBDT、FM/FFM、CF/MF、DNN/RNN 等主流的演算法；

線上推理層：包含自研的 WeiServing和WeiPS；

業務應用層：主要應用場景是特徵生成、樣本服務、線上訓練和線上推理；

右邊是自定義的一些概念，樣本庫、模型庫、服務庫以及兩個任務提交方式WeiClient （ CLI 方式提交 ）、WAIC UI （ 介面操作 ）。

2。 開發模式

接下來介紹一下開發模式，有兩層 DAG 的設計：

內層，WeiLearn 層裡面可以重寫離線的 Input、Process 和 Output 方法以及實時的 Source、Process 和 Sink 方法，使用者自己開發一個 UDF 來實現自己的業務邏輯；內層的每一個 DAG 都會組成一個 Task。

外層，即第二層 DAG 層，WeiFlow 層裡面將 WeiLearn 中產生的 Task 的依賴關係組成一個叢集內或者跨叢集的 WorkFlow，然後執行計算。

3。 CTR 模型

介紹一下 CTR 模型在微博迭代的情況，經過幾年的研究和探索，目前支撐的引數規模達千億級，服務峰值達百萬 QPS，模型更新的週期大概在 10 分鐘左右；現在是 Weilearn6。0 版本，可以看到 WeiLearn 在不斷完善更新自己的演算法：

1。0 版本僅支援 LR 離線學習

2。0 版本支援 LR/GBDT/LR+GBDT 離線學習

3。0 版本支援 LR/GBDT/LR+GBDT 離線學習以及 Wide&Deep 的深度學習

4。0 版本支援 LR/GBDTLR+GBDT/FM/MF 離線學習以及 Wide&Deep 的深度學習

5。0 版本支援 Online FM/FFM 線上學習，LR/GBDT/LR+GBDT/FM/MF 離線學習以及 Wide&Deep/DeepFM/DSSM 的深度學習

6。0 版本更新了 Online DNN 模型，加強線上機器學習模型的表達能力

Flink 在 WML 中的應用

下面介紹 Flink 在微博機器學習平臺 WML 中的架構

1。 概覽

上圖為實時計算平臺的整體情況，接下來詳細介紹一下各模組：

基礎架構層：包含 Storm 叢集、Flink 叢集、Flume 以及用於監控系統執行的 Grafana。

計算層：主要是對 Pig 和 Flink 的進一步封裝，包含 WeiPig + WeiStream 和 WeiLearn + WeiFlink；左側為實時資料來源，包含實時訊息佇列、Redis、Kafka；一些歷史資料會存到右側的 HDFS 中。

應用層：目前這套平臺主要應用於多媒體特徵生成、內容去重、資料同步、實時特徵生成、樣本服務以及線上訓練。

業務層：支撐了目前微博主要的幾個業務，包含熱門微博、關係流、影片推薦、內容監控和圖片推薦。

接下來看一下 Flink 在 ETL 的 Pipeline 中的概覽：之前是有兩個 Pipeline，一個為線上的，以前是使用 Storm 進行的處理，目前正在往 Flink 遷移，兩套現在處於並行狀態，處理流程是從訊息佇列中獲取資料進行處理，然後給到線上訓練模組 （ Flink 和 Spark Streaming 並行 ），最後提供模型服務給推薦系統呼叫；一個為離線的，和線上類似，首先寫入到 HDFS 交給 Hive 或 Spark 進行處理，再次落到 HDFS 中交給離線訓練使用，最後提供模型服務給推薦系統呼叫。因為有兩類 ETL 的 Pipeline，使用不同的框架，需要維護兩套程式碼，維護成本較高。

目前做的就是將兩套融合成一套，進行批流統一的處理，此處可能會用到 FlinkSQL，然後將 ETL 後的資料輸出到實時訊息佇列或者 HDFS 中，交給線上和離線模型訓練，最後提供模型服務給推薦系統呼叫。

2。 樣本服務

介紹一下樣本生成服務，上圖為該服務的整體架構圖，包含樣本資料的處理和計算等，除了一些生成的離線和實時資料外，還需要一些已經生成好的特徵的引用，透過普通計算、多流 Join、深度學習等處理方式生成樣本，最後儲存到樣本庫中供模型訓練來呼叫。

這個是樣本服務任務提交的方式，可以透過之前提到的 WeiClient 命令列方式提交，也可以透過 WAIC UI 方式指定樣本 ID 以及 UDF 的 class name 和要拼接的特徵 ID，透過一種統一的方式將作業提交到叢集上；之後是透過 Twinkle 或 VVP 的方式提交到 Flink 叢集，然後會對作業狀態進行管理，透過 Grafana 進行監控和報警，將歷史作業資訊儲存到 HDFS 中。

3。 多流 Join

這是微博目前的一個主流場景，多資料流 Join 場景 （ 大部分是大於等於 3 ）：有 N 個數據源，透過過濾和對映的處理後按照 Key 進行分發，在 Joining Window 中進行 Join 後 （ 此處後面會詳細講 ），會再進行一次過濾和對映以及新增特徵，最後輸出到樣本庫中。

接下來看一下剛剛講到的拼接視窗的實現方式，這是和業務比較相關的，對於 CTR 場景來說日誌有很多種 （ 多個行為日誌 ），但是到達的時間並不完全一致，比如點選這種行為日誌可能會比曝光日誌到的晚一些；這樣就會需要一個時間視窗，以 10 分鐘為例，如果某種日誌先到了，就會將對應的 Key 和 Value 儲存到 State 中，狀態儲存這塊是基於 RocksDB 和 HDFS 做的；經過這個十分鐘視窗之後，拼接好的樣本資料會輸到實時流中；此處基於 Flink 做了一些最佳化：

因為視窗是 10 分鐘的，但是如果 10 分鐘內日誌資料已經全部到達，就不同等到 10 分鐘視窗結束後再輸出去；所以自定義了樣本 Trigger 觸發機制，樣本拼接成功後就可以立即輸出，這樣可以減少一些時延

樣本補償 PU loss；此處是基於 Twitter 在 2019 年發的一篇論文的實現方式，就是拿到正樣本之後，首先對正樣本做一個梯度下降的處理，另外可能之前有 False Negative 的樣本已經發送出去了，那就需要之前的樣本進行補償，所以需要對該樣本的負樣本做一個反向的梯度下降

另外在 RocksDB 做狀態儲存這部分，引用了 Gemini 與 RocksDB 作對比，Gemini 的 IO 效能更好一些

拼接視窗時長的控制是和業務場景比較相關的，日誌到達的時間和具體的業務場景是有關係的，所以需要權衡時間視窗設定多長時間才能滿足拼接成功率的預期，這塊需要大量的離線計算和 A/B Test 來共同決定。

4。 多媒體特徵生成

介紹一下 Flink 在多媒體特徵生成場景的應用，此處主要是依賴離線計算的深度學習模型，因此整體的模型訓練走的是離線的 Pipeline，將資料在離線的 GPU 叢集進行分散式的模型訓練，然後將模型部署到 GPU 上面供線上推理的時候呼叫；線上推理模組接收到圖片流、文字流和影片流這些實時資料之後，首先會透過 RPC 呼叫 GPU 上的模型，然後將多媒體特徵結果寫入到資料中臺，由業務方去讀取結果來使用，因為這塊是一個實時的任務作業，服務穩定性需要一定的保障 （ 4 個 9 的成功率、秒級延遲、配置化開發模式 ），下面會對服務保障做詳細介紹。

針對實時任務的服務保障做了如下的工作：

全鏈路監控報警 &Case 追蹤，針對模型服務到 RPC 的情況、模型關鍵指標以及樣本情況整體是有一個全流程的監控

設定訊息機制是 At least once，每條訊息至少要被處理一次，這樣可以保障每條資料結果都能寫到特徵工程中

任何一個部分出現問題都會實現自動重啟

重啟時可以從 Checkpoints 中恢復資料和 State，可以避免一些重複計算，也是為了減少一些延時

所有實時任務都會起一個重試的任務，這樣在主流程中寫入失敗，會再次寫入到重試佇列中再進行一次重試的寫入，這樣保障資料會被計算兩次；如果最終還是寫入失敗，就會記錄到對賬離線系統中，這樣可以看到哪些資料是寫入失敗的，可以手動恢復一下。

使用 Flink 的下一步計劃

最後分享一下使用 Fllink 的下一步計劃：

1。 實時數倉

目前已經透過 Flink SQL 的方式實現了開發，但是實時和離線表的註冊還有元資料儲存是有一定差異的，希望可以抽象出一層 API 用統一的方式來進行實時和離線表的註冊以及元資料的儲存。

2。 基於 Flink 的 DL

我們希望可以將離線的深度學習完全遷移到線上深度學習來做，這樣的話就需要用到 TensorFlow on Flink，這樣就可以保證不管是模型訓練還是線上推理都可以使用同樣一套框架去完成，這樣就需要把離線訓練的全量模型也可以透過實時樣本進行增量訓練的一些校正，後面的步驟和之前基本上是保持一致的，這樣就可以將離線深度學習的這條 Pipeline 最佳化一些。

嘉賓介紹：

於茜，微博機器學習研發中心高階演算法工程師。多年來致力於使用 Flink 構建實時資料處理和線上機器學習框架，有豐富的社交媒體應用推薦系統的開發經驗。

更多最佳實踐文章：

https：//

ververica。cn/corporate-

practice/