不同块大小的Hadoop答案

【问题标题】：Different block size Hadoop不同块大小的Hadoop
【发布时间】：2015-05-14 08:14:08
【问题描述】：

我需要做什么才能在 Hadoop 中拥有更小/更大的块？

具体来说，我希望拥有更多数量的映射器，以便处理更小的数据。似乎我需要减小块大小，但我很困惑（我是 Hadoop 新手）——我需要在将文件放在 HDFS 上时做些什么，还是需要指定与输入拆分大小相关的东西，还是两者兼有？

我正在共享集群，所以我无法执行全局设置，所以如果可能的话，是否需要在每个作业的基础上执行此操作？我正在从代码（可能后来从 Oozie）运行这项工作。

【问题讨论】：

标签： hadoop

【解决方案1】：

映射器运行的内容由输入拆分控制，完全取决于您如何指定它。 HDFS 块大小与它无关（除了大多数拆分器使用块大小作为创建输入拆分的基本“块”以实现良好的数据局部性这一事实之外）。如果您愿意，您可以编写自己的拆分器，该拆分器采用 HDFS 块并拆分为 100 个拆分。另外看看Change File Split size in Hadoop。

话虽如此，这样做的智慧（“许多映射器的小分裂”）是非常值得怀疑的。其他人都在尝试做 相反的（创建几个具有聚合拆分的映射器）。见Dealing with Hadoop's small files problem、The Small Files Problem、Amazon Elastic MapReduce Deep Dive and Best Practices等。

【讨论】：

非常感谢您的回答。但是，如果拆分大小为 16MB 且块大小为 64MB，我不会让自己成为问题吗？我将失去数据局部性，并且可能会发生映射器需要从该块的四分之一所在的其他节点获取他们的部分数据？使用更小的块来“缩小 Hadoop”不是更好吗？
问题是，我的数据目前并没有那么大（可能会增长到几 GB），另一方面，执行的操作（主要在映射器中）非常密集，我m 谈论在记录基础上执行一些密集处理的机器学习算法（具体来说是聚类）。这样，我的数据由少量节点处理（因为数据不是那么大），另一方面，它们正在执行计算。你有什么更好的建议吗？
如果数据很小但计算量很大，那么失去局部性的影响应该很小。使用-Dmapreduce.input.fileinputformat.split.maxsize=... 提交作业是一项微不足道的测试。重新格式化您的 FS 以更改块大小是相当昂贵的并且会产生后果（例如，namenode 必须跟踪 x4 块）。

【解决方案2】：

您实际上不必减小块大小来拥有更多映射器，这将处理更少量的数据。

您不必修改 HDFS 块大小 (dfs.blocksize)，让它根据您的集群配置使用默认全局值。

您可以在作业配置中使用mapreduce.input.fileinputformat.split.maxsize 属性，其值低于块大小。

将使用此值计算输入拆分，并且为每个计算的输入拆分触发一个映射器。

【讨论】：

与 Remus 的问题相同 - 但如果拆分大小为 16MB 且块大小为 64MB，我不会给自己造成问题吗？我将失去数据局部性，并且可能会发生映射器需要从该块的该四分之一所在的其他节点获取他们的部分数据？使用更小的块来“缩小 Hadoop”不是更好吗？
如果您的映射器对每条记录执行高强度计算，从而导致映射器进度缓慢，但如果您仍有可用资源，那么将输入拆分大小调整为较低值真的很好。您应该考虑的一件事是在可用资源和映射器的执行之间取得平衡。您应该相应地为输入拆分找到适当的较低值，以便集群可以很好地执行并行映射器。如果超过集群能力的映射器太多，那么它们大多是按顺序进行的，这也会导致缓慢。
感谢您的回答，您和 Remus 的回答都很好，但他通过外部链接提供了更多信息，所以我接受他的回答并给您 +1。