Press "Enter" to skip to content

原力计划【王喆-推荐系统】前沿篇-(task3)流处理平台Flink:实时推荐

本站内容均来自兴趣收集,如不慎侵害的您的相关权益,请留言告知,我们将尽快删除.谢谢.

 

学习总结

 

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

 

(2)Flink 提高推荐系统实时性:用户数据进入数据流,即进入数据消息队列后,会被分割成一定时长的时间窗口,之后 Flink 会按照顺序来依次处理每个时间窗口内的数据,计算出推荐系统需要的特征。这个处理是直接在实时数据流上进行的,所以相比原来基于 Spark 的批处理过程,实时性有了大幅提高。

 

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

文章目录

一、实时性是影响推荐系统效果的关键因素
二、批流一体的数据处理体系
2.1 传统批处理大数据架构
2.3 同具批处理、流处理优势的Flink
三、Flink如何处理数据流
四、Flink 数据流处理实践

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

 

带着三个问题进行学习:

为什幺说实时性是影响推荐系统效果的关键因素?
到底什幺是批流一体的数据处理体系?
业界流行的 Flink 到底是怎幺实现数据流处理的?

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

 

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

 

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

 

2.1 传统批处理大数据架构

 

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

 

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


图1 传统批处理大数据架构

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

 

2.2 流处理大数据架构

 

流处理大数据架构:在数据产生之后就立马处理它,而不是等到它落盘后再重新处理它;即在数据产生后就直接对数据流进行处理的架构。

 

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


图2 流处理大数据架构

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

 

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

 

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

 

数据重播功能:指的是在数据落盘之后,还可以利用流处理平台同样的代码,进行落盘数据的处理,这就相当于进行了一遍重播。这样就实现了离线环境下的数据批处理。而且由于流处理和批处理使用的是一套代码,因此完美保证了代码维护的一致性,是近乎完美的数据流解决方案。


图3 批流一体大数据架构

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

大批成熟的互联网公司已经在 Spark 等批处理平台上,构建起了整套的数据体系,要想完全迁移到批流一体的数据体系上,有着非常沉重的技术负担。
批流一体的解决方案还很理想化,因为我们在实际处理特征的时候,很难让批处理和流处理完全共享一套代码。

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

 

小结:对待流处理平台,取其所长。

 

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

 

三、Flink如何处理数据流

 

Flink 中两个最重要的概念,数据流(DataStream)和窗口(Window)。

 

3.1 数据流

 

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

 

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


图4 数据流和窗口

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。


图5 Flink中的滑动窗口

问:滑动窗口这种方式有什幺用呢?

 

答:它最典型的用处就是做一些数据的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<Rating> ratingStream = inputStream.map(Rating::new);
ratingStream.keyBy(rating -> rating.userId)
        .timeWindow(Time.seconds(1))
        .reduce(
                (ReduceFunction<Rating>) (rating, t1) -> {
 
                    if (rating.timestamp.compareTo(t1.timestamp) > 0){
 
                        return rating;
                    }else{
 
                        return t1;
                    }
                }
        ).addSink(new SinkFunction<Rating>() {
 
    @Override
    public void invoke(Rating value, Context context) {
 
        System.out.println("userId:" + value.userId + "\tlatestMovieId:" + value.latestMovieId);
    }
});

 

问:怎幺把用户最近的高分电影评价历史,实时反映到推荐结果上?

 

答:我们的用户 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/

Be First to Comment

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注