增量MapReduce实现(最好不是CouchDB)

Question

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

我们对增加更新频率感兴趣,因此从头开始重新聚合所有内容都不切实际,因此我们希望进行滚动聚合以更新现有聚合以反映新的,更改的或已删除的记录.

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

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

为了预先防止一些可能的反应:

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

Answer 1

我首先想到的仍然是 Hive，因为它现在具有物化视图等功能，这些功能可以保存您的聚合，并在底层数据更改时选择性地失效。

虽然这并不是太新，但 Uber 实际上发表了一篇相当永恒的文章，介绍他们如何应对增量更新的挑战，甚至他们只引用的解决方案对于这个用例来说也可能非常有趣。本文的要点：

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

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