我们知道，在 hadoop 的复制阶段，每个 reduce worker 进程从所有 mapper 节点读取数据，并对已经排序的数据执行合并（在 mapper 端的内存排序期间进行排序）和研究他们的密钥份额和价值。
现在，我们也知道所有对应于特定数据的数据都只会发送到一个 reducer。
我的问题是：如何将数据拆分传输到减速器，即分区大小是如何决定的，以及它是由什么过程决定的，因为数据是使用拉机制而不是推机制传输的。这里要解决的一个有趣的挑战是确定数据的总体大小，因为数据驻留在多个节点上（我猜作业跟踪器/主进程可能知道所有节点的数据大小和位置，但我也不确定）。
如果数据高度倾斜并且大部分数据属于有 10 个或更多 reducer 的单个 key，这不会在并行处理方面造成性能损失。在这种情况下，只有一个 reducer 进程会以顺序方式处理大部分数据。 这种情况是否在 Hadoop 中处理？如果是，怎么做？
【问题讨论】：
标签： sorting hadoop mapreduce shuffle reduce
如何将数据拆分传输到reducer，即分区大小是如何决定的，以及在使用拉机制而不是推机制传输数据时，它是由什么进程决定的。这里要解决的一个有趣的挑战是确定数据的总体大小，因为数据驻留在多个节点上（我猜作业跟踪器/主进程可能知道所有节点的数据大小和位置，但我也不确定）。
将数据划分为分区由 Partitioner 抽象类中的 getPartition(KEY k, VALUE v, int numOfReducers) 内部编写的逻辑控制。默认的 Hadoop 分区器是 HashPartitioner。行为是利用键的 Object.hashCode() 方法并对 numOfPartitions 执行模运算。如果您发现 HashPartitioner 在您的情况下效率不高，您可以编写您的 Partitioner。
当地图任务成功完成时，它们会将状态更新通知其父 TaskTracker，而后者又会通知 JobTracker。这些通知通过心跳通信机制传输。这就是一切保持同步的方式。
如果数据高度倾斜并且大部分数据属于一个有 10 个或更多 reducer 的单个 key，这不会在并行处理方面造成性能损失。在这种情况下，只有一个 reducer 进程会以顺序方式处理大部分数据。这种情况是否在 Hadoop 中处理？如果是，如何？
是的。是真的。 MapReduce 框架提供了不同类型的 Partitioner，您可以根据需要选择：
如果您仍然不满意，您可以实现自己的逻辑。如果您需要有关如何编写自定义分区程序的帮助，请参阅 this。
HTH
附： : 你的第一个问题的第二部分我不太明白。如果答案不清楚或者您需要进一步澄清，请告诉我。
【讨论】：