Hadoop 增量MapReduce实现（最好不是CouchDB）

我在一个项目中工作，该项目有一大堆原始数据，这些数据的聚合被用来为面向公众的信息网站提供动力（一些简单的聚合，如各种总计和前十个总计，还有一些更复杂的聚合）。目前，我们每几个月更新一次，包括添加新数据，可能更新或删除现有记录，并离线重新运行所有聚合，然后将新聚合部署到生产中

我们感兴趣的是提高更新频率，这样从头开始重新聚合所有内容是不现实的，因此我们希望进行滚动聚合，更新现有聚合以反映新的、更改的或删除的记录

CouchDB的MapReduce实现提供了我想要的功能：它将MapReduce任务的中间状态存储在一个大的B树中，其中映射的输出位于叶子上，并且reduce操作逐渐将分支连接在一起。新的、更新的或删除的记录会导致子树被标记为脏并重新计算，但只需要触摸reduce树的相关部分，并且非脏子树的中间结果可以按原样重新使用

但是，由于各种原因（CouchDB的未来不确定，缺乏对非MR一次性查询的方便支持，当前SQL繁重的实现等等），我们不希望在这个项目中使用CouchDB，所以我正在寻找这种树型增量映射缩减策略的其他实现（可能，但不一定，在Hadoop或类似软件上）

要预先阻止某些可能的响应，请执行以下操作：

• 我知道MongoDB对增量MapReduce的支持；在我看来，这不是真正的支持，因为它只适用于数据集的添加，而不适用于更新或删除
• 我也知道这篇文章。这正是我想要的，但我不认为他们已经公开了他们的实现

---

我想到的第一件事仍然是Hive，因为它现在具有物化视图等功能，如果底层数据发生变化，它们可能会保存聚合并选择性地失效

虽然这不是一篇太新的文章，但Uber实际上发表了一篇相当永恒的文章，甚至他们只参考的解决方案对于这个用例来说也可能非常有趣。本文的主要内容包括：

真正明确您的实际延迟需求可以为您节省大量资金

Hadoop可以通过使用原语来支持增量处理来解决更多的问题

统一的体系结构（代码+基础设施）是未来的发展方向

---

---

充分披露：我是Cloudera的员工。它提供大数据平台，包括Hadoop，其中包含文章中提到的各种工具，以及我直接提到的Hive。

您计划多久更新一次数据？更新的范围有多广？您的数据是否适合在som中进行分区自然地将数据分成大小相当的数据块，比如日历日期？为什么不看看Apache HBase。为什么你只寻找树型策略？@sonic我不一定。不过，我想要的是，单个记录的更改只需要重新计算受这些记录影响的聚合（或者可能是这些和其他一些，但不是整个数据集）。树似乎是实现这一点的逻辑方法。当前的map reduce解决方案是否可以接受a）更改的文件集b）来自上一次运行的旧聚合值以及关于上一次运行的元数据。基于这两件事，我们可以仅仅通过检查一组更改的文件来计算新的聚合吗？