Menu

Hadoop HDFS - Hadoop distribueret filsystem

hadoop hdfs hadoop distributed file system

Prøv Vores Instrument Til At Fjerne Problemer

Denne vejledning forklarer Hadoop HDFS - Hadoop Distribueret filsystem, komponenter og klyngearkitektur. Du vil også lære om Rack Awareness Algorithm:

Som vi lærte i den foregående tutorial, er det største problem med Big Data at gemme det i et eksisterende system. Og selvom vi på en eller anden måde lagrede en del af det i et eksisterende system, tog behandling af BigData flere år.

De ønskede resultater på få minutter tog uger eller måske i måneder, og på grund af dette gik værdien af ​​dette resultat tabt.

=> Hold øje med den enkle BigData-træningsserie her.

Komponenter af Hadoop - HDFS

Hvad du lærer:

Hadoop distribueret filsystem

For at løse dette problem eller for at klare dette problem har vi nu HADOOP. Hadoop løste dette big data-problem ved hjælp af Hadoop HDFS.

lagring af store data

Hadoop HDFS løste opbevaringsproblemet med Big Data og Hadoop-kortreduktion løste problemerne i forbindelse med behandling af en del af Big Data.

Komponenter i Hadoop

Nu ved vi, at Hadoop i det væsentlige har et distribueret filsystem ... MEN HVORFOR?

hvordan man skriver test case i Excel

Hvorfor er Hadoop et distribueret filsystem?

Lad os prøve at forstå, hvad et distribueret filsystem er, og forstå fordelene ved det distribuerede filsystem.

Distribueret filsystem

Lad os tage et eksempel på læsning af 1 TB data. Vi har en server, der er en god high-end server, der har 4 I / O (Input Output) kanaler, og hver kanal har en båndbredde på 100MB / s, ved hjælp af denne maskine, vil du være i stand til at læse denne 1TB data i 43 Protokoller.

Hvis vi nu indbringer 10 antal maskiner nøjagtigt som dette, hvad vil der så ske?

Distribueret filsystem

Tid reduceret til nøjagtigt 4,3 minutter. Det er fordi hele indsatsen blev opdelt i 10 maskiner, og det er derfor, at den tid, der blev taget til at behandle 1 TB data, reduceres til 1/10thdvs. 4,3 minutter.

Tilsvarende, når vi overvejer BigData, bliver disse data opdelt i flere klumper af data, og vi behandler faktisk disse data separat, og det er grunden til, at Hadoop har valgt Distribueret filsystem frem for et centraliseret filsystem.

Komponenter af Hadoop

Hadoop HDFS har 2 hovedkomponenter til at løse problemerne med BigData.

  • Den første komponent er Hadoop HDFS til lagring af store data.
  • Den anden komponent er Hadoop Map Reduce for at behandle store data.

Vigtigste Hadoop-komponenter

Nu når vi ser Hadoop-arkitekturen (billedet nedenfor) har den to vinger, hvor venstrefløjen er 'Opbevaring' og højrefløjen er 'Forarbejdning' . Det betyder, at venstrefløjen er HDFS, dvs. Hadoop Distribution File System, og højrefløjen er GARN og Map Reduce, dvs. er behandlingsdelen.

Ved hjælp af HDFS giver Hadoop os mulighed for at gemme store data og ved hjælp af YARN & Map Reduce giver Hadoop os mulighed for at behandle de samme store data, som vi lagrer i HDFS.

Hadoop-kernekomponenter

Som du kan se på billedet ovenfor, har HDFS to store dæmoner, eller du kan kalde dem som processer eller tråde, der ikke er andet end JAVA-processer, dvs. kører inden for en JVM - NameNode og DataNode.

NameNode er en masterdemon, der kører på Master Machine, dvs. en high-end maskine i det væsentlige, og DataNode er en Slave Machine, der kører på råvarehardware. Der kan være mere DataNode, da Slave Machines er mere end en Master Machine.

Så vi har altid en NameNode og flere DataNode, der kører på Slave Machines.

På samme måde har vi GARN på den anden side, som igen har to dæmoner, den ene er Resource Manager, der kører på Master Machine og Node Manager, der kører på Slave Machine ligesom DataNode. Så hver slave maskine har to dæmoner - den ene er DataNode og den anden er Node Manager.

Master Machine kører NameNode og Resource Manager kører. NameNode er ansvarlig for at administrere dataene på det Hadoop Distribuerede Filsystem, og Ressource Manager er ansvarlig for at udføre behandlingsopgaverne over disse lagrede data.

NameNode og DataNode

Vi går dybt ind i HDFS-arkitektur, og det er derfor vigtigt at forstå, hvad der er en NameNode og en DataNode, da disse er de to hoveddæmoner, der faktisk kører HDFS fuldstændigt.

