Hvad er MapReduce i Hadoop? ArchiTekstur og diagram

⚡ Smart opsummering

MapReduce er Hadoop-programmeringsmodellen, der omdanner et stort datasæt til et lille resultat ved at køre en map-funktion over hver inputopdeling og derefter en reduce-funktion over de grupperede mellemværdier.

  • 🔘 Fire faser: Hvert job kører som opdeling, kortlægningping, blandning og reduktion, med nøgle-værdi-par, der flyder mellem hvert trin.
  • ☑️ Udarbejdet eksempel: Tre tekstlinjer bliver til syv ord, der viser præcis, hvad hver fase bidrager med.
  • ✅ Opdelt størrelse: Én kortopgave kører pr. inputopdeling, og opdelingsstørrelsen matcher normalt HDFS-blokstørrelsen.
  • 🧪 Mellemliggende data: Kortoutput skrives til en lokal disk i stedet for HDFS, fordi replikering af engangsdata er spild af data.
  • 🛠️ Samordning: Et arbejdeTracker planlægger arbejde og opgaverTracPatienter rapporterer fremskridt gennem periodiske hjerteslagssignaler.
  • ⚠️ Versionsnotat: YARN erstattede dette par med en ResourceManager, NodeManagers og en ApplicationMaster per job fra Hadoop 2.x.

MapReduce-arkitektur i Hadoop forklaret med et eksempel

Hvad er MapReduce i Hadoop?

MapReduce er et softwareframework og en programmeringsmodel, der bruges til at behandle enorme mængder data. MapReduce-programmer fungerer i to faser, nemlig Map og Reduce. Map-opgaver omhandler opdeling og kortlægning.ping af data, mens Reducer opgaver blandes og reducer dataene.

Hadoop er i stand til at køre MapReduce-programmer skrevet på forskellige sprog: Java, Rubin, Pythonog C++MapReduce-programmer er parallelle af natur, så de er meget nyttige til at udføre storstilet dataanalyse ved hjælp af flere maskiner i klyngen.

Inputtet til hver fase er nøgle-værdi-par. Derudover skal hver programmør specificere to funktioner: en map-funktion og en reduce-funktion.

KortReducer Architecture i Big Data forklaret med eksempel

Hele processen gennemgår fire udførelsesfaser, nemlig opdeling, kortlægningping, blandning og reduktion.

I denne MapReduce-vejledning vil vi forstå det med et MapReduce-eksempel.

Forestil dig at du har følgende inputdata til din MapReduce i Big data program:

Welcome to Hadoop Class
Hadoop is good
Hadoop is bad

Diagrammet nedenfor tracfører disse tre linjer gennem hver fase, fra inputopdelingerne til venstre til de endelige ordtællinger til højre.

MapReduce-arkitekturdiagram tractre inputlinjer gennem opdeling, kortlægningping, blande og reducere

Det endelige output af MapReduce-opgaven er

dårlig 1
Klasse 1
godt 1
Hadoop 3
is 2
til 1
Velkommen! 1

Dataene gennemgår følgende faser i MapReduce i Big Data.

Inputopdelinger

Input til et MapReduce-job i Big Data er opdelt i dele med fast størrelse kaldet inputopdelinger. En inputopdeling er en del af inputtet, der forbruges af et enkelt kort.

Kortping

Dette er den allerførste fase i udførelsen af ​​et MapReduce-program. I denne fase sendes data i hver opdeling til et kort.ping funktion til at producere outputværdier. I vores eksempel er opgaven med kortetping Fasen er at tælle antallet af forekomster af hvert ord fra inputopdelingerne (flere detaljer om inputopdelinger findes nedenfor) og udarbejde en liste i form af .

shuffling

Denne fase forbruger outputtet fra kortetping fase. Dens opgave er at konsolidere de relevante poster fra kortetping faseoutput. I vores eksempel er de samme ord sat sammen sammen med deres respektive frekvens.

Reduktion

I denne fase aggregeres outputværdier fra blandefasen. Denne fase kombinerer værdier fra blandefasen og returnerer en enkelt outputværdi. Kort sagt opsummerer denne fase det komplette datasæt.

I vores eksempel aggregerer denne fase værdierne fra blandefasen, dvs. den beregner det samlede antal forekomster af hvert ord.

KortReducer Architecture forklaret i detaljer

Punkterne nedenfor forklarer, hvordan opdelinger, kortlægningsopgaver og reduktionsopgaver rent faktisk placeres og gemmes på tværs af klyngen.

  • Der oprettes én kortopgave for hver opdeling, som derefter udfører kortfunktionen for hver post i opdelingen.
  • Det er altid fordelagtigt at have flere opdelinger, fordi den tid, det tager at behandle en opdeling, er kort sammenlignet med den tid, det tager at behandle hele inputtet. Når opdelingerne er mindre, er behandlingen bedre belastningsafbalanceret, da opdelingerne behandles parallelt.
  • Det er dog heller ikke ønskeligt at have for små opdelinger. Når opdelingerne er for små, begynder overheaden ved at administrere opdelingerne og oprette kortopgaver at dominere den samlede jobudførelsestid.
  • For de fleste job er det bedre at gøre splittens størrelse lig med størrelsen af ​​en HDFS blok, som som standard er 128 MB fra Hadoop 2.x og fremefter (den var 64 MB i Hadoop 1.x) og styres af dfs.blocksize ejendom.
  • Udførelse af kortopgaver resulterer i at output skrives til en lokal disk på den respektive node og ikke til HDFS.
  • Grunden til at vælge lokal disk frem for HDFS er at undgå den replikering, der finder sted under en HDFS-lagringsoperation.
  • Kortoutput er mellemoutput, som behandles ved at reducere opgaver for at producere det endelige output.
  • Når jobbet er færdigt, kan kortoutputtet smides væk. Så at gemme det i HDFS med replikering bliver overkill.
  • I tilfælde af knudefejl, før kortoutputtet forbruges af reduktionsopgaven, kører Hadoop kortopgaven igen på en anden node og genskaber kortoutputtet.
  • Reduce-opgaver fungerer ikke ud fra konceptet om datalokalitet. Output fra hver kortopgave sendes til reduce-opgaven. Kortoutput overføres til den maskine, hvor reduce-opgaven kører.
  • På denne maskine flettes outputtet og sendes derefter til den brugerdefinerede reduktionsfunktion.
  • I modsætning til map-outputtet gemmes reduce-outputtet i HDFS (den første replika gemmes på den lokale node, og andre replikaer gemmes på off-rack-noder). Så skrivning af reduce-outputtet forbruger netværksbåndbredde, men kun så meget som en normal HDFS-skrivepipeline bruger.

