Oversikt over Hadoop 2.0 Cluster Architecture Federation

Hadoop 2.0 Cluster Architecture Federation

Introduksjon:

I denne bloggen vil jeg dykke inn i Hadoop 2.0 Cluster Architecture Federation. Apache Hadoop har utviklet seg mye siden utgivelsen av Apache Hadoop 1.x. Som du vet fra min forrige blogg at følger Master / Slave Topology der NameNode fungerer som en master daemon og er ansvarlig for å administrere andre slave noder kalt DataNodes. I dette økosystemet blir denne eneste Master Daemon eller NameNode en flaskehals, og tvert imot må selskaper ha NameNode som er veldig tilgjengelig. Nettopp denne grunnen ble grunnlaget for HDFS Federation Architecture and HA (High Availability) Architecture .

Temaene jeg har dekket i denne bloggen er som følger:

• Den nåværende HDFS-arkitekturen
• Begrensninger av gjeldende HDFS-arkitektur
• HDFS Federation Architecture

Oversikt over nåværende HDFS-arkitektur:

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

• HDFS Navneområde (NS): Dette laget er ansvarlig for å administrere kataloger, filer og blokker. Den gir all filsystemoperasjonen relatert til navneområdet, for eksempel å opprette, slette eller endre filene eller filkatalogene.
• Lagringslag: Den består av to grunnleggende komponenter.
  1. Blokkadministrasjon : Den utfører følgende operasjoner:
     • Sjekker hjerterytme til DataNodes med jevne mellomrom, og det administrerer DataNode-medlemskap til klyngen.
     • Administrerer blokkeringsrapportene og opprettholder blokkeringsplasseringen.
     • Støtter blokkoperasjoner som opprettelse, modifisering, sletting og tildeling av blokkplassering.
     • Opprettholder replikasjonsfaktoren konsistent gjennom hele klyngen.

2. Fysisk lagring : Det administreres av DataNodes som er ansvarlig for lagring av data og gir dermed lese- / skrivetilgang til dataene som er lagret i HDFS.

Så, den nåværende HDFS-arkitekturen lar deg ha et enkelt navneområde for en klynge. I denne arkitekturen er en enkelt NameNode ansvarlig for å administrere navneområdet. Denne arkitekturen er veldig praktisk og enkel å implementere. Det gir også tilstrekkelig kapasitet til å imøtekomme behovene til den lille produksjonsklyngen.

hadoop admin roller og ansvar

Begrensninger av gjeldende HDFS:

Som diskutert tidligere, var den nåværende HDFS tilstrekkelig til behovene og brukssakene til en liten produksjonsklynge. Men store organisasjoner som Yahoo, Facebook fant noen begrensninger ettersom HDFS-klyngen vokste eksponentielt. La oss se raskt på noen av begrensningene:

1. Navneområdet er ikke skalerbar som DataNodes. Derfor kan vi bare ha det antallet DataNodes i klyngen som en enkelt NameNode kan håndtere.
2. De to lagene, dvs. navneplasslaget og lagringslaget er sammensveiset noe som gjør den alternative implementeringen av NameNode veldig vanskelig.
3. Ytelsen til hele Hadoop-systemet avhenger av gjennomstrømning av NameNode. Derfor avhenger hele ytelsen til alle HDFS-operasjonene av hvor mange oppgaver NameNode kan håndtere på et bestemt tidspunkt.
4. NameNode lagrer hele navneområdet i RAM for rask tilgang. Dette fører til begrensninger mht minnestørrelse dvs. antall navneområdeobjekter (filer og blokker) som en enkelt navneromserver kan takle.
5. Mange av organisasjonene (leverandøren) som har HDFS-distribusjon, gjør at flere organisasjoner (leietaker) kan bruke klyngenes navneområde. Så det er ingen skille mellom navneområdet, og det er det også ingen isolasjon blant leietakerorganisasjoner som bruker klyngen.

HDFS Federation Architecture:

• I HDFS Federation Architecture har vi horisontal skalerbarhet i navnetjeneste. Derfor har vi flere navnekoder som er samlet, dvs. uavhengige av hverandre.
• DataNodene er til stede nederst, dvs. underliggende lagringslag.
• Hver DataNode registrerer seg med alle NameNodes i klyngen.
• DataNodes overfører periodiske hjerteslag, blokkerer rapporter og håndterer kommandoer fra NameNodes.

Den illustrative representasjonen av HDFS Federation Architecture er gitt nedenfor:

Før jeg går videre, la meg kort snakke om det ovennevnte arkitektoniske bildet:

• Det er flere navnerom (NS1, NS2,…, NSn), og hvert av dem administreres av den respektive NameNode.
• Hvert navneområde har sitt eget blokkeringsbasseng (NS1 har basseng 1, NSk har basseng k og så videre).
• Som vist på bildet lagres blokkene fra basseng 1 (himmelblå) på DataNode 1, DataNode 2 og så videre. På samme måte vil alle blokkene fra hver blokkgruppe ligge på alle DataNodes.

La oss nå forstå komponentene i HDFS Federation Architecture i detalj:

Blokker basseng:

Blokkeringsbasseng er ikke annet enn sett med blokker som tilhører et bestemt navneområde. Så vi har en samling av blokkbasseng der hvert blokkbasseng administreres uavhengig av det andre. Denne uavhengigheten der hvert blokkbasseng administreres uavhengig, tillater navneområdet å opprette blokk-ID-er for nye blokker uten koordinering med andre navneområder. Datablokkene som er tilstede i hele blokkeringsbassenget er lagret i alle DataNodene. I utgangspunktet gir blokkbasseng en abstraksjon slik at datablokkene som ligger i DataNodene (som i Single Namespace Architecture) kan grupperes tilsvarende et bestemt navneområde.

Navneplassvolum:

Navneplassvolum er ikke annet enn navneområde sammen med blokkbassenget. Derfor har vi i HDFS Federation flere navneområdevolum. Det er en selvstendig ledelsesenhet, dvs. hvert navneplassvolum kan fungere uavhengig. Hvis et NameNode eller navneområde blir slettet, vil den tilsvarende blokkmassen som ligger på DataNodes også bli slettet.

Demo On Hadoop 2.0 Cluster Architecture Federation | Edureka

Nå antar jeg at du har en ganske god idé om HDFS Federation Architecture. Det er mer et teoretisk konsept, og folk bruker det ikke generelt i et praktisk produksjonssystem. Det er noen implementeringsproblemer med HDFS Federation som gjør det vanskelig å distribuere. derfor HA (High Availability) Architecture foretrekkes for å løse problemet med enkelt punkt. Jeg har dekket HDFS HA ​​Arkitektur i min neste blogg.

hva som kan serialiseres i java

Nå som du har forstått Hadoop HDFS Federation Architecture, sjekk ut av Edureka, et pålitelig online læringsfirma med et nettverk av mer enn 250 000 fornøyde elever spredt over hele verden. Edureka Big Data Hadoop Certification Training-kurset hjelper elever å bli eksperter på HDFS, Garn, MapReduce, Pig, Hive, HBase, Oozie, Flume og Sqoop ved å bruke sanntidsbruk på Retail, Social Media, Aviation, Tourism, Finance.

Har du et spørsmål til oss? Vennligst nevn det i kommentarfeltet, så kommer vi tilbake til deg.