Hadoop 2.0 kopu arhitektūras federācijas pārskats

Hadoop 2.0 kopu arhitektūras federācija

Ievads:

Šajā emuārā es dziļi ieniršu Hadoop 2.0 Cluster Architecture Federation. Apache Hadoop ir daudz attīstījies kopš Apache Hadoop 1.x izlaišanas. Kā jūs zināt no mana iepriekšējā emuāra, ka seko Master / Slave topoloģijai, kur NameNode darbojas kā galvenais dēmons un ir atbildīgs par citu vergu mezglu, ko sauc par DataNodes, pārvaldību. Šajā ekosistēmā šis vienotais galvenais dēmons vai NameNode kļūst par sašaurinājumu, un gluži pretēji, uzņēmumiem ir jābūt NameNode, kas ir ļoti pieejams. Šis iemesls kļuva par HDFS federācijas arhitektūras pamatu un HA (augstas pieejamības) arhitektūra .

Šajā emuārā apskatītās tēmas ir šādas:

• Pašreizējā HDFS arhitektūra
• Pašreizējās HDFS arhitektūras ierobežojumi
• HDFS federācijas arhitektūra

Pašreizējās HDFS arhitektūras pārskats:

Kā redzat attēlā iepriekš, pašreizējam HDFS ir divi slāņi:

• HDFS nosaukumvieta (NS): Šis slānis ir atbildīgs par direktoriju, failu un bloku pārvaldību. Tas nodrošina visas failu sistēmas darbības, kas saistītas ar nosaukumvietu, piemēram, failu vai failu direktoriju izveidošanu, dzēšanu vai modificēšanu.
• Krātuves slānis: Tas sastāv no divām pamatkomponentēm.
  1. Bloku pārvaldība : Tas veic šādas darbības:
     • Periodiski pārbauda DataNodes sirdsdarbību un tā pārvalda DataNode dalību klasterī.
     • Pārvalda bloķēšanas pārskatus un uztur bloka atrašanās vietu.
     • Atbalsta bloku darbības, piemēram, bloka atrašanās vietas izveidošanu, modificēšanu, dzēšanu un piešķiršanu.
     • Uztur replikācijas koeficientu, kas konsekvents visā klasterī.

2. Fiziskā uzglabāšana : To pārvalda DataNodes, kas ir atbildīgi par datu glabāšanu un tādējādi nodrošina lasīšanas / rakstīšanas piekļuvi HDFS saglabātajiem datiem.

Tātad pašreizējā HDFS arhitektūra ļauj jums izveidot vienu kopu nosaukumvietu. Šajā arhitektūrā par nosaukumvietas pārvaldību ir atbildīgs viens NameNode. Šī arhitektūra ir ļoti ērta un viegli īstenojama. Turklāt tas nodrošina pietiekamu spēju apmierināt mazās ražošanas kopas vajadzības.

Pašreizējā HDFS ierobežojumi:

Kā tika apspriests iepriekš, pašreizējais HDFS bija pietiekams neliela ražošanas klastera vajadzībām un izmantošanas gadījumiem. Bet lielas organizācijas, piemēram, Yahoo, Facebook atrada dažus ierobežojumus, jo HDFS kopa strauji auga. Ļaujiet mums ātri apskatīt dažus ierobežojumus:

1. Vārdamvieta ir nav mērogojams tāpat kā DataNodes. Tādējādi klasterī var būt tikai tāds skaits DataNodes, ko var apstrādāt viens NameNode.
2. Divi slāņi, t.i., nosaukumvietas slānis un krātuves slānis ir cieši savienoti kas ļoti apgrūtina NameNode alternatīvo ieviešanu.
3. Visas Hadoop sistēmas veiktspēja ir atkarīga no caurlaidspēja no NameNode. Tāpēc visu HDFS darbību darbība ir atkarīga no tā, cik daudz uzdevumu NameNode var apstrādāt noteiktā laikā.
4. Lai ātri piekļūtu, NameNode saglabā visu nosaukumvietu RAM. Tas noved pie ierobežojumiem attiecībā uz atmiņas lielums i., to nosaukumvietas objektu (failu un bloku) skaits, ar kuriem var tikt galā viens nosaukumvietas serveris.
5. Daudzas organizācijas (pārdevēji), kurām ir HDFS izvietošana, ļauj vairākām organizācijām (nomniekiem) izmantot savu kopu nosaukumvietu. Tātad, nosaukumvieta nav nošķirta, un tāpēc tā ir nav izolācijas starp īrnieku organizācijām, kas izmanto kopu.

