我计划在一个项目中，它涉及数据持久性，搜索能力和推荐功能（协同过滤）。
如图所示，我在想：
1） 拥有一组微服务来处理将持久化在nosql存储中的实体（可能是mongodb）
2） 对于搜索功能，我将使用slor，来自微服务的消息将用于更新slor索引。
3） 对于建议，我考虑使用apachemahout并使用消息队列来更新mahout中使用的slor索引
我的问题是：
1） 这是处理此类问题的正确体系结构吗？
2） 它是否需要3个数据存储：mongodb用于数据持久性，slor（lucene索引）用于搜索，solr（lucene索引）由mahout用于推荐？
3） 既然slor也是一个nosql解决方案，那么在不使用mongodb的情况下对持久性和搜索函数使用solr有什么缺点呢？
4） 如果我想使用hadoop或apachesparks进行分析，这涉及到引入另一个数据存储？
1条答案
按热度按时间isr3a4wc1#
这种结构似乎是合理的。您可以使用相同的solr集群进行普通搜索和推荐搜索。如果您想将自己的数据输入写入spark，那么可以实现一个方法来示例化mongodb中的mahout indexedataset。已经有一个伴生对象可以将（string，string）的pairdd作为单个事件的输入并创建indexeddataset。这样就不需要hdfs了。
spark保存临时文件，但不需要hdfs存储。如果你使用的是aws，你可以把spark的再培训工作放到emr上，进行培训，然后拆下来。
所以答案是：
是的，看起来很合理。您应该始终将事件流保存在一些安全的存储中。
不需要，只要您可以从mongodb读取到spark，就只需要mongodb和solr。这将在推荐者训练代码中使用mahout的spark代码进行相似性分析
没有已知的不利因素，不确定性能或devops的权衡。
您必须使用mahout的spark for similarityanalysis.cooccurrence，因为它实现了新的“相关交叉引用”（correlated cross occurrence，cco）算法，这将极大地提高您使用不同形式用户数据的能力，从而提高推荐的质量。如果使用mongodb或solr输入事件，spark不需要hdfs存储。
顺便说一句：actionml有助于数据科学，我们可以帮助您确定哪些用户信息最具预测性。我们创建了cco的第一个开源实现。我们看到，通过包含正确的cco数据，推荐的质量有了很大的提高（远远超过netflix奖的10%）。我们还支持上述体系结构的predictionio实现。我们基于mahout（我是mahout的提交者）编写了universal recommender，但是它比从头开始构建系统要简单得多，但是我们的分析帮助独立于实现，可能在项目的数据科学部分对您有所帮助。actionml.com，这里是全球推荐人。一切都是免费的。