1.预测函数上线
刚刚学习机器学习时候，我认为广告和推荐系统过程如下图所示：1）线下部分，从用户和广告（物品）属性抽取用户和物品特征，将抽取的特征合并进日志生成训练数据，训练机器学习模型；2）线上部分，来了一个请求，从用户和广告（物品）属性抽取请求中的用户和物品的特征，将这些特征合并请求生成预测实例，用线上模型得到预测结果。
但是这个架构有两个问题：1）从用户和广告（物品）属性抽取特征的程序有线上线下两套，这两套程序必须保持完全一致。但由于调参的原因，特征抽取是机器学习系统中最经常发生变化的模块。经常变化的模块需要保持一致，这很困难。那么我们能不能强行地用一套程序呢？比如，我们把特征抽取和特征处理模块写成 .so 文件。这样也有问题：线下要求快速变化以方便工程师调特征，可能会使用一些训练框架（比如 Spark）；线上要求程序快速实时，要求工程师编码严谨。写成严谨的 .so 文件，能够保证线上的需求，但无法快速变化，也不能在 Spark 上使用。2）线上特征抽取要求非常快速，特别在线上吞吐量很大的情况。但有些重度特征不可能在短时间内抽取出来，比如广告的历史点击率（生成这个特征需要遍历一段时间的点击日志）。
在读书期间，这两个问题困扰了我很久, 直到 2014 年我知道了神器 Redis。Redis 是一个开源内存数据库，支持集群模式、持久化和 Key-Value 数据结构。在使用时，我们可以将 Redis 看成一个巨大的哈希表。Redis 在后台开发中经常用作 cache 服务器, 后来被工程师们用于广告和推荐系统中的特征服务器。工程师将用户和广告（物品）的 ID 作为 Key，将用户和广告（物品）的特征作为 Value 存入 Redis，这样线上程序只需要用户和广告（物品）的 ID 就能知道特征。引入 Redis 之后，广告和推荐系统过程如下所示：1）线下部分，从用户和广告（物品）属性抽取用户和广告（物品）特征，把抽取的特征合并进日志生成训练数据用于训练机，并把抽取的特征上载到线上 Redis 服务器；2）线上部分，来了一个请求，从 Redis 服务器取出用户和广告（物品）特征，将特征合并进请求生成预测实例，用线上模型得到预测结果。
这种架构还有一个变种：在线下抽取特征之后不生成训练数据而是直接送到 Redis，在线上用 Storm 实时拼接训练数据。但我对这个变种的前因后果不太了解，就不展开讨论了。这种架构将预测函数（也就是训练出来的模型）部署在线上。为了和下面的架构区分开来，我们将这种架构称为预测函数上线架构。
2.预测结果上线
了解预测函数上线架构之后，我将之作为广告和推荐系统线上部署模型的 “正统”。 因此当 2014 年我接触到另一种架构时，我内心是拒绝的。这种架构的要点在于把预测结果上线，具体过程如下所示：1）在线上，从用户和广告（物品）属性抽取用户和物品特征，将抽取的特征合并进日志生成训练数据，训练机器学习模型；将几乎所有可能的请求合并特征，进而生成预测实例，用模型得到预测结果；2）
