Meny

Hadoop HDFS - Hadoop Distribuerat filsystem

  • Huvud
  • Övrig
  • Hadoop HDFS - Hadoop Distribuerat filsystem

hadoop hdfs hadoop distributed file system

Prova Vårt Instrument För Att Eliminera Problem

Denna handledning förklarar Hadoop HDFS - Hadoop Distribuerat filsystem, komponenter och klusterarkitektur. Du kommer också att lära dig mer om Rack Awareness Algorithm:

Som vi lärde oss i föregående handledning är det största problemet med Big Data att lagra det i ett befintligt system. Och även om vi på något sätt lagrade en del av det i ett befintligt system, tog bearbetning av BigData år.

De resultat du ville ha på några minuter tog veckor eller kanske i månader och på grund av detta förlorades värdet på resultatet.

=> Se upp den enkla BigData-träningsserien här.

Komponenter i Hadoop - HDFS

Vad du kommer att lära dig:

Hadoop distribuerat filsystem

För att lösa detta problem eller för att klara det här problemet har vi nu HADOOP. Hadoop löste detta stora dataproblem med Hadoop HDFS.

lagring av stora data

Hadoop HDFS löste lagringsproblemet för Big Data och Hadoop Map Reduce löste problemen relaterade till bearbetning av en del av Big Data.

Komponenter i Hadoop

Nu vet vi att Hadoop i huvudsak har ett distribuerat filsystem ... MEN VARFÖR?

intervjufråga för programvarutestning för erfarna

Varför är Hadoop ett distribuerat filsystem?

Låt oss försöka förstå vad ett distribuerat filsystem är och förstå fördelarna med det distribuerade filsystemet.

Distribuerat filsystem

Låt oss ta ett exempel på att läsa 1 TB data. Vi har en server som är en bra avancerad server som har 4 I / O-kanaler (Input Output) och varje kanal har en bandbredd på 100 MB / s, med den här maskinen kommer du att kunna läsa denna 1 TB-data i 43 Minuter.

Om vi ​​nu tar in 10 Numr maskiner precis så här, vad händer då?

Distribuerat filsystem

Tiden reducerades till exakt 4,3 minuter. Det beror på att hela ansträngningen delades upp i tio maskiner och det är därför tiden som det tog att bearbeta 1 TB data minskar till 1/10thdvs. 4,3 minuter.

På samma sätt, när vi överväger BigData, delas dessa data upp i flera bitar av data och vi behandlar faktiskt dessa data separat och det är därför Hadoop har valt Distribuerat filsystem framför ett centraliserat filsystem.

Komponenter av Hadoop

Hadoop HDFS har två huvudkomponenter för att lösa problemen med BigData.

  • Den första komponenten är Hadoop HDFS för att lagra Big Data.
  • Den andra komponenten är Hadoop Map Reduce to Process Big Data.

Huvudsakliga Hadoop-komponenter

Nu när vi ser arkitekturen i Hadoop (bilden nedan) har den två vingar där den vänstra vingen är 'Lagring' och högern är “Bearbetning” . Det betyder att vänster är HDFS, dvs. Hadoop Distribution File System och höger är YARN och Map Reduce dvs är bearbetningsdelen.

Med HDFS gör Hadoop det möjligt för oss att lagra Big Data och med hjälp av YARN & Map Reduce kan Hadoop bearbeta samma Big Data som vi lagrar i HDFS.

Hadoop-kärnkomponenter

Som du kan se på bilden ovan har HDFS två stora demoner eller så kan du kalla dem som processer eller trådar som inte är annat än JAVA-processer, dvs. körs i en JVM - NameNode och DataNode.

NameNode är en masterdemon som körs på Master Machine, dvs. en avancerad maskin i huvudsak och DataNode är en Slave Machine som körs på råvaruhårdvara. Det kan finnas mer DataNode eftersom slavmaskiner är mer än en mastermaskin.

Så vi har alltid en NameNode och flera DataNode som körs på slavmaskiner.

På samma sätt har vi garn på andra sidan som återigen har två demoner, en är Resource Manager som körs på Master Machine och Node Manager som körs på Slave Machine precis som DataNode. Så varje slavmaskin har två demoner - en är DataNode och den andra är Node Manager.

Huvudmaskinen körs med NameNode och Resource Manager körs. NameNode är ansvarig för att hantera data i Hadoop Distribuerade filsystemet och Resource Manager är ansvarig för att utföra bearbetningsuppgifterna över denna lagrade data.

NameNode och DataNode

Vi kommer att gå djupt in i HDFS-arkitektur och därför är det viktigt att förstå vad som är en NameNode och en DataNode eftersom dessa är de två huvudsakliga demonerna som faktiskt kör HDFS helt.

