Video: Didactische werkvormen - De eerste gedachte #18 2024
Efter kortfasen og før begyndelsen af Reduce-fasen er en handoff-proces, kendt som shuffle og sortere . Her udarbejdes data fra mapperopgaverne og flyttes til noderne, hvor reduktionsopgaverne bliver kørt. Når mapper-opgaven er færdig, sorteres resultaterne efter nøgle, partitioneret, hvis der er flere reducere, og derefter skrevet til disk.
Du kan se dette koncept i følgende figur, som viser MapReduce-databehandlingsstrømmen og dets interaktion med Hadoop-klyngens fysiske komponenter. (En hurtig note: Data i hukommelsen er repræsenteret af hvide firkanter, og data gemt på disk er repræsenteret af grå firkanter.)
For at fremskynde den samlede MapReduce-proces flyttes dataene øjeblikkeligt til reduktionsopgaverens noder for at undgå en oversvømmelse af netværksaktivitet, når den endelige mapper-opgave afslutter sit arbejde. Denne overførsel sker, mens mapper-opgaven kører, da udgange for hver post - husk - gemmes i hukommelsen af en ventende reduceringsopgave. (Du kan konfigurere om dette sker - eller ikke sker - og også antallet af involverede tråde.)
Husk, at selvom en reduktionsopgave måske har størstedelen af mapper-opgavens output, kan reduktionsopgavens behandling ikke begynde, før alle mapperopgaver er færdige.
For at undgå scenarier, hvor udførelsen af et MapReduce-job er hæmmet af en afbrydende mapper-opgave, der kører på en dårligt fungerende slave node, bruger MapReduce-rammen et koncept kaldet spekulativ udførelse .
Hvis nogle mapper opgaver kører langsommere end hvad der anses for rimeligt, vil Application Master udkoble duplikatopgaver (i Hadoop 1, JobTracker gør dette). Uanset hvilken opgave der er færdig først - duplikatet eller originalen - bliver resultaterne gemt på disk, og den anden opgave er dræbt. Hvis du overvåger dine job tæt og undrer dig over, hvorfor der er flere mapper opgaver, der løber, end du forventer, er dette en sandsynlig årsag.
Udgangen fra mapper-opgaver er ikke skrevet til HDFS, men snarere til lokal disk på slaveknuden, hvor mapper-opgaven blev kørt. Som sådan er det ikke replikeret på tværs af Hadoop-klyngen.
Bortset fra komprimering af output, kan du potentielt øge ydelsen ved at køre en combiner-opgave. Denne enkle taktik, der vises her, involverer en lokal reduktion af output for individuelle mapper opgaver.
I de fleste tilfælde er der ikke behov for ekstra programmering, da du kan fortælle systemet at bruge reduktionsfunktionen. Hvis du ikke bruger din reduceringsfunktion, skal du sikre dig, at combinerfunktionens output er identisk med reduktionsfunktionens funktion.
Det er op til MapReduce-rammen, om combinerfunktionen skal køres en gang, flere gange eller aldrig, så det er kritisk, at combinerens kode sikrer, at de endelige resultater ikke påvirkes af flere kørsler. At køre combiner kan give en præstationsfordel ved at mindske mængden af mellemliggende data, som ellers skulle overføres over netværket.
Dette reducerer også mængden af behandling, som reduktionsopgaverne skal gøre. Du løber en ekstra opgave her, så det er muligt, at enhver præstationsgevinst er ubetydelig eller måske endda resultere i dårligere overordnet præstation. Din kilometertal kan variere, så test det omhyggeligt.
Efter at alle resultaterne af mapperopgaverne er kopieret til reduceropgaverne, knyttes disse filer sammen og sorteres.
