为什么Hadoop被认为是I/O密集型的?

Nit*_*eti 3 hadoop mapreduce

我一直在阅读有关Hadoop Map/Reduce的一些文献,一般主题似乎是:Hadoop Jobs是I/O密集型的(例如:使用Map/Reduce进行排序).

是什么让这些工作I/O密集(鉴于Hadoop将计算推送到数据)?示例:为什么在Hadoop I/O密集型中进行排序?

我的直觉:似乎在地图阶段之后,中间对被发送到reducer.这会导致巨大的I/O吗?

0x0*_*FFF 5

Hadoop用于对大量数据执行计算.您的工作可能受IO(您称之为I/O密集型),CPU和网络资源的限制.在Hadoop使用的经典案例中,您正在对大量输入数据执行本地计算,同时返回相对较小的结果集,这使得您的任务比CPU和网络密集型更加IO密集,但它在很大程度上取决于作业本身.这里有些例子:

  1. IO密集的工作.您在地图方面读取了大量数据,但地图任务的结果并不是那么大.一个示例是计算输入文本中的行数,计算RCfile中某些列的总和,将Hive查询的结果通过具有相对较小基数的列的单个表获取.这意味着你的工作所做的事情主要是阅读数据并对其进行一些简单的处理.
  2. CPU密集型工作.当您需要在地图上执行一些复杂的计算或减少一侧时.例如,您正在进行某种NLP(自然语言处理),如标记化,语音标记,词干等部分.此外,如果您以高压缩率的格式存储数据,数据解压缩可能会成为流程的瓶颈(这里是Facebook的一个例子,他们正在寻找CPU和IO之间的平衡)
  3. 网络密集型.通常,如果您在群集上看到高网络利用率,则意味着有人错过了这一点,并实现了通过网络传输大量数据的作业.在使用wordcount的示例中,假设仅使用mapper和reducer处理此作业中的1PB输入数据,而不使用合并器.这样,在map和reduce任务之间移动的数据量甚至会比输入数据集大,并且所有这些都将通过网络发送.此外,这可能意味着您不使用中间数据压缩(mapred.compress.map.output和mapred.map.output.compression.codec),并且原始地图输出通过网络发送.

您可以参考本指南进行集群的初始调整那么为什么排序是IO密集型的呢?首先,您从磁盘读取数据.接下来,在排序时,映射器生成的数据量与读取的数量相同,意味着它很可能不适合内存并且应该溢出到磁盘.然后它被转移到减速器并再次溢出到磁盘.然后它由reducer处理并再次刷新到磁盘.虽然排序所需的CPU相对较小,特别是如果排序键是一个数字,并且可以很容易地从输入数据中解析.