簡介： 微博通過將 Flink 實時流計算框架跟業務場景相結合，在平台化、服務化方面做了很大的工作，在開發效率、穩定性方面也做了很多優化。我們通過模塊化設計和平台化開發，提高開發效率。

微博機器學習研發中心數據計算負責人，高級系統工程師曹富強為大家帶來 Flink 實時計算在微博的應用介紹。內容包括：

1、微博介紹
2、數據計算平台介紹
3、Flink 在數據計算平台的典型應用

一、微博介紹

本次給大家帶來的分享是 Flink 實時計算在微博的應用。微博是中國領先的社交媒體平台，目前的日活躍用户是 2.41 億，月活躍用户是 5.5 億，其中移動用户佔比超過了 94%。

二、數據計算平台介紹

1. 數據計算平台概況

下圖為數據計算平台的架構圖。

• 首先是調度，這塊基於 K8s 和 Yarn 分別部署了實時數據處理的 Flink、Storm，以及用於離線處理的 SQL 服務。
• 在集羣之上，我們部署了微博的 AI 平台，通過這個平台去對作業、數據、資源、樣本等進行管理。
• 在平台之上我們構建了一些服務，通過服務化的方式去支持各個業務方。
  -實時計算這邊的服務主要包括數據同步、內容去重、多模態內容理解、實時特徵生成、實時樣本拼接、流式模型訓練，這些是跟業務關係比較緊密的服務。另外，還支持 Flink 實時計算和 Storm 實時計算，這些是比較通用的基礎計算框架。
  -離線這部分，結合 Hive 的 SQL，SparkSQL 構建一個 SQL 計算服務，目前已經支持了微博內部絕大多數的業務方。

數據的輸出是採用數倉、特徵工程這些數據中台的組建，對外提供數據輸出。整體上來説，目前我們在線跑的實時計算的作業將近 1000 多個，離線作業超過了 5000 多個，每天處理的數據量超過了 3 PB。

2. 數據計算

下面兩張圖是數據計算，其中一個是實時計算，另外一個是離線計算。

• 實時計算主要包括實時的特徵生成，多媒體特徵生成和實時樣本生成，這些跟業務關係比較緊密。另外，也提供一些基礎的 flink 實時計算和 storm 實時計算。
• 離線計算主要包括 SQL 計算。主要包括 SQL 的即席查詢、數據生成、數據查詢和表管理。表管理主要就是數倉的管理，包括表的元數據的管理，表的使用權限，還有表的上下游的血緣關係。

3. 實時特徵

如下圖所示，我們基於 Flink 和 Storm 構建了一個實時特徵生成的服務。整體上來説，它會分為作業詳情、輸入源特徵生成、輸出和資源配置。用户按照我們事先定義好的接口去開發特徵生成的 UDF 就可以。其他的像輸入、特徵寫入，都是平台自動提供的，用户只需要在頁面上配置就好。另外，平台會提供輸入數據源的監控、作業的異常監控、特徵寫入監控、特徵讀取監控等，這些都是自動生成的。

4. 流批一體

下面介紹我們基於 FlinkSQL 構建的批流一體。首先，我們會統一元數據，將實時日誌跟離線日誌通過元數據管理平台去統一。統一之後，用户在提交作業的時候，我們會有一個統一的調度層。調度這一塊，是根據作業的類型，作業的特點，目前集羣的負載的情況，將作業調度到不同的集羣上去。

目前調度層支持的計算引擎主要就是 HiveSQL，SparkSQL 跟 FlinkSQL。Hive 和 Spark 的 SQL 主要用於批量計算，FlinkSQL 是做批流混跑。整個結果會輸出到數據倉庫中，提供給業務方使用。批流一體這塊大概有 4 個關鍵點：

• 第一，批流代碼統一，提高開發效率。
• 第二，批流元數據統一。統一管理，保證元數據一致。
• 第三，批流程序混跑，節省資源。
• 第四，批流統一調度，提高集羣利用率。

5. 數據倉庫

• 針對離線倉庫，我們把數據分成了三層，一個是原始日誌，另外一個是中間層，還有一個是數據服務層。中間是元數據的統一，下邊是實時數倉。
• 針對實時數倉，我們通過 FlinkSQL 對這些原始日誌做流式的一個 ETL，再通過一個流式彙總將最終的數據結果寫到數據的服務層，同時也會把它存儲到各種實時存儲，比如 ES、Hbase、Redis、ClickHouse 中去。我們可以通過實時存儲對外提供數據的查詢。還提供數據進一步數據計算的能力。也就是説，建立實時數倉主要是去解決離線特徵生成的週期長的問題。另外就是使用 FlinkSQL 去解決 streaming 作業開發週期比較長的問題。其中的一個關鍵點還是離線數倉跟實時數倉的元數據的管理。
  

三、Flink 在數據計算平台的典型應用

1. 流式機器學習

首先介紹流式機器學習的幾個特點，最大的特點就是實時化。這塊分為特徵的實時化和模型的實時化。

