我仍然试图获得何时使用Hadoop组合器类的直觉（我看过几篇文章，但它们对我的情况没有特别帮助）。
我的问题是，当组合器的值属于 Text 类时，使用组合器类是否合适？例如，假设我们有来自映射器的以下输出：
fruit apple
fruit orange
fruit banana
...
veggie carrot
veggie celery
...
我们可以在这里应用一个组合器类吗：
fruit apple orange banana
...
veggie carrot celery
...
甚至在它到达减速器之前？
合路器通常适用于对数据执行某种形式的聚合、最小值、最大值等操作的问题 - 这些值可以在合并器中计算映射输出，然后在化简器中再次计算所有组合输出。这很有用，因为这意味着您不会在映射器和化简器之间通过网络传输所有数据。
现在没有理由不能引入一个组合器来累积为每个键观察到的值的列表（我假设这就是您的示例显示的），但有些事情会使它更加棘手。
如果必须从映射器输出<Text, Text>对，并在化简器中使用<Text, Text>，则组合器可以轻松地将值列表连接在一起，并将其输出为文本值。现在在你的化简器中，你可以做同样的事情，将所有值连接在一起，形成一个大的输出。
如果要对输出列表进行排序和重复数据删除，您可能会遇到问题 - 因为组合器/化简器逻辑需要将 Text 对象标记回单词，对列表进行排序和重复，然后重建单词列表。
直接回答你的问题 - 什么时候合适，好吧，我可以想到一些例子：
- 如果要查找与每个键关联的字典编纂最小值或最大值
- 每个键有数百万个值，并且希望"随机"采样一小部分值
当存在使用交换或关联方法的情况时，使用组合器类。交换示例：
abc=cba 在组合任务执行期间 （ab=d），c，然后将 d，c 的值发送到化简器。现在化简器只需要执行一个任务而不是两个任务，即ab = dDC 以获得最终答案。如果使用组合器只需要做dc。
同样，对于关联 （a+b）+c = a+（b+c）关联（分组）和交换（四处移动）结果不会因您的乘法或加法方式而异。主要合并器用于服从关联和交换的结构化数据。
合路器的优点：
- 它减少了Map和化简器之间的网络I/O
- 它减少了缩减器中的磁盘 I/O，因为执行的一部分发生在合路器中。