HDFS federācijas arhitektūra:

• HDFS federācijas arhitektūrā mums ir horizontāla vārdu pakalpojuma mērogojamība. Tāpēc mums ir vairāki NameNodes, kas ir apvienoti, t.i., neatkarīgi viens no otra.
• DataNodes atrodas apakšā, t.i., pamatā esošais krātuves slānis.
• Katrs DataNode reģistrējas ar visiem klastera NameNodes.
• DataNodes periodiski pārraida sirdsdarbību, bloķē pārskatus un apstrādā komandas no NameNodes.

HDFS federācijas arhitektūras attēlojums ir sniegts zemāk:

java izveidot objektu masīvu

Pirms virzīties uz priekšu, ļaujiet man īsi parunāt par iepriekš minēto arhitektūras attēlu:

• Ir vairākas nosaukumvietas (NS1, NS2,…, NSn), un katru no tām vada attiecīgais NameNode.
• Katrai nosaukumvietai ir savs bloku kopa (NS1 ir 1. kopa, NSk ir Pool Pool un tā tālāk).
• Kā redzams attēlā, bloki no 1. baseina (debeszilā krāsā) tiek glabāti DataNode 1, DataNode 2 un tā tālāk. Līdzīgi visi bloki no katra bloka kopas atradīsies visos DataNodes.

Ļaujiet mums detalizēti izprast HDFS federācijas arhitektūras komponentus:

Bloķēt baseinu:

Bloku kopa nav nekas cits kā bloku kopums, kas pieder konkrētai nosaukumvietai. Tātad, mums ir bloku kopa, kur katrs bloka kopa tiek pārvaldīta neatkarīgi no otra. Šī neatkarība, kad katrs bloku kopa tiek pārvaldīta neatkarīgi, ļauj nosaukumvietai izveidot bloku ID jauniem blokiem bez saskaņošanas ar citām nosaukumvietām. Datu bloki, kas atrodas visos bloku portfeļos, tiek glabāti visos DataNodes. Būtībā bloku kopa nodrošina tādu abstrakciju, ka datu blokus, kas atrodas DataNodes (tāpat kā vienotās nosaukumvietas arhitektūrā), var sagrupēt atbilstoši noteiktai vārdam.

Vārdvietas apjoms:

Vārdtelpas apjoms nav nekas cits kā nosaukumvieta kopā ar tās bloku kopu. Tāpēc HDFS federācijā mums ir vairāki nosaukumvietas apjomi. Tā ir patstāvīga vadības vienība, t.i., katrs vārda vietas apjoms var darboties neatkarīgi. Ja NameNode vai nosaukumvieta tiek izdzēsta, tiks izdzēsts arī atbilstošais bloka kopa, kas atrodas DataNodes.

Demonstrācija par Hadoop 2.0 kopu arhitektūras federāciju Edureka

Tagad es domāju, ka jums ir diezgan laba ideja par HDFS federācijas arhitektūru. Tas drīzāk ir teorētisks jēdziens, un cilvēki to praktiski neizmanto praktiskajā ražošanas sistēmā. HDFS federācijā ir dažas ieviešanas problēmas, kas apgrūtina izvietošanu. Tāpēc HA (augstas pieejamības) arhitektūra ir vēlams, lai atrisinātu viena kļūmes punkta problēmu. Es esmu aptvēris HDFS HA ​​arhitektūra manā nākamajā emuārā.

Tagad, kad esat sapratis Hadoop HDFS federācijas arhitektūru, pārbaudiet Autors: Edureka, uzticams tiešsaistes mācību uzņēmums ar vairāk nekā 250 000 apmierinātu izglītojamo tīklu visā pasaulē. Edureka Big Data Hadoop sertifikācijas apmācības kurss palīdz izglītojamajiem kļūt par HDFS, dzijas, MapReduce, Pig, Hive, HBase, Oozie, Flume un Sqoop ekspertiem, izmantojot reāllaika lietošanas gadījumus mazumtirdzniecības, sociālo mediju, aviācijas, tūrisma, finanšu jomā.

Vai mums ir jautājums? Lūdzu, pieminējiet to komentāru sadaļā, un mēs ar jums sazināsimies.