小红书上首页推荐及热门方法小红书首页推荐怎么上

小红书首页本文整理自2019阿里云峰会·上海开发者大会开源大数据专场中小红书实时推荐团队负责人郭一先生现场分享。小红书作为生活分享类社区，目前有8500万用户，年同比增长为300%，大约每天有30亿条笔记在发现首页进行展示。推荐是小红书非常核心且重要的场景之一，本文主要分享在推荐业务场景中小红书的实时计算应用。
实时计算在推荐业务中的场景线上推荐流程
小红书线上推荐的流程主要可以分为三步。第一步，从小红书用户每天上传的的笔记池中选出候选集，即通过各种策略从近千万条的笔记中选出上千个侯选集进行初排。第二步，在模型排序阶段给每个笔记打分，根据小红书用户的点赞和收藏行为给平台带来的价值设计了一套权重的评估体系，通过预估用户的点击率，评估点击之后的点赞、收藏和评论等的概率进行打分。第三步，在将笔记展示给用户之前，选择分数高的笔记，通过各种策略进行多样性调整。
在此模型中最核心的点击率、点赞数、收藏、评论等都是通过机器学习模型训练对用户各项行为的预估并给出相应分数。

文章插图
推荐系统架构
在小红书线上推荐过程的背后是一套完整的从线上到线下的推荐系统，下图展示了小红书推荐系统架构，红色表示实时操作，灰色则是离线操作。通过算法推荐之后，用户和笔记进行交互，产生用户的曝光、点赞和点击的信息，这些信息被收集形成用户笔记画像，也会成为模型训练的训练样本，产生分析报表。训练样本最终生成预测模型，投入线上进行算法推荐，如此就形成了一个闭环，其中分析报表则由算法工程师或策略工程师进行分析，调整推荐策略，最后再投入到线上推荐中。

文章插图
离线批处理
离线批处理流程如下图所示，之前的处理流程是在客户端产生用户交互和打点，打点好的数据放入数仓中，以T+1模式更新用户笔记画像，生成报表并生成训练样本，最后进行模型训练和分析。小红书初级版本的离线批处理情况，整个流程都基于Hive进行处理，处理流程较慢，无法满足业务需求。

文章插图
实时流处理
2018年开始小红书将离线的pipeline升级为实时的pipeline，用户一旦产生交互点击，系统会实时维护数据，更新用户笔记画像，实时产生训练样本，更新模型及生成报表。实时的流处理大大提高了开发效率，同时实时流处理依赖于Flink 。在实时流中，首先用户的实时交互进入Kafka，借助Flink任务维护用户笔记画像，将其传给线上用户画像系统。相对来说，用户的笔记画像比较简单，不会存在过多的状态，而实时流处理中非常重要的场景是实时归因，这也是小红书最核心的业务。实时归因是一个有状态的场景，根据打点信息产生用户的行为标签，所有实时指标和训练样本都依赖行为标签，其中，实时指标放在ClickHouse，数据分析师和策略工程师基于ClickHouse数据进行分析，训练样本仍然落到Hive中进行模型训练，同时在线学习系统中会将训练样本落到Kafka，进行实时模型训练。

文章插图
实时归因实时归因数据
实时归因将笔记推荐给用户后会产生曝光，随即产生打点信息，用户笔记的每一次曝光、点击、查看和回退都会被记录下来。如下图所示，四次曝光的用户行为会产生四个笔记曝光。如果用户点击第二篇笔记，则产生第二篇笔记的点击信息，点赞会产生点赞的打点信息；如果用户回退就会显示用户在第二篇笔记停留了20秒。实时归因会生成两份数据，第一份是点击模型的数据标签，在下图中，第一篇笔记和第三篇笔记没有点击，第二篇笔记和第四篇笔记有点击，这类数据对于训练点击模型至关重要。同样，点赞模型需要点击笔记数据，比如用户点击了第二篇笔记并发生点赞，反之点击了第四篇笔记但没有点赞，时长模型需要点击之后停留的时间数据。以上提到的数据需要与上下文关联，产生一组数据，作为模型分析和模型训练的原始数据。

文章插图
Flink Job - Session Labeler
小红书在处理实时归因原始数据时应用了Flink任务。从Kafka Source中读数据再写到另外一个Kafka Sink 。Key（user_id和note_id）根据用户笔记和是否发生曝光和点击分为两个Session，Session使用Process Function API处理记录，每条记录都会记录曝光的Session和点击的Session 。Session有20分钟的定长窗口，即在收到用户行为曝光或者点击之后，开20分钟的窗口查看是否这期间会发生曝光、点击、点赞或者停留了多少时间。Session中有状态信息，比如发生点击并点赞，系统维护用户在状态中停留的时间，检查点击是否有效等。Flink窗口结束时，需要将Session State中的内容输出到下游，进行分析和模型训练，同时清除ValueState 。

小红书上首页推荐及热门方法 小红书首页推荐怎么上

秒懂生活扩展阅读

小红书上首页推荐及热门方法小红书首页推荐怎么上