基於 Apache Flink + Hologres 的實時推薦系統架構解析

簡介：《實時數倉入門訓練營》由阿里雲研究員王峯、阿里雲高級產品專家劉一鳴等實時計算 Flink 版和 Hologres 的多名技術/產品一線專家齊上陣，協力搭建這次訓練營的課程體系，精心打磨課程內容，直擊當下同窗們所遇到的痛點問題。由淺入深全方位解析實時數倉的架構、場景、以及實操應用，7 門精品課程幫助你 5 天時間從小白成長爲大牛！

本文整理自直播《基於 Apache Flink + Hologres 的實時推薦系統架構解析-秦江傑》
視頻連接:https://developer.aliyun.com/learning/course/807/detail/13888

摘要：本文由實時數倉線上課程秦江傑老師演講內容整理。
內容簡要：
1、實時推薦系統原理
2、實時推薦系統架構
3、基於 Apache Flink + Hologres 的實時推薦系統關鍵技術

實時推薦系統原理

（一）靜態推薦系統

在介紹實時推薦系統以前，先看一下靜態推薦系統是什麼樣子的。

上方是一個很是經典的靜態推薦系統的架構圖。前端會有不少用戶端的應用，這些用戶會產生大量用戶的行爲日誌，而後放到一個消息隊列裏面，進入ETL。接着經過離線系統去作一些特徵生成和模型訓練，最後把模型和特徵推到線上系統中，經過在線的服務就能夠去調用在線推理服務去得到推薦結果。
這就是一個很是經典的靜態推薦系統運做流程，下面咱們舉一個具體的例子來看靜態推薦系統究竟是怎麼樣工做的。

如上圖所示，好比在線用戶的行爲日誌多是一些用戶的瀏覽和廣告點擊的日誌，推薦系統的目的是爲了幫用戶推薦廣告，那麼在日誌裏面能夠看到如下用戶行爲：

用戶1和用戶2都看了PageID 200和一些其餘的頁面，而後用戶1看了PageID 200而且點了廣告2002，那麼在用戶日誌裏面經過ETL能夠把這樣的一系列行爲給概括出來，而後送到模型訓練裏面去訓練模型。在訓練模型的過程中咱們會用到一些特徵，在這個狀況下咱們能夠發現用戶1和用戶2都是中國的男性用戶，這多是用戶維度的一個特徵。

在這種狀況下，咱們從日誌裏面看到的結果是用戶在看了PageID 100後點了廣告2002，而且兩個用戶都是中國的男性用戶。所以，咱們的模型就有可能學到當中國的男性用戶來看PageID 100的時候，應該要給他展現廣告2002，這個行爲會被訓練到模型裏面去。這個時候咱們會把一些用戶的離線特徵都推到特徵庫，而後把這個模型也推到線上去。

假設這裏有一個用戶ID4，他正好是中國的男性用戶，這個特徵就會被推動特徵庫，那模型也被推到線上。若是用戶4來訪問的時候看PageID 100，推理服務會先去看用戶ID4的特徵，而後根據他是一箇中國的男性用戶，經過訓練的模型，系統就會給他推廣告2002，這是一個靜態推薦系統基本的工做原理。

在這種狀況下，若是發生一些變化的時候，咱們來看一下靜態推薦系統是否是可以繼續很好地工做？

假使說今天訓練了用戶1和用戶2的特徵模型，到次日發現用戶4產生了行爲，根據模型裏面的內容，模型會認爲用戶4是中國的男性用戶和用戶一、用戶2行爲一致，因此須要給他推的應該是中國男性用戶的行爲。但這個時候咱們發現用戶4的行爲其實跟用戶3更像，而不是跟用戶1和用戶2更像。

在這種狀況下，因爲模型和特徵都是靜態的，因此爲了讓用戶4可以跟用戶3獲得的行爲更像，須要去從新訓練模型，這會致使預測的效果被延遲，由於須要從新訓練用戶4，纔可以推薦出跟用戶3更像的一些行爲。

因此在這種實際操做狀況下，能夠看到靜態推薦模型存在一些問題：

• 靜態生成模型和特徵；

• 以分類模型爲例，根據用戶的類似性進行用戶分類，假設同類用戶有類似的興趣和行爲

  1. 例如中國的男性用戶有相似行爲。
  2. 一旦用戶被劃分爲某個類別，則他將一直處於這個類別中，直到被新的模型訓練從新分類。

