HDFS este un sistem de fişiere distribuit implementat în cadrul Hadoop, diferenţa faţă de alte sisteme de fişiere de acest tip constând în faptul că este proiectat să ruleze pe dispozitive mai puţin performante, fiind capabil să gestioneze în mod coerent erorile. De asemenea, oferă un nivel de accesibilitate ridicat la datele aplicaţiei, fiind adecvat pentru aplicaţii care utilizează un volum de date de dimensiuni foarte mari. Pentru utilizator, sistemul de fişiere apare ca un singur disc, rulând peste sistemele de fişiere locale (ext4, xfs) şi fiind bazat pe conceptele dezvoltate de sistemul de fişiere Google (GFS).

Presupunerile de la care a plecat proiectarea sistemului de fişiere distribuit HDFS sunt:

• erorile produse datorită hardware-ului reprezintă mai degrabă norma decât o excepţie, de vreme ce o instanţă HDFS conţine sute sau mii de servere, fiecare stocând o parte a datelor sistemului de fişiere, fiind caracterizat printr-o probabilitate de eroare non-trivială; astfel, detecţia erorilor şi recuperarea rapidă din acestea reprezintă un obiectiv pe care şi-l propune arhitectura HDFS;

• trebuie puse la dispoziţie fluxuri de acces la date de vreme ce aplicaţiile care utilizează HDFS sunt destinate prelucrării unor seturi de date mai degrabă decât interacţiunii cu utilizatorul; de aceea, accentul se pune pe asigurarea unei rate de acces de nivel înalt mai degrabă decât pe latenţa scăzută a accesului la date;

• procesarea unor seturi de date de dimensiuni mari, atingând valori de ordinul gigaocteţilor sau teraocteţilor; astfel, trebuie asigurate lăţimi de bandă agregate cât mai mari cât şi scalabilitatea pentru sute de noduri într-un cluster; un sistem distribuit de fişiere HDFS trebuie să suporte zeci de milioane de fişiere într-o singură instanţă;
• implementarea unui model de coerenţă simplu, folosind un model de acces la fişiere de tip scrie o singură dată citeşte de mai multe ori: un fişier, odată ce este creat, nu mai trebuie să fie modificat, putând fi însă accesat de mai multe ori; o astfel de presupunere simplifică problemele legate de coerenţă, permiţând asigurarea unor rate de acces la date de nivel înalt;

• relocarea dispozitivelor de procesare este mai ieftină decât mutarea datelor iar procesarea datelor este mult mai eficientă în cazul în care este executată pe aceeaşi maşină, cu atât mai mult cu cât volumul de informaţii este foarte mare; în acest fel este evitată congestia reţelei iar rata de transfer a sistemului este îmbunătăţită; de aceea HDFS oferă interfeţe astfel încât aplicaţiile să poată fi relocate unde se află datele;
• asigurarea portabilităţii între platforme hardware şi software eterogene permite adoptarea HDFS pe scară largă pentru un set de aplicaţii cât mai variat.

Arhitectura HDFS este de tip master – slave şi conţine un nod de nume (eng. NameNode), server ce gestionează spaţiul de nume al sistemului de fişiere, reglementând accesul la fişiere şi mai multe noduri de date (eng. DataNode, de regulă unul pentru fiecare nod din cluster), client ce gestionează spaţiul de stocare ataşat nodurilor pe care rulează. În plus faţă de acestea mai există şi un nod de nume secundar (eng. Secondary NameNode) care se ocupă mai ales cu întreţinerea sistemului distribuit de fişiere, astfel încât acest proces să nu fie realizat doar la nivelul nodului de nume. Acesta nu este utilizat pentru asigurarea unui nivel de disponibilitate ridicat şi nici nu funcţionează ca rezervă pentru nodul de nume. Deşi pentru utilizator spaţiul de nume este vizualizat unitar, permiţând operaţiile uzuale de încărcare şi descărcare de fişiere (ca pentru orice sistem de fişiere), implementarea HDFS presupune împărţirea acestora în blocuri care sunt stocate în mai multe noduri de date. Dacă nodul de nume se ocupă cu operaţii legate de spaţiul de nume al sistemului de fişiere (deschidere, închidere, redenumire fişiere şi directoare), determinând şi maparea blocurilor la nodurile de date, nodurile de date au rolul de a trata cererile de citire şi de scriere ce provin de la utilizatori, realizând şi crearea şi ştergerea de blocuri, respectiv replicarea, în funcţie de instrucţiunile ce provin de la nodul de nume.

