sql >> Database teknologi >  >> NoSQL >> HBase

Rack-bevidsthed i Hadoop og dets fordele

DetteHadoop selvstudie handler om Rack Awareness i Hadoop. I denne blog vil vi beskrive alt om Rack Awareness i HDFS .

Først og fremmest vil vi undersøge, hvad der er HDFS Rack Awareness-ejendom, hvad er behovet for Rack Awareness i Hadoop. Derefter vil vi diskutere replikaplacering via Rack Awareness i HDFS.

Til sidst vil vi også diskutere de forskellige fordele ved Rack Awareness in Hadoop framework.

Introduktion til HDFS Rack Awareness

Rack-bevidsthed i Hadoop er konceptet, der vælger tættere Datanodes baseret på rackinformationen. Som standard antager Hadoop-installationen, at alle noderne tilhører det samme rack.

For at forbedre netværkstrafikken, mens du læser/skriver HDFS-filer i store klynger af Hadoop. NameNode vælger data noder, som er på det samme rack eller en nærliggende sten til at læse/skrive anmodninger (klient node). HDFS Namenode opnår denne rackinformation ved at vedligeholde rack-id'erne for hver datanode.

Hvorfor Rack Awareness?

Hovedformålet med Rack-bevidsthed er at:

  • Forbedre datapålidelighed og datatilgængelighed.
  • Bedre klyngeydelse.
  • Forhindrer tab af data, hvis hele racket svigter.
  • For at forbedre netværksbåndbredden.
  • Opbevar bulkflowet i stativet, når det er muligt.

Replikaplacering via Rack Awareness i Hadoop

Hovedformålet med replikaplacering via Rack-bevidsthed, politikken er at forbedre datapålidelighed osv.

En simpel politik er at placere replikaer på racket for at forhindre tab af data, når et helt rack fejler. Og tillad brug af båndbredde fra flere racks, når du læser en fil.

bloker på flere rackklynger replikering følger nedenstående politik:

Du bør ikke placere mere end én replika på én node. Du bør heller ikke placere mere end to replikaer på samme stativ. Dette har en flaskehals, at antallet af stativer, der bruges til blokreplikering, altid skal være mindre end det samlede antal blokreplikater.

For eksempel;

  • Når en Hadoop-ramme opretter en ny blok, placerer den den første replika på den lokale node. Og placer en anden i et andet rack, og den tredje er på en anden node på den lokale node.
  • Når du genreplikerer en blok, og hvis antallet af eksisterende replikaer er én, skal du placere den anden på et andet stativ.
  • Når antallet af eksisterende replikaer er to, og hvis de to replikaer er i samme stativ, skal du placere den tredje på et andet stativ.

Fordele ved Rack Awareness i Hadoop

Lad os nu diskutere nogle fordele ved Rack Awareness i Hadoop HDFS-

  • Giv højere båndbredde og lav latenstid –  Denne politik maksimerer netværksbåndbredden ved at overføre blok i et rack i stedet for mellem racks. YARN er i stand til at optimere MapReduce jobydeevne ved at tildele opgaver til noder, der er tættere på deres data med hensyn til netværkstopologi.
  • Giver databeskyttelse mod rackfejl –  Namenode tildeler blokreplikaerne af 2 og 3 blok til noder i et andet rack fra den første replika. Det giver således databeskyttelse selv mod rackfejl. Dette er dog kun muligt, hvis Hadoop blev konfigureret med viden om dets rack-konfiguration.
  • Minimer skriveomkostningerne og maksimer læsehastigheden –  Rack-bevidsthed, politik placerer læse-/skriveanmodninger til replikaer, der er i samme stativ. Dette minimerer skriveomkostningerne og maksimerer læsehastigheden.

Konklusion

Afslutningsvis er det konceptet, der vælger tættere Datanodes baseret på rackinformationen for at forbedre datapålideligheden. Hovedformålet med Rack-Awareness er at forhindre tab af data, hvis hele racket svigter. Det forbedrer også netværksbåndbredden. Lær flere HDFS-egenskaber i detaljer.

Hvis du har spørgsmål relateret til Rack Awareness i Hadoop, så del venligst med os i kommentarfeltet. Vi vil gøre vores bedste for at hjælpe dig.


  1. MongoDB Schema Design - Mange små dokumenter eller færre store dokumenter?

  2. Mongo sorterer på en beregnet tilstand

  3. Forårsdata mongodb lukker ikke mongodb-forbindelser

  4. Percona Live Frankfurt 2018 - Begivenhedsoversigt og vores sessioner