基于 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

本文内容由阿里云实名注册用户自发贡献，版权归原做者全部，阿里云开发者社区不拥有其著做权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将马上删除涉嫌侵权内容。