很抱歉我还没有深入了解HBase和Hadoop MapReduce，但我认为你可以帮助我找到使用它们的方法，或者你可以提出我需要的框架。
第一部分
有第一个记录流，我必须存储在某个地方。它们应该可以由一些钥匙访问，具体取决于它们。多个记录可能具有相同的密钥。他们有很多。我必须在超时前删除旧记录。
还有第二流的记录，这也是非常密集的。对于每个记录（参数记录），我需要：从具有该参数记录键的第一个字符串中获取所有记录，找到第一个对应的记录，将其从第一个流存储中删除，返回合并这两个记录的结果（res1）。
第二部分
第三个记录流就像第一个。记录应该可以通过键访问（与第一部分的不同）。像往常一样，几张唱片都有相同的密钥。他们中没有那么多像第一流那样的人。我必须在超时前删除旧记录。
对于每个res1（参数记录），我必须：用该记录的另一个键从第三层获取所有记录，映射这些记录，将res1作为参数，reduce为结果。第三流记录应在存储中保持未修改状态。
具有相同关键字的记录最好存储在同一节点，通过关键字获取记录并根据给定的参数记录执行某些操作的过程最好在记录所在的节点上运行。
HBase和Hadoop MapReduce是否适用于我的情况？这样的应用程序应该是什么样子（基本想法）？如果答案是否定的，是否有框架来构建这样的应用程序？
如果你不能得到我想要的，请提问。
我与存储后端技术有关。前端接受记录可以是无状态的，并且其可扩展性很低。
我们有源源不断的记录，我们想加入他们的行列。有些记录应该被持久化，为什么有些（据我所知，第一流）是瞬态的
如果我们不考虑可伸缩性和持久性，它可以在单个java进程中实现，对随机访问的数据使用HashMap，对我们想要存储的排序数据使用TreeMap
现在让我们看看如何将其映射到NoSQL技术中，以获得我们需要的可扩展性和性能
HBase分布排序映射。因此，它可能是流2的好候选者。如果我们使用我们的密钥作为hbase表密钥，我们将获得具有相同密钥的记录的数据位置。
HBase之上的MapReduce也可用。
流1看起来像是临时随机访问的数据。我认为为这些记录付出持久性的代价是没有意义的，所以分布式内存哈希表应该这样做。例如：http://memcached.org/存储的元素可能会有具有相同密钥的记录列表
我仍然不能100%确定第三流的需求，但二级索引的需求（如果事先知道的话）可以作为另一个分布式映射在应用程序级别实现。
简言之，我的建议是，为您想要持久化和存储排序的数据选择HBase，并为瞬态（但仍然相当大）数据考虑一些更轻量级的解决方案。