HHH*_*HHH 11 hadoop mapreduce hadoop-partitioning
Hadoop是否根据程序中设置的映射器数量拆分数据?也就是说,如果映射器的数量为200(假设Hadoop集群同时允许200个映射器),则拥有大小为500MB的数据集,每个映射器是否给出了2.5 MB的数据?
此外,所有的映射器是否同时运行,或者其中一些可能会串行运行?
Tar*_*riq 25
反过来说.映射器的数量取决于分割的数量.实际上InputFormat,您正在使用的工作是创建拆分.在决定分割数量之前,您不知道映射器的数量.并且,并不总是根据HDFS块大小创建拆分.它完全取决于getSplits()InputFormat方法中的逻辑.
为了更好地理解这一点,假设您使用MR处理存储在MySQL中的数据.由于在这种情况下没有块的概念,因此总是基于HDFS块创建分裂的理论失败.对?那么拆分创建呢?一种可能性是根据MySQL表中的行范围创建拆分(这就是DBInputFormat用于从关系数据库读取数据的输入格式).假设你有100行.然后你可能有5个分裂,每个分为20行.
仅基于FileInputFormat(用于处理存储在文件中的数据的InputFormat)的InputFormats,基于输入文件的总大小(以字节为单位)创建拆分.但是,输入文件的FileSystem块大小被视为输入拆分的上限.如果您的文件小于HDFS块大小,则该文件只能获得1个映射器.如果您想要有一些不同的行为,可以使用mapred.min.split.size.但它又完全取决于您的InputFormat的getSplits().
MR split和HDFS 之间存在根本区别block,人们常常对此感到困惑.块是物理数据,而拆分只是一个逻辑块,它将被送到映射器.拆分不包含输入数据,它只是对数据的引用.什么是拆分?拆分基本上有两件事:a length in bytes和一组storage locations,它们只是主机名字符串.
回到你的问题.Hadoop允许超过200个映射器.话虽如此,仅仅500MB的数据就有200个映射器没有多大意义.永远记住,当你谈论Hadoop时,你正在处理非常庞大的数据.向每个映射器发送仅2.5 MB的数据将是一种过度杀伤力.是的,如果没有空闲的CPU插槽,那么一些映射器可能会在当前映射器完成后运行.但MR框架非常聪明,并尽力避免这种情况.如果存在要处理的数据的机器没有任何空闲的CPU插槽,则数据将被移动到附近的节点,其中有可用的空闲插槽,并进行处理.
HTH
当您将数据输入Hadoop分布式文件系统(HDFS)时,Hadoop会根据块大小(默认为64 MB)拆分数据,并在整个群集中分配块.所以你的500 MB将分成8块.它不依赖于映射器的数量,而是HDFS的属性.
现在,当您运行MapReduce作业时,Hadoop默认为每个块分配1个映射器,因此如果您有8个块,hadoop将运行8个映射任务.
但是,如果明确指定映射器的数量(即200),则每个映射处理的数据大小取决于块的分布以及映射器在哪个节点上运行.实际处理数据的映射器数量取决于您的输入拆分.
在您的情况下,假设500 MB分成8个块,即使您指定了200个映射器,并非所有这些都将处理数据,即使它们已初始化.
小智 1
我刚刚根据你的问题运行了一个示例 MR 程序,这是我的发现
输入:小于块大小的文件。
情况 1:映射器数量=1 结果:启动了 1 个映射任务。每个映射器的输入分割大小(在本例中只有一个)与输入文件大小相同。
情况 2:映射器数量 = 5 结果:启动了 5 个映射任务。每个映射器的输入分割大小是输入文件大小的五分之一。
情况 3:映射器数量 = 10 结果:启动了 10 个映射任务。每个映射器的输入分割大小是输入文件大小的十分之一。
因此,基于上述,对于小于块大小的文件,
分割大小=总输入文件大小/启动的map任务数。
注意:但请记住,不。地图任务的数量是根据输入分割决定的。
| 归档时间: |
|
| 查看次数: |
13284 次 |
| 最近记录: |