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

導讀：微博作為國內(nèi)比較主流的社交媒體平臺，目前擁有2.22億日活用戶和5.16億月活用戶。如何為用戶實時推薦優(yōu)質(zhì)內(nèi)容，背后離不開微博的大規(guī)模機器學習平臺。本文由微博機器學習研發(fā)中心高級算法工程師于茜老師分享，主要內(nèi)容包含以下四部分：

• 關(guān)于微博

• 微博機器學習平臺 ( WML ) 總覽

• Flink在WML中的應用

• 使用Flink的下一步計劃

微博2008年上線，是目前國內(nèi)比較主流的社交媒體平臺，擁有2.22億日活用戶和5.16億月活用戶，為用戶提供在線創(chuàng)作、分享和發(fā)現(xiàn)優(yōu)質(zhì)內(nèi)容的服務；目前微博的大規(guī)模機器學習平臺可以支持千億參數(shù)和百萬QPS。

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

1. 總覽

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

• 集群層：包含離線計算集群、在線計算集群和高性能計算集群；

• 調(diào)度層：包含自研的WeiBox ( 提供使用通用的接口將任務提交到不同集群的能力 )、Weiflow ( 提供將任務間的依賴關(guān)系處理好、組成DAG工作流的能力 )，以及常見的調(diào)度引擎Yarn和K8s；

• 計算平臺層：包含自研的WeiLearn ( 提供給用戶在該平臺做業(yè)務開發(fā)的能力 )，以及Hadoop/Spark離線計算平臺、Flink/Storm在線計算平臺和Tensorflow機器學習平臺；

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

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

• 業(yè)務應用層：主要應用場景是特征生成、樣本服務、在線訓練和在線推理；

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

2. 開發(fā)模式

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

• 內(nèi)層，WeiLearn層里面可以重寫離線的Input、Process和Output方法以及實時的Source、Process和Sink方法，用戶自己開發(fā)一個UDF來實現(xiàn)自己的業(yè)務邏輯；內(nèi)層的每一個DAG都會組成一個Task。

• 外層，即第二層DAG層，WeiFlow層里面將WeiLearn中產(chǎn)生的Task的依賴關(guān)系組成一個集群內(nèi)或者跨集群的WorkFlow，然后運行計算。

3. CTR模型

介紹一下CTR模型在微博迭代的情況，經(jīng)過幾年的研究和探索，目前支撐的參數(shù)規(guī)模達千億級，服務峰值達百萬QPS，模型更新的周期大概在10分鐘左右；現(xiàn)在是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中的架構(gòu)

1. 概覽

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

• 基礎架構(gòu)層：包含Storm集群、Flink集群、Flume以及用于監(jiān)控系統(tǒng)運行的Grafana。

• 計算層：主要是對Pig和Flink的進一步封裝，包含WeiPig + WeiStream和WeiLearn + WeiFlink；左側(cè)為實時數(shù)據(jù)源，包含實時消息隊列、Redis、Kafka；一些歷史數(shù)據(jù)會存到右側(cè)的HDFS中。

• 應用層：目前這套平臺主要應用于多媒體特征生成、內(nèi)容去重、數(shù)據(jù)同步、實時特征生成、樣本服務以及在線訓練。

• 業(yè)務層：支撐了目前微博主要的幾個業(yè)務，包含熱門微博、關(guān)系流、視頻推薦、內(nèi)容監(jiān)控和圖片推薦。

接下來看一下Flink在ETL的Pipeline中的概覽：之前是有兩個Pipeline，一個為在線的，以前是使用Storm進行的處理，目前正在往Flink遷移，兩套現(xiàn)在處于并行狀態(tài)，處理流程是從消息隊列中獲取數(shù)據(jù)進行處理，然后給到在線訓練模塊 ( Flink和Spark Streaming并行 )，最后提供模型服務給推薦系統(tǒng)調(diào)用；一個為離線的，和在線類似，首先寫入到HDFS交給Hive或Spark進行處理，再次落到HDFS中交給離線訓練使用，最后提供模型服務給推薦系統(tǒng)調(diào)用。因為有兩類ETL的Pipeline，使用不同的框架，需要維護兩套代碼，維護成本較高。

目前做的就是將兩套融合成一套，進行批流統(tǒng)一的處理，此處可能會用到FlinkSQL，然后將ETL后的數(shù)據(jù)輸出到實時消息隊列或者HDFS中，交給在線和離線模型訓練，最后提供模型服務給推薦系統(tǒng)調(diào)用。

2. 樣本服務