這種狀況下，比較難去作到很好的推薦，緣由是：

• 用戶的行爲很是多元化，沒法劃分到某個固定類別
  1）上午爲父母採購保健品，中午爲出差訂酒店，晚上給家人買衣服…
  2）靜態系統沒法準確將用戶放到當時當刻正確的類別中。
• 某一類別用戶的行爲類似，可是行爲自己可能會發生變化
  1）假設用戶「隨大流「，可是「大流」可能發生變化；
  2）歷史數據看出來的「大流」可能沒法準確反映線上的真實狀況。

（二）加入實時特徵工程的推薦系統

爲了解決上述問題，能夠加入動態特徵。那麼動態特徵是什麼樣的？舉個例子說明。

如上圖所示，咱們以大流發生變化的動態特徵舉例。以前的模型推薦是若是中國的男性用戶訪問PageID 100，就給他推薦廣告2002，這是一個固定不變的行爲。

在此基礎上作一些變化，當進行採樣實時特徵的時候，這個實時特徵是最近一段時間內，即當中國的男性用戶訪問PageID 100的時候，他們點擊最多的10個廣告。這個特徵沒有辦法在離線的時候計算出來，由於它是一個線上實時發生的用戶行爲。

那麼在產生用戶行爲以後能夠作一件什麼事情呢？能夠在中國的男性用戶訪問PageID 100的時候，不單純給他推廣告2002，而是推最近這段時間中國男性用戶訪問PageID 100時候點擊最多的那些廣告。

這樣的狀況下，若是中國男性用戶訪問PageID 100的時候，最近訪問最多的廣告是2001和2002。當用戶ID來了，咱們看到他是一箇中國男性用戶，就有可能給他推薦廣告2001，而不是廣告2002了。

上述就是大流發生變化的一個例子。

一樣的道理，由於系統能夠對用戶的實時特徵進行採樣，因此能更好地判斷用戶當時當刻的意圖。比方說，能夠去看用戶最近一分鐘看了哪些頁面，瀏覽哪些商品，這樣的話能夠實時判斷用戶當時當刻的想法，從而給他推薦一個更適合他當下意圖的廣告。

這樣的推薦系統是否是就徹底沒有問題呢？再看一個例子。

比方說剛纔上文提到用戶1和用戶2都是中國男性用戶，以前假設他們的行爲是相似的，在以前的歷史數據裏面也印證了這一點。可是當在線上真正看用戶行爲的時候，可能會發生什麼樣的狀況？

可能發生用戶1和用戶2的行爲產生分化，分化的緣由可能有不少種，但不知道是什麼緣由。此時給用戶1和用戶2所推薦的東西可能就徹底不同了，那是什麼緣由致使分化了？

舉個例子來講，若是用戶1來自上海，用戶2來自北京。某天北京有很是大的降溫，這個時候北京用戶2可能就開始搜索秋褲，可是上海當天仍是很熱，上海的用戶1在搜索服裝的時候，可能仍是搜索一些夏裝。這個時候，中國的男性用戶裏面，上海用戶1和北京用戶2的搜索行爲就產生了一些變化。此時就須要給他們推薦不同的廣告，可是靜態的模型沒有辦法很好地作到這一點。

由於這個模型實際上是一個靜態訓練的模型，因此若是是一個分類模型的話，當中可以產生的類別實際上是一個固定的類別，爲了產生一個新的分類，就須要對模型從新進行訓練。因爲模型訓練是離線進行的，因此可能這個訓練的模型須要在次日才能被更新，這樣就會對推薦效果產生影響。

• 經過增長動態 feature
  1）實時跟蹤一類用戶的行爲，貼合「大流」；
  2）實時追蹤用戶的行爲表現，瞭解用戶當時當刻的意圖，並將用戶劃分到更合適的類別中去。
• 可是當模型的分類方式自己發生變化時，可能沒法找到最合適的類別，須要從新訓練模型增長分類。

例：新產品上線頻繁，業務高速成長，用戶行爲的分佈變化比較快。
當遇到以上問題，須要把考慮的事情加入動態的模型更新，動態模型更新是怎麼來作？實際上是同樣的道理。

