文章目录
推荐系统存储模块的设计原则
Netflix推荐系统存储介绍
- 以Netflix为例，Netflix推荐系统架构图如下所示，Netflix 采用了非常经典的 Offline、Nearline、Online 三层推荐系统架构。红色标注的地方就是最核心的数据库部分，分别使用了Cassandra、MySQL、EVcache，这三个数据库就是Netflix解决特征和模型参数存储问题的钥匙。
- 为什么Netflix架构要使用三个数据库呢？
- 因为对于推荐服务器来说，由于线上的QPS压力巨大，每次有推荐请求到来，推荐服务器都需要把相关的特征取出。这就要求推荐服务器一定要快。而且对于成熟的互联网应用来说，它的用户数和物品数一定是巨大的，对于存储模块来说，这么多用户和物品特征所需的存储量会特别大。这样既要存储量大，又要查询快，还要面对高QPS的压力。所以没有一个独立的数据库能单独完成这样复杂的任务。
- 对于推荐服务器来说，我们就需要把特征的存储做成分级存储，把越频繁访问的数据放到越快的数据库甚至缓存中，把海量的全量数据放到便宜但是查询速度较慢的数据库中。
Netflix分级存储核心思想
- Netflix分级存储设计图：
- Netflix使用的Cassandra是当今流行的NoSQL数据库，具备大数据存储的能力。为了支持推荐服务器高 QPS 的需求，还需要把最常用的特征和模型参数存入EVcache这类内存数据库。而对于更常用的数据，我们可以把它们存储在 Guava Cache 等服务器内部缓存，甚至是服务器的内存中。
- 对于 MySQL 来说，由于它是一个强一致性的关系型数据库，一般存储的是比较关键的要求强一致性的信息，比如物品是否可以被推荐这种控制类的信息，物品分类的层级关系，用户的注册信息等等。这类信息一般是由推荐服务器进行阶段性的拉取，或者利用分级缓存进行阶段性的更新，避免因为过于频繁的访问压垮MySQL。
总结
- 推荐系统存储模块的设计原则就是分级存储，把越频繁访问的数据放到越快的数据库甚至缓存中，把海量的全量数据放到廉价但是查询速度较慢的数据库中。
Sparrow Recsys存储实践
基于Sparrow Recsys的存储系统方案
- 我们使用基础的文件系统保存全量的离线特征和模型数据，用 Redis 保存线上所需特征和模型数据，使用服务器内存缓存频繁访问的特征。
- Sparrow Recsys特征就具体含义和数据量级表格：
- 首先，用户特征的总数比较大，很难全部载入到服务器内存中，所以把用户特征载入到Redis之类的内存数据库中。
- 其次，物品特征的总数比较小，每次用户请求，一般只用到一个用户的特征，但为了物品排序，推荐服务器需要访问几乎所有候选物品的特征。完全可以把所有物品特征阶段性地载入到服务器内存中，大大减少Redis的线上压力。
- 最后，我们还要找一个地方去存储特征历史数据、样本数据等体量比较大，但不要求实时获取的数据。这个时候分布式文件系统（单机环境本机文件系统）往往是最好的选择，由于类似 HDFS 之类的分布式文件系统具有近乎无限的存储空间，我们可以把每次处理的全量特征，每次训练的Embedding全部保存到分布式文件系统中，方便离线评估时使用。
- 具体的存储方案如下表：
| 存储系统类型 | 存储特征 |
|---|---|
| 分布式文件系统 | 历次处理得出的全量特征 |
| 内存数据库Redis | 当前版本的所有用户物品特征 |
| 服务器内存 | 物品特征阶段性全量载入，用户特征根据请求中用户ID实时请求Redis |
Redis基础知识
-
Redis 是当今业界最主流的内存数据库，它有两个主要特点。
- 一是所有的数据都以KV形式存储。 其中，Key只能是字符串，Value可支持的数据结构包括string(字符串)、list(链表)、set(集合)、zset(有序集合) 和hash(哈希)。这个特点决定了Redis的使用方式，无论是存储还是获取，都应该以键值对的形式进行。
- 二是所有的数据都存储在内存中，磁盘只在持久化备份或恢复数据时起作用。这个特点决定了 Redis 的特性，一是QPS峰值可以很高，二是数据易丢失，所以我们在维护Redis时要充分考虑数据的备份问题，同样不应该把关键的业务数据唯一地放到Redis中。但对于可恢复，不关乎关键业务逻辑的推荐特征数据，就可以使用Redis。
-
在实际的Sparrow Recsys项目中，我们只用到了 Redis 最基本的操作，如set、get和keys，value的数据类型用到了string。
Sparrow Recsys 中的Redis实践
if (saveToRedis) {
//创建redis client
val redisClient = new Jedis(redisEndpoint, redisPort)
val params = SetParams.setParams()
//设置ttl为24小时
params.ex(60 * 60 * 24)
//遍历存储embedding向量
for (movieId <- model.getVectors.keys) {
//key的形式为前缀+movieId，例如i2vEmb:361
//value的形式是由Embedding向量生成的字符串，例如 "0.1693846 0.2964318 -0.13044095 0.37574086 0.55175656 0.03217995 1.327348 -0.81346786 0.45146862 0.49406642"
redisClient.set(redisKeyPrefix + ":" + movieId, model.getVectors(movieId).mkString(" "), params)
}
//关闭客户端连接
redisClient.close()
}
- 在推荐服务器中把Redis数据读取出来
//创建redis client
Jedis redisClient = new Jedis(REDIS_END_POINT, REDIS_PORT);
//查询出所有以embKey为前缀的数据
Set<String> movieEmbKeys = redisClient.keys(embKey + "*");
int validEmbCount = 0;
//遍历查出的key
for (String movieEmbKey : movieEmbKeys){
String movieId = movieEmbKey.split(":")[1];
Movie m = getMovieById(Integer.parseInt(movieId));
if (null == m) {
continue;
}
//用redisClient的get方法查询出key对应的value，再set到内存中的movie结构中
m.setEmb(parseEmbStr(redisClient.get(movieEmbKey)));
validEmbCount++;
}
redisClient.close();
- 完成之后运行Embedding程序，注意：Embedding 生成并且插入 Redis把saveToRedis变量改为true；然后运行Online部分的RecSysServer，看一下推荐服务器有没有正确地从Redis中读出物品和用户 Embedding 并产生正确的推荐结果
- 之后登录redis就可以看到用户物品向量就传到Redis中了：
