如果我使用hadoop fs -put filename将一个大小为117MB的文本文件上传到HDFS，我可以看到一个datanode包含一个64.98MB（默认文件分割大小）的文件部分，另一个数据节点包含一个大小的文件部分48.59MB。
我的问题是这个拆分位置是否以数据识别的方式计算（例如，识别文件是文本，因此将文件拆分为“\ n”）。
我意识到InputFileFormat可用于告诉正在运行的作业如何以智能方式拆分文件，但由于我没有在fs -put命令中指定文件类型，我想知道是否（如果是这样）在这种情况下，将进行智能分裂。
埃利
答案 0 :(得分：3)
我认为你在这里混淆了两件事，以下两种分裂是完全分开的：
而且，不，分割位置不是以数据识别的方式计算的。
现在，默认情况下，如果您使用FileInputFormat，那么这两种类型的分裂类型重叠（因此都是相同的）。
但是你可以随时为上面的第二点设置一个自定义分割方式（甚至根本没有分割，即将一个完整的文件转到一个映射器）。
此外，您可以更改hdfs块大小，与InputFormat分割输入数据的方式无关。
这里需要注意的另一个要点是，尽管文件在存储到HDFS时实际上是物理上破坏的，但是为了分配以便分发给映射器，文件没有实际的物理分割，而只是逻辑分裂。
从here获取示例：
假设我们要将110MB的文本文件加载到hdfs。 hdfs块大小和 输入分割大小设置为64MB。
映射器数量基于输入拆分数量而非hdfs块拆分数量。
当我们将hdfs块设置为64MB时，它正好是67108864（64 * 1024 * 1024）字节。我的意思是文件不重要 从中间分开。
现在我们有2个输入分割（所以两个地图）。第一个块的最后一行和第二个块的第一行没有意义。 TextInputFormat是 负责阅读有意义的线条并让他们进行地图工作。 TextInputFormat的作用是：
- 在第二个区块中，它将寻找第二行，这是一条完整的行并从那里读取并将其提供给第二个映射器。
- 第一个映射器将一直读到第一个块结束，并且它将处理（第一个块的最后一个不完整的行+第一个 第二块不完整的线）。
了解更多here。