Overzicht van Hadoop 2.0 Cluster Architecture Federation

Hadoop 2.0 Cluster Architecture Federation

Invoering:

In deze blog ga ik dieper in op Hadoop 2.0 Cluster Architecture Federation. Apache Hadoop is enorm geëvolueerd sinds de release van Apache Hadoop 1.x. Zoals je weet uit mijn vorige blog dat de volgt Master / Slave-topologie waarbij NameNode fungeert als een master-daemon en verantwoordelijk is voor het beheer van andere slaafknooppunten genaamd DataNodes. In dit ecosysteem wordt deze enkele Master Daemon of NameNode een bottleneck en integendeel, bedrijven hebben NameNode nodig die zeer beschikbaar is. Deze reden werd de basis van HDFS Federation Architecture en HA-architectuur (hoge beschikbaarheid) .

De onderwerpen die ik in deze blog heb behandeld zijn als volgt:

• De huidige HDFS-architectuur
• Beperkingen van de huidige HDFS-architectuur
• HDFS Federation-architectuur

Overzicht van de huidige HDFS-architectuur:

Zoals je in de bovenstaande afbeelding kunt zien, heeft de huidige HDFS twee lagen:

• HDFS-naamruimte (NS): Deze laag is verantwoordelijk voor het beheer van de mappen, bestanden en blokken. Het biedt alle bestandssysteembewerkingen met betrekking tot naamruimte, zoals het maken, verwijderen of wijzigen van de bestanden of de bestandsmappen.
• Opslaglaag: Het bestaat uit twee basiscomponenten.
  1. Blokbeheer : Het voert de volgende bewerkingen uit:
     • Controleert periodiek heartbeats van DataNodes en beheert het DataNode-lidmaatschap van het cluster.
     • Beheert de blokrapporten en onderhoudt de bloklocatie.
     • Ondersteunt blokbewerkingen zoals het maken, wijzigen, verwijderen en toewijzen van bloklocaties.
     • Behoudt replicatiefactor consistent in het hele cluster.

2. Fysieke opslag : Het wordt beheerd door DataNodes die verantwoordelijk zijn voor het opslaan van gegevens en biedt daardoor lees- / schrijftoegang tot de gegevens die zijn opgeslagen in HDFS.

Met de huidige HDFS-architectuur kunt u dus één naamruimte hebben voor een cluster. In deze architectuur is een enkele NameNode verantwoordelijk voor het beheer van de naamruimte. Deze architectuur is erg handig en gemakkelijk te implementeren. Het biedt ook voldoende capaciteit om in de behoeften van het kleine productiecluster te voorzien.

Beperkingen van de huidige HDFS:

Zoals eerder besproken, voldeed het huidige HDFS wel aan de behoeften en use cases van een klein productiecluster. Maar grote organisaties zoals Yahoo, Facebook ontdekte enkele beperkingen toen het HDFS-cluster exponentieel groeide. Laten we een korte blik werpen op enkele van de beperkingen:

1. De naamruimte is niet schaalbaar zoals DataNodes. Daarom kunnen we alleen dat aantal DataNodes in het cluster hebben dat een enkele NameNode aankan.
2. De twee lagen, d.w.z. naamruimtelaag en opslaglaag zijn stevig gekoppeld wat de alternatieve implementatie van NameNode erg moeilijk maakt.
3. De prestaties van het gehele Hadoop-systeem zijn afhankelijk van het doorvoer van de NameNode. Daarom hangt de volledige prestatie van alle HDFS-bewerkingen af ​​van het aantal taken dat de NameNode op een bepaald moment kan uitvoeren.
4. De NameNode slaat de volledige naamruimte op in RAM voor snelle toegang. Dit leidt tot beperkingen in termen van geheugen grootte d.w.z. het aantal naamruimte-objecten (bestanden en blokken) dat een enkele naamruimteserver aankan.
5. Bij veel van de organisaties (leverancier) die HDFS-implementatie hebben, kunnen meerdere organisaties (tenant) hun clusternaamruimte gebruiken. Er is dus geen scheiding van de naamruimte en daarom is er geen isolatie onder tenant organisaties die het cluster gebruiken.

