導讀：微博作為國內比較主流的社交媒體平臺，目前擁有2.22億日活使用者和5.16億月活使用者。如何為使用者實時推薦優質內容，背後離不開微博的大規模機器學習平臺。本文由微博機器學習研發中心高階演算法工程師於茜老師分享，主要內容包含以下四部分：
- 關於微博
- 微博機器學習平臺 ( WML ) 總覽
- Flink在WML中的應用
- 使用Flink的下一步計劃
01
關於微博
微博2008年上線，是目前國內比較主流的社交媒體平臺，擁有2.22億日活使用者和5.16億月活使用者，為使用者提供線上創作、分享和發現優質內容的服務；目前微博的大規模機器學習平臺可以支援千億引數和百萬QPS。
02
微博機器學習平臺 ( 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模型，加強線上機器學習模型的表達能力
03
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，可以避免一些重複計算，也是為了減少一些延時
- 所有實時任務都會起一個重試的任務，這樣在主流程中寫入失敗，會再次寫入到重試佇列中再進行一次重試的寫入，這樣保障資料會被計算兩次；如果最終還是寫入失敗，就會記錄到對賬離線系統中，這樣可以看到哪些資料是寫入失敗的，可以手動恢復一下。
04
使用Flink的下一步計劃
最後分享一下使用Fllink的下一步計劃：
1. 實時數倉
目前已經透過Flink SQL的方式實現了開發，但是實時和離線表的註冊還有元資料儲存是有一定差異的，希望可以抽象出一層API用統一的方式來進行實時和離線表的註冊以及元資料的儲存。
2. 基於Flink的DL
我們希望可以將離線的深度學習完全遷移到線上深度學習來做，這樣的話就需要用到TensorFlow on Flink，這樣就可以保證不管是模型訓練還是線上推理都可以使用同樣一套框架去完成，這樣就需要把離線訓練的全量模型也可以透過實時樣本進行增量訓練的一些校正，後面的步驟和之前基本上是保持一致的，這樣就可以將離線深度學習的這條Pipeline最佳化一些。
本次的分享就到這裡，謝謝大家。
嘉賓介紹：
於茜，微博機器學習研發中心高階演算法工程師。多年來致力於使用 Flink 構建實時資料處理和線上機器學習框架，有豐富的社交媒體應用推薦系統的開發經驗。
分享嘉賓：於茜 微博 高階演算法工程師
編輯整理：王洪達
內容來源：Flink Forward
