【王喆-推荐系统】前沿篇-(task3)流处理平台Flink：实时推荐

学习总结

（1）Flink 是最具代表性的批流一体的大数据平台。特点：让批处理和流处理共用一套代码，从而既能批量处理已落盘的数据，又能直接处理实时数据流。

（2）Flink 提高推荐系统实时性：用户数据进入数据流，

即进入数据消息队列后，会被分割成一定时长的时间窗口，之后 Flink 会按照顺序来依次处理每个时间窗口内的数据，计算出推荐系统需要的特征

。这个处理是直接在实时数据流上进行的，所以相比原来基于 Spark 的批处理过程，实时性有了大幅提高。

（3）Flink的实时性实践：利用 Flink 我们可以实时地获取到用户刚刚评价过的电影，然后通过实时更新用户 Embedding，就可以实现 SparrowRecsys 的实时推荐了。

文章目录

学习总结

一、实时性是影响推荐系统效果的关键因素

二、批流一体的数据处理体系

2.1 传统批处理大数据架构

2.2 流处理大数据架构

2.3 同具批处理、流处理优势的Flink

三、Flink如何处理数据流

3.1 数据流

3.2 窗口

四、Flink 数据流处理实践

五、作业

六、课后答疑

Reference

栗子：2020年双十一，阿里基于 Flink，实现了数据的批流一体处理，每秒能够处理 40 亿条的巨量数据。这也是业界首次在这么大规模的数据洪峰之上，实现数据流的实时处理。实时数据流处理功能的实现，让阿里的推荐系统引擎能够在双 11 期间做出更快速的反应，实时抓住用户的兴趣，给出更准确的推荐。

带着三个问题进行学习：

为什么说实时性是影响推荐系统效果的关键因素？

到底什么是批流一体的数据处理体系？

业界流行的 Flink 到底是怎么实现数据流处理的？

一、实时性是影响推荐系统效果的关键因素

ex：小明在刷抖音的足球视频，接着会继续推荐出相关视频，如果推荐系统没有实时抓住用户的兴趣点，推荐大妈广场舞的视频，小明可能会对该产品失去兴趣哈哈。

二、批流一体的数据处理体系

2.1 传统批处理大数据架构

数据处理中，无论是数据的预处理，还是特征工程，大部分是在 Spark 平台上完成的。

Spark 平台的特点：它处理的数据都是已经落盘的数据。即这些数据要么是在硬盘上，要么是在分布式的文件系统上，然后才会被批量地载入到 Spark 平台上进行运算处理，这种批量处理大数据的架构就叫做批处理大数据架构（整体架构图如下图所示）。

批处理架构的特点：慢，数据从产生到落盘，再到被 Spark 平台重新读取处理，往往要经历几十分钟甚至几小时的延迟。如果推荐系统是建立在这样的数据处理架构上，很难实时地抓住用户的新兴趣点。

2.2 流处理大数据架构

流处理大数据架构：在数据产生之后就立马处理它，而不是等到它落盘后再重新处理它；

即在数据产生后就直接对数据流进行处理

的架构。

它和批处理大数据架构相比，不仅用流处理平台替换掉了分布式批处理 Map Reduce 计算平台，而且在数据源与计算平台之间，也不再有存储系统这一层。这就大大提高了数据处理的速度，让数据的延迟可以降低到几分钟级别，甚至一分钟以内，这也让实时推荐成为了可能。

缺点：由于流处理平台是对数据流进行直接处理，它没有办法进行长时间段的历史数据的全量处理，这就让流处理平台无法应用在历史特征的提取，模型的训练样本生成这样非常重要的领域。

2.3 同具批处理、流处理优势的Flink

批流一体的大数据架构最重要的特点，就是在流处理架构的基础上添加了数据重播的功能。

数据重播功能：指的是在数据落盘之后，还可以

利用流处理平台同样的代码，进行落盘数据的处理

，这就相当于进行了一遍重播。这样就实现了离线环境下的数据批处理。而且由于流处理和批处理使用的是一套代码，因此完美保证了代码维护的一致性，是近乎完美的数据流解决方案。

很少公司实现这套方案的原因：有两大难点

大批成熟的互联网公司已经在 Spark 等批处理平台上，构建起了整套的数据体系，要想完全迁移到批流一体的数据体系上，有着非常沉重的技术负担。

批流一体的解决方案还很理想化，因为我们在实际处理特征的时候，很难让批处理和流处理完全共享一套代码。

ex：在流处理中可以很方便地计算出点击量、曝光量这类方便累计的指标，但如果遇到比较复杂的特征，像是用户过去一个月的平均访问时长，用户观看视频的进度百分比等等，这些指标就很难在流处理中计算得到了。这是因为计算这类特征所需的数据时间跨度大，计算复杂，流处理难以实现。

小结：对待流处理平台，取其所长。

具体点：在需要实时计算的地方发挥它的长处，但也没有必要过于理想主义，强调一切应用都应该批流一体，这反而会为我们增加过多的技术负担。

三、Flink如何处理数据流

Flink 中两个最重要的概念，数据流（DataStream）和窗口（Window）。

3.1 数据流

数据流其实就是消息队列，从网站、APP 这些客户端中产生的数据，被发送到服务器端的时候，就是一个数据消息队列，而流处理平台就是要对这个消息队列进行实时处理。

