搜索存储在 Hadoop 中的文档 - 使用哪个工具？答案

【问题标题】：Searching over documents stored in Hadoop - which tool to use?搜索存储在 Hadoop 中的文档 - 使用哪个工具？
【发布时间】：2012-07-17 21:37:09
【问题描述】：

我迷失在：Hadoop、Hbase、Lucene、Carrot2、Cloudera、Tika、ZooKeeper、Solr、Katta、Cascading、POI...

当您阅读有关该工具的信息时，您通常可以确定其他工具中的每一个都会被提及。

我不希望您向我解释每个工具 - 当然不会。如果您可以帮助我针对我的特定场景缩小此设置范围，那就太好了。到目前为止，我不确定以上哪一个适合，而且看起来（一如既往）有不止一种方法可以做要做的事情。

场景是：500GB - ~20 TB 的文档存储在 Hadoop 中。多种格式的文本文档：电子邮件、doc、pdf、odt。有关存储在 SQL db 中的文档的元数据（发件人、收件人、日期、部门等）。文档的主要来源将是 ExchangeServer（电子邮件和附件），但不仅如此。现在开始搜索：用户需要能够对这些文档进行复杂的全文搜索。基本上他会看到一些搜索配置面板（java 桌面应用程序，而不是 web 应用程序） - 他将设置日期范围、文档类型、发件人/收件人、关键字等 - 触发搜索并获取文档的结果列表（以及每个文档信息为什么包含在搜索结果中，即在文档中找到了哪些关键字）。

我应该考虑哪些工具，哪些不应该考虑？关键是用最少的“胶水”代码开发这样的解决方案。我精通 SQLdbs，但对 Apache 和相关技术很不适应。

基本工作流程如下所示：ExchangeServer/其他来源 -> 从 doc/pdf/... 转换 -> 重复数据删除 -> Hadoop + SQL（元数据） -> 构建/更新索引显示搜索结果

谢谢！

【问题讨论】：

标签： solr hadoop lucene cloudera carrot2

【解决方案1】：

使用 solr 是一个不错的选择。我已经将它用于您上面描述的类似场景。您可以将 solr 用作其分布式索引服务器来处理真正的海量数据。

但要获取有关所有这些文档格式的元数据，您应该使用其他工具。基本上你的工作流程是这样的。

1) 使用hadoop集群存储数据。

2) 使用 map/redcue 提取 hadoop 集群中的数据

3) 做文件识别（识别文件类型）

4) 从这些文档中提取元数据。

5) 在solr服务器中索引元数据，在数据库中存储其他摄取信息

6) Solr 服务器是分布式索引服务器，因此每次摄取都可以创建一个新的分片或索引。

7) 当需要搜索时，搜索所有索引。

8) Solr 支持所有复杂的搜索，因此您不必制作自己的搜索引擎。

9) 它也为你做分页。

【讨论】：

【解决方案2】：

我们通过将 Solr 用作 HBase 的“辅助索引器”，为我们的一些客户完成了这项工作。 HBase 的更新被发送到 Solr，您可以对其进行查询。通常人们从 HBase 开始，然后进行嫁接搜索。听起来您从一开始就知道搜索就是您想要的，因此您可能可以从提供 HBase 的管道中嵌入二级索引。

您可能会发现仅使用 Solr 就可以满足您的所有需求。

【讨论】：

如果 Solr 可以用很少的细节做所有事情，你能解释一下 HBase 的需求吗？是因为您首先从 HBase 开始，还是有更多内容？感谢您的建议。
德克斯特，已经有一段时间了。刚刚看到您的评论，您说的很对……HBase 确实为您提供了表格数据结构，但是当涉及到交互式查询时，Solr 做得非常出色。

【解决方案3】：

另一个值得关注的项目是 Lily，http://www.lilyproject.org/lily/index.html，它已经完成了将 Solr 与分布式数据库集成的工作。

另外，我不明白您为什么不想为这个应用程序使用浏览器。您正在准确描述分面搜索是什么。虽然您当然可以设置一个与服务器通信（解析 JSON）并在胖客户端 GUI 中显示结果的桌面应用程序，但所有这些工作都已经在浏览器中为您完成了。而且，Solr 附带了一个开箱即用的免费多面搜索系统：只需按照教程进行操作即可。

【讨论】：

【解决方案4】：

使用 Solr (http://lucene.apache.org/solr) 是一个很好的解决方案，但要准备好处理一些不明显的事情。首先是正确规划索引。多 TB 的数据几乎肯定需要 Solr 上的多个分片才能获得任何级别的合理性能，而您将负责自己管理这些分片。它确实提供了分布式搜索（对多个分片进行查询），但这只是成功的一半。

ElasticSearch (http://www.elasticsearch.org/) 是另一种流行的替代方案，但我在规模方面没有太多经验。它使用相同的 Lucene 引擎，所以我希望搜索功能集是相似的。

另一种解决方案类似于 SenseiDB - 从 LinkedIn 开源 - 它提供全文搜索功能（也基于 Lucene）以及经过验证的大量数据规模：

http://senseidb.com

他们确实在那边做了大量的搜索工作，我随意使用它很有希望。

假设您的所有数据都已在 Hadoop 中，您可以编写一些自定义 MR 作业，以一致的模式友好格式将数据拉入 SenseiDB。 SenseiDB 已经提供了一个 Hadoop MR 索引器，您可以查看它。

唯一需要注意的是，它的设置有点复杂，但可以为您解决多次缩放问题 - 特别是在索引性能和分面功能方面。如果 HA 对您很重要，它还提供集群支持 - 这是 Solr 的 still in Alpha（Solr 4.x 是 alpha atm）。

希望对您有所帮助，祝您好运！

更新：

我问了一个比我更精通 ElasticSearch 的朋友，它确实具有基于您拥有的机器和分片数量进行集群和重新平衡的优势。这绝对是对 Solr 的胜利——尤其是在您处理 TB 的数据时。唯一的缺点是 ElasticSearch 的当前文档状态还有很多不足之处。

【讨论】：

【解决方案5】：

附带说明，您不能说文档存储在 Hadoop 中，它们存储在分布式文件系统中（很可能是 HDFS，因为您提到了 Hadoop）。

关于搜索/索引：Lucene 是用于您的场景的工具。您可以将它用于索引和搜索。这是一个java库。还有一个相关的项目（称为 Solr），它允许您通过 WebServices 访问索引/搜索系统。因此，您还应该看看 Solr，因为它允许处理不同类型的文档（Lucene 将解释文档（PDF、Word 等）的责任放在了您的肩上，但您可能已经可以这样做了）

【讨论】：