我正在尝试执行以下查询，并且加载数据需要很长时间，因为第二个作业只使用了一个减速器。
INSERT INTO TABLE ddb_table SELECT * FROM data_dump sort by rank desc LIMIT 1000000;
为上述查询创建了两个作业。第一项工作运行得非常快，因为它使用了 80 个映射器和大约 22 个减速器。第二个工作映射器很快，但由于单个减速器，它非常慢。
我尝试使用set mapred.reduce.tasks=35增加减速器数量，但有趣的是，它仅适用于第一份工作，而不是第二份。
为什么使用单个减速器？是因为 sort by 子句吗？如何设置最大减速器？
有更好的方法吗？
我并不积极，但我的直觉是这是因为“限制”，而不是“排序依据”。事实上，“排序依据”显式只会在每个 reducer 中排序，因此您不会得到总排序。
问题在于，如果有多个 reducer，它们的协调程度不够，无法知道何时达到 1000000 条记录。所以要做到limit，就必须只有一个reducer，它维护一个记录数的count，一旦达到limit就停止输出新的。
事实上，即使可以对多个减速器进行“排序”和“限制”，你也可以在不同的运行中获得不同的输出，这取决于哪个减速器运行得最快，所以我不认为你想要什么首先在这里做是有道理的。
这只是在 Hadoop 中使用默认 Partitioner 进行排序的方式。默认分区使用 hashcode mod 数量的 reducer，所以如果你想要 35 个 reducer，你将得到 35 个输出文件，每个文件都经过排序，但范围重叠。例如，您有以字母字符 [a..z] 开头的键：file1 (a1,a2,a15,d3,d5,f6), file2(a3,a5,b1,z3) 等。为了避免重叠键范围，您需要一个 Reducer，或者您需要让您的分区程序更加了解键的性质，例如让您的分区程序将具有相同第一个字符的所有键定向到同一个分区，因此会有多个文件在输出中，但没有一个范围会重叠。例如 file1 (a1,a2,a3,a5,a15), file2(b1),file3(....) file4(d3,d6) 等。当我使用标准 Hadoop 作业或 Apache PIG 时，它适用。