我有 3 位数 GB 甚至 1 或 2 位数 TB 的数据集。因此，输入文件是一个文件列表，每个文件大小为 10GB。我在 hadoop 中的 map reduce 作业处理所有这些文件，然后只提供一个输出文件（带有汇总信息）。
我的问题是：
从 Apache 调整 hadoop/mapreduce 框架的合适文件大小是多少？我听说大文件比小文件更受欢迎。有什么想法吗？我唯一确定的是 hadoop 读取块，每个块默认为 64MB。因此，如果文件大小是 64MB 的乘数，那就太好了。
目前，我的应用程序只将输出文件写入一个文件。文件大小当然是 3 位千兆位。我想知道如何有效地对文件进行分区。当然，我可以只使用一些 unix 工具来完成这项工作。但是最好直接在hadoop中执行此操作吗？
谢谢你的评论！
PS：我没有压缩文件。输入文件的文件格式为 text/csv。
如果您不压缩文件，那么 hadoop 将处理您的大文件（比如 10G），其中包含许多与文件块大小相关的映射器。
假设您的块大小为 64M，那么您将有 ~160 个映射器处理这个 10G 文件（160*64 ~= 10G）。根据您的映射器逻辑的 CPU 密集程度，这可能是一个可接受的块大小，但如果您发现您的映射器在亚分钟时间内执行，那么您可能希望增加每个映射器完成的工作（通过增加块大小到 128、256、512m - 实际大小取决于您打算如何处理数据）。
较大的块大小将减少用于处理 10G 文件的映射器数量。当然，您可以增加 TextInputFormat 使用的最小拆分大小，但是您很可能会遇到较低的数据局部性，因为映射器可能正在处理 2 个或更多块，这些块可能并不都驻留在该节点上。
至于输出，这又取决于你的处理逻辑在做什么——你能通过引入更多的 reducer 来进行分区吗？这将创建更多输出文件，但是您需要对这些文件进行哪些分区逻辑（默认情况下，它们将由您的密钥进行哈希分区）
输入文件的大小：
调整它的一种方法是查看您的地图任务完成的速度。每个映射任务将接收 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。
Hadoop 根据输入拆分大小划分工作。它将您的总数据大小除以您的拆分大小，这就是它确定将发生多少地图作业的方式。一般的共识是每台机器需要 10-100 张地图；来自http://hadoop.apache.org/common/docs/r0.18.3/mapred_tutorial.html
映射的数量通常由输入的总大小驱动，即输入文件的总块数。地图的正确并行度似乎是每个节点大约 10-100 个地图，尽管对于非常 cpu-light 的地图任务，它已设置为 300 个地图。任务设置需要一段时间，因此最好至少花费一分钟来执行地图。
使用某些输入格式，您可以设置拆分大小，默认情况下，大多数（包括 TextInputFormat）为每个块创建一个映射。所以，如果你有几个不同的文件，你最终会得到更多不完整的 64mb 块，这是对地图的浪费。
处理一个巨大的文件比处理多个文件要高效得多。当必须考虑多个文件时，作业的设置需要更长的时间。hadoop 的核心实际上是以少量大文件为中心的。此外，HDFS 设置为处理少量大文件，并且您拥有的文件越多，namenode 将占用更多内存以跟踪它们。