hadoop mapreduce recordreader实现是否必要?

7z5jn7bk  于 2021-06-02  发布在  Hadoop
关注(0)|答案(2)|浏览(324)

从hadoop mapreduce inputformat接口上的apache文档:
“基于输入大小的逻辑拆分对于许多应用程序来说是不够的,因为需要遵守记录边界。在这种情况下,应用程序还必须实现一个recordreader,其职责是尊重记录边界,并向单个任务提供逻辑输入拆分的面向记录的视图。”
wordcount示例应用程序是否基于输入大小的逻辑拆分不足?如果是这样的话,在源代码中哪里可以找到recordreader的实现?

cnwbcb6i

cnwbcb6i1#

输入拆分是对数据的逻辑引用。如果你看一下api,你会发现它对记录边界一无所知。为每个输入分割启动一个Map器。Map绘制者的 map() 对每个记录(在wordcount程序中,文件中的每一行)运行。
但是Map绘制者怎么知道记录边界在哪里呢?
这就是你引用hadoopmapreduceinputformat接口的地方-
应用程序还必须实现一个recordreader,该recordreader负责尊重记录边界,并向单个任务提供逻辑输入拆分的面向记录的视图
每个Map器都与输入格式相关联。那个 InputFormat 有哪些信息 RecordReader 使用。看看api,您会发现它知道输入拆分和要使用的记录读取器。如果你想了解更多关于输入分割和记录阅读器的知识,你应该阅读这个答案。
RecordReader 定义记录边界;这个 InputFormat 定义什么 RecordReader 已使用。
wordcount程序没有指定任何 InputFormat ,因此默认为 TextInputFormat 它使用linerecordreader并将每一行作为不同的记录发出。这是你的源代码
[l] 基于输入大小的逻辑拆分对于许多应用程序来说是不够的,因为需要遵守记录边界。
这意味着,例如

a b c d e
f g h i j
k l m n o

我们希望每一行都能成为记录。当逻辑拆分基于输入大小时,可能有两个拆分,例如:

a b c d e
f g

以及

h i j 
k l m n 0

如果不是因为 RecordReader ,它会考虑 f g 以及 h i j 不同的记录;显然,这不是大多数应用程序想要的。
回答您的问题,在wordcount程序中,记录边界是什么并不重要,但是有可能同一个单词被拆分为不同的逻辑拆分。因此,基于大小的逻辑拆分对于wordcount程序是不够的。
每个mapreduce程序都“尊重”记录边界。否则,就没什么用了。

sq1bmfud

sq1bmfud2#

在wordcount示例中,您无法看到recorderreader实现,因为它使用了框架中指定的默认recordreader和默认inputsplit。
如果您想查看它们的实现,可以在hadoop源代码中找到。
有关记录器读取器及其工作方式的更多信息,请参阅:https://hadoopi.wordpress.com/2013/05/27/understand-recordreader-inputsplit/

相关问题