介紹一下樣本生成服務，上圖為該服務的整體架構(gòu)圖，包含樣本數(shù)據(jù)的處理和計算等，除了一些生成的離線和實時數(shù)據(jù)外，還需要一些已經(jīng)生成好的特征的引用，通過普通計算、多流Join、深度學習等處理方式生成樣本，最后存儲到樣本庫中供模型訓練來調(diào)用。

這個是樣本服務任務提交的方式，可以通過之前提到的WeiClient命令行方式提交，也可以通過WAIC UI方式指定樣本ID以及UDF的class name和要拼接的特征ID，通過一種統(tǒng)一的方式將作業(yè)提交到集群上；之后是通過Twinkle或VVP的方式提交到Flink集群，然后會對作業(yè)狀態(tài)進行管理，通過Grafana進行監(jiān)控和報警，將歷史作業(yè)信息存儲到HDFS中。

3. 多流Join

這是微博目前的一個主流場景，多數(shù)據(jù)流Join場景 ( 大部分是大于等于3 )：有N個數(shù)據(jù)源，通過過濾和映射的處理后按照Key進行分發(fā)，在Joining Window中進行join后 ( 此處后面會詳細講 )，會再進行一次過濾和映射以及添加特征，最后輸出到樣本庫中。

接下來看一下剛剛講到的拼接窗口的實現(xiàn)方式，這是和業(yè)務比較相關(guān)的，對于CTR場景來說日志有很多種 ( 多個行為日志 )，但是到達的時間并不完全一致，比如點擊這種行為日志可能會比曝光日志到的晚一些；這樣就會需要一個時間窗口，以10分鐘為例，如果某種日志先到了，就會將對應的key和value存儲到State中，狀態(tài)存儲這塊是基于RocksDB和HDFS做的；經(jīng)過這個十分鐘窗口之后，拼接好的樣本數(shù)據(jù)會輸?shù)綄崟r流中；此處基于Flink做了一些優(yōu)化：

• 因為窗口是10分鐘的，但是如果10分鐘內(nèi)日志數(shù)據(jù)已經(jīng)全部到達，就不同等到10分鐘窗口結(jié)束后再輸出去；所以自定義了樣本trigger觸發(fā)機制，樣本拼接成功后就可以立即輸出，這樣可以減少一些時延

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

• 另外在RocksDB做狀態(tài)存儲這部分，引用了Gemini與RocksDB作對比，Gemini的IO性能更好一些

• 拼接窗口時長的控制是和業(yè)務場景比較相關(guān)的，日志到達的時間和具體的業(yè)務場景是有關(guān)系的，所以需要權(quán)衡時間窗口設置多長時間才能滿足拼接成功率的預期，這塊需要大量的離線計算和A/B Test來共同決定。

4. 多媒體特征生成

介紹一下Flink在多媒體特征生成場景的應用，此處主要是依賴離線計算的深度學習模型，因此整體的模型訓練走的是離線的Pipeline，將數(shù)據(jù)在離線的GPU集群進行分布式的模型訓練，然后將模型部署到GPU上面供在線推理的時候調(diào)用；在線推理模塊接收到圖片流、文本流和視頻流這些實時數(shù)據(jù)之后，首先會通過RPC調(diào)用GPU上的模型，然后將多媒體特征結(jié)果寫入到數(shù)據(jù)中臺，由業(yè)務方去讀取結(jié)果來使用，因為這塊是一個實時的任務作業(yè)，服務穩(wěn)定性需要一定的保障 ( 4個9的成功率、秒級延遲、配置化開發(fā)模式 )，下面會對服務保障做詳細介紹。

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

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

• 設置消息機制是At least once，每條消息至少要被處理一次，這樣可以保障每條數(shù)據(jù)結(jié)果都能寫到特征工程中

• 任何一個部分出現(xiàn)問題都會實現(xiàn)自動重啟

• 重啟時可以從checkpoints中恢復數(shù)據(jù)和State，可以避免一些重復計算，也是為了減少一些延時

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

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

1. 實時數(shù)倉

目前已經(jīng)通過Flink SQL的方式實現(xiàn)了開發(fā)，但是實時和離線表的注冊還有元數(shù)據(jù)存儲是有一定差異的，希望可以抽象出一層API用統(tǒng)一的方式來進行實時和離線表的注冊以及元數(shù)據(jù)的存儲。

2. 基于Flink的DL

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

本次的分享就到這里，謝謝大家。

嘉賓介紹：

于茜，微博機器學習研發(fā)中心高級算法工程師。多年來致力于使用 Flink 構(gòu)建實時數(shù)據(jù)處理和在線機器學習框架，有豐富的社交媒體應用推薦系統(tǒng)的開發(fā)經(jīng)驗。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