Atât nodul de nume cât şi nodul de date sunt programe scrise în Java, astfel încât pot să ruleze pe cât mai multe platforme. Tipic, nodul de nume rulează pe un server dedicat, în timp ce toate celelalte maşini din cluster conţin o instanţă a nodului de date. Există şi posibilitatea ca pe o singură maşină să existe mai multe instanţe ale nodului de date, însă un astfel de caz este destul de rar. Situaţii de acest tip pot fi întâlnite în situaţia în care se doreşte separarea seturilor de date provenind de la aplicaţii diferite. Existenţa unui singur nod de nume într-un cluster simplifică foarte mult arhitectura sistemului, întrucât nodul de nume negociază utilizarea resurselor şi reţine toate metadatele cu privire la fişierele stocate. Toate datele provenite de la utilizator sunt prelucrate neapărat de nodul de date.

Aşadar, arhitectura HDFS este organizată pe două niveluri:

1. spaţiul de nume, în care este reţinută structura logică a sistemului de fişiere, constând în directoare, fişiere şi blocuri;
2. serviciul de stocare a blocurilor, format la rândul său din 2 componente:
   1. gestiunea blocurilor (implementată în nodul de nume) realizată prin stabilirea apartenenţei unui nod de date la cluster prin tratarea operaţiilor de înregistrare şi a mesajelor transmise periodic, procesarea rapoartelor cu privire la blocuri şi întreţinerea locaţiei la care sunt stocate acestea, implementarea operaţiilor legate de blocuri (creare, modificare, ştergere şi obţinerea locaţiei), gestiunea plasării replicilor (replicarea blocurilor pentru care nu este întrunit factorul de replicare şi ştergerea blocurilor pentru care este depăşit factorul de replicare);
   2. stocarea – oferită de nodurile de date prin stocarea blocurilor în cadrul sistemului local de fişiere, permiţând accesul la operaţii de citire/scriere.

În mod tradiţional, HDFS implementează o organizare a fişierelor de tip ierarhic, astfel încât un utilizator sau o aplicaţie pot crea directoare, stocând fişiere în cadrul acestora. Operaţiile suportate sunt de creare şi ştergere fişiere, relocarea unui fişier dintr-un director într-altul precum şi redenumirea unui fişier. Nu sunt implementate cote pentru utilizatori şi permisiuni de acces, dar nici obiecte de tip legătură (hard sau soft). Întreţinerea spaţiului de nume pentru sistemul distribuit de fişiere este realizat de către nodul de nume astfel că acesta înregistrează orice schimbare operată asupra sa sau proprietăţilor sale.

HDFS este proiectat pentru a stoca fişiere de dimensiuni foarte mari distribuite pe maşini în cadrul unui cluster ce conţine numeroase maşini. Astfel, fiecare fişier este reţinut ca o secvenţă de blocuri, de dimensiuni egale, fiecare dintre acestea fiind replicate pentru asigurarea toleranţei în cazul producerii de erori.

O aplicaţie poate specifica numărul de replici ale unui fişier ce ar trebui întreţinute de HDFS precum şi dimensiunea blocului. Aceste valori pot fi modificate ulterior.

Fişierele pot fi scrise o singură dată şi de către un singur proces la un moment dat de timp. Deciziile referitoare la replicarea unor blocuri sunt luate doar de nodul de nume. Acesta primeşte periodic rapoarte cu privire la blocuri de la fiecare nod de date din cluster, aceasta implicând funcţionarea corespunzătpare a nodului de date respectiv. Perioada între care se transmit rapoartele cu privire la blocurile conţinute de nodurile de date se numeşte bătaie de inimă (eng. heartbeat). Un raport conţine lista tuturor blocurile reţinute de un nod de date.

