做网站必须要购买空间吗,淘宝做轮播广告哪个网站好,旅游网页设计免费模板,灵雀云 wordpress简介#xff1a; 本篇内容主要分三个部分#xff0c;在第一部分讲一下实时计算在推荐业务中的使用场景。第二部分讲一下小红书是怎么使用Flink的一些新的功能。第三部分主要是讲一些OLAP的实时分析的场景#xff0c;以及和阿里云MC-Hologres的合作。
作者#xff1a;小红书…简介 本篇内容主要分三个部分在第一部分讲一下实时计算在推荐业务中的使用场景。第二部分讲一下小红书是怎么使用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下游的数据就不会有重复。 然后因为我们是放在阿里云上面所以说是没有任何的运维的成本。 原文链接 本文为阿里云原创内容未经允许不得转载。
