hadoop—增量mapreduce实现(最好不是couchdb)

rqqzpn5f  于 2021-06-04  发布在  Hadoop
关注(0)|答案(1)|浏览(369)

我在一个项目中工作,这个项目有一大堆原始数据,这些数据的聚合被用来为面向公众的信息网站提供动力(一些简单的聚合,比如各种总计和前十个总计,还有一些更复杂的聚合)。目前,我们每几个月更新一次,包括添加新数据,可能更新或删除现有记录,并离线重新运行所有聚合,然后将新聚合部署到生产中。
我们感兴趣的是提高更新频率,这样从头开始重新聚合所有内容是不实际的,因此我们希望进行滚动聚合,更新现有聚合以反映新的、更改的或删除的记录。
couchdb的mapreduce实现提供了我正在寻找的功能:它将mapreduce任务的中间状态存储在一个大的b树中,其中Map的输出在叶子上,reduce操作逐渐将分支连接在一起。新的、更新的或删除的记录会导致子树被标记为脏的并重新计算,但是只需要触及reduce树的相关部分,并且可以按原样重新使用来自非脏子树的中间结果。
但是,由于各种原因(couchdb未来的不确定性、缺乏对非mr一次性查询的方便支持、当前sql繁重的实现等等),我们不希望在这个项目中使用couchdb,所以我正在寻找这种树式增量map reduce策略的其他实现(可能,但不一定,(hadoop或类似软件)。
要预先准备一些可能的响应:
我知道mongodb应该支持增量mapreduce;在我看来,这不是真的,因为它只适用于数据集的添加,而不适用于更新或删除。
我也知道incoop的文件。这正是我想要的,但我不认为他们已经公开了他们的实现。

rqcrx0a6

rqcrx0a61#

我想到的第一件事仍然是hive,因为它现在具有物化视图等特性,如果底层数据发生更改,这些特性可能会保存聚合并选择性地失效。
虽然这并不算太新,但uber实际上发表了一篇相当永恒的文章,讲述了他们如何应对增量更新的挑战,甚至他们只参考的解决方案对于这个用例来说也可能非常有趣。本文的要点:
真正明确你的实际延迟需求可以为你节省很多钱。
hadoop可以通过使用原语来支持增量处理来解决更多的问题。
统一的体系结构(代码+基础设施)是未来的发展方向。
完全披露:我是cloudera的员工。一个大数据平台的提供者,包括hadoop,它包含了文章中提到的各种工具,还有我直接提到的hive。

相关问题