Modul în care sunt plasate replicile de către nodul de nume este esenţial pentru siguranţa şi performanţa HDFS motiv pentru care în implementarea acestui sistem distribuit de fişiere s-a pus în mod deosebit accentul pe optimizarea acestui proces. Deşi politica de distribuţie a replicilor nu a ajuns încă la forma finală, s-au realizat etape importante în dezvoltarea acesteia prin identificarea unui criteriu legat de rastelul (eng. rack) pe care se găseşte blocul ce se doreşte a fi replicat. Astfel, se are în vedere îmbunătăţirea disponibilităţii dar şi al utilizării lăţimii de bandă. Localizarea replicilor trebuie să ţină cont de faptul că lăţimea de bandă între două noduri ce aparţin unor rasteluri diferite este mai mică decât lăţimea de bandă între două noduri care fac parte din acelaşi rastel. Astfel, în cazul implicit (nivelul de replicare 3), politica de plasare a replicilor a HDFS este de stoca o replică pe un nod făcând parte din rastelul local, altă replică pe un alt nod din acelaşi rastel şi o alta pe un nod diferit dintr-un rastel diferit. În acest mod, se optimizează traficul între rasteluri diferite, îmbunătăţindu-se performanţa operaţiilor de scriere. Probabilitatea ca întregul rastel să nu fie disponibil datorită unei erori este mult mai mică decât cea ca un singur nod din cadrul rastelului să se defecteze, astfel că o acest tip de politică nu afectează garanţiile cu privire la disponibilitatea datelor. Totodată, se reduce lăţimea de bandă agregată când sunt citite datele, întrucât același bloc este plasat pe două rasteluri (în loc de trei). Printr-o astfel de politică, fişierul nu este distribuit în mod uniform în cadrul rastelurilor din cluster. Astfel, o treime dintre replici se găsesc pe nodul local, două treimi dintre replici sunt plasate pe rastelul local, cealaltă treime dintre replici fiind distribuite uniform de-a lungul celorlalte rasteluri.

Prin urmare, politica de distribuire a replicilor în cadrul clusterului îmbunătăţeşte performanţa operaţiei de scriere fără a se compromite nici siguranţa datelor şi nici performanţa operaţiei de scriere.

Pentru a se minimiza consumul global al lăţimii de bandă dar şi latenţa pentru operaţiile de citire, o citire de date se va realiza din locaţia cea mai apropiată de utilizatorul care a realizat o astfel de cerere. Astfel, în cazul în care există o replică pe acelaşi rastel ca nodul care realizează citirea, aceasta va fi preferată unei replici care se găseşte la distanţă.

La pornirea sistemului distribuit de fişiere HDFS, nodul de nume intră într-o stare specială denumită mod de siguranţă (eng. safemode) în care nu are loc replicarea de blocuri de date. În această stare, nodul de nume primeşte mesaje de la nodurile de date conţinând rapoarte cu privire la blocurile pe care le conţin fiecare din ele. Pentru fiecare bloc de date se specifică un număr minim de replici, el fiind considerat ca fiind replicat în siguranţă dacă nodul de nume a primit de la nodurile de date rapoarte cu privire la întrunirea acestei valori. Părăsirea modului se siguranţă se face numai după ce există un anumit procent (configurabil) de blocuri care sunt replicate în siguranţă. După depăşirea pragului cu privire la blocurile care sunt replicate în siguranţă, trebuie să mai treacă încă 30 de secunde după care se realizează trecerea din modul de siguranţă în starea de operare obişnuită. Doar în acest moment, nodul de nume identifică blocurile de date care nu dispun de un număr de replici suficiente şi realizează replicarea lor către nodurile de date.

În sistemul distribuit de fişiere HDFS, spaţiul de nume este reţinut de nodul de nume care utilizează în acest scop un jurnal de tranzacţii (EditLog) pentru a reţine în mod persistent fiecare schimbare care se realizează la nivelul metadatelor. Operaţii precum crearea unui fişier sau modificarea factorului de replicare al unui fişier determină introducerea unei înregistrări în jurnalul de tranzacţii. Întregul spaţiu de nume al sistemului distribuit de fişiere (inclusiv maparea blocurilor de date la fişiere şi proprietăţile sistemului) se reţin într-un fişier denumit FsImage.

