hadoop hdfs hadoop distributed file system
Denne opplæringen forklarer Hadoop HDFS - Hadoop Distribuert filsystem, komponenter og klyngearkitektur. Du vil også lære om Rack Awareness Algorithm:
Som vi lærte i forrige opplæring, er det største problemet med Big Data å lagre det i et eksisterende system. Og selv om vi på en eller annen måte lagret deler av det i et eksisterende system, tok behandlingen av BigData år.
Resultatene du ønsket på få minutter tok uker eller kanskje i måneder, og på grunn av dette gikk verdien av resultatet tapt.
=> Se opp den enkle BigData-treningsserien her.
Hva du vil lære:
Hadoop distribuert filsystem
For å løse dette problemet eller for å takle dette problemet har vi nå HADOOP. Hadoop løste dette big data-problemet ved hjelp av Hadoop HDFS.
Hadoop HDFS løste lagringsproblemet med Big Data og Hadoop Map Reduce løste problemene knyttet til behandling av en del av Big Data.
Nå vet vi at Hadoop egentlig har et distribuert filsystem ... MEN HVORFOR?
qa testleder intervju spørsmål og svar
Hvorfor er Hadoop et distribuert filsystem?
La oss prøve å forstå hva et distribuert filsystem er og forstå fordelene med det distribuerte filsystemet.
Distribuert filsystem
La oss ta et eksempel på å lese 1 TB data. Vi har en server som er en god high-end server som har 4 I / O (Input Output) kanaler, og hver kanal har en båndbredde på 100MB / s, ved å bruke denne maskinen, vil du kunne lese denne 1TB data i 43 Minutter.
Nå hvis vi tar inn 10 antall maskiner akkurat slik, hva vil da skje?
Tiden redusert til nøyaktig 4,3 minutter. Det er fordi hele innsatsen ble delt inn i 10 maskiner, og det er derfor tiden det tok å behandle 1 TB data reduseres til 1/10thdvs. 4,3 minutter.
På samme måte, når vi vurderer BigData, blir disse dataene delt inn i flere deler av data, og vi behandler faktisk dataene separat, og det er grunnen til at Hadoop har valgt Distribuert filsystem fremfor et sentralisert filsystem.
Komponenter av Hadoop
Hadoop HDFS har to hovedkomponenter for å løse problemene med BigData.
- Den første komponenten er Hadoop HDFS for å lagre Big Data.
- Den andre komponenten er Hadoop Map Reduce to Process Big Data.
Nå når vi ser arkitekturen til Hadoop (bildet gitt nedenfor), har den to vinger der den venstre er 'Oppbevaring' og høyre er 'Behandling' . Det betyr at venstresiden er HDFS, dvs. Hadoop Distribution File System, og høyre er YARN og Map Reduce dvs. er behandlingsdelen.
Ved å bruke HDFS gjør Hadoop oss i stand til å lagre store data, og ved hjelp av YARN & Map Reduce kan Hadoop oss behandle de samme store dataene som vi lagrer i HDFS.
Som du kan se på bildet ovenfor, har HDFS to store demoner, eller du kan kalle dem som prosesser eller tråder som ikke er annet enn JAVA-prosesser, dvs. kjører i en JVM - NameNode og DataNode.
NameNode er en master-demon som kjører på Master Machine, dvs. en high-end maskin i hovedsak, og DataNode er en Slave Machine som kjører på råvaremaskinvare. Det kan være mer DataNode ettersom slavemaskiner er mer enn en Master Machine.
Så vi har alltid en NameNode og flere DataNode som kjører på Slave Machines.
På samme måte har vi GARN på den andre siden som igjen har to demoner, den ene er Ressurssjef som kjører på Master Machine og Node Manager som kjører på Slave Machine akkurat som DataNode. Så hver Slave Machine har to demoner - den ene er DataNode og den andre er Node Manager.
Master Machine har NameNode kjørt og Resource Manager kjører. NameNode er ansvarlig for å administrere dataene på Hadoop Distributed File System, og ressurssjefen er ansvarlig for å utføre behandlingsoppgavene over disse lagrede dataene.
NameNode og DataNode
Vi vil gå dypt inn i HDFS-arkitektur, og det er derfor viktig å forstå hva som er en NameNode og en DataNode, da dette er de to hoveddemonene som faktisk kjører HDFS helt.
NameNode
- Det er en Master Daemon.
- Administrere og vedlikeholde DataNodes.
- Registrerer metadata.
- Mottar hjerterytme og blokkerer rapporter fra alle DataNodes.
DataNode
- Det er en slavedemon.
- Faktiske data lagres her.
- Serverer lese- og skriveforespørsler fra klientene.
Bare fokuser på diagrammet, som du kan se, er det en sentralisert maskinnavnode som styrer forskjellige DataNode som er der, dvs. råvaremaskinvare. Så Name Node er ingenting annet enn Master Daemon som vedlikeholder all DataNode.
Disse NameNode har all informasjon om dataene som er lagret i DataNode. DataNode, som navnet antyder, lagrer dataene som er der i Hadoop-klyngen.
NameNode har bare informasjonen om hvilke data som er lagret på hvilken DataNode. Så det vi kan si er at NameNode lagrer metadataene til dataene som er lagret på DataNodes.
DataNode gjør også en annen oppgave, det vil si at den regelmessig sender hjerterytmen tilbake til NameNode. Hjerteslag forteller faktisk NameNode at denne DataNode fortsatt lever.
For eksempel, DataNodes sender hjerterytme tilbake til NameNode, og på denne måten har NameNode bildet av at disse DataNodes lever, slik at NameNode kan bruke disse DataNode til å lagre mer data eller lese dataene fra disse DataNodes.
Nå kommer vi til DataNode, DataNode er ingenting annet enn Slave Daemons som faktisk lagrer dataene som sendes til Hadoop Cluster. Disse DataNodene er de som faktisk serverer lese- og skriveforespørselen som blir gjort av klientene.
Hvis noen vil lese dataene fra Hadoop-klyngen, blir disse forespørslene faktisk behandlet av DataNodes der dataene ligger.
Hadoop Cluster Architecture
I det forrige emnet relatert til NameNode og DataNode brukte vi begrepet “Hadoop Cluster”. La oss se raskt på hva det egentlig er?
Ovenstående bilde viser oversikten over en Hadoop Cluster Architecture. Hadoop Cluster er ikke noe annet enn en Master-Slave Topology, der det er en Master Machine som du kan se på toppen, dvs. Hadoop Cluster. I denne mastermaskinen er det en NameNode og ressurssjefen som kjører, dvs. Master Daemons.
Master Machine er koblet til alle Slave Machine ved hjelp av Core Switches, det er fordi disse DataNodes faktisk er lagret i forskjellige stativer, slik som du kan se Computer 1, Computer 2, Computer 3 til Computer N. Dette er ikke noe annet enn Slave Maskiner eller DataNodes, og de er alle til stede i ett stativ.
'Stativet er faktisk en gruppe maskiner som er til stede fysisk på et bestemt sted og er koblet til hverandre.'
Dermed er nettverksbåndbredden mellom hver maskin minst mulig. På samme måte er det flere stativer, men de er ikke tilstede på samme sted, derfor kan vi ha et 'n' antall stativer, og vi kan også ha 'n' antall DataNoder eller datamaskiner eller slave-maskiner innenfor disse stativene.
Slik fordeles slavemaskinene faktisk over klyngen, men samtidig er de koblet til hverandre.
Hvordan lagres data i HDFS?
Nå går vi sakte inn i detaljene om hvordan HDFS fungerer helt. Her vil vi utforske arkitekturen til HDFS.
Når vi sier, lagring av en fil i HDFS, lagres dataene som blokker i HDFS. Hele filen er ikke lagret i HDFS, det er fordi som kjent Hadoop er et distribuert filsystem.
Så hvis du har en filstørrelse på kanskje 1 PB (Peta Byte), så er denne typen lagring ikke til stede i en enkelt maskin ettersom Hadoop-klyngen er laget med råvaremaskinvaren. Maskinvaren i en enkelt maskin vil være omtrent 1 TB eller 2 TB.
Dermed må hele filen brytes ned i biter av data som kalles HDFS Blocks.
- Hver fil lagres på HDFS som blokker.
- Standardstørrelsen på hver blokk er omtrent 128 MB i Apache Hadoop 2.x (og 64 MB i forrige versjon, dvs. Apache Hadoop 1.x).
- Det er en mulighet for å øke eller redusere filstørrelsen til blokkene ved hjelp av konfigurasjonsfilen, dvs. hdfssite.xml som følger med Hadoop-pakken.
La oss ta et eksempel for å forstå denne mekanismen og se hvordan disse blokkene blir opprettet.
La oss vurdere en fil på 248 MB her, nå hvis vi bryter denne filen eller hvis vi flytter denne filen til Hadoop Cluster dvs. 2.x, vil denne filen bli brutt ned i en blokk, dvs. blokk A på 128 MB og en annen blokk B på 120 MB.
Som du kan se, er den første blokken på 128 MB, dvs. den aller første platen kutter der nede, og det er grunnen til at den andre blokken er på 120 MB og ikke 128 MB, dvs. enn standard blokkstørrelse.
Nå har vi et annet problem foran oss, dvs. er det trygt å ha en enkelt kopi av hver blokk?
udefinert referanse til c ++
Svaret er NEI fordi det er en sjanse for at systemet kan mislykkes, og det er ingenting annet enn råvaremaskinvare som vi kan ha store problemer med. For å løse dette problemet har Hadoop HDFS en god løsning, dvs. “Replikering av blokk”.
Hadoop Architecture Block Replication
Hadoop oppretter kopier av hver blokk som blir lagret i Hadoop Distribuert Filsystem, og slik er Hadoop et feiltolerant system, dvs. selv om systemet mislykkes eller DataNode mislykkes eller en kopi går tapt, vil du ha flere andre kopier til stede i de andre DataNodene eller i de andre serverne, slik at du alltid kan velge disse kopiene derfra.
Som vist i diagrammet ovenfor som representerer blokkreplisering, er det fem forskjellige blokker av en fil, dvs. blokk 1, 2,3,4,5. La oss sjekke med blokk 1 først, så finner du kopier av blokk 1 i node 1, node 2 og node 4.
Tilsvarende har blokk 2 også fått tre eksemplarer, dvs. node 2, node 3 og node 4 og så den samme for blokk 3, 4 og 5 i de respektive nodene.
Så bortsett fra kopiene som blir opprettet, har hver blokk blitt replikert tre ganger, dvs. Hadoop følger en standard replikasjonsfaktor på tre, noe som betyr at enhver fil du kopierer til Hadoop Distribution File System blir replikert tre ganger.
Med andre ord, hvis du kopierer 1 GB av en fil til Hadoop Distribution File System, lagrer den faktisk 3 GB av en fil i HDFS. Den gode delen er at standard replikasjonsfaktor kan endres ved å gjøre en endring i konfigurasjonsfilene til Hadoop.
Hvordan bestemmer Hadoop hvor kopiene skal lagres?
Hadoop følger faktisk begrepet Rack Awareness for å bestemme hvor den kopien av en Block skal lagres.
Nedenfor er diagrammet som viser Rack Awareness Algorithm.
Det er tre forskjellige stativer, dvs. Rack-1, Rack-2 og Rack-3.
Rack-1 har fire DataNodes og det samme gjør Rack-2 & Rack-3, og dermed vil totalt hele Hadoop Cluster bestå av alle de tre rackene, og det vil være 12 DataNodes.
La oss si at blokk A er kopiert på DataNode 1 i Rack-1, i henhold til konseptet Rack Awareness, kan ikke replikaen til Block A opprettes i samme rack, og den må lages i et hvilket som helst annet rack bortsett fra Rack-1 som hovedfilen eksisterer allerede i Rack-1.
Hvis vi lager kopier av blokk A i samme rack-1, og hvis hele rack-1 mislykkes, vil vi helt sikkert miste dataene, og kopiene må derfor lagres i et hvilket som helst annet rack, men ikke i rack-1.
Så kopien skal opprettes i DataNode 6 og 8 i Rack-2. På samme måte, for blokk B og blokk C, vil replikaene bli opprettet i forskjellige stativer, som vist i diagrammet ovenfor.
Konklusjon
Vi lærte med følgende tips fra denne opplæringen-
- Hadoop HDFS løser lagringsproblemet til BigData.
- Hadoop Map Reduce løser problemene knyttet til behandlingen av BigData.
- NameNode er en Master Daemon og brukes til å administrere og vedlikeholde DataNodes.
- DataNode er en slave-demon og de faktiske dataene lagres her. Det tjener til å lese og skrive forespørsler fra klientene.
- I Hadoop Cluster er faktisk et stativ en gruppe maskiner som er til stede fysisk på et bestemt sted og er koblet til hverandre.
- Hver fil lagres på HDFS som blokker.
- Standardstørrelsen på hver blokk er omtrent 128 MB i Apache Hadoop 2.x (64 MB i forrige versjon, dvs. Apache Hadoop 1.x)
- Det er en mulighet for å øke eller redusere filstørrelsen til blokkene ved hjelp av konfigurasjonsfilen, dvs. hdfssite.xml som følger med Hadoop-pakken.
I neste opplæring om HDFS vil vi lære om HDFS-arkitektur og lese- og skrivemekanismer.
=> Besøk her for å se BigData Training Series for alle.
Anbefalt lesing
- Hva er Hadoop? Apache Hadoop-veiledning for nybegynnere
- Filmanipulering i Unix: Oversikt over Unix File System
- Unix spesialtegn eller metategn for filmanipulering
- Tillatelser til Unix-filtilgang: Unix Chmod, Chown og Chgrp
- Ranorex Test Suite, Test Module Creation, UserCode File, Xpath og Data Binding
- VBScript-filobjekter: CopyFile, DeleteFile, OpenTextFile, Les og skriv tekstfil
- Filinngangsutgangsoperasjoner i C ++
- Java-distribusjon: Opprettelse og utføring av Java JAR-fil