来自Hadoop MapReduce InputFormat接口上的Apache文档:
"[L]基于输入大小的逻辑分割对许多人来说是不够的自记录边界以来的应用程序将得到尊重。在这样的在这种情况下，应用程序还必须在上实现RecordReader谁有责任尊重记录的界限，并提出一个逻辑InputSplit的面向记录视图的任务。"
在WordCount示例应用程序中，基于输入大小的逻辑分割是否不足?如果是这样，在源代码的哪里是一个RecordReader的实现发现?
输入分割是对数据的逻辑引用。如果您查看API，您可以看到它不知道任何关于记录边界的信息。为每个输入分割启动一个映射器。映射器的map()对每条记录(在WordCount程序中，是文件中的每一行)运行。
但是映射器如何知道记录边界在哪里呢?
这就是你从Hadoop MapReduce InputFormat Interface引用的地方-
应用程序还必须实现一个RecordReader有责任尊重记录的界限，并提供一个单个任务的逻辑InputSplit的面向记录视图
每个映射器都与一个InputFormat相关联。InputFormat有RecordReader使用的信息。看看这个API，您会发现它知道输入分割和使用什么记录读取器。如果你想了解更多关于输入分割和记录阅读器的知识，你应该看看这个答案。
A 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程序都"尊重"记录边界。否则，它没有多大用处。
你不能在WordCount示例中看到RecorderReader的实现，因为它使用默认的RecordReader和默认的InputSplit，在框架中指定。
如果你想看到它们的实现，你可以在Hadoop源代码中找到它。
有关记录器读取器及其工作原理的更多信息，请参阅:https://hadoopi.wordpress.com/2013/05/27/understand-recordreader-inputsplit/