共计 8595 个字符，预计需要花费 22 分钟才能阅读完成。
简介：整顿自 5 月 29 日 阿里云开发者大会，秦江杰和刘童璇的分享，内容包含实时举荐零碎的原理以及什么是实时举荐零碎、整体零碎的架构及如何在阿里云下面实现，以及对于深度学习的细节介绍。
本文整顿自 5 月 29 日阿里云开发者大会，大数据与 AI 一体化平台分论坛，秦江杰和刘童璇带来的《基于实时深度学习的举荐零碎架构设计和技术演进》。分享内容如下：
实时举荐零碎的原理以及什么是实时举荐零碎
整体零碎的架构及如何在阿里云下面实现
对于深度学习的细节介绍。
一、实时举荐零碎的原理
在介绍实时举荐零碎的原理之前，先来看一个传统、经典的动态举荐零碎。
用户的行为日志会呈现在音讯队列里，而后被 ETL 到特色生成和模型训练中。这部分的数据是离线的，离线的模型更新和特色更新会被推到在线零碎外面，比方特色库和在线推理的服务中，而后去服务在线的搜寻推广应用。这个举荐零碎自身是一个服务，前端展现的服务推广应用可能有搜寻举荐、广告举荐等。那么这个动态零碎到底是怎么工作的？咱们来看上面的例子。
1. 动态举荐零碎
截取当初用户的行为日志，倒入离线零碎中去做特色生成和模型训练，这段日志示意用户 1 和用户 2 同时浏览了 page#200 这个页面和其余一些页面，其中用户 1 浏览了 page#100 并且点击了 ads#2002。那么这个日志会被 ETL 到离线，而后送去做特色生成和模型训练。生成的特色和模型外面会看到，用户 1 和用户 2 都是中国男性用户，“中国男性”是这两个用户的一个特色，这个学习模型最终后果是：中国男性用户浏览了 page#100 的时候，须要给他推 ads#2002。这外面的逻辑就是把类似用户的行为归到一起，阐明这类用户应该有同样的行为。
用户特色推动特色库建设的模型，在推送至在线服务里的时候如果有一个用户 4 呈现，在线推理的服务就会到特色库外面去查这个用户的特色，查到的特色可能是这个用户正好是中国的男性用户，模型之前学到了中国男性用户拜访 page#100 时候要推 ads#2002，所以会依据学习模型给用户 4 举荐了 ads#2002。以上就是动态举荐零碎的根本工作流程。
然而这个零碎也有一些问题，比方第一天的模型训练实现后，发现用户 4 第二天的行为其实跟用户 3 更像，不是和用户 1、用户 2 相似。然而之前模型训练的后果是中国男性用户拜访 page#100 时候要推 ads#2002，并且会默认进行这种举荐。只有通过第二次模型计算后能力发现用户 4 和用户 3 比拟像，这时再进行新的举荐，是有提早的。这是因为模型和特色都是动态的。
对于动态举荐零碎来讲，特色和模型都是动态生成的。比方以分类模型为例，依据用户的类似度进行分类，而后假如同类用户都有类似的行为趣味和特色，一旦用户被化成了某一类，那么他就始终在这个类别中，直到模型被从新训练。
2. 动态举荐零碎问题
- 第一，用户行为其实是十分多元化的，没有方法用一个动态的事件去形容这个用户的行为。
- 第二，某一类用户的行为可能比拟类似，然而行为自身产生了变动。例如中国男性用户拜访 page#100 时候要推 ads#2002，这是昨天的行为法则；然而到了第二天的时候发现不是所有的中国男性用户看到 page#100 时候都会点击 ads#2002。
3. 解决方案
3.1 退出实时特色工程后可能灵便举荐
在举荐零碎中退出实时特色工程，把音讯队列外面的音讯读一份进去，而后去做近线的特色生成。举个例子，中国男性用户最近拜访 page#100 的时候点击最多的 10 个广告，这件事件是实时去追踪的。就是说中国男性用户最近 10 分钟或者半个小时之内拜访 page#100 的时候点的最多 10 个广告，个事件不是从昨天的历史数据外面失去的信息，而是明天的用户实时行为的数据，这就是实时特色。
有了这个实时特色当前，就能解决方才那个随大流的问题。同样的，如果这里的特色是对某一个用户最近 3 分钟或者 5 分钟的行为采集的，就可能更加精确的追踪到这个用户过后当刻的用意，并且给这个用户去做更精确的举荐。
所以说，在举荐零碎中退出实时特色后能精准举荐。比方方才的例子，如果用户 4 在这个状况下拜访 page#100，新的学习内容为：中国男性用户最近拜访 page#100 的时候，点的最多的是 ads#2001。那咱们会间接举荐 ads#2001，而不是依照昨天的信息给他推 ads#2002。
3.2 实时特色举荐体系的局限性
之前的用户 1 和用户 2 的行为是十分类似的，加了实时特色就能晓得它以后的用意。然而，如果用户 1 和用户 2 在做雷同的特色时，他们的行为产生了不统一；也就是说在模型外面被认为是同一类的用户，他们的行为产生分化了，变成了两类用户。如果是动态的模型，即便退出了实时特色，也无奈发现这一类新的用户；须要对模型进行从新训练当前，才可能产生一个新的分类。
退出施行特色工程举荐零碎后，能够追踪某一类用户的行为，贴合一个大流的变动；也能够实时追踪用户的体现，理解用户过后的用意。然而当模型自身的分类形式发生变化的时候，就没有方法找到最合适的分类了，须要从新对训练模型进行分类，这种状况会遇到很多。
比如说当有很多新产品上线时，业务在高速增长，每天都会产生很多的新用户，或者说用户行为散布变动得比拟快。这种状况下即便应用了实时特色零碎，因为模型自身是一个逐步进化的过程，也会导致昨天训练的模型明天再放到线下来，不肯定可能 work 的很好。
3.3 解决方案
在举荐零碎中新增两个局部：近线训练和近线样本生成。
假如有用户 1 和用户 2 别离是上海和北京的用户，这个时候会发现之前的模型不晓得上海和北京的用户是有区别的，它认为都是中国男性用户。而在退出实时训练这个模型后，就会逐步的学习北京的用户和上海的用户，两者的行为是有区别的，确认这一点后再进行举荐就会有不一样的成果。
再比如说，明天北京忽然下暴雨了或者上海天气特地热，这个时候都会导致两边用户的行为不太一样。这时再有一个用户 4 过去，模型就会分辨这个用户是上海还是北京的用户。如果他是上海的用户，可能就会举荐上海用户所对应的内容；如果不是的话，能够持续举荐别的。
退出实时模型训练，最次要的目标是在动静特色的根底上，心愿模型自身可能尽可能的贴合此时此刻用户行为的散布，同时心愿可能缓解模型的进化。
二、阿里巴巴实时举荐计划
首先理解下阿里外部施行完这套计划之后有什么益处：
- 第一个是时效性。目前阿里大促开始常态化，在大促期间整个模型的时效性失去了很好的晋升；
- 第二个是灵活性。能够依据需要随时调整特色和模型；
- 第三个是可靠性。大家在应用整个实时举荐零碎的时候会感觉不释怀，没有通过离线当天早晨大规模的计算验证，间接推上线，会感觉不够牢靠，其实曾经有一套残缺的流程去保障这件事件的稳定性和可靠性；
这个举荐模型从图上看，从特色到样本到模型，再到在线预测这个过程，和离线其实没有区别。次要的区别就是整个的流程实时化，用这套实时化的流程去服务在线的搜寻推广应用。
1. 如何施行
依据经典离线架构进行演变。
首先，用户群行为会从音讯队列来走离线存储，而后这个离线存储会存储所有的历史用户行为；而后在这个离线存储下面，通过动态特色计算样本；接下来把样本存到样本存储里，去做离线模型训练；之后把离线的这个模型公布到模型核心，去做模型验证；最初把模型验证过的模型推到推理服务去服务在线业务。这个就是残缺的离线体系。
咱们将通过三件事件进行实时化革新：
- 第一是特色计算；
- 第二是样本生成；
- 第三是模型训练。
相比之前，音讯队列不仅仅存入离线存储，还要分进去两链路：
- 第一链路会做实时的特色计算，比如说最近几分钟之内中国男性用户看 page#100 的时候点了什么广告，这个是实时计算算进去的，即最近一段时间的一些用户可能产生的一些行为特色等。
- 另外一条链路是音讯队列，能够进行实时样本拼接，就是说不须要手动去打标签，因为用户本人会通知咱们标签。比方咱们做了一个举荐，如果用户点击了，那么它肯定是个正样本；如果过了一段时间用户没有点击，那咱们认为它就是个负样本。所以不必人工去打标签，用户会帮咱们打标签，这个时候很容易就可能失去样本，而后这部分样本会放到样本存储外面去，这个跟之前是一样的。区别在于这个样本存储不仅服务离线的模型训练，还会去做实时的模型训练。
离线模型训练通常还是天级的 T+1 的，会训练出一个 base model，交给实时模型训练去做增量的训练。增量模型训练的模型产出就可能是 10 分钟、15 分钟这样的级别，而后会送到模型存储做模型验证，最初上线。
架构图中绿色的局部都是实时的，这部分有一些是新加进去的，有一些则是由本来的离线变成实时的。
2. 阿里云企业级实时举荐解决方案
在阿里云企业级实时举荐解决方案中，如何应用阿里云产品搭建？
音讯队列会用 DataHub；实时的特色和样本应用实时计算 Flink 版；离线的特色存储和动态特色计算都会用 MaxCompute；特色存储和样本核心应用 MaxCompute 交互式剖析（Hologres）；音讯队列的局部都是 DataHub；模型训练的局部会用到 PAI，模型存储和验证，还有在线推理服务这一套流程都是 PAI 外面的。
2.1 实时特色计算及推理
特色和推理就是把用户日志实时采集过去，导入实时计算 Flink 版外面去做实时特色计算。而后会送到 Hologres 外面去，利用 Hologres 流式的能力，拿它做特色核心。在这里，PAI 能够去间接查问 Hologres 外面的这些用户特色，也就是点查的能力。
在实时计算 Flink 版计算特色的时候，比如说用户最近 5 分钟的浏览记录，包含商品、文章、视频等，依据不同的业务属性，实时特色是不一样的。也可能包含比方最近 10 分钟每个品类点击率最高的 50 个商品，最近 30 分钟浏览量最高的文章、视频、商品，最近 30 分钟搜寻量最高的是 100 个词等。在这不同的场景，比方搜寻举荐，有广告、有视频、有文本、有新闻等。这些数据拿来做实时特色计算的和推理的这一条链路，而后在这个链路根底之上，有的时候也是须要动态特色回填的。
2.2 动态特色回填
比方新上线一个特色，这个新的特色在实时链路上线了之后，如果须要最近 30 天用户的行为，不可能等 30 天之后再计算。于是须要找到离线数据，而后把最近 30 天的这个特色给它补上。这就叫特色回填，也就是 backfill。通过 MaxCompute 去算这个特色回填一样也是写到 Hologres，同时施行起来也会把新的特色给加上，这是一个新特色的场景。
当然还有一些其余场景，比方算一些动态特色；再比方可能线上特色有一个 bug 算错了，然而数据曾经落到离线去了，这时候对离线特色要做一个纠错，也会用到 backfill 的过程。
2.3 实时样本拼接
实时样本拼接实质上对于举荐场景来讲，就是展现点击流之后，样本取得一个正样本或者负样本。然而这个 label 显然是不够的，还须要有特色，才可能做训练。特色能够从 DataHub 中来，在退出了实时特色当前，样本的特色是时时刻刻在发生变化的。
举一个例子，做出某一个商品的举荐行为的时候，是早上 10:00，用户的实时特色是他 9:55 到 10:00 的浏览记录。然而当看到这个样本流回来的时候，有可能是 10:15 的时候了。如果说这个样本是一个正样本，当给到用户举荐的商品且他产生了购买行为，这段时间咱们是无奈看到用户实时特色的。
因为那个时候的特色曾经变成了用户从 10:10 浏览到 10:15 的时候的浏览记录了。然而在做预测的时候，并不是依据这个 5 分钟内的浏览记录来举荐的这个商品，所以须要把过后做举荐的时候所采纳的那些特色给它保留下来，在这个样本生成的时候给它加上，这就是 DataHub 在这里的作用。
当应用 ES 做实时举荐的时候，须要把过后用来做举荐的这些特色保留下来，拿去做这个样本的生成。样本生成后，能够存储到 Hologres 和 MaxCompute 外面去，把实时样本存储到 DataHub 外面。
2.4 实时深度学习和 Flink AI Flow
这个局部会有离线训练是以“天“为级别的；也会有在线的实时训练是“分钟级”的；有的能够做的比拟极致，是按“秒”级的。不论是哪边进去的模型，最初都会送到这个模型中去，进行模型的验证以及上线。
这个其实是一个非常复杂的工作流。首先，动态特色计算是周期性的，也可能是手动的。当须要做 backfill 的时候，有手动触发的一个过程。依据这个模型图能看出它是批的训练，当它训练完了之后，须要到线下来做一个实时模型验证。这个模型验证可能是一个流作业，所以这里是从批到流的一个触发过程，模型是从流作业外面进去的，它是一个 long running 的作业，每 5 分钟产生一个模型，这每 5 分钟的模型也须要送进去做这个模型验证，所以这是一个流触发流动作的过程。
再比如说这个实时样本拼接，大家都晓得 Flink 有一个 watermark 的概念，比如说到某一个时刻往前的数据都到收集齐了，能够去触发一个批的训练，这个时候就会存在一个流作业。当他到了某一个时刻，须要去触发批训练的时候，这个工作流在传统的工作流调度外面是做不到的，因为传统的工作流调度是基于一个叫做 job status change 的过程来做的，也就是作业状态发生变化。
假如说如果一个作业跑完了并且没有出错，那么这个作业所产生的数据就曾经 ready 了，上游对这些数据有依赖的作业就能够跑了。所以简略来说，一个作业跑完了下一个作业连续上持续跑，然而当整个工作流外面只有有一个流作业的存在，那么这整个工作流就跑不了了，因为流作业是跑不完的。
比如说这个例子的实时计算，数据是一直变动的跑动，然而也会存在随时可能 ready 的，也就是说可能跑到某一个水平的时候数据就 ready 了，但其实作业基本没有跑完。所以须要引入一个工作流，这个工作流咱们把它叫做 Flink AI Flow，去解决方才那个图外面各个作业之间的协同关系这个问题。
Flink AI Flow 实质上是说节点都是一个 logical 的 processing unit，是一个逻辑解决节点，节点和节点之间，不再是上一个作业跑完跑下一个作业的关系了，而是一个 event driven 的 conditions，是一个事件触发的一个概念。
同样在工作流执行层面，调度器也不再基于作业状态发生变化去做调度动作，而是基于事件的调度。比方说事件调度这个例子，当一个流作业的 water mark 到了的时候，就是说这个工夫点之前的所有数据都到全了，能够去触发批作业去跑，并不需要流作业跑完。
对于每一个作业来讲，通过调度器提作业或者停作业是须要条件的。当这些事件满足一个条件的时候，才会进行调度动作。比如说有一个模型，当模型生成的时候，会满足一个条件，要求调度器把一个 validation 的作业模型验证的作业给拉起来，那这个就是由一个 event 产生了一个 condition，要求 schedule 去做一件事件的过程。
除此之外，Flink AI Flow 除了调度的服务之外，还提供了三个额定的反对服务来满足整个 AI 工作流语义，别离是元数据服务、告诉服务和模型核心。
- 元数据服，是帮大家治理数据集和整个工作流外面的一些状态；
- 告诉服务，是为了满足基于事件调度语义；
- 模型核心，是去治理这个模型当中的一些生命周期。
三、实时深度学习训练 PAI-ODL
Flink 生成实时样本之后，在 ODL 零碎有两个流。
- 第一个流是实时流，生成的实时样本送到 stream data source 下面比方像 kafka，在 kafka 中的这个样本会有两个流向，一个是流到 online training 中，另一个是流到 online evaluation。
- 第二个流是离线训练的数据流，拿离线的数据流向数仓来做这种 offline T+1 的 training。
在 online training 中反对用户可配置生成模型的频率，比如说用户配置 30 秒或者 1 分钟生成一次模型更新到线上。这个满足在实时举荐场景中，特地是时效性要求高的场景。
ODL 反对用户设定一些指标来主动判断生成的模型是否部署线上，当 evaluation 这边达到这些指标要求之后，这个模型会主动推上线。因为模型生成的频率十分高，通过人工去干涉不太事实。所以须要用户来设定指标，零碎主动去判断当指标达到要求，模型主动回推到线上。
离线流这边有一条线叫 model calibration，也就是模型的校对。离线训练生成 T+1 的模型会对在线训练进行模型的校对。
PAI-ODL 技术点剖析
1. 超大稠密模型训练
超大稠密模型的训练，是举荐搜寻广告这类稠密场景里罕用的一个性能。这里实际上是一个典型、传统的深度学习引擎，比方像 TensorFlow，它原生的外部实现的就是 fix size 这种固定 size variable，在稠密场景应用中会有一些常见问题。
就像 static shape，比方在通常的场景里边，像手机 APP 这种，每天都会有新用户来退出，每天也会有新的商品，新闻和新的视频等更新。如果是一个固定大小的 shape 的话，其实是无奈表白稠密场景中这种变动的语义的。而且这个 static shape 会限度模型自身长期的增量训练。如果说一个模型可增量训练时长是一两年，那很可能之前设定的这个大小曾经远远不能满足业务需要，有可能带来重大的特色抵触，影响模型的成果。
如果在理论的模型中设置的 static shape 比拟大，然而利用率很低，就会造成内存的节约，还有一些有效的 IO。包含生成全量模型的时候，造成磁盘的节约。
在 PAI-ODL 中基于 PAI-TF 引擎，PAI-TF 提供了 embedding variable 性能。这个性能提供动静的弹性特色的能力。每个新的特色会新减少一个 slot。并反对特色淘汰，比如说下架一个商品，对应的特色就会被删掉。
增量模型是说能够把一分钟内稠密特色变动的局部记录下来，产生到这个增量模型中。增量模型记录了稠密的变动的特色和全量 Dense 的参数。
基于增量模型的导出，就能够实现 ODL 场景下模型的疾速更新。疾速更新的增量模型是十分小的，能够做到频繁的模型上线。
2. 反对秒级的模型热更新
通常在咱们接触的用户中，通常是关注的次要是三点：
- 第一点就是模型的成果，我上线之后成果好不好？
- 第二点就是老本，我到底花多少钱。
- 第三点就是性能，能不能达到我对 RT 的要求。
embedding store 多级的混合存储反对用户可配置不同的存储形式。能够在满足用户性能的前提下，更大程度的升高用户的老本。
embedding 场景是十分有本人场景特点的，比如说咱们的特色存在很显著的冷热区别。有些商品或者视频自身特地热；有些则是用户的点击行为特地多，也会造成它特地热。有些冷门的商品或者视频就没人点，这是很显著的冷热拆散，也是合乎这种二八准则的。
EmbeddingStore 会把这些热的特色存储到 DRAM 下面，而后冷的特色寄存在 PMEM 或者是 SSD 上。
3. 超大稠密模型预测
此外，EmbeddingStore 反对分布式存储 Service。在 serving 的时候，每个 serving 的节点其实都须要去做一个全量的模型的加载。如果应用 EmbeddingStore 的分布式 service，就能够防止每个 serving 节点加载全量模型。
EmbeddingStore 反对用户可配置这种分布式的 embedding，独立的 isolated 这种 embedding store service。每个 serving 节点查问稠密特色时从 EmbeddingStore Service 查问。
EmbeddingStore 的设计充沛的思考了稠密特色的数据格式和拜访特点。举个简略的例子：稠密特色的 key 和 value，key 是 int64，value 就是一个 float 数组。无论是在 serving 还是在 training，拜访都是大批量的拜访。此外 Inference 阶段对稠密特色的拜访是无锁化的只读拜访。这些都是促使咱们设计基于 embedding 场景的稠密特色存储的起因。
4. 实时训练模型校对
为什么 PAI-ODL 会反对离线训练模型对 online training 有一个模型校对？
通常在实时训练过程中，会存在这种 label 不准以及样本分布的问题。因而应用天级别的模型会主动校对到 online training，加强模型的稳定性。PAI-ODL 提供的模型校对用户是无干涉的，用户基于本人业务特点配置相干配置后，每天主动依据新产生的全量模型进行 online training 端的 base 模型校对。当离线训练生成 base 模型，online training 会主动发现 base model，并且在 data stream source 会主动跳转到对应的样本，基于最新的 base 模型和新的 online training 的训练样本点开始 online training。
5. 模型回退及样本回放
尽管有样本的异样样本检测以及异样样本解决，依然无奈防止线上的更新模型会有成果问题。
当用户收到报警，线上的指标降落。须要提供给用户一个能力，能够回滚这个模型。
然而在 online training 的场景中，从发现问题到去干涉可能通过了好几个模型的迭代，产出了若干模型了。此时的回滚蕴含：
1）线上 serving 的模型回滚到问题工夫点的前一个模型；
2）同时 online training 须要回跳到问题模型的前一个模型；
3）样本也要回跳到那个工夫点来从新开始进行训练。
原文链接
本文为阿里云原创内容，未经容许不得转载。