如上圖所示，除了把用戶的實時行爲日誌作ETL到離線的地方進行Feature Generation之外，可能還要把用戶行爲日誌在線導出來，而後去作特徵生成、樣本拼接，而後作進線的模型訓練。

這裏的模型訓練一般都是流式的訓練，在一個基礎模型之上作增量的訓練，來使模型更好地貼合當時當刻用戶行爲的一些變化。在這種狀況下，經過這種實時樣本的訓練，可讓這個模型產生新的分類，它會知道上海和北京用戶的行爲多是不同的。所以，當用戶訪問PageID 100的時候，對於上海的用戶它可能會推薦廣告2002，北京的用戶可能推薦的就是廣告2011了。

在這樣的狀況分化下，假設用戶4再過來的時候，系統會看他究竟是上海的用戶仍是北京的用戶，若是他是上海的用戶的話，仍是會給他推薦廣告2002。

加入實時模型訓練的推薦系統特色：

• 在動態特徵的基礎上，實時訓練模型，使模型儘量貼近此時此刻 用戶行爲的分佈；
• 緩解模型的退化。

實時推薦系統架構

上面的例子是瞭解實時推薦系統的原理，它爲何會比通常的離線推薦系統作得更好。那麼，如何經過Flink加上Hologres和一些其餘系統/項目來搭建出這樣一套可用的實時推薦系統？

（一）經典離線推薦系統架構

首先來看一下上文提到的經典離線推薦系統的架構，以下所示。

這個架構其實以前講的架構同樣，只是增長了部分細節。

首先，經過消息隊列用來採集實時的用戶行爲，這個消息隊列裏面的實時用戶行爲會被導入到一個離線存儲來存儲歷史用戶行爲，而後天天會作靜態特徵的計算，最後放到特徵存儲裏面給線上的推理服務用。

與此同時，系統也會作離線的樣本拼接，拼接出來的樣本會存到樣本存儲裏面給離線的模型訓練使用，離線的模型訓練天天會產生新的模型去驗證，而後給到推理服務使用，這個模型是一個T+1的更新。

以上就是一個經典離線推薦系統的架構。若是要把它推動到實時推薦系統裏面，主要要作如下三件事情：

• 特徵計算
  靜態 T+1 特徵計算到實時特徵計算。
• 樣本生成
  離線 T+1 樣本生成到實時樣本生成。
• 模型訓練
  離線訓練 T+1 更新到增量訓練實時更新。

（二）阿里巴巴搜推廣在線機器學習流程

阿里巴巴搜推廣已經上線了這樣的實時推薦系統，它的整個流程其實跟離線的推薦系統是相似的，主要區別是整個過程都實時化了。

如上所示，這套系統主要有三方面的特性：
時效性：大促期間，全流程實時更新。
靈活性：根據需求，隨時調整特徵和模型。
可靠性：系統穩定、高可用，上線效果保證。
用戶能夠作到很是有時效性地更新模型、特徵，在大促的期間，能夠隨時調整特徵和模型，表現出來的效果也很好。

（三）實時推薦系統架構

實時推動系統的架構應該長成什麼樣子？

如上圖所示，相比於剛纔經典的離線推薦系統，實時推薦架構發生了一些變化。首先，消息隊列生成的數據，除了進到離線存儲保存歷史行爲之外，系統還會把這個消息隊列裏面的消息讀出來兩份，其中一份拿去作實時的特徵計算，也是會放到特徵存儲裏面，另一份是會放到實時樣本拼接裏面，跟線上的推理服務使用的用戶特徵進行一個雙流Join，這樣可以獲得一個實時的樣本。

在這種狀況下，存儲到實時系統的樣本能夠同時被拿來作離線的模型訓練，也能夠拿來作實時的模型訓練。

無論是離線的仍是實時的模型訓練，它們生成的模型都會被放到模型存儲裏面，並通過模型驗證最後上線。

離線模型訓練是天級別的，但實時模型訓練多是分鐘級、小時級甚至是秒級的。這個時候離線的模型訓練會天級別產生一個Base Model給到實時的模型訓練，而後再去作增量的模型更新。

