简介：《实时数仓入门训练营》由阿里云研究员王峰、阿里云资深技术专家金晓军、阿里云高级产品专家刘一鸣等实时计算 Flink 版和 Hologres 的多名技术 / 产品一线专家齐上阵，合力搭建此次训练营的课程体系，精心打磨课程内容，直击当下同学们所遇到的痛点问题。由浅入深全方位解析实时数仓的架构、场景、以及实操利用，7 门精品课程帮忙你 5 天工夫从小白成长为大牛！
本文整顿自直播《基于 Apache Flink + Hologres 的实时举荐零碎架构解析 - 秦江杰》
视频链接:https://c.tb.cn/F3.0d98Xr
摘要：本文由实时数仓线上课程秦江杰老师演讲内容整顿。
内容简要：
一、实时举荐零碎原理
二、实时举荐零碎架构
三、基于 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 是中国的男性用户和用户 1、用户 2 行为统一，所以须要给他推的应该是中国男性用户的行为。但这个时候咱们发现用户 4 的行为其实跟用户 3 更像，而不是跟用户 1 和用户 2 更像。
在这种状况下，因为模型和特色都是动态的，所以为了让用户 4 可能跟用户 3 失去的行为更像，须要去从新训练模型，这会导致预测的成果被提早，因为须要从新训练用户 4，才可能举荐出跟用户 3 更像的一些行为。
所以在这种实际操作状况下，能够看到动态举荐模型存在一些问题：
动态生成模型和特色；
以分类模型为例，依据用户的相似性进行用户分类，假如同类用户有类似的趣味和行为
例如中国的男性用户有相似行为。
一旦用户被划分为某个类别，则他将始终处于这个类别中，直到被新的模型训练从新分类。
这种状况下，比拟难去做到很好的举荐，起因是：
- 用户的行为十分多元化，无奈划分到某个固定类别
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 来讲有两个特色：
- Spark ML 仅提供批式算法，Alink 提供批流一体算法；
- 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 过的事件。
通过这个例子，解释了为什么须要流批混合的调度器和工作流，来实现端到端的实时举荐零碎架构里所有作业、工作流的串联。
原文链接
本文为阿里云原创内容，未经容许不得转载。