En MapReduce-applikation behandler dataene i input-splittelser på record-by-record , og at hver post forstås af MapReduce til at være en nøgle / værdi par. Når inddelingsopdelingerne er blevet beregnet, kan mapperopgaverne begynde at behandle dem - det vil sige lige efter, at ressourceadministratorens planlægningsfacilitet tildeler dem deres behandlingsressourcer. (I Hadoop 1 tildeler JobTracker mapper opgaver til specifikke behandlingsspor.)
Selskabsopgaven selv behandler sin indtastningsdeling en post ad gangen - i figuren repræsenteres denne ensomme rekord af nøgle / værdiparret. I tilfælde af vores flydata, når inddelingsfordelingen beregnes (ved hjælp af standardfilbehandlingsmetoden for tekstfiler) antages det, at hver række i tekstfilen er en enkelt post.
For hver post repræsenterer selve rækken af rækken værdien, og byteforskydningen af hver række fra begyndelsen af splittet betragtes som nøglen.
Du kan undre dig over, hvorfor rækkenummeret ikke bruges i stedet for byteforskydningen. Når du mener, at en meget stor tekstfil er opdelt i mange individuelle datablokke, og behandles så mange splitsninger, er rækkens nummer et risikabelt koncept.
Antallet af linjer i hver opdeling varierer, så det ville være umuligt at beregne antallet af rækker forud for den, der blev behandlet. Men med byteforskydningen kan du være præcis, fordi hver blok har et fast antal bytes.
Som en mapper-opgave behandler hver post, genererer den et nyt nøgle / værdipar: Nøglen og værdien her kan være helt anderledes end inputparret. Udgangen af mapper opgaven er den fulde samling af alle disse nøgle / værdi par.
Før den endelige outputfil for hver mapper-opgave er skrevet, fordeles outputen baseret på nøglen og sorteret. Denne partition betyder, at alle værdierne for hver nøgle er grupperet sammen.
I tilfælde af den ret basale prøveapplikation er der kun en enkelt reducer, så alle udgaver af mapper-opgaven er skrevet til en enkelt fil. Men i tilfælde med flere reducere, kan hver mapper-opgave også generere flere outputfiler.
Opdelingen af disse outputfiler er baseret på partitioneringsnøglen. Hvis der for eksempel kun er tre separate partitioneringstaster, der udføres til mapperopgaverne, og du har konfigureret tre reducere til jobbet, vil der være tre mapper-outputfiler. I dette eksempel, hvis en bestemt mapper opgave behandler en input split og det genererer output med to af de tre nøgler, vil der kun være to outputfiler.
Komprimer altid dine mapperopgaver 'outputfiler. Den største fordel her er i præstationsgevinster, fordi at skrive mindre outputfiler minimerer den uundgåelige pris ved overførsel af mapper-udgangen til de noder, hvor reduktionsanordningerne kører.
Standardpartitioneren er mere end tilstrækkelig i de fleste situationer, men nogle gange kan du tilpasse, hvordan dataene partitioneres, før det behandles af reduktionsanordningerne. Du kan f.eks. Ønske, at dataene i dine resultatsæt sorteres efter nøglen og deres værdier - kendt som en sekundær sortering.
For at gøre dette kan du tilsidesætte standardpartitioneren og implementere din egen. Denne proces kræver dog en vis omhu, fordi du vil sikre, at antallet af poster i hver partition er ensartet. (Hvis en reducer skal behandle meget flere data end de andre reduktionsanordninger, venter du på, at dit MapReduce-job er færdigt, mens den enkelt overarbejdede reducer slog igennem det uforholdsmæssigt store datasæt.)
Brug af mellemstore filer med ensartet størrelse, du kan bedre udnytte den parallelisme, der er tilgængelig i MapReduce-behandling.
