gpt4 book ai didi

java - Hadoop:是否可以在映射函数中包含内存结构并聚合它们?

转载 作者:可可西里 更新时间:2023-11-01 15:18:58 26 4
gpt4 key购买 nike

我目前正在阅读一篇论文,我想到了一点,作者说他们在内存中为每个 map 任务准备了一些数组,当 map 任务结束时,他们输出该数组。

这是我指的论文:http://research.google.com/pubs/pub36296.html

这看起来有点非 mapreduce 要做的事情,但我正在尝试实现这个项目,我已经得出结论,这是唯一的解决方案。我已经尝试了很多方法来使用通用的 map reduce 哲学,它处理每一行并输出一个键值对,但是这样我对每一行输入都有成千上万的上下文写入,并且需要很长时间才能写入他们。所以我的 map task 是一个瓶颈。这些上下文写入成本很高。

如果我按照他们的方式进行,我将设法显着减少键值对的数量。所以我需要找到一种方法来为每个 map task 提供内存结构。我可以在设置函数中将这些结构定义为静态,但我可以找到一种方法来判断 map task 何时结束,以便我可以输出该结构。我知道这听起来有点奇怪,但这是高效工作的唯一方法。

这就是他们在那篇论文中所说的

On startup, each mapper loads the set of split points to be considered for each ordered attribute. For each node n ∈ N and attribute X, the mapper maintains a table Tn,X of key- value pairs.

After processing all input data, the mappers out- put keys of the form n, X and value v, Tn,X [v]

以下是肖恩回答后的一些编辑:

我在工作中使用了组合器。问题是我的 map 函数中的这些 context.write(Text,Text) 命令非常耗时。我的输入是 csv 文件或 arff 文件。每一行都有一个例子。我的示例可能有多达数千个属性。我以 <(n,X,u),Y> 的形式为每个属性输出键值对,其中是节点的名称(我正在构建决策树),X 是属性的名称, u 是属性的值,Y 是文本格式的一些统计信息。如您所知,如果我有 100,000 个属性,则每个示例都必须有 100,000 个 context.write(Text,Text) 命令。在没有这些命令的情况下运行我的 map task ,它运行起来就像风一样。如果我添加 context.write 命令,它需要永远。即使是 200 万个属性的训练集。看起来我真的是在写文件而不是在内存中。所以我真的需要减少这些写入。有必要在内存中聚合它们(在映射函数中而不是在组合器中)。

最佳答案

添加一个不同的答案,因为我现在明白了问题的重点。

要知道 map task 何时结束,您可以覆盖close()。我不知道这是不是你想要的。如果您有 50 个映射器,则每个映射器看到的输入的 1/50 是未知的或无法保证的。这对你的用例来说是否合适——你只需要每个工作人员在内存中汇总它所看到和输出的统计数据?

那么您的程序就可以了,但可能不会使您的内存数据结构成为 static -- 没有人说两个 Mapper 不会在一个 JVM 类加载器中运行。

这种模式的一个更常见的版本出现在 Reducer 中,您需要在生成一条记录之前收集一些已知的 key 子集的信息。您可以使用分区程序,以及对键进行排序的事实,以了解您在一个 worker 上看到了所有该子集,并且可以知道何时完成,因为出现了一个新的不同子集。然后很容易在处理子集的同时在内存中收集数据,输出结果并在新子集进来时清除它。

我不确定这里是否可行,因为瓶颈发生在 Reducer 之前。

关于java - Hadoop:是否可以在映射函数中包含内存结构并聚合它们?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9508584/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com