下图所示：来自三个用户的数据，其中一个一个紫色的点就是一条条数据，所有紫色的点按时间排列就形成了一个消息队列。

3.2 窗口

Flink 会怎么处理这个消息队列里的数据呢？

随着时间的流失，按照时间窗口来依次处理每个时间窗口内的数据。

比如图 4 中的数据流就被分割成了 5 个时间窗口，每个窗口的长度假设是 5 分钟，这意味着每积攒够 5 分钟的数据，Flink 就会把缓存在内存中的这 5 分钟数据进行一次批处理。这样，我们就可以算出数据流中涉及物品的最新 CTR，并且根据用户最新点击的物品来更新用户的兴趣向量，记录特定物品曝光给用户的次数等等。

除了上面例子中的固定窗口以外，Flink 还提供了多种不同的窗口类型，滑动窗口（Sliding Window）也是经常会用到的。

滑动窗口的特点是在两个窗口之间留有重叠的部分，Flink 在移动窗口的时候，不是移动 window size 这个长度，而是

移动 window slide 这个长度，window slide 的长度要小于 window size

。因此，窗口内部的数据不仅包含了数据流中新进入的 window slide 长度的数据，还包含了上一个窗口的老数据，这部分数据的长度是 window size-window slide。

问：滑动窗口这种方式有什么用呢？

答：它最典型的用处就是做一些数据的 JOIN 操作。比如我们往往需要通过 JOIN 连接一个物品的曝光数据和点击数据，以此来计算 CTR，但是注意

曝光数据肯定是在点击数据之前到达 Flink 的

。

那如果在分窗的时候，恰好把曝光数据和点击数据分割在了两个窗口怎么办呢？那点击数据就不可能找到相应的曝光数据了。这个时候，只要我们使用滑动窗口，这个问题就迎刃而解了。因为两个窗口重叠的部分给我们留了足够的余量来进行数据 JOIN，避免数据的遗漏。

除了固定窗口和滑动窗口，Flink 还提供了更丰富的窗口操作，比如基于会话的 Session Window，全局性的 Global Window。

除此之外，Flink 还具有数据流 JOIN，状态保存特性 state 等众多非常有价值的操作，想继续学习可以参考 Flink 的官方文档 。本次task只要清楚

Flink 的核心概念数据流和时间窗口

就可以了，因为它反映了流处理平台最核心的特点。

四、Flink 数据流处理实践

在 SparrowRecsys 项目上利用 Flink 实现一个特征更新的应用。

因为没有真实的数据流环境，所以我们可以利用 MoviesLens 的 ratings 表来模拟一个用户评分的数据流，然后基于这个数据流，利用 Flink 的时间窗口操作，来实时地提取出用户最近的评分电影，以此来反映用户的兴趣。

（详细代码：com.sparrowrecsys.nearline.flink.RealTimeFeature）。

（1）首先定义了一个评分的数据流 ratingStream，然后在处理 ratingStream 的时候，是把 userId 作为 key 进行处理。

（2）接着，又利用到了两个函数 timeWindow 和 reduce。利用 timeWindow 函数，我们可以把处理的时间窗口设置成 1s，再利用 reduce 函数，把每个时间窗口到期时触发的操作设置好。

（3）在完成了 reduce 操作后，我们再触发 addSink 函数中添加的操作，进行数据存储、特征更新等操作。

DataStream ratingStream = inputStream.map(Rating::new); ratingStream.keyBy(rating -> rating.userId) .timeWindow(Time.seconds(1)) .reduce( (ReduceFunction) (rating, t1) -> { if (rating.timestamp.compareTo(t1.timestamp) > 0){ return rating; }else{ return t1; } } ).addSink(new SinkFunction() { @Override public void invoke(Rating value, Context context) { System.out.println("userId:" + value.userId + "\tlatestMovieId:" + value.latestMovieId); } });

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

问：怎么把用户最近的高分电影评价历史，实时反映到推荐结果上？

答：我们的用户 Embedding 是通过平均用户的高分电影 Embedding 得到的，我们只需要在得到新的高分电影后，实时地更新用户 Embedding 就可以了，然后在推荐过程中，用户的推荐列表自然会发生实时的变化。这就是 SparrowRecsys 基于 Flink 的实时推荐过程。

五、作业

（1）实时性是不是对所有推荐系统都非常重要？比如对于抖音、快手这类短视频应用，还有优酷、Netflix 这类长视频应用，实时性对哪个更重要一些？为什么？

答：短视频应用的实时性要求更高！因为相同时间内，短视频用户的单视频停留周期短、场景更换频繁，用户兴趣反馈信息更多；

（2）Flink 要加强的往往是数据的实时性，特征的实时性，你觉得模型训练的实时性重要吗？模型训练的实时性发挥的作用和特征实时性有什么不同呢？

常说的推荐实时=7特征实时+3模型实时，都很重要！特征实时推荐是加强当前用户关注话题（现在、个别），模型训练实时推荐加强的用户未来关注的话题（下次、整体）。业界常见的做法，基于用户特征实时变化的推荐（热周期-用户活跃期），至于模型训练（或强化学习）放在冷周期（用户睡眠期）。

六、课后答疑

Reference

（1）https://github.com/wzhe06/Reco-papers

（2）《深度学习推荐系统实战》，王喆

（3）flink官方文档：https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/dev/datastream/operators/windows/

Flink 推荐系统

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。