简介： 本篇内容主要分三个部分，在第一部分讲一下实时计算在推荐业务中的使用场景。第二部分讲一下小红书是怎么使用Flink的一些新的功能。第三部分主要是讲一些OLAP的实时分析的场景，以及和阿里云MC-Hologres的合作。

作者：小红书推荐工程负责人 郭一

小红书推荐业务架构

首先这个图上画了一些比较典型的推荐业务，使用大数据的主要模块，其中最左边是线上推荐引擎，一般推荐引擎会分成召回、排序、后排等几步，在这里就不细说了。主要是从大数据的角度来说，推荐引擎主要是运用预测模型来预估用户对每个候选笔记的喜欢程度。根据一定的策略来决定给用户推荐哪些笔记。推荐模型在运用时需要抓取笔记特征，这些特征又会回流到我们的训练数据中，来训练新的模型。推荐引擎返回笔记之后，用户对笔记的消费行为，包括展示、点击、点赞等行为，会形成用户的行为流。这些用户行为流结合了特征流，从而产生了模型训练的数据来迭代模型。结合用户和笔记的信息之后，就会产生用户和笔记画像和推荐业务所用到的一些分析报表。
经过一年多的改造，小红书在推荐场景中，除了从分析数据到策略这一块，需要人为参与迭代策略之外，其他的模块的更新基本上是做到了实时或近实时的进行。

推荐业务的实时计算应用

这里稍微展开讲一下特征和用户行为的数据回流之后的实时计算，以及我们怎么使用他们产生的数据。在推荐引擎产生特征流的时候，特征流因为量特别大，包括了所有推荐返回的笔记，大概有近百篇，以及这些笔记的所有特征，所以这些特征总共大概有大几百个。目前我们的做法是把特征写到一个我们自研的高效的kv中缓存几个小时，然后用户行为数据是从客户端打点回流，然后我们就开始了数据流的处理。
我们第一步是把客户端打点的用户行为进行归因和汇总。这里讲一下什么是归因和汇总。因为在小红书的APP上面，客户端的打点是分页面的，比如说用户在首页推荐中看了笔记并进行了点击，点击之后用户就会跳转到笔记页，然后用户在笔记页上浏览这篇笔记并进行点赞。同时用户可能会点击作者的头像进入作者的个人页，并在个人页中关注了作者。归因是指把这一系列的用户行为都要算作首页推荐产生的行为，而不会和其他的业务混起来。因为搜索用户，在搜索中看到同样一篇笔记，也可能返回同样的结果。所以我们要区分用户的行为到底是由哪一个业务所产生的，这个是归因。

然后汇总指的是用户的这一系列行为，关于同一篇笔记，我们会产生一条汇总的记录，汇总的记录可以便于后续的分析。然后归因之后，会有一个实时的单条用户行为的数据流。而汇总这边，因为有一个窗口期，所以汇总的数据一般会延迟目前大概是20分钟左右。当我们产生归因和汇总的数据流之后，我们就会补充上一些维表的数据，我们会根据用户笔记来找当时我们推荐产生的特征，同时我们也会把一些用户的基础信息和笔记的基础信息加到数据流上。这里面其实主要有4个比较重要的用户场景，第一个场景是产生分业务的Breakdown的信息，这个主要是能知道某一个用户在不同的笔记维度，他的点击率和一些其他的业务指标，同时我也可以知道某一篇笔记针对不同的用户，它产生的点击率，这个是我们在实时推荐当中一个比较重要的特征。另外一个很重要的是我们实时分析的一个宽表，宽表是我们把用户的信息、笔记信息和用户笔记交互的汇总信息，都变成了一个多维度的表，进行实时分析，这个后面会更加详细的和大家讲述。然后还有两个比较重要的，一个是实时训练的信息，训练的信息就是我把用户和笔记交互的信息扩充了，当时排序的时候抓起的特征，这特征加上一些我们汇总出来的标签，就给模型进行训练来更新模型。然后另外一个就是我所有的汇总信息都会进入离线数据数仓，然后会进行后续的一些分析和报表的处理。

流计算优化—Flink批流一体

然后我这里讲一下我们怎么运用Flink的一些新功能来优化流计算的过程。这里面我主要讲两点，其中第一点就是批流一体化。
刚才说了我们把一个用户的行为根据笔记的行为汇总之后进行分析，这里的汇总的信息其实很多的，汇总信息当中，除了最简单的，比如说用户有没有点赞收藏这篇笔记，其实还有一些比较复杂的标签，比如说用户在笔记页上停留了多长时间，或者是说这篇笔记之前的点击是不是一个有效点击，我们对于某些广告场景或者有些场景下面，我们需要知道如果用户点击之后停留了比如说超过5秒，那么这个点击是有效的。那么像这种复杂的逻辑，我们希望在我们的系统当中只被实现一次，就可以同时运用在实时和批的计算当中。那么在传统意义上这点是很难的，因为大多数的实现中，批和流是两个版本，就是我们在Flink上面，比如说实现了一个版本的有效点击的定义，我们同时也会需要实现一个离线版本的有效点击的定义，这个可能是一个SQL写的版本。那么小红书是运用了FLIP-27里面的一个新的功能，日志文件是一个批的形式，它可以转换成一个流的形式，这样的话我就可以做到代码意义上的批流统一。

流计算优化—Multi-sink Optimization