HDFS Federation-architectuur:

• In HDFS Federation Architecture hebben we horizontale schaalbaarheid van naamservice. Daarom hebben we meerdere NameNodes die federatief zijn, d.w.z. onafhankelijk van elkaar.
• De DataNodes zijn onderaan aanwezig, d.w.z. Onderliggende opslaglaag.
• Elke DataNode wordt geregistreerd met alle NameNodes in het cluster.
• De DataNodes verzenden periodieke hartslagen, blokkeren rapporten en behandelen opdrachten van de NameNodes.

De grafische weergave van de HDFS Federation-architectuur wordt hieronder gegeven:

Voordat ik verder ga, wil ik het kort hebben over het bovenstaande architecturale beeld:

• Er zijn meerdere naamruimten (NS1, NS2,…, NSn) en elk ervan wordt beheerd door zijn respectievelijke NameNode.
• Elke naamruimte heeft zijn eigen blokpool (NS1 heeft pool 1, NSk heeft pool k enzovoort).
• Zoals in de afbeelding te zien is, worden de blokken van pool 1 (hemelsblauw) opgeslagen op DataNode 1, DataNode 2 enzovoort. Op dezelfde manier zullen alle blokken van elke blokpool op alle DataNodes staan.

Laten we nu de componenten van de HDFS Federation-architectuur in detail begrijpen:

Pool blokkeren:

Block pool is niets anders dan een set blokken die tot een specifieke naamruimte behoren. We hebben dus een verzameling blokpools waarbij elke blokpool onafhankelijk van de andere wordt beheerd. Door deze onafhankelijkheid, waarbij elke blokpool onafhankelijk wordt beheerd, kan de naamruimte blok-ID's voor nieuwe blokken maken zonder de coördinatie met andere naamruimten. De datablokken die aanwezig zijn in de hele blokpool worden opgeslagen in alle DataNodes. In wezen biedt block pool een abstractie zodat de datablokken die zich in de DataNodes bevinden (zoals in de Single Namespace Architecture) gegroepeerd kunnen worden overeenkomstig een bepaalde naamruimte.

Naamruimtevolume:

Het naamruimtevolume is niets anders dan de naamruimte samen met de blokpool. Daarom hebben we in HDFS Federation meerdere naamruimtevolumes. Het is een op zichzelf staande beheerseenheid, d.w.z. elk naamruimtevolume kan onafhankelijk functioneren. Als een NameNode of naamruimte wordt verwijderd, wordt de overeenkomstige blokpool die zich op de DataNodes bevindt, ook verwijderd.

Demo op Hadoop 2.0 Cluster Architecture Federation | Edureka

Nu denk ik dat je een redelijk goed idee hebt van HDFS Federation Architecture. Het is meer een theoretisch concept en mensen gebruiken het in het algemeen niet in een praktisch productiesysteem. Er zijn enkele implementatieproblemen met HDFS Federation waardoor het moeilijk te implementeren is. Daarom, de HA-architectuur (hoge beschikbaarheid) heeft de voorkeur om het Single Point of Failure-probleem op te lossen. Ik heb de HDFS HA-architectuur in mijn volgende blog.

Nu je Hadoop HDFS Federation Architecture begrepen hebt, kun je het door Edureka, een vertrouwd online leerbedrijf met een netwerk van meer dan 250.000 tevreden leerlingen verspreid over de hele wereld. De Edureka Big Data Hadoop-certificeringstraining helpt leerlingen expert te worden in HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume en Sqoop met behulp van real-time use cases op het gebied van Retail, Social Media, Aviation, Tourism, Finance.

c ++ type conversie

Heeft u een vraag voor ons? Vermeld het in het opmerkingengedeelte en we nemen contact met u op.