Imaginea spaţiului de nume a sistemului distribuit de fişiere, împreună cu fişierul Blockmap sunt încărcate în memorie, proiectarea acestora fiind suficient de compactă astfel încât o maşină ce dispune de 4 GB de memorie RAM să poată reţine informaţii despre un număr mare de fişiere şi directoare. La pornirea nodului de nume, acesta citeşte fişierele EditLog şi FsImage de pe disc, aplică toate tranzacţiile reprezentării încărcate în memorie a sistemului distribuit de fişiere, rezultatul obţinut fiind stocat şi pe disc sub forma unui fişier FsImage, eliminând din fişierul EditLog operaţiile care au fost deja reţinute persistent. Acest proces se numeşte punct de control (eng. checkpoint).

Un nod de date stochează informaţiile HDFS în sistemele de fişiere locale, fiecărui bloc corespunzându-i un anume fişier fără a se cunoaşte semnificaţia sa din perspectiva sistemului distribuit de fişiere. La pornirea nodului de date, sistemul local de fişiere este parcurs, generându-se lista blocurilor de date HDFS ce corespund fiecărui fişier, pe baza acesteia generându-se raportul transmis nodului de nume.

Un nod de date nu stochează toate fişierele în acelaşi director, întrucât pentru sistemul local de fişiere poate fi dificil să gestioneze în mod eficient un număr mare de fişiere localizate într-o singură locaţie. Din acest motiv, este utilizată o euristică pentru a determina numărul optim de fişiere din cadrul unui singur director, creând subdirectoare în mod corespunzător.

Toate protocoalele de comunicaţii din cadrul sistemului distribuit de fişiere HDFS sunt bazate pe protocolul TCP/IP. Un client realizează o conexiune către nodul de nume pe un port (configurabil), transmisia de date făcându-se folosind protocolul ClientProtocol, la fel cum nodul de date comunică cu nodul de nume folosind protocolul DataNodeProtocol, acestea fiind abstractizate sub forma unor apeluri la distanţă (eng. Remote Procedure Call). Prin proiectare, nodul de nume nu iniţiază niciodată apeluri la distanţă ci doar răspunde la astfel de apeluri transmise de clienţi sau noduri de date.

Obiectivul sistemului distribuit de fişiere HDFS este reprezentat de robusteţe, adică de a stoca datele în mod sigur chiar şi în situaţia în care au loc anumite defecţiuni. Cele mai frecvente tipuri de defecţiuni sunt datorate erorilor la nivelul nodului de nume, la nivelul nodurilor de date respectiv partiţiilor reţelei de calculatoare.

O defecţiune la nivelul nodului de nume poate fi legată de coruperea fişierelor EditLog sau FsImage, care sunt structuri de date centrale ale HDFS. O astfel de situaţie poate determina ca instanţa HDFS să nu mai fie funcţională. Din acest motiv, nodul de nume poate fi configurat astfel încât să întreţină mai multe copii ale acestor fişiere. Astfel, orice modificare realizată la nivelul acestor fişiere va determina propagarea actualizărilor spre copii în mod sincron. La pornirea nodului de nume, sunt selectate cele mai recente versiuni consistente ale fişierelor EditLog sau FsImage pentru a fi utilizate. Maşina care găzduieşte nodul de nume reprezintă singura cauză care poate determina defecţiunea întregului cluster HDFS, fiind necesară intervenţia manuală, de vreme ce repornirea automată sau utilizarea unui nod de siguranţă nu sunt implementate.

Există posibilitatea ca un bloc de date ce provine de la un nod de date să fie corupt, datorită unor defecţiuni produse la nivelul dispozitivului de stocare, unor erori de reţea sau al unor probleme la nivelul aplicaţiilor. Din acest motiv, HDFS implementează sume de control pentru a verifica conţinutul fişierelor. De fiecare dată când este creat un fişier, se calculează şi sumele de control pentru fiecare bloc al fişierului, acestea fiind stocate în fişiere separate (ascunse) în acelaşi spaţiu de nume. Astfel, atunci când un client primeşte un fişier, verifică şi faptul că datele transmise de fiecare nod de date corespund sumei de control stocate în fişierul asociat. În cazul în care s-a produs o eroare, clientul poate opta pentru a primi blocul de la un alt nod de date ce conţine replica blocului respectiv.

