架构：数据持久性、搜索和推荐系统

Question

我正在计划一个涉及数据持久性、搜索功能和推荐功能（协作过滤）的项目。

如图所示，我在想：

1) 拥有一组微服务来处理将持久保存在 NoSQL 存储中的实体（可能是 MongoDb）

2) 对于搜索功能，我将使用 Slor，来自微服务的消息将用于更新 Slor 索引。

3) 对于建议，我正在考虑使用 Apache Mahout 并使用消息队列来更新 Mahout 中使用的 Slor 索引

我的问题是：

1) 这是处理此类问题的正确架构吗？

2) 它是否需要 3 个数据存储：用于数据持久性的 MongoDB、用于搜索的 Slor（Lucene 索引）和用于推荐的 mahout 使用的 Solr（Lucene 索引）？

3) 既然 Slor 也是 NoSQL 解决方案，那么在不使用 MongoDB 的情况下，将 Solr 用于持久性和搜索功能有什么缺点？

4) 如果我想使用 Hadoop 或 Apache Sparks 进行分析，这涉及到引入另一个数据存储？

Answer 1

这种架构看起来很合理。您可以使用相同的 Solr 集群进行普通搜索以及 Recommender 搜索。如果您想将自己的数据输入写入 Spark，您可以实现一种方法来从 MongoDB 实例化 Mahout IndexedDataset。已经有一个伴随对象用于将 (String, String) 的 PairRDD 作为单个事件的输入并创建 IndexedDataset。这将消除对 HDFS 的需求。

Spark 保存临时文件，但不需要 HDFS 进行存储。如果您使用的是 AWS，您可以将 Spark 再培训工作放到 EMR 上，以启动培训，然后再拆除。

所以答案是：

1. 是的，看起来很合理。您应该始终将事件流保存在一些安全的存储中。

2. 不，只要您可以从 MongoDB 读取到 Spark，只需要 MongoDB 和 Solr。这将在 Recommender 训练代码中使用 Mahout 的 Spark 代码进行 SimilarityAnalysis.cooccurrence

3. 没有已知的缺点，不确定性能或 devops 权衡。

4. 您必须使用来自 Mahout 的 Spark for SimilarityAnalysis.cooccurrence，因为它实现了新的“相关交叉出现”(CCO) 算法，该算法将大大提高您使用不同形式的用户数据的能力，从而增加建议的质量。如果您使用 MongoDB 或 Solr 提供事件，Spark 不需要 HDFS 存储。

顺便说一句：ActionML 有助于其中的数据科学部分，我们可以帮助您确定哪些用户信息最具预测性。我们创建了 CCO 的第一个开源实现。通过包含正确的 CCO 数据，我们已经看到推荐质量的大幅提升（远高于 Netflix 的 10%）。我们还支持上述架构的 PredictionIO 实现。我们基于 Mahout（我是 Mahout 提交者）编写了 Universal Recommender，但它比从头开始构建系统要交钥匙得多，但是我们的分析帮助独立于实现，可能会在数据科学部分为您提供帮助项目。 ActionML.com，通用推荐器here。一切都是免费的 OSS。