整個的架構裏面有一點須要提到的是，推理服務在使用這個特徵存儲裏面拿過來的特徵作推理的同時，它還須要把本次作推理所用的特徵也加上Request ID送到消息隊列裏面。這樣的話實時樣本拼接的時候，當產生一個正樣本，比方說用戶展現了某一個廣告，而後點擊了以後它是一個正樣本，這時候纔可以知道當時用了哪些特徵給用戶推薦的廣告，因此這個特徵信息是須要推理服務保留下來，送到實時樣本里面作樣本拼接，才能生成一個很好的樣本。

這個架構裏面能夠看到，相比於經典的離線推薦系統，在綠色框的部分都是實時的部分，有一些部分是新加的，有一些部分是把原來離線的部分變成了實時的部分。好比實時特徵計算是新加的，實時樣本拼接是把原來的離線樣本拼接的部分變成了實時，實時模型訓練是新加的，模型驗證也是一樣的道理，是把原來的離線模型驗證，變成了實時的模型驗證。

（四）基於 Flink + Hologres 的實時推薦方案

若是要實現剛纔的實時推薦系統架構，會用到一些什麼樣的系統？

如上圖所示，消息隊列用的是Kafka，離線的存儲假設用的是HDFS。無論是實時特徵計算仍是離線特徵計算，如今均可以用Flink來進行計算，利用Flink流批一體的能力，可以保證明時和離線的特徵計算所產生的結果是一致的。
Hologres在這裏的做用是特徵存儲，Hologres特徵存儲的好處是能夠提供很是高效的點查，另外一個就是在作實時特徵計算的時候，常常會產生一些不許確的特徵，須要在後期對這些特徵進行一些修正。能夠經過Flink加Hologres的機制進行很好的特徵的修正。

一樣的道理，在推理服務這一側，經過保留用來作推理的特徵，放到後面的樣本拼接裏面,這裏的消息隊列也會使用Kafka。樣本拼接這個事情會用Flink來作，Flink一個很是經典的應用場景作雙流Join。把樣本給拼接出來後，在把特徵給加上，接着把算好的樣本一樣也放進Hologres裏面作樣本的存儲。

在樣本存儲的狀況下，Hologres裏面的樣本既能夠拿來作實時的模型訓練，經過讀取Hologres的Binlog來作實時的模型訓練，也能夠經過Hologres批量的Scan去作離線的模型訓練。

無論是在線仍是離線的模型訓練，均可以用Flink或者是FlinkML，也就是Alink來作。若是是傳統機器學習的話，也能夠用TensorFlow來作深度學習的模型訓練，這樣的模型仍是可能會存到HDFS，而後經過Flink和TensorFlow作模型的驗證，最後作線上的推理服務。

線上推理服務不少用戶會有本身的推理引擎，若是有能夠用，若是想用Flink和TensorFlow的話也能夠直接使用。

（五）實時特徵計算及推理 （Flink + Hologres）

首先咱們來看實時特徵計算和推理的過程，如上圖所示。

剛纔提到咱們會把實時的用戶行爲採集下來，送到Flink裏面去作實時特徵計算，而後存進Hologres裏面給線上推理服務使用。

這裏的實時特徵可能包含：

• 用戶最近 5 分鐘的瀏覽記錄
  1）商品、文章、視頻
  2）停留時長
  3）收藏、加購、諮詢，評論
• 最近 10 分鐘每一個品類中點擊率最高的 50 個商品
• 最近 30 分鐘瀏覽量最高的文章、視頻、商品
• 最近 30 分鐘搜索量最高的 100 個詞

對於搜推廣業務，均可以用這樣的實時特徵來更好的得到推薦效果。

（六）實時樣本拼接（Flink + Hologres）

再往下咱們會看實時樣本拼接的部分，以下圖所示。

實時用戶行爲會被採集下來，進到Flink裏面去作樣本的拼接。這裏的樣本拼接包含了兩個部分，第一個部分是首先要知道這個樣本是正樣本仍是負樣本，這是經過分析實時用戶行爲的日誌來的，咱們會有展現流、點擊流，若是展現流Join點擊流，而後發現展現的一個Item被用戶點擊了，那麼這就是正樣本。若是咱們展現了某個Item用戶沒有點擊，那麼就是一個負樣本，這就是咱們判斷正負樣本的過程。