NameNode

  • Det är en Master Daemon.
  • Hantera och underhålla DataNodes.
  • Registrerar metadata.
  • Tar emot hjärtslag och blockera rapporter från alla DataNodes.

DataNode

  • Det är en slavdemon.
  • Här lagras faktiska data.
  • Serverar läs- och skrivförfrågningar från klienterna.

NameNode DataNode

Fokusera bara på diagrammet, som du kan se finns det en centraliserad maskinnamnod som styr olika DataNode som finns där, dvs. råvaruhårdvara. Så Namnod är inget annat än Master Daemon som underhåller alla DataNode.

Dessa NameNode har all information om de data som lagras i DataNode. DataNode, som namnet själv antyder, lagrar data som finns där i Hadoop-klustret.

NameNode har endast information om vilka data som lagras på vilken DataNode. Så vad vi kan säga är att NameNode lagrar metadata för de data som lagras på DataNodes.

DataNode gör också en annan uppgift, dvs den skickar regelbundet hjärtslag tillbaka till NameNode. Hjärtslag säger faktiskt till NameNode att denna DataNode fortfarande lever.

Till exempel, DataNodes skickar ett hjärtslag tillbaka till NameNode och på det sättet har NameNode bilden att dessa DataNodes lever, så NameNode kan använda dessa DataNode för att lagra mer data eller läsa data från dessa DataNodes.

Nu kommer vi till DataNode, DataNode är inget annat än Slave Daemons som faktiskt lagrar data som skickas till Hadoop-klustret. Dessa DataNodes är de som faktiskt serverar läs- och skrivförfrågan som görs av klienterna.

Om någon vill läsa data från Hadoop-klustret, behandlas dessa förfrågningar faktiskt av DataNodes där data finns.

Hadoop Cluster Architecture

I det tidigare ämnet relaterat till NameNode och DataNode använde vi termen ”Hadoop Cluster”. Låt oss ta en snabb titt på vad exakt är det?

Hadoop Cluster Architecture

Ovanstående bild visar översikten över en Hadoop-klusterarkitektur. Hadoop Cluster är inget annat än en Master-Slave Topology, där det finns en Master Machine som du kan se på toppen, dvs. Hadoop Cluster. I denna Master Machine finns en NameNode och Resource Manager som kör, dvs. Master Daemons.

Master Machine är ansluten till alla Slave Machine med Core Switches, det beror på att dessa DataNodes faktiskt är lagrade i olika rack, så som du kan se Computer 1, Computer 2, Computer 3 till Computer N. Detta är inget annat än Slave Maskiner eller DataNodes och de finns alla i ett rack.

'Racket är faktiskt en grupp maskiner som är fysiskt närvarande på en viss plats och är anslutna till varandra.'

Således är nätverksbandbredden mellan varje maskin så liten som möjligt. På samma sätt finns det fler rack, men de finns inte på samma plats, därför kan vi ha ett 'n' antal rack och vi kan också ha 'n' antal DataNoder eller datorer eller slavmaskiner inom dessa rack.

Detta är hur slavmaskinerna faktiskt fördelas över klustret, men samtidigt är de anslutna till varandra.

Hur lagras data i HDFS?

Nu går vi långsamt in i detaljerna om hur HDFS fungerar helt. Här kommer vi att utforska arkitekturen för HDFS.

När vi säger att lagra en fil i HDFS lagras data som block i HDFS. Hela filen lagras inte i HDFS, det beror på att Hadoop är som du vet ett distribuerat filsystem.

Så om du har en filstorlek på kanske 1 PB (Peta Byte), så finns den här typen av lagring inte i en enda maskin eftersom Hadoop-klustret görs med hjälp av råvaruhårdvaran. Maskinvaran i en enda maskin skulle vara ungefär 1 TB eller 2 TB.

Således måste hela filen delas upp i bitar av data som kallas HDFS-block.

  • Varje fil lagras på HDFS som block.
  • Standardstorleken för varje block är cirka 128 MB i Apache Hadoop 2.x (och 64 MB i den tidigare versionen, dvs. Apache Hadoop 1.x).
  • Det finns en möjlighet att öka eller minska filstorleken på blocken med hjälp av konfigurationsfilen, dvs hdfssite.xml som medföljer Hadoop-paketet.

Låt oss ta ett exempel för att förstå denna mekanism och se hur dessa block skapas.

Låt oss överväga en fil på 248 MB här, nu om vi bryter den här filen eller om vi flyttar den här filen till Hadoop Cluster, dvs. 2.x, kommer den här filen att brytas ned i ett block, dvs Block A på 128 MB och ett annat Block B på 120 MB.

