推荐系统学习笔记——五、推荐系统通用技术架构

五、推荐系统通用技术架构

一个大量借鉴Netflix架构的推进系统架构。其 数据流图 如下：

数据源

系统的数据源，主要有 三个：

• 前端的打点日志，以Kafka流形式的数据
• 物品内容数据：存储在MySQL中的业务的物品本身的内容数据，如id、标签、图片等等
• 来自web系统的用户画像数据，存在Hbase，包含两类：
  • 用户自身的人口属性的数据，性别、年龄、职业
  • 根据用户历史行为，算出用户偏好的数据

前端的打点日志进入kafka流之后，有两个分发：

• 一个进入近线计算层，主要是Spark Streaming（近线层）
  • 接收的有3个输入：
    • 打点日志
    • HIVE中的离线历史数据
    • 离线训练好的预估模型。
  • 可以在近线层完成他们的耦合和计算，在秒的级别实现了海量数据、机器学习模型以及实时性的组合 。
  • 计算结果有3个：
    • 用户或者物品的特征向量
    • 给用户更新的排序列表
    • 召回索引
• 一个进入Hadoop的HDFS，进行存储（离线层）。一般是15分钟一个切片。这个存储位与Hive的表，可以直接用表模型进行访问
  • 离线层大量的计算都是围绕Spark Batch来展开的。Spark非常的灵活，几乎可以输入任何来源的数据，比如：上图中，可以读取HDFS的数据，也可以读取Hive的数据，也可以扫描MySQL的数据，也可以扫描Hbase的数据，把他们整合起来。
  • Spark Batch的输出：
    • Spark Mllib离线训练机器学习的预估模型，输出Spark Mllib的模型
    • SparkBatch可以对特征进行处理，导出本地或者HDFS文件，用于tensorflow的模型训练，结果是CTR预估模型

tensorflow的模型和Spark Mllib模型区别：

• tensorflow支持深度学习模型，并且能够直接用于在线模型服务
• Spark Mllib，和spark Batch完美配合的，能够很容易的结合Spark Batch的处理的代码和Spark 机器学习训练的代码，使用起来比较方便。

有一个问题：Spark的编程范式是一种Batch的形式，非常不适合于在线模型服务需要的几毫秒、几十毫秒的场景。

• Spark Mllib的模型的应用：
  • 一是重新应用于Spark Batch，离线计算用户的推荐列表（特征向量、排序列表、召回索引、热度榜单）
  • 一是用于Spark Streaming，用于近线层模型预估的服务

存储层：

主要存储高速缓存。

• redis
  • 性能更高，查询更快，一般几毫秒、数十毫秒就可以返回
  • 存储的数据比较小
  • 选择存储的数据：item的数据。item的内容数据，i2i推荐结果，item特征向量，都是item粒度，数据量不是那么大。
• Cassandra
  • 稍微慢一点儿，七八十毫秒
  • 可以存储大量的数据
  • 选择存储的数据：存储用户的数据。u2i的推荐结果，user特征向量。一个产品，用户量很大 ，可以存储到Cassandra

在线模型服务

tensorflow 官方提供一个serving框架，提供在线高速的模型服务

在线服务，spring boot

• 做了推荐服务的几个环节，包括召回、排序、过滤、打散、分页、内容合并等等
• 输入是：读取redis，读取Cassandra，也可能调用serving进行在线排序。
• 除了考虑推荐系统的功能，还有许多工程的事情需要考虑
  • 本地LRU缓存：为了提高访问的性能，会使用本地的LRU缓存。用户的推荐列表会先在本地缓存，但是本地空间有限，队列慢的话，就会把最近最常访问的那个移除掉
  • AB测试分桶：非常重要的组件，调用外部的AB测试平台
  • 兜底补足（超时截断）：访问web数据或者调用在线服务的时候，很可能种种原因导致不能及时返回。这时候为了保证用户体验，就应该先断开请求，直接使用本地缓存的热榜之类的直接返回给前端，而不是让用户一直等待

产品客户端

• Android、IOS、TV、PC
• 用户在客户端做出操作之后，产生两个行为日志：
  • 一个达到前端的打点日志的kafka流，和前面对接起来
  • 进入画像系统，更新用户偏好的兴趣向量