2019阿里云峰会·上海开发者大会于7月24日盛大开幕，本次峰会与未来世界的开发者们分享开源大数据、IT基础设施云化、数据库、云原生、物联网等领域的技术干货，共同探讨前沿科技趋势。本文整理自开源大数据专场中小红书实时推荐团队负责人郭一先生的经常演讲，将为大家分享小红书大数据计算平台架构演进。
开源大数据专场PPT下载
以下内容根据演讲视频以及PPT整理而成。
一、实时计算在推荐业务中的场景
1. 线上推荐流程
小红书线上推荐的流程主要可以分为三步。第一步，从小红书用户每天上传的的笔记池中选出候选集。既通过各种策略从近千万条的笔记中选出上千个侯选集进行初排。第二步，在模型排序阶段给每个笔记打分。小红书内部用户的点赞和收藏的给平台带来的价值做了一套权重的设计，通过预估用户的点击率CTR，预计点击之后的点赞、收藏和评论的概率进行打分。第三步，在将笔记展示给用户之前，选择分数高的笔记，通过各种策略进行多样性调整。
2. 推荐系统架构
下图展示了小红书推荐系统架构，红颜色表示实时操作，灰色则是离线操作。通过算法推荐之后，用户和笔记进行交互，产生用户的曝光、点赞和点击的信息，这些信息被收集之后形成用户笔记画像，也会成为模型训练的训练样本，产生分析报表。训练样本最终生成预测模型，投入线上进行算法推荐，这样就形成了一个闭环。分析报表则由算法工程师或策略工程师进行分析，调整推荐策略，最后投入线上。
3. 离线批处理
离线批处理流程如下图所示，在客户端产生用户交互和打点，打点好的数据以T+1模式更新用户笔记画像，生成报表并生成训练样本，最后进行模型训练和分析。这是小红书初级版本的离线批处理情况，整个流程都基于Hive进行处理，可以发现整个流程是非常慢的。
4.实时流处理
2018年开始小红书将离线的pipeline升级成实时的pipeline。用户一旦产生交互点击，系统会实时维护数据，更新用户笔记画像，实时产生训练样本，更新模型及生成报表。实时的流处理大大增加了开发效率。实时流处理依赖于Flink，首先用户的实时交互进入Kafka，借助Flink任务维护用户笔记画像，将其传给线上用户画像系统。相对来说，用户的笔记画像比较简单，不会存在过多的状态。而实时流处理中非常重要的场景是实时归因，它是小红书最核心的业务。实时归因是一个有状态的场景，实时归因根据打点信息产生用户的行为标签，所有实时指标和训练样本都依赖行为标签。其中，实时指标放在Click House，数据分析师和策略工程师基于ClickHouse数据进行分析。训练样本仍然落到Hive中进行模型训练。
二、实时归因
1. 实时归因数据
实时归因将笔记推荐给用户后会产生曝光，随即在小红书客户端上产生打点信息。用户笔记的每一次曝光、点击、查看和回退都会被记录下来。如下图所示，四次曝光的用户行为会产生四个笔记曝光。如果用户点击第二篇笔记，则产生第二篇笔记的点击信息，点赞会产生点赞的打点信息，如果用户回退就会显示用户在第二篇笔记停留了20秒。实时归因会生成两份数据，第一份是点击模型的数据标签，在下图中，第一篇笔记和第三篇笔记没有点击，第二篇笔记和第四篇笔记有点击，这类数据对于训练点击模型至关重要。同样，点赞模型需要点击笔记数据，比如用户点击了第二篇笔记并发生点赞，反之点击了第四篇笔记但没有点赞。时长模型需要点击之后停留的时间数据。以上提到的数据需要与上下文关联，产生一组数据，作为模型分析和模型训练的原始数据。
2. 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 中的内容输出到下游，进行分析和模型训练，同时清ValueState。
3. 实际生产需要解决的问题
在实际生产中落地Flink任务需要解决较多的问题。首先是如何对Flink进行集群管理？上了生产环境之后需要做Checkpoint，将任务持久化。以及非常重要的一点，Backfill。持久化一旦出错，需要回到过去的某个时间，重新清除错误数据并恢复数据。
Flink集群管理：小红书选择将Flink部署在 K8S集群上。在小红书看来，K8S或许是将来的趋势。
Checkpoint & State持久化：Flink 的State 分为两种，FsStateBackend和RocksDBStateBa
ckend。FsStateBackend支持较小的状态，但不支持增量的状态。在实时归因的场景中有20分钟的窗口，20分钟之内发生的所有的状态会放在内存中，定期做持久化。如果要避免这20分钟的数据丢失，RocksDBStateBackend是较好的选择，因为RocksDBStateBackend支持增量Checkpoint。
RocksDB调优：具体使用RocksDBStateBackend时依然会遇到调优问题。小红书在开始测试的时候，Checkpoint频率设的较短，一分钟做一次Checkpoint。而RocksDB每次做Checkpoint时都需要把数据从内存flash到磁盘上面，Checkpoint做的很频繁时会产生非常多的小std文件，RocksDB需要花大量时间和资源去做Compaction，把小文件和并成大文件。State本身已经比较大，假如flash不断做Compaction，磁盘I/O会成为瓶颈，最后导致产生反压上游。另一个问题是使用RocksDBStateBackend会有生成较多的MemTable。如果内存没有配置好，会导致out of memory，需要重新计算内存，调配MemTable，Parallelism和K8S point的内存。调优之后任务跑的较为稳定，这时需要把本地磁盘换成高性能的SSD，保证内存足够大。此外，每次做Checkpoint会产生性能损失。小红书选择将Checkpoint频率改成十分钟，同样可以满足生产需求，而且回填10分中的数据只需要一到两分钟。还需要注意调大RocksDB Compaction Threshold，避免频繁做小文件的Compaction。
Backfill：回填是生产中常见的场景。实际生产中如果开发者写错代码导致数据错误，则需要删除错误数据，重新跑正确代码回填正确的数据。另外，如果原本只有点赞功能，会产生有一个新的回填场景，分析用户点赞是否为有效点赞或者对其做简单的逻辑恢复。Backfill非常依赖Flink对Hive的支持，小红书一直以来的数据都存放在Hive上，所以非常期待Flink 1.9版本性能的提高，尤其对Hive的支持的提升和对批的支持的加强。
三、Red Flink实时流计算平台
1.小红书实时流计算平台及周边生态
小红书推荐系统是一个流计算的平台，同时涉及周边的生态。如下图所示，最右边是数据接入的模块，支持从客户端接入数据，同时后端的服务提供LogSDK的模块帮助业务直接接入实时计算的平台。红颜色模块是流计算平台中正在开发的模块。比如，Canal通过事务的数据库直接将订单流对接到数据平台，系统自动分析数据Schema，一旦Schema发生变化，自动重启Flink任务。左下角是基于Flink 1.8做的开发，主要增加了Latency监控，便于分析Flink堵塞的Operator，同时将Latency监控直接导出到系统中。小红书基于Flink的SQL也做了开发，实现了不同的connector。
2. 小红书Flink系统
如下图，业务方使用小红书Flink实时流计算平台时，可以选择数据目的地。比如aws-hive和rex-clickhouse表明数据需要放到Hive和ClickHouse中。然后在Schema中输入JSON或PB格式数据，平台可以自动识别Schema，同时将数据Schema转成Flink SQL ETL的命令，自动更新Flink ETL Job的任务。此外，系统会对任务进行监控，监控任务的延迟时间，有无数据丢失，如果延迟过高或有数据丢失则产生报警。
3. 平台小红书推荐预测模型的演近
2018年12月，小红书的推荐预测模型只是非常简单的Spark上的GBDT模型。后期在GBDT模型上加了LR层，后来还引入了Deep和Wide。到2019年7月，小红书推荐预测模型已经演化到了GBDT + Sparse D&W的模型。小红书主要有9个预测任务，包括click、hide、like、fav、comment、share以及follow等。其中，Click是小红书最大的模型，一天大概产生5亿的样本进行模型训练，数据量达到1T/天。
目前小红书的Red ML模型基于KubeFlow，在小红书开始做ML模型时，KubeFlow在开的社区中比较受欢迎，而且TFJob可以支持TensorFlow的分布式训练。
