2

从数据流的角度来看 MapReduce 和 HBase 的组合，我的问题似乎很合适。我有大量文档要映射、合并和缩减。我之前的 SQL 实现是将任务拆分为批处理操作，将 Map 的结果累积存储到表中，然后执行相当于 reduce 的操作。这样做的好处是，在执行期间（或执行之间）的任何时候，我都可以在那个时间点获得 Map 的结果。

据我了解，将此作业作为 MapReduce 运行需要每次运行所有 Map 函数。

我的 Map 函数（实际上是任何函数）总是为给定的输入提供相同的输出。如果我不需要，重新计算输出根本没有意义。我的输入（一组文档）将不断增长，我将定期对数据运行 MapReduce 操作。在执行之间，我应该只需要为新添加的文档计算 Map 函数。

我的数据可能是 HBase -> MapReduce -> HBase。鉴于 Hadoop 是一个完整的生态系统，它可能能够知道给定函数已应用于具有给定标识的行。我假设 HBase 表中的条目是不可变的。Hadoop 是否/可以考虑到这一点？

我从文档（尤其是 Cloudera 视频）中了解到，重新计算（潜在冗余数据）可能比针对 Hadoop 正在用于处理的问题类别进行持久化和检索更快。

有什么意见/答案吗？

4

2 回答 2

1

为什么不在不同的环境中应用您的 SQL 工作流？意思是，在您的输入表中添加一个“已处理”列。当需要运行摘要时，请运行类似于以下内容的管道：

映射（map_function）在（输入表过滤！处理）；在 hbase 或简单的 hdfs 中存储到 map_outputs 中。

在（map_outputs）上映射（减少函数）；存储到 hbase 中。

假设您将数据存储在按插入日期排序的 Hbase 中，如果您在某处记录成功汇总运行的时间戳，并打开日期晚于上次成功汇总的输入的过滤器，您可以让生活变得更轻松 - 您将节省一些显着的扫描时间。

这是一个有趣的演示文稿，展示了一家公司如何构建他们的工作流程（尽管他们不使用 Hbase）： http ://www.scribd.com/doc/20971412/Hadoop-World-Production-Deep-Dive-with-High-Availability

于 2009-11-09T01:07:39.627 回答
1

如果您希望避免每次都运行 Map 步骤，请将其分解为自己的步骤（通过使用 IdentityReducer 或将作业的 reducer 数量设置为 0）并使用 map 步骤的输出运行后续步骤.

这实际上是否比每次从原始数据重新计算更快取决于输入数据与输出数据的体积和形状，映射步骤的复杂程度等。

请注意，在新数据集上运行映射器不会附加到以前的运行 - 但您可以通过使用过时的输出文件夹来解决这个问题。这就是说你可以将你的第一批文件映射的输出存储在 中my_mapper_output/20091101，下周的一批文件存储在my_mapper_output/20091108等等。如果你想减少整个集合，你应该可以my_mapper_output作为输入文件夹传入，并捕获所有输出集。

于 2009-11-20T19:30:30.107 回答