与hadoop接近实时

Question

我需要一些很好的参考资料，以便将Hadoop用于实时系统，例如在很短的响应时间内进行搜索。我知道hadoop有它的hdfs开销，但最好用hadoop做这个。

Answer 1

您需要提供有关系统目标和挑战的更多信息，以获得良好的建议。也许Hadoop不是你需要的，你只需要一些分布式系统foo？ （哦，你完全确定你需要一个分布式系统吗？你可以用几个大内存机器上的复制数据库做很多事情。）

对你的问题一无所知，我会给你很少的回答尝试。

1. 看看HBase，它在HDFS之上提供了一个结构化的可查询数据存储，类似于Google的BigTable。 http://hadoop.apache.org/hbase/
2. 您可能需要一些管理复制和数据分片的帮助。看看Gizzard，这是一个中间件：http://github.com/twitter/gizzard
3. 处理总是可以事先完成。如果这意味着你实现了太多的数据，那么像Lucandra这样的东西可以提供帮助 - Lucene作为后端运行在Cassandra之上？ http://github.com/tjake/Lucandra

如果你确实需要在查询时进行认真的处理，那么这样做的方法是运行专门的进程来执行你需要的特定类型的计算，并使用类似Thrift的东西发送计算请求并接收结果。优化它们以将所有需要的数据存储在内存中。然后，接收查询本身的进程只能将问题分解为碎片，将碎片发送到计算节点，然后收集结果。这听起来像Hadoop，但不是因为它是用于计算预加载数据的特定问题而不是用于任意计算的通用计算模型。

Answer 2

Hadoop完全是这种要求的错误工具。它针对大批量作业进行了明确优化，可以运行几分钟甚至几小时甚至几天。

FWIW，HDFS与开销无关。事实上，Hadoop作业将jar文件部署到每个节点，设置工作区域，启动每个作业运行，在计算阶段之间通过文件传递信息，与作业运行者沟通进度和状态等等。

Answer 3

这个查询已经过时了，但它回答了问题。即使有数百万份文档，但没有像FAQ文档那样实时更改，Lucene + SOLR的分发应该足以满足需求。 Hathi Trust使用相同的组合索引数十亿份文件。

如果索引实时变化，这是一个完全不同的问题。即使Lucene在处理更新索引时也会遇到问题，你必须查看实时搜索引擎。有一些尝试实时重新制作Lucene，也许它应该有效。您还可以查看HSearch，这是一个基于Hadoop和HBase的实时分布式搜索引擎，托管在http://bizosyshsearch.sourceforge.net