Oversigt over Hadoop 2.0 Cluster Architecture Federation

Hadoop 2.0 Cluster Architecture Federation

Introduktion:

I denne blog dykker jeg dybt ned i Hadoop 2.0 Cluster Architecture Federation. Apache Hadoop har udviklet sig meget siden frigivelsen af ​​Apache Hadoop 1.x. Som du ved fra min tidligere blog, at følger Master / Slave Topology, hvor NameNode fungerer som en master-dæmon og er ansvarlig for styring af andre slavernoder kaldet DataNodes. I dette økosystem bliver denne enkelt Master Daemon eller NameNode en flaskehals, og tværtimod skal virksomheder have NameNode, som er meget tilgængelig. Netop denne grund blev grundlaget for HDFS Federation Architecture and HA (høj tilgængelighed) arkitektur .

De emner, jeg har dækket i denne blog, er som følger:

java til magt af

• Den nuværende HDFS-arkitektur
• Begrænsninger i den nuværende HDFS-arkitektur
• HDFS Federation Architecture

Oversigt over nuværende HDFS-arkitektur:

Som du kan se i figuren ovenfor, har den nuværende HDFS to lag:

• HDFS Navneområde (NS): Dette lag er ansvarlig for styring af mapper, filer og blokke. Det giver alle filsystemhandlinger relateret til Navneområde som at oprette, slette eller ændre filerne eller filmapperne.
• Opbevaringslag: Den består af to grundlæggende komponenter.
  1. Blokering : Den udfører følgende handlinger:
     • Kontrollerer periodisk hjerterytme af DataNodes, og det administrerer DataNode-medlemskab til klyngen.
     • Administrerer blokrapporterne og opretholder blokplaceringen.
     • Understøtter blokoperationer som oprettelse, ændring, sletning og tildeling af blokplacering.
     • Opretholder replikationsfaktor konsistent i hele klyngen.

2. Fysisk opbevaring : Det styres af DataNodes, som er ansvarlige for lagring af data og derved giver læse- / skriveadgang til de data, der er gemt i HDFS.

Så den nuværende HDFS-arkitektur giver dig mulighed for at have et enkelt navneområde til en klynge. I denne arkitektur er en enkelt NameNode ansvarlig for styring af navneområdet. Denne arkitektur er meget praktisk og nem at implementere. Det giver også tilstrækkelig kapacitet til at imødekomme behovene i den lille produktionsklynge.

Begrænsninger af nuværende HDFS:

Som tidligere diskuteret var den nuværende HDFS tilstrækkelig til behovene og brugssagerne for en lille produktionsklynge. Men store organisationer som Yahoo, Facebook fandt nogle begrænsninger, da HDFS-klyngen voksede eksponentielt. Lad os se hurtigt på nogle af begrænsningerne:

1. Navneområdet er ikke skalerbar ligesom DataNodes. Derfor kan vi kun have det antal DataNodes i klyngen, som en enkelt NameNode kan håndtere.
2. De to lag, dvs. navnepladslag og lagerlag er tæt koblet hvilket gør den alternative implementering af NameNode meget vanskelig.
3. Ydeevnen for hele Hadoop-systemet afhænger af kapacitet af NameNode. Derfor afhænger hele ydelsen af ​​alle HDFS-operationer af, hvor mange opgaver NameNode kan håndtere på et bestemt tidspunkt.
4. NameNode gemmer hele navneområdet i RAM for hurtig adgang. Dette fører til begrænsninger med hensyn til hukommelsesstørrelse dvs. antallet af namespace-objekter (filer og blokke), som en enkelt namespace-server kan klare.
5. Mange af de organisationer (leverandør), der har HDFS-implementering, tillader flere organisationer (lejer) at bruge deres klyngenavne. Så der er ingen adskillelse af navneområdet, og derfor er der ingen isolation blandt lejerorganisationer, der bruger klyngen.

HDFS Federation Architecture:

• I HDFS Federation Architecture har vi vandret skalerbarhed i navneservice. Derfor har vi flere navnekoder, som er sammensat, dvs. uafhængige af hinanden.
• DataNodes er til stede i bunden, dvs. underliggende lagerlag.
• Hver DataNode registreres med alle NameNodes i klyngen.
• DataNodes sender periodiske hjerterytme, blokerer rapporter og håndterer kommandoer fra NameNodes.

Den billedlige gengivelse af HDFS Federation Architecture er vist nedenfor:

Før jeg går videre, skal jeg kort tale om ovenstående arkitektoniske billede:

• Der er flere navneområder (NS1, NS2,…, NSn), og hver af dem administreres af dens respektive NameNode.
• Hvert navneområde har sin egen blokpool (NS1 har pool 1, NSk har pool k og så videre).
• Som vist på billedet lagres blokke fra pool 1 (himmelblå) på DataNode 1, DataNode 2 og så videre. Tilsvarende vil alle blokke fra hver blokpulje være på alle DataNodes.

Lad os nu forstå komponenterne i HDFS Federation Architecture i detaljer:

Bloker pool:

Block pool er intet andet end sæt blokke, der tilhører et specifikt navneområde. Så vi har en samling af blokpool, hvor hver blokpool styres uafhængigt af den anden. Denne uafhængighed, hvor hver blokpulje styres uafhængigt, tillader navneområdet at oprette blok-id'er til nye blokke uden koordination med andre navneområder. Datablokkene til stede i al blokpuljen er gemt i alle DataNodes. Dybest set giver blokpuljen en abstraktion, således at datablokkene, der befinder sig i DataNodes (som i Single Namespace Architecture), kan grupperes svarende til et bestemt navneområde.

Navneområde volumen:

Navneområdevolumen er intet andet end navneområde sammen med dets blokpulje. Derfor har vi i HDFS Federation flere navneområdevolumener. Det er en selvstændig styringsenhed, dvs. hvert navneområdevolumen kan fungere uafhængigt. Hvis et NameNode eller navneområde slettes, slettes den tilsvarende blokpulje, der findes på DataNodes.

Demo On Hadoop 2.0 Cluster Architecture Federation | Edureka

Nu antager jeg, at du har en ret god idé om HDFS Federation Architecture. Det er mere et teoretisk koncept, og folk bruger det generelt ikke i et praktisk produktionssystem. Der er nogle implementeringsproblemer med HDFS Federation, der gør det vanskeligt at implementere det. Derfor er den HA (høj tilgængelighed) arkitektur foretrækkes til at løse problemet med et enkelt punkt i svigt. Jeg har dækket HDFS HA-arkitektur i min næste blog.

Nu hvor du har forstået Hadoop HDFS Federation Architecture, skal du tjekke af Edureka, et pålideligt online læringsfirma med et netværk på mere end 250.000 tilfredse elever spredt over hele kloden. Edureka Big Data Hadoop-certificeringskursus hjælper elever med at blive eksperter i HDFS, Garn, MapReduce, Pig, Hive, HBase, Oozie, Flume og Sqoop ved hjælp af realtidsanvendelsessager på Retail, Social Media, Aviation, Tourism, Finance domæne.

Har du et spørgsmål til os? Nævn det i kommentarfeltet, og vi vender tilbage til dig.