基于 HBase 和 Hadoop MapReduce 的分布式多图

Question

很抱歉我对HBase和Hadoop MapReduce没有深入了解，但是我想你可以帮我找到使用它们的方法，或者你可以提出我需要的框架。

---

第一部分

我必须将第一条记录流存储在某处。它们应该可以通过某些键访问，具体取决于它们。多条记录可以具有相同的键。他们有很多。我必须在超时之前删除旧记录。

还有第二条记录流，也很密集。对于每条记录（参数记录），我需要：使用该参数记录的键从第一个流中获取所有记录，找到第一个相应的记录，从第一个流存储中删除它，返回结果（res1 em>) 合并这两条记录。

---

第二部分

第 3 条记录流与第 1 条记录类似。记录应该可以通过键访问（与第一部分的不同）。与往常一样，几条记录将具有相同的键。没有像第一流那样多。我必须在超时之前删除旧记录。

对于每个 res1（参数记录），我必须：使用该记录的另一个键从 3rd strem 获取所有记录，map 这些以 res1 作为参数的记录，reduce 为结果。 3rd 流记录应在存储中保持不变。

---

具有相同键的记录优先存储在同一个节点上，通过键获取记录并根据给定的参数记录执行某些操作的过程优先运行在记录所在的节点上。

---

HBase 和 Hadoop MapReduce 是否适用于我的情况？以及这样的应用程序应该是什么样子（基本想法）？如果答案是否定的，是否有构建此类应用的框架？

如果你不能得到我想要的东西，请提出问题。

Answer 1

我与存储后端技术有关。前端接受记录可以是无状态的，并且具有微不足道的可扩展性。

我们有大量记录，我们想即时加入它们。一些记录应该被保留，为什么一些（据我所知 - 第一流）是短暂的。
如果我们不考虑可伸缩性和持久性 - 它可以在单个 Java 进程中实现，使用 HashMap 用于随机访问的数据，使用 TreeMap 用于我们想要存储排序的数据
现在让我们看看如何将它映射到 NoSQL 技术中以获得我们需要的可扩展性和性能。
HBase 是分布式排序图。所以它可能是流 2 的良好候选者。如果我们使用我们的键作为 hbase 表键 - 我们将获得具有相同键的记录的数据局部性。
基于 HBase 的 MapReduce 也可用。
流 1 看起来像临时随机访问的数据。我认为为这些记录付出持久性的代价是没有意义的——所以分布在内存哈希表中应该这样做。例如：http://memcached.org/ 存储元素可能会有具有相同键的记录列表。
我仍然不能 100% 确定第三个流的要求，但是可以在应用程序级别上将二级索引的需要（如果事先知道的话）作为另一个分布式映射来实现。
简而言之 - 我的建议是为您想要持久化和存储排序的数据选择 HBase，并考虑一些更轻量级的解决方案来处理瞬态（但仍然是相当大的）数据。