NameNode

  • Det er en Master Daemon.
  • Administration og vedligeholdelse af DataNodes.
  • Registrerer metadata.
  • Modtager hjerterytme og blokerer rapporter fra alle DataNodes.

DataNode

  • Det er en slave-dæmon.
  • Faktiske data gemmes her.
  • Serverer læse- og skriveanmodninger fra klienterne.

NameNode DataNode

Bare fokuser på diagrammet, som du kan se, er der en central maskinnavnode, der styrer forskellige DataNode, der er der, dvs. råvarehardware. Så Name Node er intet andet end Master Daemon, som vedligeholder al DataNode.

Disse NameNode har alle oplysninger om de data, der er gemt i DataNode. DataNode, som navnet antyder, gemmer de data, der er der i Hadoop-klyngen.

NameNode har kun oplysningerne om, hvilke data der er gemt på hvilken DataNode. Så hvad vi kan sige er, at NameNode gemmer metadataene for de data, der er gemt på DataNodes.

DataNode udfører også en anden opgave, dvs. det sender regelmæssigt hjerterytmen tilbage til NameNode. Heartbeats fortæller faktisk NameNode, at denne DataNode stadig er i live.

For eksempel, DataNodes sender et hjerteslag tilbage til NameNode, og på denne måde har NameNode det billede, at disse DataNodes er i live, så NameNode kan bruge disse DataNode til at gemme flere data eller læse dataene fra disse DataNodes.

Nu kommer vi videre til DataNode, DataNode er intet andet end Slave Daemons, der faktisk lagrer de data, der sendes til Hadoop Cluster. Disse DataNodes er dem, der rent faktisk tjener den læse- og skriveanmodning, der fremsættes af klienterne.

Hvis nogen ønsker at læse dataene fra Hadoop-klyngen, behandles disse anmodninger faktisk af de DataNodes, hvor dataene opholder sig.

Hadoop Cluster Architecture

I det forrige emne relateret til NameNode og DataNode brugte vi udtrykket “Hadoop-klynge”. Lad os se hurtigt på, hvad der præcist er?

Hadoop Cluster Architecture

Ovenstående billede viser oversigten over en Hadoop Cluster Architecture. Hadoop Cluster er intet andet end en Master-Slave Topology, hvor der er en Master Machine, som du kan se på toppen, dvs. Hadoop Cluster. I denne Master Machine er der en NameNode og Resource Manager, der kører, dvs. Master Daemons.

Master Machine er forbundet til alle Slave Machine ved hjælp af Core Switches, det er fordi disse DataNodes faktisk er gemt i forskellige stativer, så som du kan se Computer 1, Computer 2, Computer 3 indtil Computer N. Dette er intet andet end Slave Maskiner eller DataNodes, og de findes alle i et rack.

'Racket er faktisk en gruppe maskiner, der er fysisk til stede et bestemt sted og er forbundet med hinanden.'

Netværksbåndbredden mellem hver maskine er således mindst mulig. Tilsvarende er der flere racks, men de er ikke til stede på samme sted, derfor kan vi have et 'n' antal racks, og vi kan også have 'n' antal DataNodes eller computere eller Slave Machines inden for disse racks.

Sådan fordeles slave-maskinerne faktisk over klyngen, men samtidig er de forbundet med hinanden.

Hvordan gemmes data i HDFS?

Nu bevæger vi os langsomt i detaljerne om, hvordan HDFS fungerer helt. Her vil vi udforske arkitekturen i HDFS.

Når vi siger, at gemme en fil i HDFS, gemmes dataene som Blocks i HDFS. Hele filen er ikke gemt i HDFS, det skyldes, som Hadoop er et distribueret filsystem.

Så hvis du har en filstørrelse på måske 1 PB (Peta Byte), er denne slags lager ikke til stede i en enkelt maskine, da Hadoop-klyngen er lavet ved hjælp af råvarehardwaren. Hardware i en enkelt maskine ville være omkring 1 TB eller 2 TB.

Således skal hele filen opdeles i klumper af data, der kaldes HDFS Blocks.

  • Hver fil gemmes på HDFS som Blocks.
  • Standardstørrelsen på hver blok er ca. 128 MB i Apache Hadoop 2.x (og 64 MB i den tidligere version, dvs. Apache Hadoop 1.x).
  • Der er en mulighed for at øge eller mindske filstørrelsen på blokkene ved hjælp af konfigurationsfilen, dvs. hdfssite.xml, der følger med Hadoop-pakken.

Lad os tage et eksempel for at forstå denne mekanisme og se, hvordan disse blokke oprettes.

Lad os overveje en fil på 248 MB her, nu hvis vi bryder denne fil, eller hvis vi flytter denne fil til Hadoop Cluster dvs. 2.x, så bliver denne fil opdelt i en blok, dvs. Blok A på 128 MB og en anden Blok B på 120 MB.