Fiecare nod de date transmite periodic mesaje nodului de nume conţinând rapoate cu privire la blocurile conţinute. O defecţiune produsă la nivelul unei partiţii a reţelei de calculatoare poate face ca unele noduri de date să îşi piardă conectivitatea cu nodul de nume. Acest fapt este detectat prin lipsa mesajelor care ar fi fost transmise în mod normal, astfel încât nodurile de date respective vor fi marcate ca nefuncţionale, astfel încât nu se vor mai realiza cereri pentru operaţii de intrare / ieşire faţă de acestea, replicându-se corespunzător blocurile de date pe care le gestionau.

Arhitectura HDFS este compatibilă cu unele mecanisme de echilibrare (neimplementate încă în versiunea curentă). Astfel, datele vor fi mutate de pe un nod de date pe altul dacă spaţiul disponibil scade sub un anumit prag. De asemenea, în situaţia în care se înregistrează o cerere pentru un anumit fişier din partea mai multor clienţi, se vor crea replici suplimentare, echilibrându-se celelalte date din cadrul clusterului.

De asemenea, vor fi implementate şi instantanee (eng. snapshots), reprezentând copii ale unor date la un moment dat de timp, acestea putând fi utilizate atunci când instanţa HDFS este coruptă, astfel încât să se poată reveni la cea mai recentă configuraţie funcţională, realizându-se recuperarea din eroare cât mai rapid.

O cerere cu privire la crearea unui fişier nu este transmisă instantaneu nodului de nume, informaţiile fiind reținute în fişiere locale temporare până când acestea stochează date ce au o dimensiune echivalentă dimensiunii unui bloc de date. Doar în acest moment este contactat nodul de date care adaugă fişierul la ierarhia sistemului distribuit de fişiere, alocând un bloc de date corespunzător într-un nod de date pe care îl transmite clientului ca răspuns la cererea sa. Ulterior, clientul va transfera informaţiile din fişierul local temporar către nodul de date indicat şi când această operaţie se încheie, nodul de nume înregistrează crearea fişierului ca fiind persistentă. Stocarea temporară a fişierelor pe client este datorată faptului că aplicaţiile care utilizează HDFS au nevoie de fluxuri pentru scriere în fişiere şi în cazul în care un astfel de comportament nu ar fi adoptat, viteza la care operează reţeaua de calculatoare şi congestia ar avea un impact considerabil asupra ratei de transfer, diminuând performanţele încărcării de fişiere.

În momentul în care un client scrie date într-un fişier HDFS, el va primi de la nodul de nume lista nodurilor de date care vor stoca replici ale blocului în cauză. Transferul se va face în secvenţe de 4KB care după ce vor fi stocate de nodul de date, vor fi transmise mai departe următorului nod de date ce va reţine o replică a blocului de date respectiv (în cazul în care secvenţa din blocul de date nu a ajuns încă la toate nodurile de date ce vor conţine replici). Blocurile sunt astfel transmise între nodurile de date care vor reţine replicile sale printr-un mecanism de tip bandă de asamblare.

Similar, atunci când un fişier este şters de un utilizator sau o aplicaţie, acesta nu este îndepărtat din sistemul distribuit de fişiere HDFS ci transferat (pentru o perioadă de timp) în directorul /trash de unde poate fi recuperat în mod rapid, după care este eliminat din spaţiul de nume, eliberându-se şi blocurile asociate fişierului respectiv în nodurile de date.

Dacă factorul de replicare al unui fişier este redus, nodul de nume selectează replicile suplimentare care pot fi şterse, astfel încât în cadrul mesajelor periodice schimbate cu nodurile de date va fi transmisă această informaţie, eliberându-se blocurile în cauză cu actualizarea spaţiului liber existent în cluster.

