小红书推荐大数据在阿里云上的实践

本文涉及的产品
大数据开发治理平台 DataWorks,不限时长
简介: 本篇内容主要分三个部分,在第一部分讲一下实时计算在推荐业务中的使用场景。第二部分讲一下小红书是怎么使用Flink的一些新的功能。第三部分主要是讲一些OLAP的实时分析的场景,以及和阿里云MC-Hologres的合作。

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

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

小红书推荐业务架构

1.png

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

推荐业务的实时计算应用

2.png

这里稍微展开讲一下特征和用户行为的数据回流之后的实时计算,以及我们怎么使用他们产生的数据。在推荐引擎产生特征流的时候,特征流因为量特别大,包括了所有推荐返回的笔记,大概有近百篇,以及这些笔记的所有特征,所以这些特征总共大概有大几百个。目前我们的做法是把特征写到一个我们自研的高效的kv中缓存几个小时,然后用户行为数据是从客户端打点回流,然后我们就开始了数据流的处理。

我们第一步是把客户端打点的用户行为进行归因和汇总。这里讲一下什么是归因和汇总。因为在小红书的APP上面,客户端的打点是分页面的,比如说用户在首页推荐中看了笔记并进行了点击,点击之后用户就会跳转到笔记页,然后用户在笔记页上浏览这篇笔记并进行点赞。同时用户可能会点击作者的头像进入作者的个人页,并在个人页中关注了作者。归因是指把这一系列的用户行为都要算作首页推荐产生的行为,而不会和其他的业务混起来。因为搜索用户,在搜索中看到同样一篇笔记,也可能返回同样的结果。所以我们要区分用户的行为到底是由哪一个业务所产生的,这个是归因。

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

流计算优化—Flink批流一体

3.png

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

流计算优化—Multi-sink Optimization

4.png

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

5.png

最后我讲一下我们的OLAP场景和阿里云MaxCompute、Hologres的一个合作。小红书在推荐业务下面有很多OLAP场景,这里我讲4个比较常见的场景应用,最常见的其实就是根据用户的实验组分组进行比较的一个实时分析。因为我们在推荐业务上面需要大量的调整策略或者是更新模型,然后每次调整策略和更新模型我们都会开一个实验,把用户放到不同的ABtest里面来比较用户的行为。那么一个用户其实在推荐当中会同时处于多个实验,在每一个实验里面是属于一个实验组,我们按实验分组做的实验分析,主要就是把一个实验拿出来,然后把用户的行为和汇总数据,根据这个实验当中的实验组进行分维度的分析,看看不同的实验组它的用户指标有什么差别。然后这个场景是一个非常常见的场景,但是也是计算量非常大的场景,因为它需要根据用户的实验tag进行分组。

然后另外一个场景就是我们小红书的推荐其实是跑在了多个数据中心上面,不同的数据中心经常有一些变动,比如说是运维的变动,我们要起一个新的服务,或者是我们可能有些新的模型需要在某个计算中心先上线,那么我们需要一个端到端的方案去验证不同的数据中心之间的数据是不是一致,用户在不同数据中心的体验是不是一样。这个时候就需要我们根据不同的数据中心进行比较,比较用户在不同的数据中心当中产生的行为,他们最终的指标是不是一致,同样我们也用到了我们的模型和代码的发布当中。我们会看一个模型发布或者一份代码发布的老版本和新版本,他们产生的用户的行为的指标对比,看他们是不是一致。同样我们的OLAP还用在了实时业务指标的告警,如果用户的点击率和用户的点赞数突然有一个大幅的下降,也会触发我们的实时的告警。

6.png

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

小红书+Hologres

7.png

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

8.png

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

9.png

在和阿里云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,下游的数据就不会有重复。 然后因为我们是放在阿里云上面,所以说是没有任何的运维的成本。
谢谢大家!

更多大数据客户实战案例:https://developer.aliyun.com/article/772449

首月199元开通DataWorks专业版+MaxCompute按量付费黄金搭档:

