Apache Spark 是解决此类问题的绝佳解决方案。

但是，首先让我们明确一下实时处理的定义。这是必须保证在指定时间内响应的处理类型，这在交互式业务站点上实际上非常低。您可以在此答案中阅读有关这些规范的信息。

Spark 在 0.1 秒以下的预测中并没有提供如此奢侈的预测，我在引用

摘自我 1993 年出版的《可用性工程》一书中的第 5 章：

• 0.1 秒大约是让用户感觉到系统在瞬间做出反应的极限，这意味着除了显示结果之外不需要特殊的反馈。

拥有一个您希望在其上显示预测的交互式商业网站并不意味着您的预测必须是实时的。

所以显而易见的是，实际上，以下内容：

问： 现在我已经为我的用户计算了推荐，我应该怎么做？

答：让我们为我们的系统定义一个服务层，以便在需要推荐时进行查询。

它可以足够快地接听您的电话，例如 Elasticsearch、Solr、HBase、Redis。什么口味都适合你。

另一方面，好吧

问： 我不希望我的系统是静态的，我需要每隔 T 小时/天/等重新计算我的预测

A： Spark 可以在这里完美地完成预定的工作。（一个简单的 cron 就可以了）

问： 但是我什么时候重新训练我的推荐系统？

A：我想说这实际上取决于很多东西，在这里讨论有点过于宽泛。如果您愿意，可以在此处阅读有关该主题的信息。

好的，所以我们现在定义了我们的批处理层。

问： 那么通过 Kafka、Rabbit 等实时传输的数据呢？

答：这实际上是它可能变得更加复杂的时候，因为您将用于计算距离、近似值和新推荐的方法取决于您正在构建的推荐系统类型以及您使用的技术。

Spark 流非常适合在基于“窗口”的微批处理上应用“简单”计算。这可以是我们的速度层。

总而言之，以上所有内容都定义了所谓的lambda 架构。遵循这种设计的最佳框架之一是Oryx（个人意见）。挺有意思的，你应该看看。

我还相信，在没有速度层的情况下，很有可能为推荐系统设置 RT 。

我希望这能回答你的问题。

对于内存计算，从 Python 或 R 以及它们的机器学习库之一开始不是更简单吗？如果数据不适合 RAM，则可以仅加载其中的一部分（例如，通过以随机概率 p 加载每个向量，仅加载 p 部分向量）。一旦您分析了您的数据，并了解了哪些方法最有效，您就可以扩展您的系统并在其中一种分布式计算工具中重写您的代码（或者您可能发现您根本不需要它）。

最好的解决方案不是计算余弦相似度（为了推荐一个项目），而是转换 您的 特征，以便您可以使用近似相似度搜索，其中存在许多快速选项。换句话说，预先计算以加快查询速度。（这意味着您将为您的用户和项目找到一个共同嵌入。）