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

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
简介: ex:小明在刷抖音的足球视频,接着会继续推荐出相关视频,如果推荐系统没有实时抓住用户的兴趣点,推荐大妈广场舞的视频,小明可能会对该产品失去兴趣哈哈。

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

带着三个问题进行学习:

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

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

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

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

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

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

2.1 传统批处理大数据架构

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

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

image.png

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

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

2.2 流处理大数据架构

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

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

image.png

图2 流处理大数据架构

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

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

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

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

image.png

图3 批流一体大数据架构

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

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

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

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

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

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

三、Flink如何处理数据流

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

3.1 数据流

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

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

image.png

图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。

image.png

图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模型实时,都很重要!特征实时推荐是加强当前用户关注话题(现在、个别),模型训练实时推荐加强的用户未来关注的话题(下次、整体)。业界常见的做法,基于用户特征实时变化的推荐(热周期-用户活跃期),至于模型训练(或强化学习)放在冷周期(用户睡眠期)。

相关实践学习
基于Hologres轻松玩转一站式实时仓库
本场景介绍如何利用阿里云MaxCompute、实时计算Flink和交互式分析服务Hologres开发离线、实时数据融合分析的数据大屏应用。
Linux入门到精通
本套课程是从入门开始的Linux学习课程,适合初学者阅读。由浅入深案例丰富,通俗易懂。主要涉及基础的系统操作以及工作中常用的各种服务软件的应用、部署和优化。即使是零基础的学员,只要能够坚持把所有章节都学完,也一定会受益匪浅。
相关文章
|
3月前
|
存储 SQL 安全
联通实时计算平台问题之如何体现集群治理的效果
联通实时计算平台问题之如何体现集群治理的效果
|
3月前
|
消息中间件 分布式计算 Kafka
联通实时计算平台问题之实时计算平台对于用户订阅和数据下发是如何支持的
联通实时计算平台问题之实时计算平台对于用户订阅和数据下发是如何支持的
|
3月前
|
消息中间件 监控 Java
联通实时计算平台问题之监控Kafka集群的断传和积压情况要如何操作
联通实时计算平台问题之监控Kafka集群的断传和积压情况要如何操作
|
3月前
|
消息中间件 监控 Kafka
联通实时计算平台问题之Flink状态后端数据量较大时,问题排查要如何进行
联通实时计算平台问题之Flink状态后端数据量较大时,问题排查要如何进行
|
3月前
|
消息中间件 存储 算法
联通实时计算平台问题之亿级标签关联实现且不依赖外部系统要如何操作
联通实时计算平台问题之亿级标签关联实现且不依赖外部系统要如何操作
|
3月前
|
消息中间件 监控 Kafka
联通实时计算平台问题之实时计算平台的数据处理流程是什么样的
联通实时计算平台问题之实时计算平台的数据处理流程是什么样的
|
3月前
|
监控 Java Serverless
美团 Flink 大作业部署问题之想在Serverless平台上实时查看Spring Boot应用的日志要怎么操作
美团 Flink 大作业部署问题之想在Serverless平台上实时查看Spring Boot应用的日志要怎么操作
|
存储 数据安全/隐私保护 流计算
Flink流处理之窗口算子分析
窗口算子WindowOperator是窗口机制的底层实现,它几乎会牵扯到所有窗口相关的知识点,因此相对复杂。本文将以由面及点的方式来分析WindowOperator的实现。首先,我们来看一下对于最常见的时间窗口(包含处理时间和事件时间)其执行示意图: 上图中,左侧从左往右为事件流的方向。
1648 0
|
2月前
|
运维 数据处理 数据安全/隐私保护
阿里云实时计算Flink版测评报告
该测评报告详细介绍了阿里云实时计算Flink版在用户行为分析与标签画像中的应用实践,展示了其毫秒级的数据处理能力和高效的开发流程。报告还全面评测了该服务在稳定性、性能、开发运维及安全性方面的卓越表现,并对比自建Flink集群的优势。最后,报告评估了其成本效益,强调了其灵活扩展性和高投资回报率,适合各类实时数据处理需求。
|
4月前
|
存储 监控 大数据
阿里云实时计算Flink在多行业的应用和实践
本文整理自 Flink Forward Asia 2023 中闭门会的分享。主要分享实时计算在各行业的应用实践,对回归实时计算的重点场景进行介绍以及企业如何使用实时计算技术,并且提供一些在技术架构上的参考建议。
803 7
阿里云实时计算Flink在多行业的应用和实践

热门文章

最新文章