https://dw-common-buy.data.aliyun.com/promc

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
4天前
|
弹性计算 安全 关系型数据库
阿里云产品在技术探索中的实践和思考
本文讲述了作者在使用阿里云产品进行技术探索的实践中,如何借助ECS、RDS、OSS、SLB和VPC构建高可用分布式系统。从最初的虚拟主机服务到全面的云服务,阿里云帮助解决了性能、负载均衡、数据存储和网络安全等问题。在面对性能优化、成本控制和安全管理的挑战时,作者通过监控、调整和采用安全措施确保了系统的高效运行。未来,作者将继续在云计算领域探索,利用AI、大数据及物联网技术驱动业务创新和增长。
30 0
|
1天前
|
存储 分布式计算 DataWorks
【阿里云云原生专栏】云原生下的数据湖建设:阿里云MaxCompute与DataWorks解决方案
【5月更文挑战第26天】在数字化时代,数据成为企业创新的关键。阿里云MaxCompute和DataWorks提供了一种构建高效、可扩展数据湖的解决方案。数据湖允许存储和分析大量多格式数据,具备高灵活性和扩展性。MaxCompute是PB级数据仓库服务,擅长结构化数据处理;DataWorks则是一站式大数据协同平台,支持数据集成、ETL和治理。通过DataWorks收集数据,MaxCompute存储和处理,企业可以实现高效的数据分析和挖掘,从而提升业务洞察和竞争力。
10 0
|
2天前
|
存储 Prometheus 运维
【阿里云云原生专栏】云原生下的可观测性:阿里云 ARMS 与 Prometheus 集成实践
【5月更文挑战第25天】阿里云ARMS与Prometheus集成,为云原生环境的可观测性提供强大解决方案。通过集成,二者能提供全面精准的应用监控,统一管理及高效告警,助力运维人员及时应对异常。集成示例代码展示配置方式,但需注意数据准确性、监控规划等问题。这种集成将在云原生时代发挥关键作用,不断进化以优化用户体验,推动业务稳定发展。
13 0
|
4天前
|
存储 弹性计算 大数据
【阿里云弹性计算】阿里云ECS在大数据处理中的应用:高效存储与计算实践
【5月更文挑战第23天】阿里云ECS在大数据处理中发挥关键作用,提供多样化实例规格适应不同需求,尤其大数据型实例适合离线计算。通过集成分布式文件系统如OSS,实现大规模存储,而本地存储优化提升I/O性能。弹性扩容和计算优化实例确保高效运行,案例显示使用ECS能提升处理速度并降低成本。结合阿里云服务,ECS构建起强大的数据处理生态,推动企业创新和数字化转型。
16 0
|
5天前
|
SQL 关系型数据库 数据库
阿里云数据库 RDS SQL Server版实战【性能优化实践、优点探析】
本文探讨了Amazon RDS SQL Server版在云数据库中的优势,包括高可用性、可扩展性、管理便捷、安全性和成本效益。通过多可用区部署和自动备份,RDS确保数据安全和持久性,并支持自动扩展以适应流量波动。可视化管理界面简化了监控和操作,而数据加密和访问控制等功能保障了安全性。此外,弹性计费模式降低了运维成本。实战应用显示,RDS SQL Server版能有效助力企业在促销高峰期稳定系统并保障数据安全。阿里云的RDS SQL Server版还提供了弹性伸缩、自动备份恢复、安全性和高可用性功能,进一步优化性能和成本控制,并与AWS生态系统无缝集成,支持多种开发语言和框架。
29 2
|
6天前
|
安全 Cloud Native 数据安全/隐私保护
【阿里云云原生专栏】云原生安全挑战与对策:阿里云的安全防护实践
【5月更文挑战第22天】随着云原生技术推动企业数字化转型,安全挑战日益凸显:容器安全、微服务安全和数据安全成为关注点。阿里云通过容器安全沙箱、镜像安全扫描服务保障容器安全;使用API网关和RAM强化微服务安全;借助TDE和SSE保护数据安全。通过这些实践,用户可在享受云原生优势的同时确保业务安全。
123 0
|
6天前
|
弹性计算 关系型数据库 数据库
利用阿里云进行性能优化:实践案例分享
在开发在线教育平台过程中,我们遇到了由于用户访问量增加而导致的性能瓶颈问题。通过使用阿里云的多种服务,包括RDS数据库、ECS弹性扩展、SLB负载均衡、OSS存储和CDN加速,我们对数据库、应用服务器和静态资源加载进行了全面优化。优化后的系统性能显著提升,数据库查询速度提高了60%,服务器负载下降了40%,静态资源加载时间减少了70%,从而极大改善了用户体验。本文详细介绍了问题分析、具体解决方案及其实施效果,旨在为其他开发者提供有价值的参考。
82 3
|
6天前
|
存储 弹性计算 监控
利用阿里云云产品进行项目成本节约的实践
本文分享了利用阿里云降低成本的实践经验,主要通过选择合适的计费模式(如按量付费、包年包月和抢占式实例)、优化资源配置(弹性伸缩、资源监控与调整、适配存储方案)、利用优惠和成本管理工具(预留实例券、成本预警、优惠活动)以及案例分析,实现云计算成本的有效控制。通过这些策略,企业在保证灵活性和扩展性的同时,能更好地管理云服务成本,提高项目经济效益。
71 1
|
7天前
|
弹性计算 关系型数据库 MySQL
【阿里云弹性计算】从零搭建:基于阿里云ECS的高性能Web服务部署实践
【5月更文挑战第21天】本文介绍了如何使用阿里云ECS搭建高性能Web服务。首先,注册阿里云账号购买ECS实例,选择合适配置。接着,通过SSH连接实例,更新系统并安装Apache、PHP和MySQL。创建网站目录,上传代码,配置数据库和PHP。然后,启用Gzip压缩和KeepAlive,调整Apache并发连接数以优化性能。此教程为在阿里云上构建高效Web服务提供了基础指南。
111 5
|
7天前
|
Cloud Native 数据管理 关系型数据库
【阿里云云原生专栏】云原生数据管理:阿里云数据库服务的分布式实践
【5月更文挑战第21天】阿里云数据库服务在云原生时代展现优势,应对分布式数据管理挑战。PolarDB等服务保证高可用和弹性,通过多副本机制和分布式事务确保数据一致性和可靠性。示例代码展示了在阿里云数据库上进行分布式事务操作。此外,丰富的监控工具协助用户管理数据库性能,支持企业的数字化转型和业务增长。
177 1

热门文章

最新文章