Accesul la HDFS se poate face direct, prin intermediul unui client, disponibil inclusiv din browser, fie prin intermediul unor interfeţe de programare (Java, C++) care obţin metadatele de la nodul de nume (locaţia blocurilor), accesând apoi informaţiile din nodurile de date. Un astfel de model este utilizat inclusiv de MapReduce. Alternativ, comunicaţia dintre clienţi şi HDFS poate fi realizată printr-un server intermediar (eng. proxy), dintre cele care sunt livrate împreună cu Hadoop:

• Thrift care foloseşte un limbaj de definire al interfeţelor;
• WebHDFS REST în care răspunsurile sunt formatate ca JSON, XML sau folosind ProtocolBuffers;
• Avro care implementează mecanismul de serializare al datelor.

HDFS utilizează un model de permisiuni pentru fişiere şi directoare asemănător modelului POSIX, astfel încât fiecare fişier şi director sunt asociate unui proprietar şi unui grup, specificându-se permisiuni diferite pentru utilizatorul care este proprietar, pentru alţi utilizatori care fac parte din cadrul aceluiaşi grup şi pentru alţi utilizatori.

Pentru fişiere permisiunea r e necesară pentru a citi un fişier, iar permisiunea w este solicitată spre a scrie un fişier sau pentru a adăuga informaţii la acesta. În cazul fişierelor, permisiunea x nu este definită, neexistând noţiunea de fişiere executabile. De aceea, pentru fişiere nu există biţii setuid sau setgid, modelul fiind preluat (spre simplificare) şi în cazul directoarelor.

Pentru directoare, permisiunea r este solicitată pentru a se lista conţinutul acestuia, permisiunea w pentru operaţiile de creare sau ştergere în timp ce permisiunea x este necesară pentru a accesa subdirectoarele acestuia. Totodată, poate fi folosit bit-ul lipicios (eng. sticky bit) pentru a împiedica operaţiile de ştergere sau relocare a unui director de altcineva în afară de superutilizator, respectiv proprietarul directorului sau al fişierului.

Permisiunile unui fişier sau director reprezintă modul acestora, reprezentarea sa făcându-se în acelaşi fel ca în Unix (inclusiv reprezentarea octală). În momentul în care este creat un fişier sau director, proprietarul său este determinat de identitatea utilizatorului autentificat în cadrul procesului care emite comanda iar grupul său este dat de grupul directorului părinte (regula BSD). Identitatea fiecărui proces care accesează sistemul distribuit de fişiere HDFS este compusă din numele utilizatorului şi lista de grupuri. Verificarea permisiunilor pentru un fişier sau un director se face prin compararea numelui utilizatorului cu proprietarul obiectului sau, în caz că acestea nu coincid prin compararea grupului obiectului cu membrii listei de grupuri. Dacă nu se identifică nici o potrivire, se testează celelalte permisiuni ale obiectului care se doreşte a fi accesat. O operaţie asupra unui fişier sau asupra unui director nu poate fi realizată dacă nu sunt întrunite drepturile necesare.

HDFS permite administratorului să stabilească anumite cote pentru numărul de denumiri folosite şi pentru spaţiul de stocare utilizat pentru fiecare director în parte. Operarea celor două tipuri de cote se realizează independent, însă modul de utilizare al acestora este asemănător.

Cota pentru numărul de denumiri este o constrângere referitoare la numărul de fişiere şi directoare din ierarhia aflată sub directorul indicat ca parametru. Astfel, nu vor putea fi create sau redenumite fişiere sau directoare în cazul în care nu se verifică această constrângere. Stabilirea unei cote va putea fi realizată şi în cazul când valoarea specificată va determina o violare a constrângerii. Un director nou creat nu are nici o cotă asociată. Cea mai mică cotă, 1, forţează un director să rămână gol (denumirea directorului este contorizată în cadrul cotei). Cea mai mare cotă este Long.Max_Value.

Cota pentru spaţiul de stocare reprezintă o constrângere cu privire la numărul de octeţi utilizaţi de fişierele aflate în ierarhia directorului dat ca parametru. Alocarea unui bloc va eşua în cazul când cota respectivă nu ar permite scrierea întregului bloc. Fiecare replică a unui bloc va fi contorizată în cadrul cotei. Cotele vor fi menţinute şi în cazul redenumirii unui director (operaţia de redenumire va eşua însă în cazul în care prin aceasta se va încălca cota cu privire la spaţiul de stocare). Un director nou creat nu are nici o cotă asociată. Cota minimă este 0, permiţând totuşi crearea unui fişier (fără a se putea adăuga blocuri la acesta), iar cea mai mare cotă este Long.Max_Value.

