我正在计划一个涉及数据持久性、搜索功能和推荐功能(协同过滤)的项目。
如图所示，我在想:
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 进行分析，这涉及引入另一个数据存储？
最佳答案
这个架构看起来很合理。您可以使用相同的 Solr 集群进行常规搜索和 Recommender 搜索。如果您想将自己的数据输入写入 Spark，您可以实现一种方法来从 MongoDB 实例化 Mahout IndexedDataset。已经有一个伴随对象，用于将 (String, String) 的 PairRDD 作为单个事件的输入并创建 IndexedDataset。这将消除对 HDFS 的需求。
Spark 保存临时文件但不需要 HDFS 进行存储。如果您使用的是 AWS，则可以将 Spark 再训练工作放到 EMR 上，以启动进行训练，然后再拆除。
所以答案是:
是的，看起来很合理。您应该始终将事件流保存在某个安全的存储空间中。
不需要，只需要MongoDB和Solr，只要能从MongoDB读取到Spark即可。这将在 Recommender 训练代码中使用 Mahout 的 Spark 代码完成 SimilarityAnalysis.cooccurrence
没有已知的缺点，不确定性能或 devops 权衡。
您必须将 Spark 用于 Mahout 的 SimilarityAnalysis.cooccurrence，因为它实现了新的“相关交叉出现”(CCO) 算法，该算法将大大提高您使用不同形式的用户数据的能力，从而增加推荐质量。如果您使用 MongoDB 或 Solr 提供事件，Spark 不需要 HDFS 存储。
顺便说一句:ActionML帮助这方面的数据科学部分，我们可以帮助您确定哪些用户信息最具预测性。我们创建了 CCO 的第一个开源实现。通过包含正确的 CCO 数据(远高于 Netflix 奖品 10%)，我们已经看到推荐质量有了非常大的提高。我们还支持上述架构的 PredictionIO 实现。我们基于 Mahout 编写了 Universal Recommender(我是 Mahout 的提交者)，但它比从头构建系统要交 key 得多，但是我们的分析帮助独立于实现，可能会在数据科学部分为您提供帮助项目。 ActionML.com，通用推荐系统 here .全部都是免费的 OSS。
关于java - 架构 : Data Persistency , 搜索和推荐系统，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35341667/