• 特徵實時化主要是為了更及時的去反饋用户行為，更細粒度的去刻畫用户。
• 模型實時化是要根據線上樣本實時訓練模型，及時反映對象的線上變化情況。

■ 微博流式機器學習的特點：

• 樣本的規模大，目前的實時樣本能達到百萬級別的 qps。
• 模型的規模大。模型訓練參數這塊，整個框架會支持千億級別的訓練規模。
• 對作業的穩定性要求比較高。
• 樣本的實時性要求高。
• 模型的實時性高。
• 平台業務需求多。

■ 流式機器學習有幾個比較難的問題：

• 一個就是全鏈路，端到端的鏈路是比較長的。比如説，一個流式機器學習的流程會從日誌收集開始，到特徵生成，再到樣本生成，然後到模型訓練，最終到服務上線，整個流程非常長。任何一個環節有問題，都會影響到最終的用户體驗。所以我們針對每一個環節都部署了一套比較完善的全鏈路的監控系統，並且有比較豐富的監控指標。
• 另外一個是它的數據規模大，包括海量的用户日誌，樣本規模和模型規模。我們調研了常用的實時計算框架，最終選擇了 Flink 去解決這個問題。

■ 流失機器學習流程：

• 首先是離線訓練，我們拿到離線日誌，去離線的生成樣本之後，通過Flink去讀取樣本，然後去做離線訓練。訓練完成之後把這些訓練的結果參數保存在離線的參數服務器中。這個結果會作為模型服務的 Base 模型，用於實時的冷啓動。
• 然後是實時的流式機器學習的流程。我們會去拉取實時的日誌，比如説微博的發佈內容，互動日誌等。拉取這些日誌之後，使用 Flink 去生成它的樣本，然後做實時的訓練。訓練完成之後會把訓練的參數保存在一個實時的參數服務器中，然後會定期的從實時的參數服務器同步到實時的參數服務器中。
• 最後是模型服務這一塊，它會從參數服務中拉取到模型對應的那些參數，去推薦用户特徵，或者説物料的特徵。通過模型對用户和物料相關的特徵、行為打分，然後排序服務會調取打分的結果，加上一些推薦的策略，去選出它認為最適合用户的這一條物料，並反饋給用户。用户在客户端產生一些互動行為之後，又發出新的在線請求，產生新的日誌。所以整個流式學習的流程是一個閉環的流程。
• 另外，
• 離線的樣本的延時和模型的更新是天級或者小時級，而流式則達到了小時級或者分鐘級；
• 離線模型訓練的計算壓力是比較集中的，而實時的計算壓力比較分散。

■ 樣本
這裏簡單介紹一下我們流式機器學習樣本的發展歷程。2018 年 10 月，我們上線了第一個流式樣本作業，是通過 Storm 和外部存儲 Redis 去做的。2019 年 5 月，我們使用新的實時計算框架 Flink，採用 union+timer 方案替代 window 計算來實現多個數據流的 join 操作。2019 年 10月，上線了一個xx樣本作業，單個作業的 qps 達到了幾十萬。在今年 4 月份，把樣本生成流程平台化。到今年 6 月份，平台化做了一個迭代，支持樣本的落盤，包括樣本庫，還有樣本的各種監控指標的完善。

流式機器學習所謂的樣本生成，其實就是多個數據流按照相同的 key 做一個拼接。比如説，我們有三個數據流，數據清洗後的結果存儲為 , k 是聚合的 key，v 是樣本中需要的值。數據 union 後做 KeyBy 聚合，聚合後將數據存儲在內存區域 value state 中。如下圖所示：

• 如果 k1 不存在，則註冊 timer，再存到 state 中。
• 如果 k1 存在，就從 state 中把它給拿出來，更新之後再存進去。到最後它的 timer 到期之後，就會將這條數據輸出，並且從 state 中清除掉。

■ 樣本平台
我們把整個樣本拼接的過程做了一個平台化的操作，分成了 5 個模塊，包括輸入、數據清洗、樣本拼接、樣本的格式化和輸出。基於平台化開發，用户只需要關心業務邏輯部分即可。需要用户開發的有：

• 對應輸入數據的數據清洗邏輯。
• 樣本輸出前的數據格式化邏輯。

其餘的在UI上配置即可實現，具體有：

• 樣本拼接的時間窗口。
• 窗口內對字段的聚合操作。

資源由平台方審核並配置。另外，整個平台提供基礎的一些監控，包括輸入數據的監控、樣本指標的監控、作業異常監控、樣本輸出量的監控。

■ 流式機器學習項目的樣本 UI
下圖為流式機器學習項目的樣本。左邊是樣本生成的作業配置，右邊是樣本庫。樣本庫主要是做樣本的管理展示，包括樣本的説明權限，樣本的共享情況等等。

■ 流失機器學習的應用
最後介紹一下流式機器學習應用的效果。目前我們支持實時樣本拼接，QPS 達到百萬級別。支持流式模型訓練，可以同時支持幾百個模型訓練，模型實時性支持小時級/分鐘級 模型更新。流式學習全流程容災，支持全鏈路自動監控。近期在做的一個事情是流式的深度學習，增加實時模型的表達能力。還有強化學習這一塊，探索一些新的應用場景。

