我正在使用当前版本的Hadoop,并运行一些 TestDFSIO 基准测试(v.1.8)来比较默认文件系统是HDFS与默认文件系统的情况是S3存储桶(通过 S3a 使用)。
当读取默认文件系统为S3a的 100 x 1 MB 文件时,我发现YARN Web UI中的最大容器数量少于默认情况下HDFS的情况,S3a约为慢4倍。
当使用默认文件系统作为S3a读取 1000 x 10 KB 文件时,我发现YARN Web UI中的最大容器数量<至少 10倍比默认情况下HDFS的情况,S3a 慢16倍。 (例如,HDFS默认为50秒的测试执行时间,而S3a默认为测试执行时间 16分钟。)
在每种情况下,启动的地图任务的数量都是预期的,没有任何区别。但是为什么是YARN创建至少 10倍容器数量(例如HDFS上的117个与S3a上的8个相比)?当群集的vcores,RAM和作业的输入分裂以及启动的地图任务是相同时,YARN如何决定创建多少个容器?和只有存储后端不同?
当运行相同的TestDFSIO作业时,期望HDFS与Amazon S3(通过S3a)之间的性能差异当然很好,我所了解的是YARN如何决定它在那些期间启动的最大容器数量作业,只有默认文件系统被更改,因为目前,当默认文件系统是S3a时,YARN几乎不使用90%的并行性(默认文件系统是HDFS时通常会这样做)。
群集是一个15节点的群集,包含1个NameNode,1个ResourceManager(YARN)和13个DataNode(工作节点)。每个节点有128 GB RAM和48核CPU。这是一个专用的测试集群:在TestDFSIO测试运行期间,集群上没有其他任何运行。
对于HDFS,dfs.blocksize
为256m
,它使用4个硬盘(dfs.datanode.data.dir
设置为file:///mnt/hadoopData1,file:///mnt/hadoopData2,file:///mnt/hadoopData3,file:///mnt/hadoopData4
)。
对于S3a,fs.s3a.block.size
设置为268435456
,即256m,与HDFS默认块大小相同。
Hadoop tmp目录位于SSD上(将hadoop.tmp.dir
设置为/mnt/ssd1/tmp
中的core-site.xml
,并将mapreduce.cluster.local.dir
设置为/mnt/ssd1/mapred/local
mapred-site.xml
}})
性能差异(默认HDFS,默认设置为S3a)总结如下:
TestDFSIO v. 1.8 (READ)
fs.default.name # of Files x Size of File Launched Map Tasks Max # of containers observed in YARN Web UI Test exec time sec
============================= ========================= ================== =========================================== ==================
hdfs://hadoop1:9000 100 x 1 MB 100 117 19
hdfs://hadoop1:9000 1000 x 10 KB 1000 117 56
s3a://emre-hadoop-test-bucket 100 x 1 MB 100 60 78
s3a://emre-hadoop-test-bucket 1000 x 10 KB 1000 8 1012
答案 0 :(得分:1)
长话短说,YARN用于决定要创建的容器数量的重要标准之一是基于数据位置。当使用非HDFS文件系统(例如S3a)连接到Amazon S3或其他与S3兼容的对象存储库时,文件系统负责提供有关数据位置的信息,因为在这种情况下,没有数据是节点本地的,每个节点都需要从网络中检索数据,或者从另一个角度看,每个节点都有相同的数据位置。
前一段解释了我在使用S3a文件系统对Amazon S3运行Hadoop MapReduce作业时观察到的容器创建行为。为了解决这个问题,我开始研究补丁,并通过HADOOP-12878跟踪开发。
另见: