Hadoop用于对大量数据进行计算。您的工作可能受到IO（您称之为I/O密集型）、CPU和网络资源的限制。在Hadoop使用的经典案例中，您对大量输入数据执行本地计算，同时返回相对较小的结果集，这使得您的任务比CPU和网络更需要IO，但这在很大程度上取决于作业本身。以下是一些例子：
我一直在阅读一些关于Hadoop Map/Reduce的文献，总的主题似乎是：Hadoop作业是I/O密集型的（例如：使用Map/Reduse排序）。
是什么让这些工作的I/O密集型（考虑到Hadoop将计算推向数据）？示例：为什么Hadoop I/O中的排序是密集型的？
我的直觉：似乎在映射阶段之后，中间对被发送到减速器。这是造成巨大I/O的原因吗？
- IO密集型工作。你在地图上读了很多数据，但地图任务的结果并没有那么大。一个例子是计算输入文本中的行数，计算RCfile中某列的总和，在具有相对较小基数的列分组的单个表上获得Hive查询的结果。这意味着你的工作主要是读取数据并对其进行一些简单的处理
- CPU密集型作业。当你需要在地图或缩小面上执行一些复杂的计算时。例如，您正在进行某种NLP（自然语言处理），如标记化、部分拼写标记、词干等。此外，如果您以高压缩率的格式存储数据，则数据解压缩可能会成为该过程的瓶颈（以下是Facebook的一个示例，他们在其中寻求CPU和IO之间的平衡）
- 网络密集型。通常，如果您看到集群上的网络利用率很高，这意味着有人错过了要点，并实现了通过网络传输大量数据的作业。在wordcount的例子中，想象一下在这个作业中只使用映射器和reducer而不使用组合器来处理1PB的输入数据。这样，在map和reduce任务之间移动的数据量将比输入数据集还要大，所有这些都将通过网络发送。此外，这可能意味着您不使用中间数据压缩（mapred.compress.map.output和mapred.map.output.compression），并且原始地图输出是通过网络发送的
有关集群的初始调整，您可以参考本指南那么，为什么排序是IO密集型的呢？首先，您从磁盘中读取数据。接下来，在排序中，映射器产生的数据量与读取的数据量相同，这意味着它很可能无法放入内存，应该溢出到磁盘。然后，它被转移到减速器中，并再次扩散到磁盘上。然后它被减速器处理，再次被冲洗到磁盘上。而排序所需的CPU相对较小，尤其是如果排序键是一个数字，并且可以很容易地从输入数据中解析出来。
在Hadoop的MapReduce框架中，每次MapReduce操作后，结果都会写回磁盘，这可能是I/O密集型的。Apache Spark对此进行了改进，它能够在内存中存储或缓存足够小的中间结果，并将转换优化为在RDD上执行的DAG。请参阅Apache Spark与Hadoop方法有何不同？
Hadoop和map reduce的性能有限。两者性能有限的原因是生成大量输入和输出文件的文件系统。它降低了两者的计算速度。map reduce的结果可以存储在内存中，这样可以加快计算速度。