2. 多模態內容理解

■ 簡介
多模態就是使用機器學習的一些方法去實現或者理解多元模態信息的能力或者技術。微博的這塊主要包括圖片、視頻、音頻、文本。

• 圖片這塊包括，物體識別打標籤、OCR、人臉、明星、顏值、智能裁剪。
• 視頻這塊包括版權檢測、logo 識別。
• 音頻這塊有，語音轉文本、音頻的標籤。
• 文本主要包括文本的分詞、文本的時效性、文本的分類標籤。

舉個例子，我們一開始做視頻分類的時候只用到了視頻抽幀後的那些幀，也就是圖片。後來第二次優化的時候，加入了音頻相關的東西，還有視頻對應的博文相關的東西，相當於把音頻、圖片、文本，多模態的融合考慮，更精準的去生成這個視頻的分類標籤。

■ 平台
下圖為多模態內容理解的平台架構。中間這部分是 Flink 實時計算，實時的接收圖片流、視頻流、發博流這些數據，然後通過模型插件調用下邊的基礎服務，深度學習模型服務。調用服務之後，會返回內容特徵。然後我們把特徵存儲到特徵工程，通過數據中台對外提供給各個業務方。整個作業運行過程中全鏈路監控報警，異常情況第一時間響應。平台自動提供日誌收集，指標統計，CASE 追蹤等功能。中間這一塊使用 zk 做服務發現，解決實時計算和深度學習模型之間服務狀態同步的問題。另外，除了狀態同步，也會有一些負載均衡的策略。最下邊就是使用數據-對賬系統，進一步提高數據處理成功率。

■ UI
多模態內容理解的 UI，主要包括作業信息、輸入源信息、模型信息、輸出信息、資源配置。這塊通過配置化的開發，去提高開發效率。然後會自動生成模型調用的一些監控指標，包括模型調用的成功率和耗時。當作業提交之後，會自動生成一個用於指標統計的作業。

3. 內容去重服務

■ 背景
在推薦場景下，如果給用户一直推重複的內容，是很影響用户體驗的。基於這個考慮，結合 Flink 實時流計算平台、分佈式向量檢索系統和深度學習模型服務構建的一套內容去重服務平台,具有低延遲、高穩定性、高召回率的特點。目前支持多個業務方，穩定性達到 99.9+%。

■ 架構
下圖為內容去重服務的架構圖。最下邊是多媒體的模型訓練。這塊做離線的訓練。比如説我們會拿到一些樣本數據，然後去做樣本處理，樣本處理完之後把樣本存到樣本庫中去。當我需要做模型訓練的時候，我從樣本庫中去拉取樣本，然後做模型訓練，訓練好的結果會保存到模型庫中去。

內容去重這裏主要用到的模型是向量生成模型。包括圖片的向量、文本的向量、視頻的向量。

當我們把訓練好的模型驗證沒有問題之後，會把這個模型保存到模型庫中。模型庫保存了模型的一些基礎信息，包括模型的運行環境、版本。然後需要把模型部署上線，部署的過程需要從模型庫中拉取模型，同時需要知道這個模型的運行的一些技術環境。

模型部署好之後，我們會通過 Flink 實時的從物料庫中讀取物料，然後調用多媒體預估服務去生成這些物料對應的向量。然後會把這些向量保存在 Weiss 庫中，它是微博自研的一個向量召回檢索系統。存到 Weiss 庫中之後會對這條物料做向量召回的過程，召回跟這條物料相似的一批物料。在精排比對這塊，會從所有的召回結果中加上一定的策略，選出最相似的那一條。然後把最相似的這一條跟當前物料聚合到一起，形成一個內容 ID。最後業務去用的時候，也是通過物料對應的內容 ID 做去重。

■ 應用
內容去重的應用場景，主要業務場景有三個：

• 第一，支持視頻版權 - 盜版視頻識別 - 穩定性 99.99%，盜版識別率 99.99%。
• 第二，支持全站微博視頻去重 - 推薦場景應用 - 穩定性 99.99%，處理延遲秒級。
• 第三，推薦流物料去重 - 穩定性 99%，處理延遲秒級，準確率達到 90%

■ 最後
我們通過將 Flink 實時流計算框架跟業務場景相結合，在平台化、服務化方面做了很大的工作，在開發效率、穩定性方面也做了很多優化。我們通過模塊化設計和平台化開發，提高開發效率。目前實時數據計算平台自帶全鏈路監控，數據指標統計和 debug case 追蹤（日誌回看）系統。另外，基於 FlinkSQL 在批流一體這塊目前也有一定的應用。這些都是 Flink 給我們帶來的一些新的變化，我們會持續不斷的探索 Flink 在微博中更大的應用空間。

原文鏈接
本文為阿里雲原創內容，未經允許不得轉載。