小红书如何实现高效推荐？解密背后的大数据计算平台架构

本文整理自2019阿里云峰会上海开发者大会开源大数据专场中小红书实时推荐团队负责人郭毅先生的现场分享。 作为生活分享社区小红书推荐，小红书目前拥有8500万用户，同比增长300%，首页每天展示约30亿条笔记。 推荐是小红书核心、重要的场景之一。 本文主要分享小红书在推荐业务场景中的实时计算应用。

实时计算在推荐业务中的场景

网上转介流程

小红书的在线推荐流程可以分为三个主要步骤。 第一步是从小红书用户每天上传的笔记池中选取候选集，即通过各种策略从近千万条笔记中选取数千个候选集进行初步排名。 第二步是在模型排序阶段对每条笔记进行打分，根据小红书用户的点赞和收藏给平台带来的价值设计加权评价体系。 通过预估用户的点击率，来评估点击率。 对后续点赞、收藏和评论的概率进行评分。 第三步，在将笔记呈现给用户之前，选择得分高的笔记，并通过各种策略进行多样性调整。

在这个模型中，核心的点击率、点赞数、收藏数、评论数等都是通过机器学习模型训练来估计的，从而预测用户行为并给出相应的分数。

推荐系统架构

小红书在线推荐流程的背后是一套从线上到线下完整的推荐系统。 下图是小红书推荐系统的架构。 红色表示实时运行，灰色表示离线运行。 经过算法推荐后，用户与笔记进行交互，生成用户曝光、点赞、点击信息。 这些信息被收集起来形成用户笔记肖像，也将成为模型训练的训练样本并生成分析报告。 训练样本最终生成预测模型，投入在线算法推荐，从而形成闭环小红书推荐，其中分析报告由算法工程师或策略工程师分析，调整推荐策略，最后投入在线算法推荐。在线推荐。

离线批处理

离线批处理流程如下图所示。 前面的处理过程是在客户端生成用户交互和管理，将处理后的数据放入数据仓库，以T+1模式更新用户笔记画像，生成报告并生成训练样本。 最后进行模型训练和分析。 对于小红书初级版本的离线批量处理，整个流程是基于Hive的。 处理过程缓慢，无法满足业务需求。

实时流处理

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

实时归因

实时归因数据

实时归因向用户推荐笔记后会产生曝光，进而生成管理信息。 用户笔记的每一次曝光、点击、查看、回滚都会被记录。 如下图所示，四次曝光的用户行为将导致四次笔记曝光。 如果用户点击第二条笔记，则会生成第二条笔记的点击信息，并生成类似的点击信息； 如果用户返回，则会显示用户在第二个音符上停留了 20 秒。 实时归因会生成两条数据。 第一个是点击模型的数据标签。 在下图中，第一个和第三个音符没有咔嗒声，而第二个和第四个音符有咔嗒声。 此类数据对于训练点击模型至关重要。 同样，同类模型需要点击备注数据。 例如，如果用户点击第二个笔记并且喜欢它，相反，他点击第四个笔记但不喜欢它。 时长模型需要点击后所花费时间的数据。 上述数据需要与上下文关联生成一组数据，作为模型分析和模型训练的原始数据。

Flink 工作 –

小红书在处理实时属性原始数据时应用了Flink任务。 从 Kafka 读取数据并写入另一个 Kafka Sink。 Key（和）根据用户备注以及是否发生曝光和点击分为两部分，使用API​​处理记录，每条记录都会记录曝光和点击。 有一个20分钟的定长窗口，即在收到用户行为曝光或点击后，打开一个20分钟的窗口，查看这段时间是否会有曝光、点击、点赞，或者停留多长时间。 里面有状态信息，比如点击、点赞，系统维护用户在该状态停留的时间，检查点击是否有效等。当Flink窗口结束时，需要将State中的内容输出到下游进行分析和模型训练，同时进行清理。

实际生产中需要解决的问题

要在实际生产中实现Flink任务，需要解决很多问题。 首先是如何管理Flink的集群，这需要在生产环境安装好之后进行，并且任务要持久化。 特别是一旦持久化失败，就需要回到过去的某个时间，清除错误的数据并恢复数据。

Flink集群管理：小红书选择在K8s集群上部署Flink。 在小红书看来，K8S可能是未来的趋势之一。

