Sto utilizzando la versione corrente di Hadoop ed eseguo alcuni benchmark TestDFSIO (v. 1.8) per confrontare i casi in cui il file system predefinito è HDFS rispetto al file system predefinito è un secchio S3 (utilizzato tramite S3a).In che modo YARN decide di creare quanti contenitori? (Perché la differenza tra S3a e HDFS?)
Durante la lettura 100 x 1 MB file con file system di default come S3a, osservo il numero di contenitori max in UI FILATO Web è inferiore nel caso di HDFS come predefinito e S3a è di circa 4 volte più lento .
Durante la lettura 1000 x 10 KB file con file system di default come S3a, osservo il numero di contenitori max in filato utente web è almeno 10 volte meno rispetto al caso di HDFS come predefinito e S3a è circa 16 volte più lento. (Per esempio 50 secondi di test del tempo di esecuzione con HDFS predefinita, contro 16 minuti di test del tempo di esecuzione con S3a di default.)
Il numero di Mappa Compiti lanciato è come previsto in ogni caso, non c'è alcuna differenza rispetto a quella . Ma perché è YARN che crea almeno 10 volte meno numero di contenitori (ad esempio 117 su HDFS rispetto a 8 su S3a)? In che modo YARN decide di creare il numero di contenitori quando i vcores, la RAM e l'input del lavoro si suddividono e le attività della mappa avviate sono lo stesso; e è diverso il back-end di storage?
Naturalmente potrebbe aspettarsi una differenza di prestazioni tra HDFS rispetto ad Amazon S3 (tramite S3a) quando si eseguono gli stessi lavori di TestDFSIO, quello che sto cercando è capire come YARN sta decidendo il numero di contenitori massimi che lancia durante quei lavori, dove viene modificato solo il file system predefinito, perché al momento, è come quando il file system predefinito è S3a, YARN non utilizza quasi il 90% del parallelismo (cosa che normalmente avviene quando il file system predefinito è HDFS) .
Il cluster è un cluster a 15 nodi, con 1 NameNode, 1 ResourceManager (YARN) e 13 DataNode (nodi worker). Ogni nodo ha 128 GB di RAM e 48 core di CPU. Questo è un cluster di test dedicato: durante le esecuzioni di test di TestDFSIO, nient'altro viene eseguito sul cluster.
Per HDFS, il dfs.blocksize è 256m, ed utilizza 4 HDD (dfs.datanode.data.dir è impostato file:///mnt/hadoopData1,file:///mnt/hadoopData2,file:///mnt/hadoopData3,file:///mnt/hadoopData4).
Per S3a, fs.s3a.block.size è impostato su 268435456, ovvero 256 m, come le dimensioni di blocco predefinite di HDFS.
La directory Hadoop tmp è in uno SSD (impostando hadoop.tmp.dir a /mnt/ssd1/tmp in core-site.xml, e anche l'impostazione mapreduce.cluster.local.dir-/mnt/ssd1/mapred/local in mapred-site.xml)
La differenza di prestazioni (default HDFS, contro di default impostato S3a) è riassunta qui di seguito :
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
Qual è la vostra versione Hadoop? Che backend shuffle stai usando? –
Quali sono le impostazioni di riutilizzo jvm? –
Ancora un'altra domanda che mi è venuta in mente: il tuo lavoro era in esecuzione in modalità "Uber"? –