如何发布网站到域名,wordpress博客常用插件,wordpress博客怎麽用,网站主页设计优点简介#xff1a; 《实时数仓入门训练营》由阿里云研究员王峰、阿里云资深技术专家金晓军、阿里云高级产品专家刘一鸣等实时计算 Flink 版和 Hologres 的多名技术/产品一线专家齐上阵#xff0c;合力搭建此次训练营的课程体系#xff0c;精心打磨课程内容#xff0c;直击当下…简介 《实时数仓入门训练营》由阿里云研究员王峰、阿里云资深技术专家金晓军、阿里云高级产品专家刘一鸣等实时计算 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和一些其他系统/项目来搭建出这样一套可用的实时推荐系统 一经典离线推荐系统架构 首先来看一下上文提到的经典离线推荐系统的架构如下所示。 这个架构其实之前讲的架构一样只是增加了部分细节。 首先通过消息队列用来采集实时的用户行为这个消息队列里面的实时用户行为会被导入到一个离线存储来存储历史用户行为然后每天会做静态特征的计算最后放到特征存储里面给线上的推理服务用。 与此同时系统也会做离线的样本拼接拼接出来的样本会存到样本存储里面给离线的模型训练使用离线的模型训练每天会产生新的模型去验证然后给到推理服务使用这个模型是一个T1的更新。 以上就是一个经典离线推荐系统的架构。如果要把它推进到实时推荐系统里面主要要做以下三件事情 特征计算 静态 T1 特征计算到实时特征计算。样本生成 离线 T1 样本生成到实时样本生成。模型训练 离线训练 T1 更新到增量训练实时更新。二阿里巴巴搜推广在线机器学习流程 阿里巴巴搜推广已经上线了这样的实时推荐系统它的整个流程其实跟离线的推荐系统是类似的主要区别是整个过程都实时化了。 如上所示这套系统主要有三方面的特性 时效性大促期间全流程实时更新。 灵活性根据需求随时调整特征和模型。 可靠性系统稳定、高可用上线效果保证。 用户可以做到非常有时效性地更新模型、特征在大促的期间可以随时调整特征和模型表现出来的效果也很好。 三实时推荐系统架构 实时推进系统的架构应该长成什么样子 如上图所示相比于刚才经典的离线推荐系统实时推荐架构发生了一些变化。首先消息队列生成的数据除了进到离线存储保存历史行为以外系统还会把这个消息队列里面的消息读出来两份其中一份拿去做实时的特征计算也是会放到特征存储里面另外一份是会放到实时样本拼接里面跟线上的推理服务使用的用户特征进行一个双流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的机器学习算法 这里简单的介绍一下AlinkAlink是基于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过的事件。 通过这个例子解释了为什么需要流批混合的调度器和工作流来实现端到端的实时推荐系统架构里所有作业、工作流的串联。 原文链接 本文为阿里云原创内容未经允许不得转载。