Som du kan se, er den første blok på 128 MB, dvs. den allerførste plade klipper dernede, og derfor er den anden blok på 120 MB og ikke 128 MB, dvs. det spilder ikke noget plads, hvis den resterende filstørrelse er mindre end standardblokstørrelsen.

Hadoop-klyngeeksempeldiagram

Nu har vi et andet problem foran os, dvs. er det sikkert at have en enkelt kopi af hver blok?

udefineret henvisning til c ++

Svaret er NEJ, fordi der er en chance for, at systemet kan mislykkes, og det er intet andet end råvarehardware, som vi måske har store problemer med. For at løse dette problem har Hadoop HDFS en god løsning, dvs. “Replikering af blok”.

Hadoop Architecture Block Replication

Hadoop opretter replikaer af hver blok, der bliver gemt i Hadoop Distribueret filsystem, og sådan er Hadoop et fejltolerant system, dvs. selvom dit system fejler, eller din DataNode mislykkes, eller en kopi går tabt, har du flere andre kopier findes i de andre DataNodes eller på de andre servere, så du altid kan vælge disse kopier derfra.

Bloker replikering

Som det ses i ovenstående diagram, der repræsenterer blokreplikering, er der fem forskellige blokke af en fil, dvs. blok 1, 2,3,4,5. Lad os først kontrollere med blok 1, så finder du kopier af blok 1 i knude 1, knude 2 og knude 4.

Tilsvarende har blok 2 også fået tre kopier, dvs. knude 2, knude 3 og knude 4 og således den samme for blok 3, 4 og 5 i de respektive knudepunkter.

Så bortset fra replikerne, der bliver oprettet, er hver blok blevet replikeret tre gange, dvs. Hadoop følger en standardreplikationsfaktor på tre, hvilket betyder, at enhver fil, som du kopierer til Hadoop Distribution File System, bliver replikeret tre gange.

Med andre ord, hvis du kopierer 1 GB af en fil til Hadoop Distribution File System, gemmer den faktisk 3 GB af en fil i HDFS. Den gode del er, at standardreplikationsfaktoren kan ændres ved at foretage en ændring i Hadoops konfigurationsfiler.

Hvordan beslutter Hadoop, hvor replikerne skal gemmes?

Hadoop følger faktisk begrebet Rack Awareness for at beslutte, hvor den replika af en blok skal gemmes.

Nedenfor er diagrammet, der viser Rack Awareness Algorithm.

Rack Awareness Algorithm

Der er tre forskellige stativer, dvs. Rack-1, Rack-2 og Rack-3.

Rack-1 har fire DataNodes og det samme gør Rack-2 & Rack-3, således at i alt hele Hadoop Cluster vil bestå af alle de tre racks, og der vil være 12 DataNodes.

Lad os sige, at blok A er kopieret på DataNode 1 i Rack-1, ifølge konceptet Rack Awareness kan repliken af ​​Block A ikke oprettes i samme rack, og den skal oprettes i ethvert andet rack bortset fra Rack-1 som hovedfilen findes allerede i Rack-1.

Hvis vi opretter replikaer af Blok A i samme Rack-1, og hvis hele Rack-1 fejler, end vi mister dataene med sikkerhed, skal replikerne derfor gemmes i ethvert andet rack, men ikke i Rack-1.

Så repliken oprettes i DataNode 6 og 8 i Rack-2. Tilsvarende, for blok B og blok C, oprettes replikerne i forskellige stativer, som vist i ovenstående diagram.

Konklusion

Vi lærte med følgende henvisninger fra denne tutorial-

  • Hadoop HDFS løser opbevaringsproblemet med BigData.
  • Hadoop Map Reduce løser problemerne i forbindelse med behandlingen af ​​BigData.
  • NameNode er en Master Daemon og bruges til at administrere og vedligeholde DataNodes.
  • DataNode er en Slave-dæmon, og de faktiske data gemmes her. Det tjener til at læse og skrive anmodninger fra klienterne.
  • I Hadoop Cluster er et rack faktisk en gruppe maskiner, der er til stede fysisk på et bestemt sted og er forbundet med hinanden.
  • Hver fil gemmes på HDFS som Blocks.
  • Standardstørrelsen på hver blok er ca. 128 MB i Apache Hadoop 2.x (64 MB i den tidligere version, dvs. Apache Hadoop 1.x)
  • Der er en mulighed for at øge eller mindske filstørrelsen på blokkene ved hjælp af konfigurationsfilen, dvs. hdfssite.xml, der følger med Hadoop-pakken.

I den næste tutorial om HDFS lærer vi om HDFS-arkitektur og læse- og skrivemekanismer.

=> Besøg her for at se BigData-træningsserien for alle.

Anbefalet læsning

^