所以我使用的是MultipleOutputs包中的org.apache.hadoop.mapreduce.lib.output。
我有一个减速器正在连接2个数据源并发出3个不同的输出。
调用了55个减少任务，平均每个任务花费大约6分钟来发送数据。有异常值需要大约11分钟。
所以我观察到，如果我评论实际输出发生的部分，即对mos.write()的调用（多输出），则平均时间减少到几秒，整个作业在大约2分钟内完成。
我确实有很多数据要发出（大约40-50 GB）数据。
在考虑压缩和不考虑压缩的情况下，我可以做些什么来加快速度。
详细信息：我正在使用TextOutputFormat并提供hdfs路径/ uri。
进一步澄清：
我的减速器输入数据很少，但减速器正在进行减少侧连接，因此会发出大量数据。由于异常值减少器大约需要大约11分钟，因此减少减速器的数量会增加这个时间，从而增加我的工作总时间并且不会解决我的目的。
减速器的输入来自2个映射器。 映射器1 - ＆gt;发出大约10,000条记录。 （密钥ID） 映射器2 - ＆gt;发出大约15M的记录。 （密钥ID，密钥Id2，密钥Id3）
在reducer中，我得到属于Key Id的所有内容，按Key Id，KeyId2和KeyId3排序。
所以我知道我有一个迭代器，就像： Mapper1输出然后输出Mapper2。
这里我将Mapper1输出存储在ArrayList中，并开始流式传输Mapper2的输出。
对于我执行的每条Mapper2记录，mos.write(....)
我有条件地将此记录的一部分存储在内存中（在HashSet中）
每次KeyId2更改时，我都会额外执行mos.write(...)
在我的reducer的close方法中，如果我在条件步骤中存储了任何内容，则会发出。所以第三个mos.write(...)
我已经阅读了文章http://blog.cloudera.com/blog/2009/12/7-tips-for-improving-mapreduce-performance/ 如上所述：
提示1：正确配置我的群集是我无法控制的。
提示2：一般使用LZO压缩 - 或压缩。我正在尝试的东西。
提示3：调整映射器和缩减器的数量 - 我的映射器完成得非常快（以秒为单位）可能因为它们几乎是身份映射器。减速器需要一些时间，如上所述（这是我试图减少的时间）因此增加减速器的数量可能会对我有所帮助 - 但随后会出现资源争用，一些减速器将不得不等待。对我来说，这更像是一种实验性的尝试和错误。
Tip4：编写一个组合器。不适用于我的情况（减少边连接）
提示5：使用apt writable - 我现在需要使用Text。所有这三个输出都将进入目录，其中有一个hive架构。后来当我想出如何从多个输出中发出ParquetFormat文件时，我可能会改变这个和表的存储方法。
提示6：重用可写。好的，这是我到目前为止还没有考虑过的事情，但我仍然认为它的磁盘写入花费时间而不是处理或java堆。但无论如何我会再次试一试。
提示7：使用穷人的分析。有点已经完成了，并且发现它实际上是大多数时间采用的mos.write步骤。答案 0 :(得分：0)
<强> DO
1。减少减速机数量。
优化的减速机数量（对于一般的ETL操作）是1个减速机的大约1GB数据。 在这里，您的输入数据（以GB为单位）本身小于减速器的数量。
2。可以完成代码优化。共享代码，请参考http://blog.cloudera.com/blog/2009/12/7-tips-for-improving-mapreduce-performance/进行优化。
3。如果这样做没有帮助，那么请理解您的数据。数据可能会有所偏差。如果你不知道什么是倾斜的，那么倾斜加入猪会有所帮助。