Video: Thorium. 2024
Etter kartfasen og før begynnelsen av Reduce-fasen er en handoff-prosess, kjent som shuffle og sort . Her fremstilles data fra mapperoppgaver og flyttes til noder der reduksjonsoppgaver vil bli kjørt. Når mapper oppgaven er fullført, blir resultatene sortert etter nøkkel, partisjonert hvis det er flere reduksjonsverktøy, og deretter skrevet til disk.
Du kan se dette konseptet i følgende figur, som viser MapReduce-databehandlingsflyten og samspillet med de fysiske komponentene i Hadoop-klyngen. (En rask notat: Data i minnet representeres av hvite firkanter, og data lagret på disk er representert av grå firkanter.)
For å øke hastigheten på den generelle MapReduce-prosessen, flyttes dataene øyeblikkelig til reduksjonsoppgaverens noder for å unngå en flom av nettverksaktivitet når den endelige mapperoppgaven fullfører sitt arbeid. Denne overføringen skjer mens mapper-oppgaven kjører, da utgangene for hver plate - husk - lagres i minnet av en ventende reduksjonsoppgave. (Du kan konfigurere om dette skjer - eller ikke skjer - og også antall tråder involvert.)
Husk at selv om en reduksjonsoppgave kan ha størsteparten av mapperoppgaveens utgang, kan oppgavens behandling ikke starte før alle mapperoppgaver er ferdig.
For å unngå scenarier der ytelsen til en MapReduce-jobb hindres av en svingende mapperoppgave som kjører på en dårlig slaver node, bruker MapReduce-rammen et konsept som heter spekulativ utførelse .
Hvis noen mapperoppgaver kjører langsommere enn det som anses rimelig, vil Application Master gjore dupliserte oppgaver (i Hadoop 1, gjør JobTracker dette). Uansett hvilken oppgave først ferdig - duplikatet eller originalen - blir resultatene lagret på disk, og den andre oppgaven blir drept. Hvis du overvåker jobbene dine nøye og lurer på hvorfor det er flere mapperoppgaver som kjører enn du forventer, er dette en sannsynlig grunn.
Utgangen fra mapper oppgavene er ikke skrevet til HDFS, men heller til lokal disk på slave node der mapper oppgaven ble kjørt. Som sådan er det ikke replisert over Hadoop-klyngen.
Bortsett fra å komprimere utgangen, kan du potensielt øke ytelsen ved å kjøre en kombinatoroppgave. Denne enkle taktikken, som vises her, innebærer å utføre en lokal reduksjon av utdataene for individuelle mapper-oppgaver.
I de fleste tilfeller er det ikke nødvendig med ekstra programmering, da du kan fortelle at systemet bruker reduksjonsfunksjonen. Hvis du ikke bruker reduksjonsfunksjonen din, må du sørge for at kombinasjonsfunksjonens utgang er identisk med reduksjonsfunksjonen.
Det er opp til MapReduce-rammeverket om kombinasjonsfunksjonen må kjøres en gang, flere ganger eller aldri, så det er kritisk at kombinatorens kode sikrer at de endelige resultatene ikke påvirkes av flere løp. Kjører kombinatoren kan gi en ytelsesfordel ved å redusere mengden mellomliggende data som ellers måtte overføres over nettverket.
Dette reduserer også mengden behandling som reduksjonsoppgaver skulle trenge. Du kjører en ekstra oppgave her, så det er mulig at en ytelsesgevinst er ubetydelig eller kan til og med resultere i dårligere ytelse. Kilometertrykket kan variere, så test dette nøye.
Etter at alle resultatene av mapper oppgavene er kopiert til reduksjonsoppgaver nodene, blir disse filene slått sammen og sortert.
