共计 4399 个字符，预计需要花费 11 分钟才能阅读完成。
简介： 本篇内容次要分三个局部，在第一局部讲一下实时计算在举荐业务中的应用场景。第二局部讲一下小红书是怎么应用 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，上游的数据就不会有反复。而后因为咱们是放在阿里云下面，所以说是没有任何的运维的老本。
原文链接
本文为阿里云原创内容，未经容许不得转载。
