简介： 本篇内容主要分三个部分，在第一部分讲一下实时计算在推荐业务中的使用场景。第二部分讲一下小红书是怎么使用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还用在了实时业务指标的告警，若是用户的点击率和用户的点赞数忽然有一个大幅的降低，也会触发咱们的实时的告警。
spa
小红书OLAP数据的规模
在高峰时候咱们大概每秒钟有35万条用户行为被记入咱们的实时计算当中。而后咱们大宽表大概有300个字段，而后咱们但愿可以保持两周多大概15天左右的数据，由于咱们在作实验分析的时候，常常须要看本周和上一周的数据的对比，而后咱们大概天天有近千次的查询。3d
小红书+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，下游的数据就不会有重复。 而后由于咱们是放在阿里云上面，因此说是没有任何的运维的成本。
原文连接 本文为阿里云原创内容，未经容许不得转载。