写点什么

用 GaussDB(for Redis) 存画像,推荐业务轻松降本 60%

作者:科技怪咖
  • 2022 年 8 月 30 日
    海南
  • 本文字数:1899 字

    阅读完需:约 6 分钟

一、什么是推荐系统


不知道大家有没有过这样的经历,当你前脚刚在某电商网站买了一个手机,过两天再打开该电商网站,首页推荐显示的必定有耳机、手机壳、蓝牙音箱等手机配件。如果你买的不是手机,而是一件衣服,那么下次打开电商网站显示的,必定是和衣服搭配的裤子和鞋子等。


聪明的你不禁要问,为何电商网站如此强大,竟能提前预知你的偏好,并且给你推荐你可能喜欢的商品?其实在这背后,都离不开那强大的推荐系统。


什么是推荐系统?首先我们来看看维基百科上的定义:推荐系统是一种信息过滤系统,可以根据用户历史行为预测用户对物品的“评分”或“偏好”。 简单来说,如果你是一个电子发烧友,那么系统肯定会给你推荐各种新鲜出炉的 3C 产品,如果你是一个 coder,那么你的页面肯定充满各种编程大全的书籍。推荐系统近年来非常流行,应用于各行各业,推荐的对象包括:电影、音乐、新闻、书籍、学术论文、搜索查询、分众分类、电商购物和游戏业务等。


二、推荐系统的架构


了解了什么是推荐系统之后,接下来我们继续介绍下推荐系统的架构,以游戏行业为例,一个典型的游戏业务的推荐系统架构设计如下:



推荐系统主要由 3 部分组成,分别是:行为日志收集特征生产特征消费。\


01. 行为日志


大数据业务通过收集用户的行为日志,分析获得用户画像,并且将这些用户画像保存在分布式文件系统 HDFS 中。


02. 特征生产


工程业务负责为大数据业务提供一套接口调用,主要是“灌库”,即定时或按一定逻辑把 HDFS 中的用户画像加工成特征,灌入工程业务负责的“KV 存储”。


03. 特征消费


工程业务团队还负责将算法团队的推荐模型进行工程落地,他们开发线上推理组件,从 KV 存储中提取特征数据、分析计算,最终得出推荐结论,展示给用户。


三、推荐系统的存储痛点


上一节中我们介绍了游戏行业中推荐系统的架构,这也是推荐系统的一个典型架构。从架构图可以看出,KV 存储在整套链路中,承载着重要的承上启下作用。然而,推荐系统中的 KV 存储却存在着两个大的痛点,第一个是成本高,第二个是扩容慢。


01. 成本高


首先第一个是成本高的问题。通常我们搭建 KV 存储的首选是选择自建一个开源 Redis 集群作为 KV 存储系统。


一方面,开源 Redis 的数据全部放在内存中,众所周知内存的存储成本非常昂贵,只适用于存储少量数据,如果数据量大,存储成本将成为企业的负担;


另一方面,开源 Redis 在进行 AOF 文件重写的过程中存在 fork 机制,导致开源 Redis 在 AOF 文件重写时,其内存利用率只有 50%,这就进一步使增加了开源 Redis 的内存使用成本。


02. 扩容慢


除了成本比较高,开源 Redis 还存在扩容慢的问题,在自建的开源 Redis 集群中,随着业务增长,KV 存储的容量不得不进行扩容。但由于原生 Redis 本身的架构特点,在扩容过程中难免要发生 key 的跨 slot 迁移,如下图所示,跨 slot 迁移需要耗时很久并且业务受影响时间长。



四、为什么推荐 GaussDB(for Redis)


知道了推荐系统的痛点所在,该如何解决呢?究其根本是降本增效,而 GaussDB(for Redis)可以说是为解决这些问题而生。


01. 降本


GaussDB(for Redis)从两个方面降低 KV 数据的存储成本:**


**第一个方面,GaussDB(for Redis)的所有数据全部落在存储,相比开源 Redis 数据存放在内存中,其成本降低了 75%~90%,形成极大的价格优势。举个例子,一个 512GB 的开源 Redis 集群,其成本几乎要 5w/月,而相同规格的实例,如果替换成 GaussDB(for Redis),其成本节约 40%以上,几乎节省了一个人力成本在里面。下面这张表格是不同层级存储器之间的成本对比图。



另一方面,在推荐系统中,KV 数据主要存储的是用户画像的信息,这些信息基本上都是经过 Protobuf 序列化后的信息,而 GaussDB(for Redis)自带的数据压缩功能,可以对序列化后的信息进行高压缩比的压缩,实际占用空间仅为开源 Redis 的 50%左右,这又进一步降低了 KV 数据的存储成本。


02. 增效


除了降本,另一方面就是增效了。众所周知,开源 Redis 的架构中,如下图所示,其存储和计算是不分离的,这就导致节点进行扩容的时候,会发生分片的迁移,从而导致业务会受到影响。


\



GaussDB(for Redis)为了解决这个问题,采用了存算分离的架构,如下图所示:



在存算分离的架构下,底层数据可以被任意上层计算节点访问,扩容过程不发生数据拷贝搬迁,速度极快;同时还做到分钟级节点扩容,业务秒级感知;存储扩容业务 0 感知。无论是扩节点还是扩存储容量,对业务的影响几乎为 0。


五、总结


本文简单介绍了推荐系统是什么,并以游戏业务为例,阐明了推荐系统的架构和存在的存储痛点,同时 GaussDB(for Redis)是如何解决这些存储痛点的。在大数据时代,推荐系统的应用场景将会越来越多,作为推荐系统的数据存储,GaussDB(for Redis)完美弥补了开源 Redis 的短板,能够为推荐系统提供强有力的技术支撑。

用户头像

科技怪咖

关注

还未添加个人签名 2022.07.29 加入

还未添加个人简介

评论

发布
暂无评论
用GaussDB(for Redis)存画像,推荐业务轻松降本60%_科技怪咖_InfoQ写作社区