我的map reduce作业如下所示：我将前两个块Map到键1，后两个块将Map到键2，依此类推，如图所示：现在，理论上我想把每把钥匙都送到减速机上。但我的问题是：现实中如何选择合适的Map器/还原器数量？看起来我需要#mappers=#hdfs块的数量，还原器的数目是Map器的一半。这是个好办法吗？这个案子的正确选择是什么？
13z8s7eq1#
Partitioning your job into maps and reduces
为任务选择合适的大小可以从根本上改变hadoop的性能。增加任务数会增加框架开销，但会增加负载平衡并降低失败的成本。一个极端是1 map/1 reduce情况，其中没有任何分布。另一个极端是当框架的开销资源耗尽时，使用1000000个Map/1000000个减少。
Number of Maps
Map的数量通常由输入文件中dfs块的数量驱动。尽管这会导致人们调整他们的dfs块大小来调整Map的数量。Map的正确并行级别似乎是10-100个Map/节点，尽管对于非常cpu的光照Map任务，我们已经将其提高到300个左右。任务设置需要一段时间，因此最好至少花一分钟执行Map。实际上，控制Map的数量是很微妙的。mapred.map.tasks参数只是对Map数inputformat的一个提示。默认的inputformat行为是将总字节数拆分为正确的片段数。但是，在默认情况下，输入文件的dfs块大小被视为输入拆分的上限。拆分大小的下限可以通过mapred.min.split.size设置。因此，如果您需要10tb的输入数据和128mb的dfs块，那么您将得到82k个Map，除非mapred.map.tasks更大。最终输入格式决定了Map的数量。也可以使用jobconf的conf.setnummaptasks（int num）手动增加map任务的数量。这可以用来增加Map任务的数量，但不会将该数量设置为低于hadoop通过分割输入数据确定的数量。
Number of Reduces
理想的异径管应为使其最接近的最佳值：块大小的倍数5到15分钟之间的任务时间创建尽可能少的文件除此之外的任何事情都意味着你的减速机很有可能不是很好。有一个巨大的趋势是用户使用一个非常高的值（“更多的并行意味着更快！”）或者是一个非常低的值（“我不想破坏我的命名空间配额！”）。两者都同样危险，导致一个或多个：工作流下一阶段的糟糕性能洗牌导致的糟糕性能糟糕的整体性能，因为您用最终无用的对象使namenode过载没有真正理智的原因而销毁磁盘io由于处理大量的cfif/mfif工作而导致大量网络传输现在，总是有例外和特殊情况。一个特别的例子是，如果遵循这个建议使得工作流中的下一步做了一些可笑的事情，那么我们就需要在上面的一般经验法则中成为一个例外。目前，reduce的数量被输出文件的缓冲区大小限制为大约1000（io.buffer.size2numreduces<<heapsize）。这将在某个点上被修正，但在它被修正之前，它提供了一个相当坚定的上界。reduce任务的数量也可以通过jobconf的conf.setnumreducetasks（int num）以与map任务相同的方式增加。我明白了，我想这会解决你关于reducer数量的困惑，假设你的集群中有100个reduce插槽可用。负载系数为0.95时，所有95个reduce任务将同时启动，因为有足够的reduce插槽可用于所有任务。这意味着没有任务将在队列中等待，直到其中一个任务完成。当reduce任务比较“小”时，即完成得比较快，或者它们或多或少都需要相同的时间时，我建议使用此选项。另一方面，在负载系数为1.75的情况下，100个reduce任务将同时启动，只要reduce插槽可用，其余75个任务将在队列中等待，直到reduce插槽可用为止。这提供了更好的负载平衡，因为如果某些任务比其他任务“更重”，即需要更多的时间，那么它们将不会成为作业的瓶颈，因为其他减少的插槽现在将执行队列中的任务，而不是完成任务并等待。这也减轻了每个reduce任务的负载，因为map输出的数据被扩展到更多的任务。https://github.com/paulhoule/infovore/wiki/choosing-the-number-of-reducers
1条答案
按热度按时间13z8s7eq1#
为任务选择合适的大小可以从根本上改变hadoop的性能。增加任务数会增加框架开销，但会增加负载平衡并降低失败的成本。一个极端是1 map/1 reduce情况，其中没有任何分布。另一个极端是当框架的开销资源耗尽时，使用1000000个Map/1000000个减少。
Map的数量通常由输入文件中dfs块的数量驱动。尽管这会导致人们调整他们的dfs块大小来调整Map的数量。Map的正确并行级别似乎是10-100个Map/节点，尽管对于非常cpu的光照Map任务，我们已经将其提高到300个左右。任务设置需要一段时间，因此最好至少花一分钟执行Map。
实际上，控制Map的数量是很微妙的。mapred.map.tasks参数只是对Map数inputformat的一个提示。默认的inputformat行为是将总字节数拆分为正确的片段数。但是，在默认情况下，输入文件的dfs块大小被视为输入拆分的上限。拆分大小的下限可以通过mapred.min.split.size设置。因此，如果您需要10tb的输入数据和128mb的dfs块，那么您将得到82k个Map，除非mapred.map.tasks更大。最终输入格式决定了Map的数量。
也可以使用jobconf的conf.setnummaptasks（int num）手动增加map任务的数量。这可以用来增加Map任务的数量，但不会将该数量设置为低于hadoop通过分割输入数据确定的数量。
理想的异径管应为使其最接近的最佳值：
块大小的倍数5到15分钟之间的任务时间创建尽可能少的文件
除此之外的任何事情都意味着你的减速机很有可能不是很好。有一个巨大的趋势是用户使用一个非常高的值（“更多的并行意味着更快！”）或者是一个非常低的值（“我不想破坏我的命名空间配额！”）。两者都同样危险，导致一个或多个：
工作流下一阶段的糟糕性能洗牌导致的糟糕性能糟糕的整体性能，因为您用最终无用的对象使namenode过载没有真正理智的原因而销毁磁盘io由于处理大量的cfif/mfif工作而导致大量网络传输
现在，总是有例外和特殊情况。一个特别的例子是，如果遵循这个建议使得工作流中的下一步做了一些可笑的事情，那么我们就需要在上面的一般经验法则中成为一个例外。
目前，reduce的数量被输出文件的缓冲区大小限制为大约1000（io.buffer.size2numreduces<<heapsize）。这将在某个点上被修正，但在它被修正之前，它提供了一个相当坚定的上界。
reduce任务的数量也可以通过jobconf的conf.setnumreducetasks（int num）以与map任务相同的方式增加。
我明白了，我想这会解决你关于reducer数量的困惑，假设你的集群中有100个reduce插槽可用。
负载系数为0.95时，所有95个reduce任务将同时启动，因为有足够的reduce插槽可用于所有任务。这意味着没有任务将在队列中等待，直到其中一个任务完成。当reduce任务比较“小”时，即完成得比较快，或者它们或多或少都需要相同的时间时，我建议使用此选项。
另一方面，在负载系数为1.75的情况下，100个reduce任务将同时启动，只要reduce插槽可用，其余75个任务将在队列中等待，直到reduce插槽可用为止。这提供了更好的负载平衡，因为如果某些任务比其他任务“更重”，即需要更多的时间，那么它们将不会成为作业的瓶颈，因为其他减少的插槽现在将执行队列中的任务，而不是完成任务并等待。这也减轻了每个reduce任务的负载，因为map输出的数据被扩展到更多的任务。
https://github.com/paulhoule/infovore/wiki/choosing-the-number-of-reducers