Redis解决推荐系统特征的存储问题

推荐系统存储模块的设计原则

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实践

• 安装Redis：

  • Linux安装请参考此链接
  • Windows安装请参考此链接

• 运行离线程序，通过Jedis客户端写入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中了：