那么还有一个Flink的功能就是一个在Flink 1.11上的Multi-sink Optimization。它的意思是我一份数据会写到多个数据应用上去，比如我会同时需要做张用户行为的宽表，同时也生成一份离线的数据。那么Multi-sink Optimization做的是，你只需要从Kafka里面读一次，如果是同一个key的话，他只需要去Lookup一次kv就可以产生多份数据，同时写到多个sink，这样可以大大减少我们对Kafka的压力和对 kv查询的压力。

小红书OLAP典型场景

最后我讲一下我们的OLAP场景和阿里云MaxCompute、Hologres的一个合作。小红书在推荐业务下面有很多OLAP场景，这里我讲4个比较常见的场景应用，最常见的其实就是根据用户的实验组分组进行比较的一个实时分析。因为我们在推荐业务上面需要大量的调整策略或者是更新模型，然后每次调整策略和更新模型我们都会开一个实验，把用户放到不同的ABtest里面来比较用户的行为。那么一个用户其实在推荐当中会同时处于多个实验，在每一个实验里面是属于一个实验组，我们按实验分组做的实验分析，主要就是把一个实验拿出来，然后把用户的行为和汇总数据，根据这个实验当中的实验组进行分维度的分析，看看不同的实验组它的用户指标有什么差别。然后这个场景是一个非常常见的场景，但是也是计算量非常大的场景，因为它需要根据用户的实验tag进行分组。
然后另外一个场景就是我们小红书的推荐其实是跑在了多个数据中心上面，不同的数据中心经常有一些变动，比如说是运维的变动，我们要起一个新的服务，或者是我们可能有些新的模型需要在某个计算中心先上线，那么我们需要一个端到端的方案去验证不同的数据中心之间的数据是不是一致，用户在不同数据中心的体验是不是一样。这个时候就需要我们根据不同的数据中心进行比较，比较用户在不同的数据中心当中产生的行为，他们最终的指标是不是一致，同样我们也用到了我们的模型和代码的发布当中。我们会看一个模型发布或者一份代码发布的老版本和新版本，他们产生的用户的行为的指标对比，看他们是不是一致。同样我们的OLAP还用在了实时业务指标的告警，如果用户的点击率和用户的点赞数突然有一个大幅的下降，也会触发我们的实时的告警。

小红书OLAP数据的规模

在高峰时候我们大概每秒钟有35万条用户行为被记入我们的实时计算当中。然后我们大宽表大概有300个字段，然后我们希望能够保持两周多大概15天左右的数据，因为我们在做实验分析的时候，经常需要看本周和上一周的数据的对比，然后我们大概每天有近千次的查询。

小红书+Hologres

我们在7月和阿里云的MaxComputer和Hologres进行了一个合作。Hologres其实是新一代的智能数仓的解决方案，它能够把实时和离线的计算都通过一站式的方法来解决。同时它的应用主要可以用在实时大屏、Tableau和数据科学当中，我们研究下来是比较适合我们的推荐场景的。

小红书Hologres应用场景

Hologres做的事情主要是对离线的数据进行了查询和加速，然后对离线的数据做表级别的交互查询响应，他就无须再做从离线把数据搬到实时数仓的这么一个工作，因为它都在里面了。整个实时数仓，它是通过搭建用户洞察体系，实时监控平台的用户数据，可以从不同的角度对用户进行实时诊断，这样可以帮助实施精细化的运营。这个其实对于我们用户大宽表来说也是一个非常适合的场景。然后它的实时离线的联邦计算可以基于实时计算引擎和离线数仓MaxCompute交互分析，实时离线联邦查询，构筑全链路精细化运营。

Hologres VS  Clickhouse

在和阿里云MaxCompute合作之前，我们是自建了Clickhouse的集群，当时我们也是一个很大规模的集群，一共用了1320个core，因为Clickhouse它不是一个计算存储分离的方案，所以当时我们为了节约成本，只存放了7天的数据，然后因为Clickhouse对于用户实验tag这个场景其实没有很好的优化，所以说我们当时查询超过三天的数据就会特别慢。因为是个OLAP场景，我们希望每次用户的查询能在两分钟之内出结果，所以是限制了我们只能查过去三天的数据。同时另外还有一个问题就是Clickhouse对于组件的支持是有些问题的，所以我们没有在Clickhouse集群上面配置组件，如果上游的数据流有些抖动，数据造成一些重复的情况下，下游的Clickhouse里面其实会有一些重复的数据。同时我们也是派了专人去运维Clickhouse，然后我们通过调研发现，Clickhouse如果你要做成集群版的话，它的运维成本还是很高的。所以我们在7月份的时候和阿里云合作，把我们推荐的一个最大的用户宽表迁移到了MaxCompute和Hologres上面，然后我们在Hologres上面一共是1200个core，因为它是计算存储的方案，所以1200个core就足够我们使用了。但是我们在存储的方面是有更大的需求的，我们一共存了15天的数据，然后因为Hologres对于用户根据实验分组这个场景是做了一些比较定制化的优化，所以说我们现在可以轻松地查询7天到15天的数据，在这个根据实验组分组的场景下面，其查询的性能与Clickhouse相比是有大幅提升的。Hologres它其实也支持Primary Key，所以我们也是配置了Primary Key，我们在这个场景下面是用了insert or ignore这个方法，然后因为配置了Primary Key，它就天然具有去重的功能，这样的话我们上游只要保证at least once，下游的数据就不会有重复。 然后因为我们是放在阿里云上面，所以说是没有任何的运维的成本。

 

原文链接
本文为阿里云原创内容，未经允许不得转载。