我有 3 位数 GB 甚至 1 或 2 位数 TB 的数据集。因此，输入文件是一个文件列表，每个文件的大小为 10GB。我在 hadoop 中的 map reduce 作业处理所有这些文件，然后只提供一个输出文件（包含聚合信息）。
我的问题是：
-
从Apache调整Hadoop/mapreduce框架的合适文件大小是多少？我听说较大的文件大小比较小的文件更受欢迎。有什么想法吗？我唯一确定的是Hadoop读取块，默认情况下每个块有64MB。因此，如果文件大小是64MB的乘法器，那就太好了。
-
目前，我的应用程序仅将输出文件写入一个文件。然后文件大小当然是 3 位数千兆位。我想知道如何有效地对文件进行分区。当然，我可以使用一些 unix 工具来完成这项工作。但是，直接在hadoop中执行此操作是否更可取？
感谢您的评论！
附言：我没有压缩文件。输入文件的文件格式为文本/csv。
如果你不压缩文件，那么Hadoop将处理你的大文件（比如10G），并带有许多与文件块大小相关的映射器。
假设您的块大小为 64M，那么您将有 ~160 个映射器处理这个 10G 文件 （160*64 ~= 10G）。根据映射器逻辑的 CPU 密集程度，这可能是可接受的块大小，但如果您发现映射器在亚分钟时间内执行，那么您可能希望增加每个映射器完成的工作（通过将块大小增加到 128、256、512m - 实际大小取决于您打算如何处理数据）。
较大的块大小将减少用于处理 10G 文件的映射器数量。当然，您可以增加 TextInputFormat 使用的最小拆分大小，但这样您很可能会遇到较低的数据局部性，因为映射器可能正在处理 2 个或更多块，这些块可能并非全部驻留在该节点上。
至于输出，这再次取决于您的处理逻辑正在做什么 - 您可以通过引入更多化简器进行分区吗？这将创建更多的输出文件，但这些文件需要什么分区逻辑（默认情况下，它们将由您的键进行哈希分区）
输入文件的大小：
调整此目的的一种方法是查看地图任务的完成速度。 每个地图任务将接受 1 个文件作为输入，如果它们在 30-40 秒内完成，则应考虑增加每个文件的大小，以便每个映射器有更多的工作要做。 这是因为地图任务在执行任何实际工作之前大约需要 30 秒来初始化。
它还取决于群集一次可以运行的映射任务数。 您可以尝试调整文件和块大小，以便利用尽可能多的地图任务。 有关更多想法，请参阅此博客文章：http://www.cloudera.com/blog/2009/12/7-tips-for-improving-mapreduce-performance/
输出文件的大小：
执行此操作的简单方法是指定多个化简器（每个化简器将生成一个输出文件）。 如果要按某个键（例如，年-月）对结果进行分区，则可以将其包含在映射任务的输出键中，它们将被排序到同一个化简器中。 然后，您只需要检查每个文件即可查看它具有哪个年月密钥。
压缩：
我建议您考虑压缩文件。 这样做将使输入文件"更大"，因为每个文件将包含更多数据供单个地图任务操作。 它还将减少您在群集中使用的磁盘量。 如果有的话，它还可能会提高集群上mapreduce的性能，因为读取和移动文件将产生更少的磁盘I/O和网络流量。
此外，压缩映射任务的中间输出（映射任务的输出，然后再转到化简器）。 它将以类似的方式提高性能。 这是通过设置 mapred.compress.map.output=true 来完成的。
Hadoop根据输入分割大小来划分工作。 它将您的总数据大小除以您的分割大小，这就是它确定将发生多少地图作业的方式。 普遍的共识是，每台机器需要 10-100 张地图;与 http://hadoop.apache.org/common/docs/r0.18.3/mapred_tutorial.html 相比
对于某些输入格式，映射的数量通常由输入的总大小（即输入文件的块总数）驱动。映射的正确并行级别似乎是每个节点大约 10-100 个映射，尽管它已经设置为非常 CPU 轻的映射任务 300 个映射。任务设置需要一段时间，因此最好至少需要一分钟才能执行地图。
您可以设置分割大小，默认情况下，大多数（包括文本输入格式）为每个块创建一个地图。因此，如果您有多个不同的文件，您最终会得到更多不完整的 64mb 块，这是对地图的浪费。
处理一个巨型文件比处理多个文件要高效得多。 当作业必须考虑多个文件时，作业的设置需要更长的时间。Hadoop的核心实际上是以少量的大文件为中心。 此外，HDFS被设置为处理少量的大文件，你拥有的文件越多，namenode会吃掉更多的ram，以便跟踪它们。