僅僅有正負樣本的判斷顯然不夠，由於在作訓練的時候還須要這個特徵，這些特徵是從推理服務過來的，當展現某一個Item的時候，推理服務就使用了某一些特徵來判斷用戶是否會對這個東西感興趣。這些特徵會放到Kafka裏面留存下來，進到Flink裏面。作樣本拼接的過程中，會經過Request ID Join上當時去作推薦的所用到這些特徵，而後生成一個完整的樣本放到Hologres裏面。

這裏會利用 Flink 多流 Join 能力進行樣本拼接，與此同時也會作多流同步、正負樣本、樣本修正。

（七）實時模型訓練 / 深度學習 ( PAI-Alink / Tensorflow)

在樣本生成了之後，下一個步驟就是實時的模型訓練或者深度學習。

如上圖所示，在這種狀況下，剛纔說到樣本是存在Hologres裏面的，Hologres裏面的樣本能夠用做兩個用途，既能夠用作在線的模型訓練，也能夠用作離線的模型訓練。

在線的模型訓練和離線的模型訓練能夠分別利用Hologres的Binlog和批量Scan的功能去作。從性能上來說，其實跟通常的消息隊列或者文件系統去掃描相差並不大。

這裏若是是深度模型的話，能夠用TensorFlow來作訓練。若是是傳統機器學習模型的話，咱們能夠用Alink或者說FlinkML來作訓練，而後進到HDFS存儲，把模型給存儲起來，接着再經過Flink或者TensorFlow來作模型的驗證。

上述過程是實際搭建實時模型和深度模型訓練能夠用到的一些技術。

（八）Alink–Flink ML（基於Flink的機器學習算法）

這裏簡單的介紹一下Alink，Alink是基於Flink的一個機器學習算法庫，目前已經開源，正在向 Apache Flink 社區進行貢獻中。

如上圖所示，Alink (Flink ML)相比於Spark ML來說有兩個特點：

1. Spark ML 僅提供批式算法，Alink 提供批流一體算法；
2. Alink 在批式算法上和 Spark ML 至關。

（九）離線特徵回填 (Backfill)

介紹完訓練部分，再來看離線特徵回填。這個過程實際上是說在上線實時特徵之後，須要上線新的特徵，應該怎麼作？

如上圖所示，通常會分紅兩步。第一步會在實時的系統裏面先把新的特徵給加上，那麼從某一個時刻開始，Hologres裏面存儲生成的特徵都是有新的特徵了。對於那些歷史數據怎麼辦？這個時候就須要從新作一個特徵回填，用HDFS裏面存的歷史行爲數據跑一個批量的任務，而後把歷史上的一些特徵給補上。

因此離線特徵回填在這個架構圖裏面也是由Flink的離線特徵計算來完成的，從HDFS裏面把歷史行爲數據讀出來，而後去算一些離線的特徵，把過去的歷史消息裏面的特徵給補上。

基於Apache Flink + Hologres的實時推薦系統關鍵技術

剛纔的架構裏面所用到的關鍵技術比較多，接下來主要講兩個點。

（一）可撤回訂正的特徵和樣本

第一個點是可撤回訂正的特徵和樣本，如上圖所示。

圖中有下部陰影的區域裏面，經過Flink和Hologres配合，會進行一些樣本和特徵的撤回和訂正。
爲何須要特徵和樣本的訂正？

• 實時日誌存在亂序
  例如某個用戶點擊事件因爲系統延遲晚到產生 False Negative 樣本。
• 通常經過離線做業從新計算離線樣本
  從新跑整個離線樣本計算
• 經過 Apache Flink + Hologres 撤回機制點更新
  僅更新須要更正的特徵和樣本

實時日誌有可能會存在一些亂序，有些流可能到得早一些，有些流可能到得晚一些。在這種狀況下，在作多流Join的時候就有可能會因爲系統的延遲、晚到而產生一些False Negative樣本。

舉個例子，好比在作展現和點擊流Join的時候，可能一開始認爲用戶並無點擊某一個廣告，後來發現用戶點擊了，可是這條事件到的時間晚了。在這種狀況中，一開始會告訴下游用戶沒有點擊，這是一個False Negative，後面發現用戶其實點擊了，所以須要對 False Negative作修正。當發生這種狀況，須要對以前的樣本作撤回或者更新，去告訴它以前的樣本不是負樣本，而是正樣本。