Hvordan fungerer MapReduce Organizes?

I denne MapReduce-vejledning vil vi lære, hvordan MapReduce fungerer.

Hadoop opdeler jobbet i opgaver. Der er to typer opgaver:

  1. Kortopgaver (Opdelinger og kort)ping)
  2. Reducer opgaver (omrokering, reduktion)

Den komplette udførelsesproces, dvs. udførelsen af ​​både Kort- og Reducér-opgaverne, styres af to typer enheder kaldet:

  1. JobTracker: fungerer som en mester og er ansvarlig for den komplette udførelse af et indsendt job.
  2. Flere opgaverTrackers: opfører sig som slaver, hvor hver af dem udfører en del af jobbet.

For hvert job, der indsendes til udførelse i systemet, er der ét jobTracker, der ligger på NameNode, og der er flere opgaverTrackers, der ligger på DataNodes.

Bemærk: jobbetTracker og opgaveTracker-parret tilhører MapReduce version 1 (Hadoop 1.x). Fra Hadoop 2.x og fremefter opdeler YARN disse opgaver mellem en klyngeomfattende ResourceManager, en NodeManager på hver node og én ApplicationMaster pr. job, selvom selve map-, shuffle- og reduce-faserne er uændrede.

Diagrammet nedenfor viser, hvordan et indsendt job er opdelt i opgaver og tracked på tværs af klyngen.

Diagram, der viser et job opdelt i kort og reduceret opgaver tracked af JobbetTracker og opgaveTrackirsebær

  • Et job er opdelt i flere opgaver, som derefter køres på flere dataknuder i en klynge.
  • Det er jobbets ansvar tracker til at koordinere aktiviteten ved at planlægge opgaver til at køre på forskellige dataknuder.
  • Udførelsen af ​​en individuel opgave varetages derefter af opgaven tracker, som findes på hver datanude, der udfører en del af jobbet.
  • Opgaven tracarbejdsgiverens ansvar er at sende statusrapporten til arbejdsgiveren tracker.
  • Derudover er opgaven tracker sender periodisk et 'hjerteslag'-signal til JobTracfor at underrette den om systemets aktuelle tilstand.
  • Således jobbet tracker holder track af den samlede status for hvert job. I tilfælde af opgavefejl, jobbet tracker kan omplanlægge den til en anden opgave tracker.

Ofte Stillede Spørgsmål

YARN gjorde det, fra Hadoop 2.x og fremefter. En klyngeomfattende ResourceManager håndterer planlægning, en NodeManager kører på hver node, og én ApplicationMaster pr. job. tracudfører sine opgaver. Kortlægnings- og reduktionsfaserne er uændrede.

Modeller, der er trænet på tidligere jobhistorik, forudsiger kørselstid, anbefaler opdelte størrelser og reduceringsantal og registrerer skævhed tidligt. De overvåger også tællerværdier og markerer usædvanligt langsomme eller fejlende job, før en kørsel afsluttes.

Copilot håndterer scaffoldingen godt: mapper- og reducer-signaturer, generiske applikationer, import og driverkonfigurationskald. Skemabeslutninger, såsom hvilket felt der er gruppenping nøgle, har stadig brug for en udvikler, der kender dataene.

Et almindeligt udgangspunkt er en smule under antallet af tilgængelige reduce-slots, så hver reducer kører i én bølge. For få skaber lange haler; for mange producerer mange små outputfiler.

En combiner er en valgfri mini-reducer, der kører på kortoutput, før den krydser netværket. Den reducerer shuffle-trafik kraftigt, men den må kun bruges, når reduce-operationen er både associativ og kommutativ.

Spark gemmer mellemresultater i hukommelsen og udtrykker et job som en énrettet graf af stadier, hvorimod MapReduce skriver mellemliggende output til disk mellem faser. Spark er derfor langt hurtigere til iterativt arbejde.

Partitioneringsværktøjet bestemmer, hvilken reducer der modtager hver mellemliggende nøgle, og hasher som standard nøglen modulo efter reducerantallet. En brugerdefineret hash skrives, når den hash efterlader en enkelt reducer overbelastet.

Hadoop opretter én kortopgave pr. inputopdeling, og en opdeling er et byteinterval snarere end en hel fil. Én stor fil giver mange opdelinger; mange små filer giver bittesmå, ineffektive kortopgaver.

Opsummer dette indlæg med: