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

Question

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

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

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

由于各种原因（虽然CouchDB的未来存在不确定性，缺乏对非MR一次性查询的便捷支持，当前SQL大量实施等），我们宁愿不将CouchDB用于此项目，所以我正在寻找这种树式增量map-reduce策略的其他实现（可能，但不一定，在Hadoop或类似的上面）。

预先取消一些可能的回应：

• 我知道MongoDB支持增量MapReduce;在我看来，这不是真实的东西，因为它真的只适用于数据集的添加，而不是更新或删除。
• 我也知道Incoop论文。这完全描述了我想要的东西，但我认为他们没有公开他们的实现。

Answer 1

我想到的第一件事仍然是Hive，因为它现在具有物化视图等功能，可以保留您的聚合并在基础数据更改时有选择地使之无效。

尽管它不是太新，但是Uber实际上在how they approached the challenge of incremental updates上发表了一篇相当永恒的文章，即使是他们仅引用的解决方案在此用例中也可能非常有趣。本文的主要要点：

1. 真正了解您的实际延迟需求可以节省大量资金。
2. Hadoop通过使用原语支持增量处理可以解决更多问题。
3. 统一的架构（代码+基础架构）是未来的方式。

---

全面披露：我是Cloudera的雇员。一个大数据平台的提供者，包括Hadoop，其中包含本文中引用的各种工具，以及我直接引用的Hive。