& 状态持久化：Flink的State分为、和两种。 支持较小的状态，但不支持增量状态。 在实时归因场景中，有一个20分钟的窗口，20分钟内发生的所有状态都会被存储在内存中并定期持久化。 如果你想避免这20分钟的数据丢失，它是一个更好的选择，因为它支持增量。

调音：具体使用过程中还是会遇到调音问题。 小红书开始测试时，频率设置比较短，一分钟做一次，每次做完都需要将数据从内存刷到磁盘。 当频率较高时，会生成很多小的std文件，并且会花费很多时间。 将小文件集成并合并为大文件需要时间和资源。 国家本身就比较大。 如果闪存持续下去，磁盘I/O将成为瓶颈，最终导致上游背压。

还有一个问题就是使用的时候会产生更多。 如果内存配置不当，会导致out of，需要重新计算内存，分配内存，K8s点内存。 调优后，任务运行更加稳定。 这时就需要将本地磁盘更换为高性能SSD，以保证内存有足够的空间。

而且每次做都会有性能损失。小红书选择将频率改为十分钟，也能满足生产需求，回填10分钟的数据只需要一到两分钟。 需要注意的是要调整大小，避免频繁合并小文件

：回填是生产中常见的情况。 在实际生产中，如果开发人员编写了错误的代码，导致数据错误，则需要删除错误的数据，重新运行正确的代码，回填正确的数据。 另外，如果只有一个like函数，则会生成一个新的。 需要回填场景，分析用户的点赞是否为有效的点赞，或者对其进行简单的逻辑恢复。 非常依赖Flink对Hive的支持。 小红书的数据一直存储在 Hive 上，所以非常期待 Flink 1.9 版本的性能提升，尤其是对 Hive 支持的完善以及对批量支持的加强。

Red Flink实时流计算平台

小红书实时流计算平台及周边生态

小红书的推荐系统是一个流计算平台，也涉及到周边的生态。 如下图，最右侧为数据访问模块，支持客户端数据访问，后端服务提供的模块帮助业务直接访问实时计算平台。 红色模块是流计算平台中正在开发的模块。 例如Canal通过交易的数据库日志直接将订单流连接到数据平台。 系统自动分析数据，如果有变化则自动重启对应的Flink任务。 左下角是基于Flink 1.8开发的。 在此基础上根据业务需求增加监控，方便分析Flink拥塞情况，同时监控直连系统。 小红书也基于Flink的SQL进行了开发，实现了不同的服务，例如Hbase、Kafka等。目前该平台不仅支持实时归因场景，还支持数据ETL、实时Spam、实时DAU 。 包括我们现在开发的实时RGMV大促看板都是基于这个平台。

小红书Flink系统

下图是系统的部分截图。 左边，业务方使用小红书Flink实时流计算平台时，可以选择数据去向，比如aws-hive、rex-，表示数据需要放在Hive中，然后在 中输入 JSON 或 PB 格式的数据，平台可以自动识别，同时将数据转换为 Flink SQL ETL 命令，并自动更新 Flink ETL Job 的任务。 另外系统会对任务进行监控，监控任务的延迟时间，是否有数据丢失。 如果延迟太高或者有数据丢失，将会产生警报以及警报的级别。

小红书平台推荐预测模型的演进

上面简单介绍了小红书的实时计算平台，其他部分就是sum。 2018年12月，小红书的推荐预测模型还只是Spark上一个非常简单的GBDT模型。 后来GBDT模型中加入了LR层，随后又引入了Deep和Wide。 截至2019年7月，小红书的推荐预测模型已进化为GBDT+D&W模型。 小红书主要有9个预测任务，包括点击、隐藏、点赞、收藏、分享等。 其中，Click是小红书最大的模型。 每天生成约5亿个样本用于模型训练，数据量达到1T/天。

目前小红书的Red ML模型是基于小红书做ML模型时开源社区流行的分布式训练，TFJob可以支持。

总结与展望

小红书从去年年底开始就在做推荐系统。 系统的建设既依赖开源社区，又拥抱开源社区。 整个实时计算平台基于Flink构建，期待Flink 1.9支持Hive和Batch的新功能； AI目前是小红书比较强烈的要求，包括模型训练算力、效率等都非常敏感，也会持续关注社区相关技术； 后期希望将Flink和AI结合起来，将流计算和机器学习无缝结合，实现更智能、更高效的推荐。