Som du kan se är det första blocket på 128 MB, dvs den allra första plattan skär ner och det är därför det andra blocket är på 120 MB och inte 128 MB, dvs det kommer inte att slösa bort något utrymme om återstående filstorlek är mindre än standardblockstorleken.

Hadoop Cluster Exempel Diagram

Nu har vi en annan fråga framför oss, dvs. är det säkert att ha en enda kopia av varje block?

standardgateway är inte tillgängligt Windows 10

Svaret är NEJ eftersom det finns en chans att systemet kan misslyckas och det är inget annat än råvaruhårdvara på grund av vilket vi kan ha stora problem. För att lösa problemet har Hadoop HDFS en bra lösning, dvs. ”Replikering av block”.

Hadoop Architecture Block Replication

Hadoop skapar repliker av varje block som lagras i Hadoop Distribuerade filsystemet och så här är Hadoop ett fel-tolerant system, dvs även om ditt system misslyckas eller din DataNode misslyckas eller en kopia går förlorad kommer du att ha flera andra kopior finns i andra DataNodes eller i andra servrar så att du alltid kan välja dessa kopior därifrån.

Blockera replikering

Som framgår av ovanstående diagram som representerar blockreplikering finns det fem olika block i en fil, dvs. block 1, 2,3,4,5. Låt oss först kontrollera med block 1 så hittar du kopior av block 1 i nod 1, nod 2 och nod 4.

På samma sätt har block 2 också fått tre kopior, dvs. nod 2, nod 3 och nod 4 och så samma för block 3, 4 och 5 i respektive nod.

Så bortsett från replikerna som skapas har varje block replikerats tre gånger, dvs. Hadoop följer en standardreplikationsfaktor på tre vilket innebär att alla filer som du kopierar till Hadoop Distribution File System replikeras tre gånger.

Med andra ord, om du kopierar 1 GB av en fil till Hadoop Distribution File System, lagras den faktiskt 3 GB av en fil i HDFS. Den goda delen är att standardreplikationsfaktorn kan ändras genom att ändra i konfigurationerna för Hadoop.

Hur bestämmer Hadoop var replikerna ska lagras?

Hadoop följer faktiskt konceptet Rack Awareness för att bestämma var man ska lagra vilken replik av ett Block.

Nedan visas diagrammet som visar Rack Awareness Algorithm.

Rackmedvetenhetsalgoritm

Det finns tre olika rack dvs Rack-1, Rack-2 och Rack-3.

Rack-1 har fyra DataNoder och det gör Rack-2 & Rack-3, så totalt sett kommer hela Hadoop-klustret att bestå av alla de tre racken och det kommer att finnas 12 DataNodes.

Låt oss säga att Block A kopieras på DataNode 1 i Rack-1, enligt konceptet Rack Awareness kan repliken av Block A inte skapas i samma rack, och det måste skapas i något annat rack förutom Rack-1 som huvudfilen finns redan i Rack-1.

Om vi ​​skapar repliker av Block A i samma Rack-1 och om hela Rack-1 misslyckas kommer vi säkert att förlora data, så replikerna måste därför lagras i något annat rack men inte i Rack-1.

Så repliken kommer att skapas i DataNode 6 och 8 i Rack-2. På samma sätt, för block B och block C, kommer replikerna att skapas i olika rack, som visas i ovanstående diagram.

Slutsats

Vi lärde oss med följande tips från denna handledning-

  • Hadoop HDFS löser lagringsproblemet med BigData.
  • Hadoop Map Reduce löser problemen relaterade till bearbetning av BigData.
  • NameNode är en Master Daemon och används för att hantera och underhålla DataNodes.
  • DataNode är en slavdemon och den faktiska informationen lagras här. Det tjänar till att läsa och skriva förfrågningar från klienterna.
  • I Hadoop Cluster är ett rack faktiskt en grupp maskiner som är fysiskt närvarande på en viss plats och är anslutna till varandra.
  • Varje fil lagras på HDFS som block.
  • Standardstorleken för varje block är cirka 128 MB i Apache Hadoop 2.x (64 MB i den tidigare versionen, dvs. Apache Hadoop 1.x)
  • Det finns en möjlighet att öka eller minska filstorleken på blocken med hjälp av konfigurationsfilen, dvs hdfssite.xml som medföljer Hadoop-paketet.

I nästa handledning om HDFS lär vi oss om HDFS-arkitektur och läs- och skrivmekanismer.

=> Besök här för att se BigData Training Series för alla.

Rekommenderad läsning

^