Hadoop MapReduce：适当的输入文件大小？答案

【问题标题】：Hadoop MapReduce: Appropriate input files size?Hadoop MapReduce：适当的输入文件大小？
【发布时间】：2012-06-16 09:18:42
【问题描述】：

我有 3 位数 GB 甚至 1 或 2 位数 TB 的数据集。因此，输入文件是一个文件列表，每个文件大小为 10GB。我在 hadoop 中的 map reduce 作业处理了所有这些文件，然后只给出一个输出文件（带有汇总信息）。

我的问题是：

从 Apache 调整 hadoop/mapreduce 框架的合适文件大小是多少？我听说大文件比小文件更受欢迎。有什么想法吗？我唯一确定的是 hadoop 读取块，每个块默认为 64MB。因此，如果文件大小是 64MB 的乘数，那就太好了。
目前，我的应用程序仅将输出文件写入一个文件。文件大小当然是 3 位千兆位。我想知道如何有效地对文件进行分区。当然，我可以只使用一些 unix 工具来完成这项工作。但是否更喜欢直接在 hadoop 中执行此操作？

感谢您的 cmets！

附：我没有压缩文件。输入文件的文件格式为text/csv。

【问题讨论】：

很多问题（请将答案回复到您原来的问题中）：您是否在压缩文件，如果是，您使用的是什么压缩类型（gzip、bz2、...）？输入文件的文件格式是什么（文本、二进制？）
@Chris：我没有压缩文件。输入文件的文件格式为 text/csv。谢谢！

标签： file hadoop size mapreduce

【解决方案1】：

输入文件的大小：

调整它的一种方法是查看地图任务完成的速度。每个映射任务将接收 1 个文件作为输入，如果它们在 30-40 秒内完成，那么您应该考虑增加每个文件的大小，以便每个映射器有更多的工作要做。这是因为地图任务在执行任何实际工作之前需要大约 30 秒来初始化。

这还取决于您的集群一次可以运行多少个地图任务。您可以尝试调整文件和块大小，以便尽可能多地利用地图任务。有关更多想法，请参阅此博客文章：http://www.cloudera.com/blog/2009/12/7-tips-for-improving-mapreduce-performance/

输出文件的大小：

执行此操作的简单方法是指定多个减速器（每个减速器将生成一个输出文件）。如果您想按某个键（例如，年月）对结果进行分区，您可以将其包含在 map 任务的输出键中，它们将被排序到同一个 reducer。然后你只需要检查每个文件，看看它有什么年月键。

压缩：

我建议您考虑压缩文件。这样做会使输入文件“更大”，因为每个文件都将包含更多数据供单个地图任务操作。它还将减少您在集群中使用的磁盘数量。如果有的话，它还可能会提高集群上 mapreduce 的性能，因为读取和移动文件会减少磁盘 I/O 和网络流量。

另外，压缩 map 任务的中间输出（map 任务的输出在它进入 reducer 之前）。它将以类似的方式提高性能。这是通过设置mapred.compress.map.output=true来完成的。

【讨论】：

【解决方案2】：

如果您不压缩文件，则 hadoop 将处理您的大文件（例如 10G），其中包含与文件块大小相关的许多映射器。

假设您的块大小为 64M，那么您将有 ~160 个映射器处理这个 10G 文件（160*64 ~= 10G）。根据您的映射器逻辑的 CPU 密集程度，这可能是一个可接受的块大小，但如果您发现您的映射器在亚分钟时间内执行，那么您可能希望增加每个映射器完成的工作（通过增加块大小到 128、256、512m - 实际大小取决于您打算如何处理数据）。

较大的块大小将减少用于处理 10G 文件的映射器数量。当然，您可以增加 TextInputFormat 使用的最小拆分大小，但是您很可能会遇到较低的数据本地化，因为映射器可能正在处理 2 个或更多块，这些块可能并不都驻留在该节点上。

至于输出，这又取决于你的处理逻辑在做什么——你能通过引入更多的 reducer 来进行分区吗？这将创建更多的输出文件，但是您需要对这些文件进行哪些分区逻辑（默认情况下，它们将按您的键进行哈希分区）

【讨论】：

对于分区，我的意思是将输出文件拆分为其他几个文件，因为我将再次将此输出用作其他 map reduce 作业的输入。 1 个 1TB 大小的文件有点糟糕，对吧？
取决于（与以前类似的问题 - 压缩？输出格式？）。如果您可以使用多个 reducer 来构建输出文件，您将获得更好的吞吐量（在这种情况下，您实际上会获得多个输出文件，但它们可以在后续作业中使用。一切都取决于是否一切都需要一个减速器）
映射器的数量不取决于块大小，它们取决于输入拆分的大小。
@siddharthajain - 默认情况下，FileInputFormat 使用文件的块数来确定拆分数 - 除非您摆弄作业参数，否则您的块大小小于默认的最小拆分大小.

【解决方案3】：

Hadoop 根据输入拆分大小划分工作。它将您的总数据大小除以您的拆分大小，这就是它确定将发生多少地图作业的方式。一般的共识是每台机器需要 10-100 张地图；来自http://hadoop.apache.org/common/docs/r0.18.3/mapred_tutorial.html

map 的数量通常由输入的总大小驱动，即输入文件的总块数。地图的正确并行度似乎是每个节点大约 10-100 个地图，尽管对于非常 cpu-light 的地图任务，它已设置为 300 个地图。任务设置需要一段时间，因此最好至少花费一分钟来执行地图。

对于某些输入格式，您可以设置分割大小，默认情况下，大多数（包括 TextInputFormat）为每个块创建一个映射。所以，如果你有几个不同的文件，你最终会得到更多不完整的 64mb 块，这是对地图的浪费。

处理一个大文件比处理多个文件效率高得多。当必须考虑多个文件时，作业的设置需要更长的时间。 hadoop 的核心实际上是以少量大文件为中心的。此外，HDFS 设置为处理少量大文件，并且您拥有的文件越多，namenode 将占用更多内存以跟踪它们。

【讨论】：