12

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

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

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

但是，出于各种原因（CouchDB 未来的不确定性、对非 MR 一次性查询缺乏方便的支持、当前 SQL 繁重的实现等），我们不想在这个项目中使用 CouchDB，所以我'正在寻找这种树状增量 map-reduce 策略的其他实现（可能，但不一定，在 Hadoop 或类似的顶部）。

抢占一些可能的响应：

  • 我知道 MongoDB 应该支持增量 MapReduce；在我看来，这不是真的，因为它真的只适用于添加到数据集，而不是更新或删除。
  • 我也知道Inoop论文。这正是我想要的，但我认为他们没有公开他们的实现。
4

1 回答 1

1

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

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

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

全面披露：我是 Cloudera 的员工。大数据平台的提供商，包括 Hadoop，其中包含文章中提到的各种工具，还有我直接提到的 Hive。

于 2020-08-01T21:40:05.957 回答