Cu toții am auzit de trenduri. Avem trenduri în muzică, în modă și bineînțeles în IT. Pentru anul 2013, au fost anunțate mai multe trenduri, care la ora actuală fac deja parte din viața noastră. Câți din noi nu am auzit de cloud, machine to machine (M2M) sau NoSQL. Toate acestea sunt trenduri care au pătruns în viața noastră, făcând parte din cotidian. Big Data este un trend care s-a manifestat și anul trecut, menținându-se printre cele mai puternice trend-uri și în acest an.
În cadrul următoarei serii de articole doresc să vorbesc despre Hadoop. De ce? Big Data nu există fără Hadoop. Big Data ar fi doar o mulțime de octeți pe care clientul nu ar ști cum să îi proceseze. Clienți au început de mult timp să ceară o modalitate scalabilă prin care să putem procesa datele. În cazul sistemelor clasice, procesarea a 50T de date devine o problemă. Sistemele de calcul pentru indexarea și procesarea acestui volum de date este extrem de costisitoare - nu doar financiar cât și din punct de vedere a timpului.
La ora actuala Hadoop este una (dacă nu chiar cea mai bună) soluție de procesare a unui volum mare de date. Înainte de toate să vedem cum a apărut și cum a ajuns să fiu un sistem care poate să ruleze distribuit pe 40.000 de instanțe fără nici un fel de probleme.
În urmă cu câțiva ani (2003-2004), Google a publicat un articol despre modul în care face față la cantitatea imensă de date pe care trebuie să o proceseze. Acesta a explicat ce soluție folosește pentru a putea procesa și stoca un volum mare de date. Fiind în era web, iar numărul de site-uri și de date disponibile pe internet era foarte mare - nu doar că era mare, dar creștea amețitor (și continuă să crească), Apache Software Foundation inspirându-se din articolele publicate de către Google, ajută la creare Apache Hadoop. Putem spune că acest articol a devenit standardul pentru stocarea, procesarea și analiza datelor.
Doua caracteristici foarte importante pentru care Hadoop este la ora actuală un sistem pe care multe companii îl adoptă pentru procesarea Big Data sunt scalabilitatea și modul unic prin care datele sunt procesate și stocate. Pe toată perioada dezvoltării acestui sistem Hadoop a fost și va rămâne un proiect open-source. La început a fost sprijinit de Yahoo, care avea nevoie de un sistem de indexare pentru motorul de căutare pe care îl au. Acesta sistem ajunge să funcționeze atât de bine încât ajunge să fie folosit de către Yahoo și pentru publicitate.
Un lucru extrem de interesant este că Hadoop nu a apărut peste noapte, iar la început nu era un sistem atât de robust precum este astăzi. La început scalabilitate era o problemă, în momentul când era nevoie să scaleze mai mult de 10-20 de noduri. Același lucru se întâmpla în ceea ce privește performanța, unde nu excela. Companii precum Yahoo, IBM, Cloudera, Hortonworks au văzut valoarea pe care Hadoop o aduce și au investit în el. Fiecare din aceste companii aveau un sistem asemănător, care încerca să rezolve aceeași problemă. La ora actuală acesta ajunge să fie un sistem robust care poate să fie folosit cu succes. Companii precum Yahoo, Facebook, IBM, ebay, Twitter, Amazon îl folosesc fără nici un fel de problemă.
Deoarece în Hadoop datele pot să fie stocate extrem de simplu, iar odată informația procesată ajungă să ocupe foarte puțin spațiu, orice sistem legacy sau orice sistem extrem de mare poate să stocheze datele pe termen lung foarte ușor și cu costuri minime.
Modul în care este construit Hadoop este extrem de interesant. Fiecare parte din el este gândită pentru ceva mare, de la sistemul de stocare de fișiere, la modul de procesare sau de scalabilitate. Unul din cele mai importate și interesante componente pe care Hadoop le are este sistemul de stocare a fișierelor - Hadoop Distributed File System (HDFS).
În general, când vorbim de sisteme de stocare cu capacități foarte mari, gândul ne zboară la hardware custom care este extrem de costisitor, preț și întreținere. HDFS este un sistem care nu are nevoie de hardware special. Rulează fără probleme pe configurații normale, putând fi folosit împreuna cu calculatoarele pe care le avem acasă sau la birou.
Poate una din cele mai importante proprietăți ale acestui sistem este modul în care orice problemă hardware este privită. De la bun început acest sistem a fost gândit să ruleze pe zeci, sute de instanțe, din această cauză orice problemă hardware care poate să apară nu este privită ca o eroare, ca o excepție de la flow-ul normal. HDFS este un sistem care știe că nu toate componentele înregistrate în sistem vor funcționa. Fiind un sistem care este conștient de acest lucru, este mereu pregătit să detecteze orice problemă apărută și să înceapă procedura de recuperare.
Fiecare componentă din sistem, stochează o parte din fișiere, iar fiecare bit stocat, acesta poate să fie replicat într-una sau mai multe locații. HDFS este văzut ca un sistem care este folosit pentru stocare fișierelor care au de la câțiva giga și ajung de dimensiunea câtorva tera. Acest sistem este pregătit pentru a putea distribui un fișier pe una sau mai multe instanțe.
Sistemele normale de stocare de fișiere au ca principal scop stocarea datelor, iar în cazul în care avem nevoie de aceste date pentru a le procesa, acestea ne trimit datele stocate. HDFS este total diferit. Din cauza că lucrează cu cantități de date extrem de mari, modul în care rezolvă această problemă este inovator. Orice sistem am folosi, am avea probleme în momentul în care dorim să transferăm cantități mari de date pentru procesare. HDSF ne permite în schimb să trimitem pe componentele unde datele sunt stocate logica de procesare. Prin acest mecanism, datele de procesat nu mai sunt transferate și doar rezultatul final trebuie să fie trimis mai departe - doar când este nevoie.
Într-un astfel de sistem v-ați aștepta la un sistem cu un mecanism de versionare extrem de complex. Un sistem care să ne permite să avem mai multe surse care scriu în același fișier. De fapt HDSF este un sistem de stocare care permite să avem un singur writer și oricâți cititori. Este gândit în acest mod din cauză tipului de date care sunt stocate. Aceste date nu sunt date care se schimbă des, care să necesite modificări. De exemplu log-urile unei aplicații nu vor fi modificate, același lucru se întâmplă și cu datele obținute în urma unui audit. De foarte multe ori datele care ajung să fie stocate, odată ce sunt procesate ajung să fie șterse și niciodată modificate.
Înainte să vorbim despre arhitectura acestui sistem și modul în care lucrează, aș vrea să discutăm din nou despre o altă proprietate pe care acest sistem o are - portabilitatea. Din această cauză HDSF este un sistem care este folosit nu doar împreună cu Hadoop cât și ca un sistem de stocare a datelor. Cred că această proprietate l-a ajutat să fie atât de răspândit.
Din punct de vede software, acesta este scris în Java și poate să ruleze pe orice fel de sistem.
Dacă analizăm arhitectura unui astfel de sistem este necesar să introducem în vocabularul nostru doi termeni: NameNode și DataNode. Este un sistem de tip master-slave.
NameNode este "the master" sistemului de stocare. Acesta se ocupă de sistemul de stocarea a numelui fiecărui fișier și știe unde poate să fie găsit - maparea fișierelor. Acest sistem nu stochează datele din fișierele, el doar ocupându-se cu maparea fișierelor, știind în fiecare moment locație unde aceste sunt stocate. Odată ce numele a fost rezolvat de către NameNode, acesta va redirecta clienții spre DataNode-uri.
DataNode reprezintă "slave-urile" care stochează conținutul propriu zis al fișierului. Clienți vor accesa DataNode pentru a putea accesa informația stocată - scriere și citire a datelor.
Fiind un sistem care este pregătit pentru ca o componentă să cadă, pe lângă NameNode, avem un Seccondary NameNode. Acestă componentă face în mod automat checkpoint-uri la NameNode, iar în cazul în care se întamplă ceva cu NameNode-ul, această componentă este pregătită să ofere checkpoint-ul pentru a se putea restaura starea pe care NameNode-ul a avut-o înainte să cadă. Trebuie remarcat că Seccondary NameNode nu va prelua niciodată funcția pe care NameNode-ul o are. Acesta nu va rezolva locația unde fișierele sunt stocate. Singurul său scop este de a crea checkpoint-uri pentru NameNode.
Toate datele care sunt stocate sunt sub forma fișierelor. Pentru client, un fișier nu este împărțit în mai multe parți, chiar dacă intern acest lucru se întâmplă. Intern, fiecare fișier este împărțit în blocuri care ajung să fie stocate pe unul sau mai multe DataNode-uri. Un fișier foarte mare poate să fie stocat pe 2, 3 sau chiar 20 de noduri. NameSpace-ul controlează acest lucru, putând cere ca block-urile să fie replicate în mai multe locații.
În Figura 2 se poate vedea arhitectura acestui sistem. Ceea ce este interesant la această arhitectură este modul în care se lucrează cu fișiere. Datele pe care clienții le accesează nu trec niciodată prin NameNode. Din această cauză, chiar dacă avem un singur NameNode în tot sistemul, odată ce s-a rezolvat locația fișierelor, nici o cerere de la client nu mai trebuie să treacă prin NameNode.
Modul în care fișierele sunt stocate pentru a putea fi accesate de către clienți este foarte simplu. Clientul își poate defini o structură de directoare și fișiere. Toate aceste date sunt stocate de către NameNode. Acesta este singurul care știe modul în care directoarele și fișierele sunt definite de clienți. Opțiuni precum hard-link sau soft-link nu sunt suportate de către HDFS.
Deoarece datele stocate sunt foarte importante, HDFS ne permite să setăm numărul de copii pe care dorim să le avem pentru fiecare fișier. Acesta se poate seta în momentul în care creăm fișierul sau oricând după acest moment. NameNode-ul este cel care cunoaște numărul de copii care trebuie să existe pentru fiecare fișier și are grijă ca acesta să existe.
De exemplu când creștem numărul de replicări pe care dorim să le avem pentru un fișier NameNode-ul o să aibă grijă ca toate blocurile de date să fie replicate încă o dată. Treaba NameNode-ului nu se termină în acest moment. De la fiecare bloc în parte acesta primește un semnal de tip "sunt în viață" la un interval specific de timp - heardbeat. În cazul în care unul din blocuri nu trimite acest semnal, NameNode-ul va înceape procedura de recuperare în mod automat.
Modul în care datele se replică este extrem de complex. HDSF trebuie să țină cont de foarte mulți factori. În momentul în care este nevoie să se facă o noua copie, trebuie ținut cont că aceasta acțiune o să consume lățimea de bandă. Din acestă cauză avem un load-balancer care se ocupă de distribuirea datelor în cluster. Există mai multe opțiuni pentru replicare, una din cele mai des întâlnite este în care 30% din replici să fie pe același nod. Din punct de vedere a ldistribuirii replicilor pe rack-uri , doua treimi sunt pe același rack, iar cealaltă parte este pe un rack separat.
Datele dintr-un DateNod pot să ajungă să fie mutate automat într-un alt DateNod în cazul în care se detectează că datele nu sunt distribuite uniform.
Toate copiile care există pentru un fișier sunt folosite. În funcție de locația de unde se dorește să se acceseze aceste date, clientul vor avea acces la copia care se află cel mai aproape de el. Din această cauză, HDSF este un sistem care știe cum arată rețeaua sa internă - incluzând fiecare DataNode, rack și restul sistemelor.
Namespace-ul pe care NameNode-ul îl are este stocat în memorie RAM, putând să fie accesat cu ușurință. Acesta este replicat pe hard disk la intervale foarte bine stabilite - numele imaginilor care se scriu pe disk poartă numele de FsImage. Din cauză că copia de pe disk nu este 1 la 1 cu cea din memoria RAM, există un fișier în care sunt scrise toate modificările care se fac asupra structurii fișierelor sau a directoarelor - EditLog. Prin acest mod în cazul în care se întâmplă ceva cu memoria RAM sau cu NameNode-ul, recuperarea acestuia este simplă și poate să conțină și ultimele modificări.
Un lucru extrem de interesant este modul în care un client poate să creeze un fișier. Inițial, datele nu sunt stocate direct in DataNode, ci într-o locație temporară. Doar în momentul în care există destule date pentru ca o operație de scriere să merite, doar atunci NameNode-ul este notificat și copiază informația in DataNode.
În momentul în care un client dorește să șteargă un fișier, acesta nu este șters fizic din sistem. Fișierul este doar marcat pentru ștergere și mutat în directorul trash. În trash este ținută doar ultima copie a fișierului, iar clientul poate să intre în acest director pentru a o recupera. Toate fișierele din trash sunt șterse în mod automat după un anumit interval de timp.
În cadrul acestui articol, am prezentat cum a apărut Hadoop, care sunt proprietățile sale principale și modul în care datele sunt stocate. Am văzut ca HDFS este un sistem creat să lucreze cu multe date. Acest lucru îl face extrem de bine și cu costuri minime.
În următorul număr vom vedea cum putem să procesăm această informație.
de Simplex team
