我正在研究 Hadoop，看看它的哪些产品适合我们对大型数据集（每组数十亿条记录）进行快速查询的需求
查询将针对芯片测序数据执行。每条记录是文件中的一行。为了清楚起见，下面显示了数据集中的示例记录。
一行（记录）看起来像：
1-1-174-418 TGTGTCCCTTTGTAATGAATCACTATC U2 0 0 1 4 ***103570835*** F .. 23G 24C
突出显示的字段称为“匹配位置”，我们感兴趣的查询是该“匹配位置”的一定范围内的序列#。例如，范围可以是“匹配位置”> 200 和“匹配位置”+ 36 < 200,000。
关于我应该开始完成任务的 Hadoop 产品有什么建议吗？HBase、Pig、Hive 还是 ...？
粗略的指导方针：如果您需要大量快速返回且不需要聚合数据的查询，则需要使用 HBase。如果您正在查看更多以分析和聚合为重点的任务，则需要 Pig 或 Hive。
HBase 允许您指定扫描的开始行和结束行，这意味着它应该满足您提供的查询示例，并且似乎最适合您的用例。
对于后代，这是雪岭在 Hadoop 邮件列表中收到的答案：
首先，来自雪灵的更多细节：
数据集不会经常更新。但是对数据集的查询很频繁。查询越快越好。例如，我们在 Mysql 数据库（50 亿条记录随机分散到 24 个表中）上进行了测试，对最大表（400,000,000 条记录）的最慢查询大约是 12 分钟。因此，如果使用任何 Hadoop 产品可以加快搜索速度，那么该产品就是我们正在寻找的产品。
Cloudera 的 Todd Lipcon 的回应是：
在这种情况下，我会推荐以下内容：
- 将所有数据放在 HDFS 上
- 编写一个 MapReduce 作业，按匹配位置对数据进行排序
作为这项工作的第二个输出，您可以编写一个“稀疏索引”——基本上是一组这样的条目：
您基本上是在每 10K 条记录左右给出偏移量。如果你每 10K 记录索引一次，那么总共 50 亿将意味着 100,000 个索引条目。每个索引条目不应超过 20 个字节，因此 100,000 个条目将是 2MB。这非常容易放入内存中。（您可以改为每 100 条记录建立索引，最终得到 200MB，仍然很容易放入内存中）
然后，为了满足您的计数范围查询，您可以简单地扫描您的内存稀疏索引。一些索引块将完全包含在范围内，在这种情况下，您只需将“后面的条目数”列相加。开始和结束块将被部分覆盖，因此您可以使用文件偏移信息从 HDFS 加载该文件，从该偏移开始读取，并完成计数。
每个查询的总时间应该 <100ms 没问题。
随后的一些回复建议使用 HBase。
您可能需要查看 HBase 或 Cassandra 等 No-SQL 数据库方法。我更喜欢 HBase，因为它有一个不断发展的社区。
您还可以看一下 JAQL ( http://code.google.com/p/jaql/ )，但不幸的是它用于查询 JSON 数据。但也许这无论如何都有帮助。