我有一个'大数据'文本搜索问题，我在这里寻找Stackexchange网站上的一般建议 - https://softwareengineering.stackexchange.com/questions/203855/text-search-big-data-problem
这篇SO帖子中有一个特定的问题，即围绕ElasticSearch与Hadoop的集成（但我认为我会提供一些背景知识）。
问题概述
基本上我有大量文本，分成不同的“行”，每行代表一个项目。我有另一个较小的列表，其中包含本文中的搜索词。我想交叉引用这两个并进行反向索引查找，并返回我找到的索引。
注意：我知道20GB并不是海量数据，但本次练习的第二个目标是与大数据技术人员合作，为我们使用真正的大数据（＆gt; TB）奠定基础项目！
方法
我继续调查Lucene搜索路线，但据我所知，这将导致以下方法：
但对我来说，这仍然是串行的，即我依赖于搜索服务器的可扩展性非常快，但我仍然必须从我的列表顶部开始，然后继续努力，一个接一个。
我可以将原始列表拆分成块，并在不同的服务器上运行我的C＃应用程序，这将是一种方法。
具体问题
但是我想知道我是否可以使用Hadoop Map Reduce直接与ElasticSearch（我首选的Lucene路线）进行交流？我搜索过（！）但找不到任何东西，除了使用带有猪的Wonderdog。很好 - 但我看不到Pig UDF和ElasticSearch的例子。
任何指示赞赏，代码示例非常欢迎！
邓肯
答案 0 :(得分：4)
对于名为elasticsearch-hadoop
的新官方支持看看这里：http://www.elasticsearch.org/blog/elasticsearch-and-hadoop/
答案 1 :(得分：2)
你可能能够做到这一点。
一种可能的方法是让每个hadoop节点运行仅嵌入路由的弹性搜索节点。这应该使查询更有效，因为节点将确定每个查询需要联系哪些节点并利用有效的内部协议来执行此操作。您可以通过添加更多es数据节点来水平扩展。
唯一的缺点是你的hadoop节点不会接近不同节点上的数据;所以你有一点延迟通过网络。但即便如此，你应该能够以这种方式运行大量看似非常便宜的查询。由于它只有20GB，因此您的es节点很少需要转到磁盘并可以在内存中执行所有操作，使用过滤器缓存等。
我实际上在1节点集群中使用非hadoop代码对弹性搜索进行了一些消歧，并且我每秒管理2000-2500个简单查询，而不会过多地强调弹性搜索。花了我大约45分钟来处理700万份文件。添加要扩展的节点。你的milage可能会有所不同。
对于许多hadoop节点，您可以通过拥有大量并发请求来解决延迟效应，并且大型ES群集应该能够轻松跟上集体负载。只需增加副本数量即可减少每个节点的负载。
您可以使用批量索引api以及reduce步骤的一部分。另一个想法是使用search_type = scan在弹性搜索中迭代所有文档，而不是使用hdfs中的文件。可选，但可能效果很好。