基於上述這種狀況，咱們須要整套鏈路上面有一個撤回的能力，須要逐級告訴下游以前的錯誤，須要把它給修正，經過Apache Flink + Hologres配合能夠完成這樣一個機制。

爲何要作這樣一件事情？

之前產生這種False Negative樣本的時候，通常都是經過離線做業從新計算離線樣本進行更正。這種方式的代價是可能須要從新跑整個離線的樣本計算，但最終目的其實僅僅是修正全部樣本里其中很小的一部分樣本，所以這個代價是比較高昂的。

經過Apache Flink + Hologres實現的機制，能夠作到對False Negative樣本進行點狀的更新，而不是從新跑整個樣本，這種狀況下，更正特徵和樣本的代價就會小不少。

（二）基於事件的流批混合工做流

在這個架構裏另外一個關鍵技術是基於事件的流批混合工做流，它是什麼意思？

看這個圖，除了剛纔所示那些系統以外，這也是一個很是複雜的工做流。由於不一樣的系統之間，它可能存在依賴關係和調度關係，有的時候是數據依賴，有的時候是控制依賴。

例如，咱們可能會週期性或者按期去跑一些離線的靜態特徵計算，有多是作特徵回填，也有多是更正實時特徵產生的問題，但多是默認週期性地跑，也有多是手動觸發地跑。還有的時候是當離線模型訓練生成以後，須要去觸發在線模型驗證的動做，也有多是在線的模型訓練生成之後要去觸發在線模型訓練的動做。

還有多是樣本拼接到了某一個點，好比上午10點樣本拼接完成以後，想要告訴模型訓練說，上午10點以前的樣本都拼接好了，但願想跑一個批量離線訓練的任務，把昨天早上10點到今天早上10點的數據作離線的模型訓練。這裏它是由一個流任務觸發一個批任務的過程。在剛纔提到的批量模型訓練生成以後，須要放到線上作模型驗證的過程中，它實際上是一個批任務觸發流任務的過程，也會線上模型訓練產生的模型，須要去線上模型訓練進行驗證，這是流任務觸發流任務的過程。

因此在這個過程中，會涉及到不少不一樣任務之間的交互，這裏叫作一個比較複雜的工做流，它既有批的任務又有流的任務，因此它是一個流批混合的工做流。

（三）Flink AI Flow

如何作到流批混合的工做流實現？

使用的是Flink AI Flow，它是一個大數據加AI頂層工做流抽象。

如上圖所示，一個工做流一般能夠分爲Workflow定義和Workflow執行這兩個步驟。

Workflow定義會定義Node和Relation，即定義節點和節點之間的關係。在Flink AI Flow裏面，咱們把一個節點定義成一個Logical Processing Unit，而後把這個節點之間的關係定義成Event driven conditions。在這樣的抽象下面，在Workflow執行層面作了一個基於事件的調度。

抽象嚴格來，在一個系統裏面會有不少的事件，把這些事件組合到一塊兒，可能會知足某一些條件，當知足一個條件的時候，會產生一些動做。

例如，一個工做流中可能有一個任務A，它可能會監聽這個系統裏面各類各樣的事件。當事件1發生，而後發生了事件2，接着發生了事件3，當事件按照這麼一個序列發生以後，須要作啓動任務A的動做，事件123按序發生是條件。

經過這樣的抽象，能夠很好地把之前傳統工做流和帶有流做業的工做流整合起來。由於之前傳統的工做流裏都是基於做業狀態發生變化進行調度，通常是做業跑完了，而後去看怎麼跑下一個做業。這個方式的問題是若是做業是一個流做業，那麼這個做業永遠跑不完，這個工做流沒法正常工做。

在基於事件的調度裏面，很好地解決了這個問題。將再也不依賴做業的狀態發生變化來進行工做流調度，而是基於事件來作。這樣的話即便是一個流做業，它也能夠產生一些事件，而後告訴調度器作一些其餘的事情。

爲了完成整個調度語義，還須要一些支持服務，協助完成整個調度語義的支持服務包括：

• 元數據服務（Metadata Service）
• 通知服務（Notification Service）
• 模型中心（Model Center）

下面來分別看一下這些支持服務的內容。

（四）元數據服務/Metadata Service

