Video: FabioJ Kart - Finalizando 2024
En MapReduce-applikasjon behandler dataene i inngangssplittelser på record-by-record , og at hver plate forstås av MapReduce til å være en nøkkel / verdi par. Etter at inngangssplittelsene er beregnet, kan mapperoppgavene begynne å behandle dem - det vil si rett etter at ressursadministratorens planleggingsfasilitet tildeler dem deres behandlingsressurser. (I Hadoop 1 tilordner JobTracker mapperoppgaver til bestemte behandlingsspor.)
Mappen oppgaven selv behandler sin inngangssplitt en plate om gangen - i figuren representeres denne enslige platen av nøkkel / verdi-paret. Når det gjelder flydata, når inngangssplittene beregnes (ved bruk av standardfilbehandlingsmetode for tekstfiler) antas det at hver rad i tekstfilen er en enkelt post.
For hver plate representerer teksten i rækken seg selv verdien, og byteforskyvningen for hver rad fra begynnelsen av splitten anses å være nøkkelen.
Du lurer kanskje på hvorfor radnummeret ikke brukes i stedet for byteforskyvningen. Når du vurderer at en veldig stor tekstfil er oppdelt i mange individuelle datablokker, og behandles så mange deler, er radnummeret et risikabelt konsept.
Antall linjer i hver deling varierer, så det ville være umulig å beregne antall rader som ligger foran den som behandles. Men med byteforskyvningen kan du være presis, fordi hver blokk har et fast antall byte.
Når en mapper oppgave behandler hver plate, genererer den et nytt nøkkel / verdi-par: Nøkkelen og verdien her kan være helt forskjellig fra inngangsparet. Utdataene fra mapper oppgaven er hele samlingen av alle disse nøkkel / verdi parene.
Før den endelige utdatafilen for hver mapperoppgave er skrevet, deles utgangen basert på nøkkelen og sorteres. Denne partisjonen betyr at alle verdiene for hver nøkkel er gruppert sammen.
I tilfelle av den ganske grunnleggende prøveapplikasjonen er det bare en enkelt reduksjon, så all utdata fra mapper oppgaven er skrevet til en enkelt fil. Men i tilfeller med flere reduksjonselementer, kan hver mapperoppgave generere flere utdatafiler også.
Fordelingen av disse utdatafilene er basert på partisjoneringsnøkkelen. Hvis det for eksempel bare er tre forskjellige partisjoneringsnøkler for mapperoppgavene, og du har konfigurert tre reduksjonsverktøy for jobben, vil det være tre mapper-utdatafiler. I dette eksempelet, hvis en bestemt mapper oppgave behandler en inngangssplitt og det genererer utgang med to av de tre tastene, vil det bare være to utdatafiler.
Komprimer alltid mapper oppgavene dine utdatafiler. Den største fordelen her er i ytelsesgevinster, fordi å skrive mindre utdatafiler minimerer den uunngåelige kostnaden ved å overføre mapperutgangen til noder der reduksjonsmidlene kjører.
Standardpartisjoneren er mer enn tilstrekkelig i de fleste situasjoner, men noen ganger kan det være lurt å tilpasse hvordan dataene deles før det behandles av reduksjonsmaskinene. For eksempel vil du kanskje at dataene i resultatsettene skal sorteres etter nøkkelen og deres verdier - kjent som en sekundær sortering.
For å gjøre dette kan du overstyre standardpartisjoneren og implementere din egen. Denne prosessen krever litt omhu, men fordi du vil sørge for at antall poster i hver partisjon er ensartet. (Hvis en reduksjonsprosess skal behandle mye mer data enn de andre reduksjonsmidlene, vil du vente på at MapReduce-jobben er ferdig, mens den enkle overarbeidede reduksjonsmaskinen slog gjennom sitt uforholdsmessig store datasett.)
Bruk mellomliggende filer med jevne mellomrom, du kan bedre dra nytte av parallellismen som er tilgjengelig i MapReduce-prosessering.
