我有一个MapReduce作业，它由一个包含几行记录的单个输入文件组成。处理每条记录需要相当长的时间。因此，我的输入文件，尽管其大小可能远小于HDFS块大小，但在单个节点上执行时将花费大量时间。
如何告诉Hadoop有效地在节点之间平均分配输入文件？这样，即使输入文件很小，它仍然被分割成几个并行执行的任务。
此外，我们可以告诉hadoop将文件拆分为N个任务吗？其中N是可用节点的数量？
谢谢！
编辑：为了更清楚，我想做的事情如下。我有很多大文件。我有一个外部程序，它将处理每个文件。每个文件都需要花费大量的时间来处理。
因此，我将这些文件的文件名存储在一个输入文件中，然后我希望Hadoop将其平均分割。然后在映射器中，我将ID对应的文件复制到本地机器并调用程序。
您可以为您的工作设置映射器和还原器任务的数量，如下面的
conf.setNumMapTasks(10);
conf.setNumReduceTasks(5);
您也可以使用mapred.max.split.size属性根据需要更改输入拆分大小。
这个fair amount of time多少钱？看来您误解了Hadoop。启动MR作业时会有一些初始延迟。这是一个must和unavoidable，无论您的数据是1KB还是1TB。这种延迟是由于初始化、拆分、地图创建等原因造成的。这并不是因为你的文件有几个记录。处理far less than HDFS block size大小的文件不会给你带来任何好处。坦率地说，Hadoop的使用效率很低。
你不需要告诉Hadoop任何事情。该平台足够智能，可以拆分文件以实现最大效率。如果您有一个小于块的文件，并且仍在对其进行拆分，则会进一步降低性能。
您可以告诉Hadoop将文件拆分为N部分，但这并不简单。您必须扩展API并编写自己的自定义InputFormat来实现这一点，因为拆分输入是InputFormat的职责。
但在做这些之前，我建议您阅读更多关于Hadoop的内容。此外，请浏览以下帖子：http://blog.cloudera.com/blog/2009/02/the-small-files-problem/
回复您的最后一条评论：
如果我理解正确，您将使用MR来拆分包含"输入文件名"的文件，并将该文件复制到本地FS。你真的从这种方法中获得了什么主要优势吗？我的意思是，当与HDFS这样的分布式存储一起使用时，MR显示了它的强大功能。此外，当你使用MR复制那个大文件时，你会失去数据排序，最终可能会得到错误的结果。IMHO，您最好将这些文件保存在本地FS中，并使用简单的Java程序拆分包含名称的文件。我认为使用Hadoop just as a store没有任何意义。