深度学习推荐系统实战_39_30_流处理平台Flink是如何快速识别用户兴趣实现实时推荐的
你好，我是王哲。
那今天啊我想和你聊聊流处理平台，flink是怎么实现实时推荐功能的那在今年刚刚结束的双十一活动中啊，技术圈呢出现了一个非常劲爆的新闻，就是阿里基于flink实现了数据的批流一体处理。
每秒钟呢能够处理四十亿条的巨量处据，这也是业界啊首次在这么大规模的数据宏峰上呢实现数据流的实时处理。
也正是因为实时数据流处理功能的实现啊，让阿里的推荐系统呢能够在双十一期间做出更快的反应，实时抓住用户的兴趣，给出更准确的推荐。
那这节课啊我就带你揭开阿里使用的流处理平台。
Flink的面纱来重点要解决三个问题，分别是问题。
一、为什么说实时性是影响推荐系统效果的关键因素问题。
二、到底什么是批流一体的数据处理体系？问题。
三、业界流行的flink到底是怎么样实现一个数据流处理的？好了，那我们先来解决第一个问题，为什么说实时性是影响推荐系统的关键因素？周星驰的功夫你应该看过吧，它里面有一句著名的台词说呀天下武功无坚不摧，唯快不破。
那如果说推荐模型的架构呢是一把无坚不摧的玄铁重剑啊，那么推荐系统的实时性啊，就是唯快不破的柳叶飞刀。
那么这把柳叶飞刀到底是怎么发挥作用的呢？我说一个我们身边的场景你就明白了。
假设啊你现在呢正在手机上刷抖音，你刚刚看了一个精彩的足球进频的视频，感觉意犹未尽啊，还想看更多这样的视频。
这时候抖音的推荐系统肯定不会让你失望，它很快呢就会接收到你观看了精彩的进球视频的信号，快速的抓住你的兴趣点，然时呢它会迅速的做出反馈，给你推荐更多类似的视频。
那我们也可以试想一下，如果抖音的推荐系统实时性不够的话，会发生什么呢？可能你看完了精彩的进球视频之后呢，推荐系统还跟什么都没发生一样，依旧按部就班的给你推荐一些原本就设定好的不相关的视频。
如果是这样的话呀，抖音又怎么能让你欲罢不能，刷了又想刷呢？这个例子啊就充分说明了推荐系统只有拥有实时抓住用户新兴趣点的能力，才能让你的用户呢离不开你那作为推荐系统的工程师啊，我们就要好好想想到底怎样呢才能实现用户兴趣的快速提取呢？这就不得不提到推荐系统的快据体系了。
我们之前说的数据处理啊，无论是数据的预处理还是特征工程，大部分啊是在spark平台上完成的。
Spark平台特点。
是啊它处理的数据呢都是已经落盘的数据。
也就是说啊这些数据要么在硬盘上，要么在分布式的文件系统上，然后呢才会被批量的载入到spark平台上进行运算处理。
这种批处理大数据的架构呢就叫做批处理大数据架构。
我把它的整体结构图呢放在了文稿里，你可以去看看。
但是啊批处理架构的特点就是慢数据从产生到落盘，再到被spark平台重新读取处理，经常是要经历几十分钟甚至几个小时的延迟。
如果推荐系统是建立在这样的数据处理架构上，还有可能实时的抓住用户的新数据点吗？肯定是没有希望了。
那怎么办呢？我们能不能在数据产生之后立马处理它，而不是等到它落盘之后再处理它呢？当然是可以的。
这种在数据产生后啊，就直接对数据流进行处理的架构呢，就叫做流处理大数据架构。
我在文稿中呢放了一张流处理架构的示意图。
从图中啊我们可以看到它和批处理大数据架构相比啊，不仅用流处理平台代替了分布式批处理MAREDC ce的计算平台。
而且啊在数据源与计算平台之间呢，也不再有存储系统这一层了。
这就大大提高了数据处理的速度，让数据的延迟啊可以降低到几分钟级别甚至一分钟以内，这也让实时推荐啊成为了可能。
但是啊流处理平台呢也不是十全十美了。
由于流处理平台呢是对数据流进行直接处理，它没有办法进行长时间段的历史数据的全量处理。
这就让流处理平台啊没法应用在历史特征的提取模型的训练以及样本生成这样非常重要的领域。
那是不是说根本就没有能够同时具有批处理流处理优势的解决方案吗？当然是有的。
这就是我们在一开始说的批流一体的大数据架构。
其中啊最有代表性的就是flick.我把它的架构示意图啊放在了文稿里。
批流一体的大数据架构最重要特点啊，就是在流处理架构的基础上呢添加了数据重播的功能。
那我们怎么去理解这个数据重播功能呢？它指的是啊数据落盘之后，我们还可以利用流处理平台，同样的代码呢进行一个落盘数据的处理。
这就相当于啊进行了一遍重播，这样不就实现了离线环境下数据批处理了吗？而且啊由于流处理和批处理使用的是一套代码，因此啊完美保证了代码维护的一致性，是近乎完美的数据流解决方案。
那既然批流一体的大数据架构这么完美，那为什么我们很少听说有实现这套方案的公司呢？以我个人的实践经验来看，这主要是因为它实现起来啊有两个难点。
难点一大批成熟的互联网公司啊，已经在spark这样的批处理平台上构建起了整套的数据体系。
要想完整迁移到批流一体的数据体系上呢，是有着非常沉重的技术负担的难点。
二批流一体的解决方案呢还很理想化。
因为我们在实际处理特征的时候啊，很难让批处理和流处理完全共享一套代码。
比如说啊我们在流处理中呢，可以很方便的计算出点击量曝光量这类方便累计的指标。
但如果遇到比较复杂的特征，像是用户过去一个月的平均访问时长，用户观看视频的进度百分比等等，这些指标就很难在流处理中计算得到了。
这是因为啊计算这类特征呢所需的数据时间跨度大，计算复杂，流处理呢难以实现。
现在啊在对待流处理平台的时候呢，我们的态度呢应该是取其所长。
更具体点来说呢，就是在需要实时计算的地方呢发挥它的长处，但也没有必要过于理想主义，强调一切应用都应该批流一体，这反而呢会给我们增多过多的技术负担。
现在啊我们已经清楚流处理平台的特点和优势的。
但flink平台到底是怎么进行流数据处理的呢？我们现在认识flink中两个最重要的概念，数据流和窗口。
数据流呢其实就是消息队列，从网站、app这些客户端中产生的数据啊被发送到服务器端的时候呢，就是一个数据消息队列。
而流处理平台呢就是要对这个消息队列啊进行实时处理，就像文稿中的图四一样，上面呢是来自三个用户的数据，其中呢一个个紫色的点啊就是一条条数据。
所有紫色的点呢按照时间的排列呢就形成了一个消息队列。
知道什么是消息队列。
那flink会怎么处理这个消息队列里的数据呢？答案很简单，那就是随着时间的流失，按照时间窗口啊来依次处理每个时间窗口内的数据。
比如说啊图四中的数据流呢就被分割成了五个时间窗口，每个窗口的长度啊假设是五分钟。
这就意味着每积攒够五分钟的数据啊，flink就会把缓存在内存中的这五分钟的数据啊进行一次批处理。
这样啊我们就可以计算出数据流中涉及物品的最新CPR.并且啊根据用户最新点击的物品呢来更新用户的兴趣向量，记录特定物品曝光给用户的次数等等。
那除了刚才这个例子中的固定窗口以外啊，flink呢还提供了很多种不同的窗口类型。
滑动窗口啊也是我们会经常用到的，结合文稿中的图五啊，我们可以看到滑动窗口的特点啊，是在两个窗口之间呢留有重叠的部分。
这样的话，flink在移动窗口的时候不是移动windows size这个长度，而是移动windows slide的这个长度。
Windows slide长度呢要小于windows size.因此啊窗口内部的数据啊不只包含了数据流中新进进入的windows lide长度的数据啊，还包含了上一个窗口的老数据。
那滑动窗口这种方式有什么用呢？它最典型的用处啊就是做一些数据的junin操作。
比如啊我们经常需要通过join连接一个物品的曝光数据和点击数据来计算CPR.但你要知道啊，曝光数据呢肯定是在点击数据之前呢达到flink的那如果在分窗的时候，恰好把曝光数据和点击数据分割在了两个窗口，怎么办呢？点击数据就不可能找到相应的曝光数据了。
这个时候啊只要我们使用滑动窗口，这个问题就迎刃而解了。
因为两个窗口的重叠部分呢，给我们留了足够的余量来进行数据join,避免数据的遗漏。
事实上啊除了固定窗口和滑动窗口，flink还提供了更丰富的窗口操作。
比如说啊基于绘画的session window,全局性的global window,以及很多其他非常有价值的操作。
如果你还想进一步了解的话，可以在课后参考我在文稿中给出的flink官方文档链接。
我们这节课呢只需要清楚flink的核心概念、数据流和时间窗口就可以了。
因为它反映了流处理平台最核心的特点。
讲完了基础知识，接下来就又到了实践的环节了。
我们要继续在sparrow access项目上利用flink呢来实现一个特征更新的应用。
因为没有真实的数据流环境啊，所以我们利用movie les的rating表呢来模拟一个用户评分的数据流。
然后呢，基于这个数据流啊，利用flink的时间窗口操作，来实时的提取出用户最近的评分电影，以此呢来反映用户的兴趣。
我把sparl access的相关代码呢放在了文稿里。
你可以看到啊，我首先呢是定义了一个评分的数据流rating stream.然后呢，在处理rating stream的时候呢，是把user ID作为更t进行处理的。
接着啊我又利用到了两个函数time window和reduce利用time window函数啊，我们可以把处理的时间窗口呢设置为一秒，再利用reduce函数呢把每个时间窗口到期时触发的操作呢设置好在完成了。
Reduce操作后啊，我们在触发add i ink函数中添加的操作，进行一个数据存储特征更新等等操作。
那看完了这些操作，你知道我们应该怎么把用户最近的用户评价历史实时的反映到推荐结果上了吗？其实很简单，我们的用户embedding是通过平均用户的高分电影embedding得到的。
我们只需要在得到新的高分电影后呢，实时的更新用户embedding就可以了。
然后在推荐的过程中啊，用户的推荐列表啊自然会发生实时的变化。
这就是sparry access基于flink的实施推荐过程。
好了，今天课程讲完了，我们一起来做个总结。
这节课呢我们了解了流处理平台flink的特点。
并且呢通过flink的实践清楚了利用流处理平台，提高实时推荐系统实时性的方法。
Flink啊是最具代表性的批流一体的大数据平台。
它的特点啊是让批处理和流处理共用一套代码，从而呢既能批处理已落盘的数据，又能直接处理实时数据流。
从理论上来说啊，是近乎完美的数据流解决方案。
而flink提高推荐系统实时性的原理呢，可以理解成啊是用户数据进入数据流，也就是数据消息队列后呢会被分割成一定时长的时间窗口之后啊，flink会按照顺序来依次处理，每个时间窗口内的数据计算出推荐系统需要的特征。
这个处理啊是直接在实时数据流上进行的。
所以啊相比原来基于spark的批处理过程，实时性的大幅提高。
为了方便你复习啊，我把这节课的核心概念呢总结在了文稿的表格里，希望你能记住他们。
至于flink的实时性实践，我们要记住利用flink我们可以实时的获取到用户刚刚评价过的电影，然后呢就可以通过实时更新用户embedding来实现spiral access的实时推荐。
最后啊我们再来看两道课后思考题。
第一题，你觉得实时性是不是对所有的推荐系统都非常重要呢？比如说实时性，是对于抖音、快手这类短视频应用，还是对优酷、netflix、 x类类视频应用更重要一些。
为什么？第二题，flink要加强的往往是数据的实时性以及特征的实时性。
那你觉得模型训练的实时性重要吗？模型训练的实时性发挥的作用和特征实时性有什么不同呢？期待在留言区看到你对flink的思考和疑惑，我们下节课见。