Directoarele nu folosesc spaţiu în sistemul local de fişiere şi prin urmare nu sunt contorizate în calculul cotei. În aceeaşi situaţie se găsesc şi metadatele. Cotele sunt calculate în funcţie de factorul de replicare al fişierului, modificarea acestuia generând ajustarea corespunzătoare a cotelor. Cotele sunt reţinute în mod persistent în fişierul FsImage, detectarea unei încălcări a acestei constrângeri la încărcarea sa determinând afişarea unor mesaje de eroare. Modificările cu privire la cote sunt reţinute în jurnalul de tranzacţii.

Este implementat şi un shell unde pot fi emise comenzi ce interacţionează cu sistemul distribuit de fişiere HDFS ca şi cu alte sisteme de fişiere suportate de Hadoop cu ar fi sistemul de fişiere local, HFTP, S3 precum şi altele. Acesta este invocat folosind comanda:

./hadoop fs <args>

unde argumentele sunt URI-uri indicând calea către o anumită resursă.

Formatul unui URI este scheme://authority/path unde scheme este hdfs pentru sistemul de fişiere distribuit HDFS şi file pentru sistemul local de fişiere. Atât schema cât şi autoritatea sunt opţionale, în mod implicit fiind utilizată schema specificată în configuraţia curentă.

Forma unei comenzi în shell-ul HDFS este:

./hdfs [--config configurationDirectory] command [genericOptions] [commandOptions]

Opţiunile generice pe care le suportă toate aceste comenzi sunt:

• -conf <configuration_file>: specificarea unui fişier de configuraţie pentru o anumită aplicaţie;
• -D<property=value>: indicarea unei valori pentru o anumită proprietate;
• -fs <local|namenode:port>: precizarea unui anumit nod de nume;
• -jt <local|jobtracker:port>: stabilirea unui anumit proces de tip monitorizare a sarcinilor;
• -files <file_list>: indicarea unei liste de fişiere care vor fi copiate în clusterul map-reduce;
• -libjars <jar_list>: indicarea unei liste de arhive .jar care vor fi incluse în classpath;
• -archives <archive_list>: indicarea unei liste de arhive care vor fi dezarhivate pe maşinile unde este realizată procesarea; listele vor avea elementele separate prin caracterul , (virgulă).

Comanda dfs realizează o operație asupra sistemului de fișiere.

./hdfs dfs -<command> -<option> <URI>

Listarea tuturor comenzilor care sunt suportate de către shell poate fi realizată prin comanda:

./hdfs dfs -help

în timp ce informaţii detaliate cu privire la o anumită comandă pot fi obţinute indicând şi denumirea comenzii respective:

./hdfs dfs –help <command>

O listă a tuturor comenzilor disponibile în shell-ul sistemului distribuit de fişiere HDFS este redată în continuare:

Comanda fsck verifică inconsistenţele de la nivelul sistemului distribuit de fişiere, în special în privinţa blocurilor pierdute sau a blocurilor al căror număr de replici este mai mic decât factorul de replicare precizat pentru fişierul din care fac parte.

./hdfs fsck /

Întrucât datele nu sunt distribuite în mod uniform între nodurile de date ale clusterelor HDFS (nodurile de date noi conţin o perioadă de timp informaţii mai puţine, localizarea blocurilor noi se face pe baza topologiei nodurilor de date), există necesitatea ca acestea să fie echilibrate, căci cluster-ul nu declanşează acest proces în mod automat. În acest sens, există un utilitar administrativ care analizează modul în care sunt plasate blocurile în cluster-ul HDFS, re-echilibrând încărcarea nodurilor de date:

./hdfs balancer

De asemenea, sunt puse la dispoziţie o serie de comenzi administrative (disponibile numai administratorului HDFS) prin care poate fi gestionat clusterul în cauză, acestea având forma:

./hdfs dfsadmin -<command> [args]

O listă a tuturor comenzilor de administrare este redată mai jos: