Prezentare generală a Hadoop 2.0 Cluster Architecture Federation



Apache Hadoop 2.x constă în îmbunătățiri semnificative față de Hadoop 1.x. Acest blog vorbește despre Hadoop 2.0 Cluster Architecture Federation și componentele sale.

Federația Hadoop 2.0 Cluster Architecture

Introducere:

În acest blog, mă voi scufunda profund în Hadoop 2.0 Cluster Architecture Federation. Apache Hadoop a evoluat foarte mult de la lansarea Apache Hadoop 1.x. După cum știți din blogul meu anterior că urmează Topologia Master / Slave unde NameNode acționează ca un demon master și este responsabil pentru gestionarea altor noduri slave numite DataNodes. În acest ecosistem, acest singur Master Daemon sau NameNode devine un blocaj și, dimpotrivă, companiile trebuie să aibă NameNode care este extrem de disponibil. Tocmai din acest motiv a devenit baza HDFS Federation Architecture și Arhitectură HA (Disponibilitate înaltă) .

Subiectele pe care le-am abordat în acest blog sunt următoarele:





  • Arhitectura HDFS actuală
  • Limitări ale arhitecturii HDFS actuale
  • Arhitectura Federației HDFS

Prezentare generală a arhitecturii HDFS actuale:

Arhitectură single namespace HDFS - Prezentare generală a Hadoop 2.0 Cluster Architecture Federation - Edureka

implementarea listei legate în c

După cum puteți vedea în figura de mai sus, HDFS-ul curent are două straturi:



  • Spațiu de nume HDFS (NS): Acest strat este responsabil pentru gestionarea directoarelor, fișierelor și blocurilor. Oferă toate operațiunile sistemului de fișiere legate de spațiul de nume, cum ar fi crearea, ștergerea sau modificarea fișierelor sau a directoarelor de fișiere.
  • Strat de stocare: Acesta cuprinde două componente de bază.
    1. Managementul blocurilor : Efectuează următoarele operațiuni:
      • Verifică periodic bătăile inimii DataNodes și gestionează calitatea de membru DataNode la cluster.
      • Gestionează rapoartele de bloc și menține locația blocului.
      • Suportă operații de blocare, cum ar fi crearea, modificarea, ștergerea și alocarea locației blocului.
      • Menține factorul de replicare consistent în întregul cluster.

2. Stocare fizică : Este gestionat de DataNodes care sunt responsabili pentru stocarea datelor și, prin urmare, oferă acces de citire / scriere la datele stocate în HDFS.

Deci, actuala arhitectură HDFS vă permite să aveți un singur spațiu de nume pentru un cluster. În această arhitectură, un singur NameNode este responsabil pentru gestionarea spațiului de nume. Această arhitectură este foarte convenabilă și ușor de implementat. De asemenea, oferă o capacitate suficientă pentru a satisface nevoile grupului mic de producție.

Limitări ale HDFS curente:

După cum sa discutat anterior, HDFS-ul actual a fost suficient pentru nevoile și cazurile de utilizare ale unui mic cluster de producție. Dar, organizațiile mari, cum ar fi Yahoo, Facebook au găsit unele limitări pe măsură ce clusterul HDFS a crescut exponențial. Să ne uităm rapid la câteva dintre limitări:



  1. Spațiul de nume este nu scalabil precum DataNodes. Prin urmare, putem avea doar acel număr de DataNodes din cluster pe care un singur NameNode îl poate gestiona.
  2. Cele două straturi, adică stratul spațiului de nume și stratul de stocare sunt strans cuplate ceea ce face ca implementarea alternativă a NameNode să fie foarte dificilă.
  3. Performanța întregului sistem Hadoop depinde de debit a NameNode. Prin urmare, întreaga performanță a tuturor operațiunilor HDFS depinde de câte sarcini poate face NameNode la un anumit moment.
  4. NameNode stochează întregul spațiu de nume în RAM pentru acces rapid. Acest lucru duce la limitări în ceea ce privește Capacitate de memorie Adică numărul de obiecte ale spațiului de nume (fișiere și blocuri) cu care poate face față un singur server de spațiu de nume.
  5. Multe dintre organizațiile (furnizor) care au implementare HDFS, permit mai multor organizații (chiriaș) să își folosească spațiul de nume cluster. Deci, nu există o separare a spațiului de nume și, prin urmare, există nici o izolare printre organizațiile de chiriași care utilizează clusterul.

Arhitectura Federației HDFS:

  • În HDFS Federation Architecture, avem scalabilitate orizontală a serviciului de nume. Prin urmare, avem mai multe NameNodes care sunt federate, adică independente unul de celălalt.
  • DataNodes sunt prezente în partea de jos, adică stratul de stocare subiacent.
  • Fiecare DataNode se înregistrează cu toate NameNodes din cluster.
  • DataNodes transmit periodic bătăi ale inimii, blochează rapoarte și gestionează comenzile de la NameNodes.

Reprezentarea picturală a Arhitecturii Federației HDFS este dată mai jos:

Înainte de a merge mai departe, permiteți-mi să vorbesc pe scurt despre imaginea arhitecturală de mai sus:

doar la timp compilatorul Java
  • Există mai multe spații de nume (NS1, NS2, ..., NSn) și fiecare dintre ele este gestionat de către NameNode-ul respectiv.
  • Fiecare spațiu de nume are propriul grup de blocuri (NS1 are Pool 1, NSk are Pool k și așa mai departe).
  • Așa cum se arată în imagine, blocurile din piscina 1 (albastru deschis) sunt stocate pe DataNode 1, DataNode 2 și așa mai departe. În mod similar, toate blocurile din fiecare pool de blocuri vor locui pe toate DataNodes.

Acum, să înțelegem în detaliu componentele arhitecturii federației HDFS:

Blocare piscină:

Blocul de blocuri nu este altceva decât un set de blocuri care aparțin unui anumit spațiu de nume. Deci, avem o colecție de blocuri de blocuri în care fiecare bloc de blocuri este gestionat independent de celălalt. Această independență în care fiecare pool de blocuri este gestionat independent permite spațiului de nume să creeze ID-uri de blocuri pentru blocuri noi fără coordonarea cu alte spații de nume. Blocurile de date prezente în întregul pool de blocuri sunt stocate în toate DataNodes. Practic, grupul de blocuri oferă o abstracție astfel încât blocurile de date care se află în DataNodes (ca în arhitectura spațiului de nume unic) pot fi grupate corespunzător unui anumit spațiu de nume.

Volumul spațiului de nume:

Volumul spațiului de nume nu este altceva decât spațiul de nume împreună cu grupul său de blocuri. Prin urmare, în Federația HDFS avem mai multe volume de spațiu de nume. Este o unitate de gestionare autonomă, adică Fiecare volum al spațiului de nume poate funcționa independent. Dacă un NameNode sau un spațiu de nume este șters, grupul de blocuri corespunzător care se află pe DataNodes va fi, de asemenea, șters.

sortare c ++ stl

Demo On Hadoop 2.0 Cluster Architecture Federation | Edureka

Acum, cred că aveți o idee destul de bună despre HDFS Federation Architecture. Este mai mult un concept teoretic și oamenii nu îl folosesc în general într-un sistem practic de producție. Există unele probleme de implementare cu Federația HDFS care îngreunează implementarea. De aceea Arhitectură HA (Disponibilitate înaltă) este preferat pentru a rezolva problema punctului unic de eșec. Am acoperit Arhitectură HDFS HA în următorul meu blog.

Acum că ați înțeles Hadoop HDFS Federation Architecture, verificați de Edureka, o companie de învățare online de încredere, cu o rețea de peste 250.000 de elevi mulțumiți răspândiți pe tot globul. Cursul Edureka Big Data Hadoop Certification Training îi ajută pe cursanți să devină experți în HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume și Sqoop folosind cazuri de utilizare în timp real în domeniul Retail, Social Media, Aviație, Turism, Finanțe.

Ai o întrebare pentru noi? Vă rugăm să o menționați în secțiunea de comentarii și vă vom răspunde.