元數據服務是管理數據集，在工做流裏面但願用戶不用很是繁瑣地找到本身的數據集，能夠幫用戶管理數據集，用戶要用的時候給一個名字就能夠。

元數據服務也會管理項目（Project），這裏的Project是指Flink AI Flow裏面的Project，一個Project裏面能夠含有多個工做流，管理Project最主要的目的是爲了保證工做流可以被複現。

在元數據服務裏面，還會管理工做流和做業，每一個工做流裏面可能會涉及到不少的做業。除此以外，也會管理模型血緣，能夠知道模型的版本是由哪個工做流當中的哪個做業生成的，最後也支持用戶定義一些自定義實體。

（五）通知服務/Notification Service

第二個服務是通知服務，它是一個帶主鍵的事件和事件監聽。

舉個例子，如上圖所示。一個客戶端但願監聽一個事件，這個事件的Key是模型。若是 Key被更新的時候，監聽的用戶就會收到一個call back，會告訴他有一個事件被更新了，那個事件的主鍵是模型，Value是模型的URI，版本號是1。

這裏可以起到的一個做用就是若是驗證一個做業，它能夠去監聽Notification Service。當有一個新模型生成的時候，須要被通知而後對這個模型進行驗證，因此經過Notification Service就能夠作這樣的事情。

（六）模型中心/Model Center

模型中心作的是模型多版本的管理，參數的記錄，包括模型指標的追蹤和模型生命週期的管理，還有一些模型可視化的工做。

舉個例子闡述Flink AI Flow是如何把實時推薦系統裏面複雜的工做流，用一個完整的工做流描述出來。

如上所示，假若有一個DAG，它裏面包含了模型的訓練，模型的驗證以及在線推理這三個做業。

首先，經過Scheduler模型訓練的做業，在提交上去以後，Scheduler會到Metadata Service裏面去更新做業的狀態，變成一個待提交的狀態。假設環境是K8S Cluster，那麼它會提交到Kubernetes上去跑這樣一個訓練做業。

訓練做業跑起來以後，能夠經過做業狀態監聽器去更新做業的狀態。假使這個做業是一個流式的訓練做業，跑了一段時間之後會生成一個模型，這個模型會註冊到模型中心。註冊完了之後，模型中心會發出一個事件，表示有一個新的模型版本被註冊了，這個事件會到Scheduler, Scheduler會監聽這些事件。

以後Scheduler就會去看，當收到這個事件的時候，有沒有一些條件被知足了，而後須要作一些什麼樣的動做。有一個模型生成的時候，Scheduler須要去對這個模型進行驗證，這個條件被知足之後，須要去拉起一個做業，這個做業就是一個模型驗證的做業。

模型驗證做業被拉起以後，它會到模型中心找到最新被生成的一個模型版本，而後對它去進行模型的驗證。假設模型驗證經過了，這個模型驗證是個批做業，它會告訴Model Center模型被Validated了，這個時候模型中心就會發送一條Model Validated Version Event給Scheduler，模型被更新了之後，Scheduler會去看Model Validated，觸發拉起線上的推理服務。推理服務拉起以後，它會到模型中內心面把剛剛被Validated過的模型拉過來作推理。

假設推理服務也是一個流的做業，也是一直跑在那裏。過了一段時間以後，線上的流的訓練做業又生成了一個新的模型，剛纔那條路又會再走一遍，它會有一個模型生成的一個New Model Version Validated，它又會被Scheduler聽到，Scheduler又拉起一個Validated做業，Job2又會被拉起，拉起以後Validated做業又會去驗證模型，有可能這個模型驗證又經過了，又會發送一條模型New Model Version Validated給模型中心，模型中心會把這個Event又給到 Scheduler。這個時候，Scheduler會看到推理做業其實已經起在那裏了，可能就什麼都不作。

推理做業同時也在監聽着Model Version Validated事件，當它收到這個事件的時候，會去作的一件事情就是到模型中內心面從新加載最新的被Validated過的事件。

經過這個例子，解釋了爲何須要流批混合的調度器和工做流，來實現端到端的實時推薦系統架構裏全部做業、工做流的串聯。

目前，Flink AI Flow也做爲開源 Flink 生態項目放在Github上面，感興趣的同窗能夠經過下方連接進行觀看。

https://github.com/alibaba/flink-ai-extended/tree/master/flink-ai-flow

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。