Gestiune și Analiză Big Data a Unui Lanț de Magazine Folosind Hadoop

LISTA DE FIGURI

Figură 1. Multitudinea de date 6

Figură 2. Tipuri de scalări 8

Figură 3. Apache Hadoop 9

Figură 4. Arhitectura Hadoop 10

Figură 5. Arhitectura "Google File System" 12

Figură 6. Modul de stocare al datelor în cluster 14

Figură 7. Diferențe în denumirea elementelor între Hbase și Big Table 20

Figură 8. Interfață HBASE – Master 23

Figură 9. Interfață HBASE – Region Server 23

Figură 10. Arhitectură de nivel înalt Lucrare de Licență 31

Figură 11. Interfață Hadoop 37

Figură 12. Interfață YARN 38

Figură 13. Interfață administrare aplicație 38

Figură 14. Diagramă bază de date SQL 39

CAPITOLUL 1 – INTRODUCERE, OBIECTIVE, MOTIVAȚIE

INTRODUCERE

Pentru început o să vorbesc puțin despre tema pe care mi-am ales-o pentru Lucrarea de Licență. Ea este o aplicație de gestiune a datelor care provin dintr-un lanț de magazine de tip supermarket dar ea poate fi folosita pe viitor pentru orice tip de magazine, chiar poate fi extinsa pentru orice tip de business.

După cum bine știm hypermarket-urile scot zilnic câteva sute sau chiar mii de bonuri fiscale cu diferite produse pentru fiecare bon, iar o statistica pentru acestea, pentru a analiza cerința de piață și ce anume este nevoie pentru a optimiza costurile magazinului poate fi complicate.

Toate aceste facturi pot fi stocate și electronic iar o baza de date obișnuită ar putea fi depășită și ar putea chiar aduce întârzieri în procesarea lor. Spre exemplu daca s-ar dori scoaterea de statistici pentru a evidenția produsele cel mai des cumpărate sau statistici mai complexe cum ar fi produsele cele mai scumpe cel mai des cumpărate sau cele din gama de electronice care sunt returnate pentru a putea fi excluse din vânzare pentru a simplifica munca angajaților, toate aceste lucruri ar putea avea un timp foarte mare de procesare.

Stocarea tuturor datelor referitoare la produsele cumpărate, prețul acestora în funcție de luna curenta, perioada anului, și numărul acestora pot ocupa un spațiu de stocare de ordinul petabyte ( 1024 ^ 5 ).

Pentru a putea implementa o soluție de scoatere de rapoarte și pentru a putea analiza mai ușor datele, m-am gândit să folosesc framework-ul Hadoop care mă va ajuta să implementez și să execut program ce vor putea procesa date în cantități foarte mari, având un timp de execuție mic.

Conceptul Big Data a apărut odată cu dezvoltarea aplicațiilor de tip enterprise și a dezvoltării tehnologiei în domeniul IT.

Când vorbim despre acest lucru trebuie să avem în minte faptul ca, Big Data este caracterizat de cei trei “V” definiți de Gartner și anume “Volum, Viteza, Varietate”

Primul V vine de la VOLUM și se refera la faptul că odată cu trecerea timpului, volumul de date cauzat de creșterea tranzacțiilor este din ce în ce mai mare și o varianta clasica de stocare a acestora și chiar de procesare, nu mai este eficienta.

Al doilea V se refera la VITEZA cu care datele pot fi accesate dar și la faptul că ar trebui să fie disponibile un timp cat mai îndelungat. De asemenea se refera și la scrierea acestora și analiza lor în vederea obținerii unui rezultat relevant cererii.

Ultimul V provine de la VARIETATE. Întotdeauna au existat problem de traducere și interpretare a unui volum mare de informații tranzacționale. în prezent exista mai multe tipuri de informații pentru a fi analizate, cele mai multe provenind de la rețelele de socializare ( spre exemplu Facebook,Twitter etc. ) precum și cele mobile. Varietatea mare a datelor consta în multitudinea de baze de date, documente digitale , e-mail, video, imagini, tranzacții online etc.

Primul lucru ne arata că momentan sunt în jur de 1.39 miliarde de utilizatori, iar acest fapt ne indica un spațiu de stocare foarte mare daca ne gândim că pentru fiecare utilizator avem nevoie de date suplimentare (nume, vârsta, adresa, pozele fiecăruia etc) și putem estima câteva sute de MB pentru fiecare dintre ei. De asemenea din articol putem afla că numărul utilizatorilor a crescut cu 13% fata de anul anterior.

De asemenea zilnic sunt date peste 4.5 miliarde de “like”-uri iar creșterea este de 67% fata de luna August 2012.

După cum putem observă doar din aceste câteva cifre, creșterea datelor este una exponențiala, ajungând să devina din ce în ce mai mare.

Aplicația mea se va baza pe analiza datelor provenite dintr-un lanț de magazine și crearea de statistici pentru că cei ce vor vrea să le analizeze să aibă mult mai mult timp pentru acest lucru și să nu mai își petreacă timpul încercând să le grupeze și apoi să scoată aceste rapoarte, totul făcându-se automat prin aplicație.

OBIECTIVE

Obiectivul general este de a crea o aplicație cu ajutorul căreia firmele de Business Intelligence (BI) care vor analiza datele provenite dintr-un lanț de magazine de tip supermarket să poată scoate rapoarte în ceea ce privește vânzările acestora.

De asemenea vor putea să precizeze care vor fi vânzările în anumite zile cheie și cu ce anume trebuie să alimenteze stocul de produse într-un mod eficient.

Un obiectiv secundar al proiectului este învățarea de tehnologii noi și implementarea lor în aplicații care vor putea fi folosite pe piață pentru a ușura munca oamenilor.

MOTIVAȚIE

In ultimul timp firmele mari se confruntă cu problema gestionarii datelor și a capacității de stocare a acestora, ajungând la dimensiuni foarte mari, încât putem deja să vorbim de unități de măsură petabyte (1024 ^ 5 în comparație cu gigabyte care are o valoare de 1024 ^ 3 octeți).

Deoarece este destul de greu să se poată gestiona o multitudine de informații într-un timp cat mai scurt și cu resurse de calcul actuale fără a fi nevoie de un super calculator, am vrut să vin în ajutorul firmelor care analizează aceste date cu o noua aplicație. Acesta va face mai ușoară folosirea lor fără a mai irosi ore întregi pentru a configura sistemul și a citi datele, timpul acesta salvat rămânând doar pentru analizarea statisticelor deja create de program și stabilirea deciziilor ce se vor lua pe baza acestora.

Având la dispoziție sub o licență libera, framework-ul Hadoop care permite scrierea de programe ce pot procesa cantități mari de date și automat executarea lor pe un cluster de computer, m-am gândit să mapez aplicația mea peste acest program de dezvoltare și automat să ușurez munca celor care vor folosi aplicația mea.

CAPITOLUL 2 – TEHNOLOGII ACTUALE

Tehnologiile pe care le voi folosi în lucrarea mea de licență vor fi următoarele:

Apache Hadoop – pentru a putea gestiona datele într-un mod mai rapid și fără a necesita o mașina de calcul extrem de puternica.

De asemenea voi putea folosi sistemul de fișiere HDFS pentru stocare sigura.

Baze de date NoSql deoarece voi folosi un volum mare de date pentru a fi procesate.

Baze de date relaționale folosind MySql pentru stocare de utilizatori necesari autentificării în aplicație.

Framework-ul Spring MVC pentru a putea crea aplicația, folosind limbajul de programare Java.

Hibernate pentru persistenta datelor din aplicație.

2.1 CONCEPTUL BIG DATA

Conceptul de Big Data a apărut odată cu dezvoltarea tehnologiei și cu creșterea numărului de utilizatori ce folosesc aplicații IT.

După cum se definește și în cartea Hadoop Illuminated Big Data este “Un set de date foarte mare și vag ce sfidează stocarea tradițională”.

Fiecare om aduce contribuția lui la creșterea datelor de pe internet, după cum bine știm în fiecare zi se trimit mail-uri, se postează poze, de exemplu pe Facebook și se scriu documente, știri acestea putând fi accesate și online spre deosebire de trecut când le puteai afla doar de la televizor sau cumpărând un ziar. De asemenea luând tot că exemplu Facebook, zilnic se dau “like”-uri, se distribuie postări ale prietenilor, se creează prietenii noi online, și apar noi utilizatori, toate aceste lucruri trebuie stocate și măresc capacitatea datelor care trebuie salvate pentru a nu se pierde nimic din activitatea fiecărui utilizator.

Mai devreme am discutat despre contribuția fiecărui utilizator la creșterea volumului de date dar mai putem vorbi și la faptul că fiecare aplicație IT contribuie ea însăși la acest lucru. Un exemplu foarte concludent sunt log-urile, fișierele în care se scriu toate evenimentele care apar la nivelul unei aplicații. Într-un server web, în documentul creat automat se stochează date referitoare la cererile care s-au trimis sau primit de către server, ip-urile care s-au conectat la acesta, schimbările de funcționare care au apărut la nivelul acestuia, spre exemplu când a fost pornit, daca a fost o fluctuație de curent acesta a repornit și automat apar datele exacte când acesta s-a redeschis etc.

Cum de a apărut conceptul Big Data putem afla tot din cartea Hadoop Illuminated: “La început big data a apărut din datele provenite din web, adică din întregul Internet! Nu uita că Hadoop a fost creat pentru a putea indexa web-ul.”

Tot din aceasta carte putem afla faptul că în momentul de fata multitudinea de date provine din multe surse cum ar fi :

Mediile de socializare online și site-uri cum ar fi : Facebook, Twitter, LinkeID care generează o cantitate mare de date.

Fiecare click pe care utilizatorii îl dau pe site-uri este înregistrat în fișierele de tip “log” pentru a putea fi analizat și pentru a putea optimiza aplicațiile că acestea să devina din ce în ce mai accesate.

Datele provenite de la senzori.

Referitor la ultimul exemplu aș putea spune că este necesar să nu se piardă absolut nicio informație care provine de la senzori pentru că rezultatul cercetării să fie unul pozitiv.

După cum bine știm fișierele de stocare a informațiilor provenite de la server, log-urile în mod predefinit, au o capacitate limitată de stocare aceste fiind suprascrise în momentul în care aceasta capacitate este plina. Exact pentru a încerca să se evite acest lucru a apărut Apache Hadoop pentru a putea salva datele nu doar pe o singura mașină ci pe un cluster de calculatoare pentru a nu mai avea o capacitate limitată de stocare a datelor. De asemenea datele pot fi procesate direct pe mașinile unde se găsesc și nu mai este nevoie să fie aduse pe o mașină de procesare, fiind aduse doar rezultatele în momentul în care se termina de executat.

Figură 1. Multitudinea de date

2.2 APACHE HADOOP

Înainte de a începe discuția tehnică despre Apache Hadoop voi face un scurt istoric despre cum a apărut și cine a fost la baza acestui tool pe care acum îl folosesc.
Totul a început în anii 90’ mai exact în anul 1995 atunci când un utilizator ce voia să facă o căutare pe web folosea unul dintre motoarele de căutare de la vremea respective cum ar fi Altavista sau Excite, sau o alta aplicație ce folosea mai multe motoare de căutare și agrega datele într-unul singur și ii afișa utilizatorului, rezultatul căutării. în anul 2000 a apărut Google iar prin faptul că toate rezultatele căutărilor pe acest motor de căutare erau foarte rapide și prin puterea cuvântului aproape că a apărut un nou cuvânt în dicționar, atunci când făceai o căutare nu mai spuneai “caut ceva pe internet” se spunea “Google it”. Ei bine toți erau interesați de acest lucru și voiau să știe cum au reușit să acapareze toate motoarele de căutare deja existente. La baza acestuia sta GFS ( Google file sistem ) sistemul de fișiere distribuite Google și tehnologia MapReduce. Cei de la Google s-au gândit că este mai bine să împartă multitudinea de date în bucăți mai mici de dimensiuni egale, iar acestea să fie împărțite pe un cluster de calculatoare, procesarea făcându-se chiar în locul unde datele se afla, urmând că doar rezultatul să fie trimis acolo de unde se face cererea.

In 2003 Google lansează documentația oficiala pentru GFS dar acest lucru nu a potolit setea oamenilor de a afla cum funcționează motorul lor de căutare, deoarece în spatele acestui sistem de fișiere este MapReduce care se ocupa de gestiunea datelor și împarte procesarea în bucăți mai mici iar la final reușește să agrege datele într-un singur rezultat.

In 2004 Google lansează și documentația pentru MapReduce, iar doi dintre angajații Yahoo de la vremea respectiva (Doug Cutting și Michael Cafarella), care lucrau deja la un nou motor de căutare numit “Nutch Search Engine Project” curioși de documentațiile lansate, încearcă să facă o implementare a ceea ce Google descria în cele două documente.

In 2005 apare prima versiune Hadoop. Numele acestuia provine de la copilul de 2 ani al lui Doug Cutting care avea un elefănțel de plus și pe care îl striga Hadoop.

In 2006 Yahoo donează proiectul Hadoop către Apache și astfel apar în scena cei de la Apache iar acum proiectul este Open Source asta înseamnă că oricine poate contribui la implementarea și îmbunătățirea lui astfel că dezvoltarea lui devine mult mai rapida deoarece comunitatea este una foarte mare.

In documentația oficiala Apache Hadoop este descris că fiind “Un proiect ce dezvolta un software open-source pentru computație de date sigura, scalabila și distribuita”.

A fost conceput pentru a putea realiza procesări distribuite de date, cu dimensiuni foarte mari ajungând și la unități de măsură a datelor de tip petabait pe clustere de mii de calculatoare, fiind proiectat astfel încât să fie scalabil chiar și la aceste dimensiuni.

Un cluster se poate defini că “Un set de mai multe mașini, legate prin intermediul unei rețele de calculatoare, care se găsesc în aceeași locație fizică. Nu este necesar că performanțele pe care le oferă acestea să fie foarte ridicate, scalarea realizându-se nu prin adăugarea de resurse la o mașină (de vreme ce legea lui Moore oricum nu poate acoperi creșterea cantității de date), ci prin creșterea numărului de mașini în cadrul unui cluster, respectiv prin creșterea numărului de clustere, framework-ul Hadoop fiind proiectat pentru a gestiona astfel de modificări. Mai mult, spre diferență de modelul “tradițional” de procesare distribuită, nu se face o separare între noduri de procesare și noduri de stocare (întrucât pot apărea blocaje) ci un nod implementează ambele funcționalități, fiind procesate datele stocate local.”

Hadoop nu se bazează pe un super calculator care poate procesa o cantitate mare de date ci pe mai multe calculatoare cu specificații medii. Se bazează pe o scalare pe orizontala și nu un ape verticala. în figura 2.2 voi încerca să explic puțin diferența dintre cele două scalari.

Figură 2. Tipuri de scalări

Folosind acest tip de scalare, Hadoop poate avea o putere mai mare de procesare deoarece se poate ajunge pana la mii de computere într-un singur cluster depășind cu mult puterea de calcul al celui mai puternic calculator care se poate construi la ora actuala.

Hadoop are în component următoarele module:

1. Hadoop Common – utilitare care ajuta la manipularea celorlalte module.

2. Sistemul de fișiere distribuite Hadoop (HDFS) – un sistem de fișiere distribuit care permite accesul la date.

3. Hadoop YARN – un utilitar pentru planificare joburilor și pentru gestiunea de resurse în cadrul cluster-ului de calculatoare.

4. MapReduce – un sistem baza pe procesarea paralela a unor seturi mari de date.

APACHE HADOOP

Figură 3. Apache Hadoop

Arhitectura Hadoop este formata din mai multe elemente de baza care împreuna reușesc să creeze framework-ul. Acestea sunt numite și demoni. Demonii sunt o serie de aplicații server și sunt controlate de sistemul de operare cu un set de semnale specifice.

Într-un cluster Hadoop avem un computer care este denumit și computer principal sau Master și restul computerelor care sunt și cele secundare sau Slave.

In componenta Master-ului avem : Job Tracker și Name Node și Secondary Node, iar în component Slave-ului avem Task Tracker-ul și Data Node. De asemenea tot ce se găsește în computerele secundare pot fi și în cel principal, dar nu și invers.

Pentru a înțelege mai ușor cele ce urmează să le explic, voi încerca să reprezint toate noțiunile printr-o imagine:

ARHITECTURA DE NIVEL INALT

Figură 4. Arhitectura Hadoop

Nodul de nume – conține meta dată pentru fiecare fișier care este stocat în HDFS. Meta datele conțin informații despre blocurile de date cat și locația lor în cluster, cum ar fi pe ce nod de date se afla. Poate fi o componenta destul de sensibila deoarece daca el se defectează se pot pierde informații fără de care nu se mai pot accesa datele din cluster chiar daca aceste pe parcurs sunt multiplicate de cel puțin 3 ori pentru a fi cat mai mica probabilitatea de pierdere a datelor.

Nodurile de date – Stochează blocurile de date din HDFS pe hardisk-ul mașinii locale din care face parte.

Job Tracker – face parte din component principala și anume din Master. El gestionează tot ce se întâmpla cu un job. El programează funcțiile mai mici ale unui job cum are fi maparea sau reducerea către noduri separate de date, tine evidenta task-urilor și a nodurilor de date și chiar a celor care au avut eroare și nu au putut fi terminate.

Task Tracker – face parte din component secundare și anume nodurile de date și gestionează task-urile individuale. Este responsabil cu pornirea task-urilor de mapare și reducere și comunica cu Job Tracker-ul.

2.3 Exemple ale Big Data în lumea realĂ

Câteva exemple ale folosirii framework-ului Hadoop în producție apar la adresa :

http://wiki.apache.org/hadoop/PoweredBy

Printre cele mai importante sunt :

“A9.com – Amazon

Procesam milioane de sesiuni zilnic pentru analiza, folosind Java.

Clusterele noastre variază între 1 și 100 de noduri.

Adobe

Folosind Apache Hadoop și Apache HBase pentru câteva domenii de la servicii media pana la stocare de date structurate și le procesam pentru uz intern.

Momentan avem în jur de 30 de noduri funcționale HDFS, Hadoop și HBase în clustere având de la 5 la 14 noduri în ambele domenii, producție și dezvoltare. Avem în plan să ajungem la un cluster de 80 de noduri.

In mod constant folosim Apache HBase pentru a scrie date și executam job-uri de MapReduce pentru a le procesa și apoi le stocam înapoi în Apache HBase sau pe sisteme externe.

Cluster-ul nostru de producție este în funcțiune din Octombrie 2008.

EBay

Un cluster de 532 de noduri ( 8 * 532 procesoare, 5.3 PB).

Folosire intense a Java MapReduce și al Apache HBase.

Îl folosim pentru optimizări de căutare și cercetare.

Twitter

Folosim Apache Hadoop pentru a stoca și a procesa tweet-uri, fișiere de logare, și multe alte tipuri de date generate pe Twitter.

Facebook

Folosim Apache Hadoop pentru a stoca copii ale fișierelor de log interne și îl folosim pentru a scoate rapoarte.

Momentan avem două clustere majore

Un cluster de 1100 mașini de calcul cu 8800 procesoare și o capacitate de stocare de 12 PB.

Un cluster de 300 de mașini de calcul cu 2400 procesoare și o capacitate de stocare de 3 PB.

Toate sunt calculatoare normale cu 8 procesoare și o capacitate de stocare de 12TB fiecare.”

După cum se poate observă și în exemplele de mai sus, acest concept este folosit în multe dintre aplicațiile de care ne lovim zi de zi și acest lucru arata că este un lucru care trebuie luat în serios, analizat cu multa atenție și folosit cat de mult se poate pentru că reduce foarte mult timpul de acces la date.

2.4 SISTEMUL DE FIȘIERE HDFS

După cum este definit în documentația lui originala de pe site-ul oficial hadoop.apache.org, HDFS este un sistem de fișiere distribuite conceput pentru a putea funcționa pe calculatoare cu o putere de calcul nu foarte sofisticata. Se aseamănă foarte mult cu alte sisteme de fișiere distribuite, dar are și diferențe. HDFS este tolerant la eșecuri, asta înseamnă că atunci când unul dintre calculatoarele din cluster se strica, nu face că tot cluster-ul să cedeze sau chiar să se piardă date importante.

HDFS oferă transfer rapid de date către aplicații și este potrivit pentru o cantitate mare de date.

Un alt sistem distribuit de fișiere este GFS provenind de la Google File System. HDFS se aseamănă foarte mult cu acesta și în cele ce urmează o să fac câteva mici asemănări.

Am citit cartea “The Google File System” scrisa de Sanjay Ghemawat, Howard Gobioff, și Shun-Tak Leung, angajați ai Google și am observăt câteva asemănări intre cele două sisteme. Una dintre acestea este faptul că ambele se bazează pe computere cu un preț mic și cu o performanta medie, nu pe un super calculator și citez:

“Sistemul conține sute sau chiar mii de mașini de stocare construite din componente cu un preț mic și medii că putere și sunt accesate de către calculatoare client care au un număr comparabil cu numărul lor”.

O alta asemănare care am observăt-o între cele două sisteme este faptul că arhitectura este una similara. Voi adăuga o imagine din carte pentru a putea face comparație cu arhitectura care am desenat-o mai sus a HDFS.

Figură 5. Arhitectura "Google File System"

In ambele arhitecturi se folosește conceptul de nod principal și noduri secundare “master/slave”, în cel principal fiind stocate meta datele conținând informații despre nodurile secundare sau “chunkserver” așa cum sunt denumite în GFS și despre datele ce sunt conținute acolo, urmând că procesarea datelor să se facă direct pe nodurile de date și trimise apoi către mașină client.

In continuare voi intra puțin în detaliul arhitecturii HDFS pentru a face mai ușoară înțelegerea modului de funcționare a sistemului.

Sistemul poate fi configurabil în multe moduri, cele predefinite putând susține multe dintre aceste clustere fiind nevoie de configurare suplimentara doar în cazul unor clustere foarte mari că și dimensiune.

Fiind scris în Java este suportat de majoritatea platformelor pe care urmează să fie rulat, de asemenea are și linie de comandă pentru a putea interacționa direct cu HDFS.

După cum știm de mai sus, HDFS folosește un nod de nume și noduri de date, acestea având și ele implementat un server web pentru a fi mai ușoară accesarea lor și de asemenea pentru a se stabili mai ușor statusul acestora.

Interfața web poate fi accesata daca sunt folosite configurările predefinite prin portul 50070. Aici se pot vedea nodurile de date și statistici de baza despre cluster, cum ar fi dimensiunea fiecărui nod de date, care sunt conectate și care sunt disponibile, etc. Tot aici putem accesa și fișierele care se afla în cluster, având implementat un sistem de căutare.

Modul de funcționare intern pentru a stoca datele este următorul, un fișier este spart în mai multe blocuri iar acestea sunt stocate într-un set de noduri de date. Nodul de nume executa operații în spațiul de nume al fișierelor, cum ar fi deschidere, închidere și redenumire, dar deține și o mapare a tuturor blocurilor din nodurile de date. Aceste din urma citesc și scriu cererile de la mașinile client, dar și creează blocuri, le șterg și automat le multiplica. Multiplicare se face în mod predefinit de trei ori, acest lucru garantând existent datelor chiar și atunci când unul dintre nodurile de date este defect. Este proiectat să stocheze fișiere de dimensiuni foarte mari pe un cluster compus din multe calculatoare iar lucrul acesta este realizat prin stocarea fiecărui fișier că o secvența de blocuri cu aceeași dimensiune. în mod implicit dimensiunile blocurilor sunt de 64MB sau de 128MB.

In mod uzual se folosește pe sisteme de operare Linux, funcționează pe mașini de lucru cu o putere de lucru normala și fiind scris în Java face să fie independent de arhitectura hardware.

Accesarea datelor din cluster se face în felul următor: datele fiind replicate pe mai multe noduri, în momentul în care se face o cerere pentru aducerea unui anumit fișier la un client, se încearcă găsirea celui mai apropiat nod de date. Daca o replica se găsește în același rack că și nodul care vrea să citească datele, atunci aceasta este preferata pentru a satisface cererea.

De replicarea datelor se ocupa nodul de nume care ia toate deciziile legate de acest lucru. El primește periodic un raport care este trimis la un interval de timp numit și bătaie de inima (eng. heartbeat) de la fiecare nod de date în care sunt specificate toate blocurile de date conținute de acel nod.

Modul de siguranță este o stare specifica nodului de nume în care intra la pornire. Replicarea datelor nu se face în momentul în care nodul de nume se afla în modul de siguranță (eng. safemode). în momentul acesta nodul de nume primește mesaje de raport de la nodurile de date care conțin o lista cu toate blocurile care se găsesc la acea locație. Fiecare bloc de date are specificat un număr minim de replicări. Un bloc de date este considerat a fi în siguranță daca numărul minim de replicări este egal cu cel specificat. După ce se efectuează aceasta verificare se mai așteaptă încă 30 de secunde iar nodul de nume iese din modul de siguranță. După acest lucru nodul de nume face o lista cu blocurile de date care se găsesc într-un număr mai mic decât cel în care ar trebui să fie replicat și le replica pe alte noduri de date.

Pentru stocarea sistemului de fișiere un spațiu de nume se afla în nodul de nume. Acesta folosește un jurnal de tranzacții numit EditLog pentru a stoca fiecare modificare care apare asupra meta datelor. De exemplu atunci când este creat un fișier face că nodul de nume să stocheze aceasta modificare în jurnalul de tranzacții. La fel se întâmplă și daca schimbam numărul minim de copii ale unui fișier în cluster. Acest jurnal este stocat pe mașină unde funcționează nodul de nume. Spațiul de nume plus harta tuturor blocurilor și proprietățile sunt stocate într-un fișier care se numește FsImage. La fel că și jurnalul și aceasta este stocat tot pe sistemul local. Nodul de nume păstrează o imagine a întregului spațiu de nume al sistemului de fișiere în memorie. Acesta este foarte compact, de exemplu o memorie de 4GB RAM este suficienta pentru un număr foarte mare de fișiere și directoare. La pornire, citește FsImage și jurnalul de pe disk și aplica toate tranzacțiile din jurnal în reprezentarea fișierului FsImage din memorie iar apoi scrie noua versiune pe disk. Acest proces se numește punct de verificare (eng. checkpoint ). în momentul de fata, așa cum este conceput, un punct de verificare apare doar în momentul în care este pornit nodul de nume.

Figură 6. Modul de stocare al datelor în cluster

Protocoalele de comunicație folosite sunt cele de TCP/IP. Un client creează o conexiune cu un port TCP de pe calculatorul nod de nume (eng. NameNode ). Se folosește protocolul numit ClientProtocol la comunicația cu nodul de nume. Nodul de date comunica cu nodul de nume folosind DataNode Protocol. O procedura pentru comunicații la distanță RPC (Remote Procedure Call) înglobează ambele protocoale Client Protocol și DataNode Protocol. După cum a fost conceput nodul de nume nu inițiază apeluri RPC, el doar răspunde cererilor făcute de nodurile de date sau clienți.

Una din caracteristicele de baza ale HDFS este faptul că stocarea datelor este fiabila chiar și atunci când se întâmplă să apară probleme asupra mașinilor din clusterul din care face parte. Cele mai comune tipuri de probleme sunt cele apărute la nivelul nodului de nume, la nodurile de date și partiționării de rețea.

După cum am scris și anterior, fiecare nod de date trimite periodic mesaje de tip “bătaie de inima” (eng. heartbeat ) către nodul de nume. O partiționare a rețelei ar putea să facă acele noduri de nume să își piardă conectivitatea cu nodul de nume. în aceasta situație acesta detectează faptul că nu se mai primește acel mesaj de la respective mașină și îl marchează că fiind scos din funcțiune sau că nu răspunde la niciun fel de cerere de IO. Orice eveniment de acest tip face că datele de pe acel nod de date să nu poată fi accesate. Acest lucru va face că factorul de multiplicare al datelor să scadă sub limita minima admisa, de aceea nodul de nume va replica datele de fiecare data când este nu atinge limita pentru a putea fi sigur că în orice moment datele se afla în cluster de cel puțin atâtea ori cat este specificat în configurație.

Accesarea sistemului de fișiere HDFS poate fi făcută în mai multe feluri. în mod predefinit este oferită o interfață Java pentru că aplicațiile să o folosească. Unul dintre modurile de acces este linia de comanda numită și “FS Shell”. Cu ajutorul ei, un utilizator poate accesa datele din HDFS. O să dau câteva comenzi din documentația oficiala pentru a putea înțelege mai ușor lucrul cu linia de comanda.

Exista de asemenea și comenzi folosite în general doar de administrator. Acest set de comenzi se numește DFSAdmin iar mai jos sunt puse câteva comenzi de baza.

O alta modalitate de accesare a datelor este folosirea unui browser web pentru a vedea conținutul din HDFS.

In momentul în care un fișier este șters de o aplicație sau de către un utilizator, ea nu este ștearsă imediat din HDFS. Este redenumita și trimisa în directorul numit “/trash”, de unde poate fi restaurata pentru a putea fi accesata din nou atâta timp cat se afla în acest director. Fișierul rămâne în coșul de reciclare atâta timp cat este configurat, iar după expirarea acestui timp, nodul de nume șterge fișierele din spațiu de nume HDFS, acest lucru făcând că blocurile asociate fișierului să fie eliberate. în tot acest proces poate exista o decalare de timp intre ștergerea unui fișiere și crearea de spațiul liber în HDFS.

Configurarea curenta de ștergere automata a fișierelor din coșul de reciclare este că după un interval de 6, acesta să se golească.

Configurabil este și numărul de replicare al datelor în cluster. în momentul în care se micșorează numărul, nodul de nume selectează copiile care pot fi șterse. La următoarea “bătaie de inima” transfera aceasta informație la nodul de date, care șterge blocurile corespunzătoare, iar acel spațiu devine liber în cluster. și aici pot apărea diferențe de timp pana când se eliberează spațiul și poate fi refolosit.

2.5 Map Reduce

Hadoop MapReduce este o aplicație software care ajuta utilizatorii să scrie aplicații pentru procesarea unui set mare de date în paralele pe clustere foarte mari (mii de computere ) și cu un preț mediu pentru fiecare.

De obicei MapReduce este bazat pe anumite munci, treburi (eng. job), care de obicei împarte setul de date în bucăți independente care sunt procesate de sarcina de mapare (eng. map tasks) . Framework-ul sortează apoi ceea ce mapper-ul a returnat iar acest lucru va fi intrarea task-ului de reducere (eng. reducer tasks).

Nodurile de stocare și cele de procesare se găsesc pe aceeași mașină fizica, iar MapReduce și HDFS funcționează pe același set de noduri. Acest lucru permite aplicației să programeze task-uri pe nodurile unde datele sunt deja prezente, ducând la un consum de lățime de banda în cluster foarte scăzut.

Pe scurt, aplicațiile specifica locațiile de intrare și ieșire a datelor și oferă funcțiile de mapare și reducere prin implementări ale interfețelor sau a claselor abstracte. Toate aceste lucruri plus câțiva parametrii specifici formează configurația job-ului.

MapReduce lucrează doar cu perechi cheie- valoare <key, value> astfel încât, vede intrarea că fiind de forma aceasta, procesează datele și la ieșire va fi un fișier cu conținut tot în formatul cheie valoare.

Un exemplu banal care are că scop numărarea de cuvinte dintr-un anumit input se numește “Word Count” și este următorul :

Codul Sursa:

Se observă ușor că interfețele Mapper și Reducer sunt extinse și automat exista două funcții pentru acest lucru, unui care ii atribuie fiecărui cuvânt unic cate o cheie unica, iar funcția de reducere care numără de cate ori apare fiecare cheie, automat fiecare cuvânt.

Având că input propozițiile : Hello World Bye World Hello Hadoop Goodbye Hadoop ieșirea va fi de forma :

In prima fază, metoda de mapare împarte intrarea primita în cuvinte identificate după spațiul dintre ele și le face de forma < <cuvânt>, 1>. Implementarea este în metoda “map” suprascrisa prin implementarea clasei Mapper.

Si pentru exemplul de mai sus avem :

Apoi este implementat Reducer-ul în metoda “reduce” și aduna toate valorile care apar la aceeași cheie.

Iar rezultatul este următorul :

2.6 BAZE DE DATE NOSQL

Bazele de date relaționale sau RDMBS (Relational database management systems) fac parte din tehnologia predominanta care este folosita la ora actuala pentru a stoca și păstra date atât pentru aplicațiile web cat și pentru aplicațiile din companii. Chiar daca pe parcursul timpului s-a mai încercat adoptarea unor alte tehnologii cum ar fi baze de date bazate pe obiecte sau stocarea sub forma de XML nu au reușit să fie atât de populare că bazele de date relaționale, acestea chiar fiind absorbite ajungându-se să se poată stoca direct un XML și apoi să fie folosit pentru indexare de text.

Recent conceptul de a avea o singura baza de date care poate acoperi absolut orice nevoie de stocare a început să fie analizat de către cei care lucrează în domeniu și astfel s-au lovit de probleme de eficienta și consistenta a datelor lucru ce a făcut la apariția unei varietăți mari de alternative ale bazelor de date relaționale.

Acest lucru a dus la apariția de baze de date numite NOSQL (not only SQL), utilizat pentru a specifica creșterea bazelor de date non relaționale care devin din ce în ce mai folosite de către dezvoltatorii Web.

Conceptele de bază, tehnicile și modelele de programare folosite la implementarea bazelor de date NoSql sunt următoarele: Consistenta datelor care spune în ce mod un sistem de date este consistent sau nu după execuția unor operații. Se poate spune că într-un sistem distribuit de obicei atunci când cineva efectuează o operație de scriere în baza de date, toți ceilalți cliente care vor să efectueze o operație de citire trebuie să aibă disponibile toate datele care au fost scrise anterior.

Disponibilitatea datelor înseamnă că datele trebuie să fie stocate într-un sistem care permite citirea și scrierea continua chiar și atunci când unul dintre computerele din sistemul distribuit are o problema hardware sau software. Toleranta la partiții se refera la faptul că atunci când comunicația se face în rețea, datele trebuie să fie disponibile chiar daca între două noduri din rețea nu se poate realiza o conexiune la momentul în care se face cererea. Astfel sistemul trebuie să reușească să gestioneze acest tip de problema iar una din rezolvări ar fi multiplicarea datelor astfel încât atunci când un nod nu este disponibil, datele necesare să fie accesate dintr-o alta locație.

Stocare datelor se realizează sub forma de cheie-valoare, având un model simplu în comun: un dicționar, o mapare care ajuta clienții să pună sau să extragă valori pentru diferite chei. Pe lângă faptul că ne oferă un API (interfețe ce pot fi implementate în funcție de nevoia de business), stocările moderne sub forma de cheie valoare favorizează scalabilitatea crescuta și consistenta iar multe dintre ele omit cererile ad-hoc și în special join-urile și operațiile agregate. De obicei lungimea cheilor stocare au o dimensiune limitată la un număr de octeți pe când la valoare sunt mai puține limitări de dimensiune pentru date.

2.7 HBASE

Așa numit și Baza de date Hadoop, Hbase este o implementare a ceea ce deja cunoaștem a fi Big Table scrisa de către cei de la Google. De asemenea exista și diferențe între aceste două baze de date și acestea le voi prezenta în cele ce urmează.

Înainte de a începe cu datele tehnice despre Hbase, voi face un scurt istoric pentru a evidenția puțin modul în care acesta a apărut. Hbase a fost creat în 2007 în compania Powerset, situate în San Francisco care dezvolta un limbaj natural pentru un motor de căutare în Internet. în 2008 aceasta firma a fost cumpărată de către cei de la Microsoft și astfel suportul oferit către dezvoltarea de Hbase a fost abandonat. Mai apoi a fost reluat de către cei de la Apache Software Foundation și acum este disponibil sub licența lor de dezvoltare.

Una dintre diferențele între cele două baze de date, Hbase și Big Table este faptul că apar denumiri specific Hbase și anume :

Figură 7. Diferențe în denumirea elementelor între Hbase și Big Table

Hbase este un mediu de stocare distribuit, persistent și cu o consistenta a datelor crescuta cu scrieri aproape optime și posibilitatea de citire cu o performanta excelenta. El face că utilizarea discului de stocare să fie una eficienta prin algoritmi de compresie care pot fi selectați bazați pe tipul de date specifice familiilor de coloane. Nu exista un limbaj de interogări declarative în implementarea de baza și are suport limitat pentru tranzacții. Hbase gestionează încărcarea și eșecurile transparent fata de client pentru că acesta să fie afectat cat mai puțin. Scalabilitatea este un lucru de baza iar clusterul de calculatoare poate fi modificat chiar și în timp ce sistemul este în producție. Aceasta schimbare nu implica nicio rebalansare a datelor sau reîmpărțire complicate ci este una complet automata.

In aplicația mea, Hbase a fost instalat pe nodul master, putând fi accesat de oriunde din rețeaua din care aceasta face parte.

Instalarea Hbase în aplicație am făcut-o urmând următorii pași :

Pasul 1: Am descărcat versiunea de Hbase 0.98.12-hadoop2 folosind următoarea comanda :

“wget http://link-site-oficial”

Pasul 2: Dezarhivare și mutare fișier în locația dorita:

“tar -zxvf fisier.tar.gz”

După finalizarea dezarhivării, am mutat fișierul în locația dorita și am adăugat în “bash” locația către Hbase pentru a putea folosi executabilele fără a mai fi nevoie să scriu toata calea către acestea.

Am folosit următoarele comenzi:

“sudo cp -r hbase-0.98.12-hadoop2 /usr/local/hbase

sudo vim $HOME/.bashrc

(la sfârșitul fișierului se adaugă) :

export HBASE=/usr/local/hbase

export PATH=$PATH:$ HBASE /bin

exec bash

$PATH (pentru a putea vedea daca s-a adăugat în variabila PATH noua locație pentru Hbase)”

Pasul 3: Modificarea fișierului “hbase-env.sh” și adăugarea următoarelor linii:

“export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64

export HBASE_REGIONSERVERS=/usr/local/hbase/conf/regionservers

export HBASE_MANAGES_ZK=true”

Pasul 4: Modificarea fișierului de configurări “hbase-site.xml”

Pasul 5: Utilizarea scriptului de pornire a procesului Hbase :

“master@masterPC:~$ start-hbase.sh”

Pasul 6: Daca totul a funcționat cu succes se poate verifica disponibilitatea Hbase într-un browser web la următoarea adresa :

“http://masterpc:60010/master-status”

Tot aici se poate vedea și Region Server-ele ce sunt active, în cazul de fata doar unul singur și anume cel de pe master.

De asemenea tot aici se pot accesa celelalte taburi și se poate vedea memoria folosita, memoria heap, cererile totale de scriere și de citire dar și un o mica analiza asupra cate cereri se fac pe secunda.

Tot aici putem vedea și cate fișiere sunt stocate, și memoria pe care acestea o ocupa dar și tabelele și fișierele de jurnal care conțin toata activitatea înregistrată asupra procesului Hbase care se afla în rulare.

Figură 8. Interfață HBASE – Master

Tot aici daca accesam unul dintre serverele de regiune, în cazul meu doar unul singur, voi fi redirecționat automat la adresa :

“http://masterpc:60030/rs-status” se observă că portul s-a schimbat dar și denumirea, inițial fiind “master-status” iar acum este “rs-status”, iar rezultatul va fi următorul:

Figură 9. Interfață HBASE – Region Server

Unde că și la master se pot vedea detalii de memorie și cereri făcuse asupra serverului respective.

Tot aici se pot seta nivele de logare, dar pot și accesate și metricile Hbase sub forma de JSON:

Un fragment din fișierul care conține metrici este prezentat în cele ce urmează fiind evidențiată memoria Heap și cea NonHeap utilizata:

“Memoria Heap este un spațiu de memorie gestionat de către sistemul de operare și utilizat de către procese pentru a obține spațiu în plus în momentul rulării. Orice proces poate utiliza aceasta memorie dar bineînțeles că nu poate folosi spațiul rezervat unui alt proces. Rolul aceste memorii este de a oferii spațiu suplimentar.”

Pe lângă partea vizuală a Hbase unde se pot vedea tabele și unde se poate administra, oferă și un shell pentru a se folosi doar linia de comanda, prin intermediul căruia se poate configura la fel de bine baza de date.

Pentru a putea înțelege mai bine partea de shel o să fac în cele ce urmează un exemplu simplu de inserare și vizualizare a tabelelor în linia de comanda.

Inițial un tabel trebuie să aibă și o familie de coloane (column family). Folosind comanda :

“hbase shell” am intrat în utilitarul în care vom putea folosi comenzi specific hbase. Astfel pentru crea un tabel voi folosi :

După creare am adăugat rânduri în tabel cu ajutorul comenzii “put”:

Si am listat conținutul tabelei de test al cărui nume este “tabelTest” cu ajutorul comenzii “scan” iar rezultatul este în figura de mai sus.

Se poate observă cum printează Hbase datele într-o forma orientata pe celula, afișând fiecare coloana separat.

Daca vrem să afișăm sau să preluam doar o singura înregistrare de pe un rând atunci se pot folosi mai multe comenzi și se poate face extragerea în mai multe moduri dar momentan doar pentru a simplifica exercițiul deoarece este unul doar de test atunci se poate folosi comanda:

“get ‘tabelTest’, ‘rand1’ ” iar afișarea va fi similara cu cea precedenta doar că în cazul acesta un singur rând va fi afișat.

De asemenea atunci când vrem să ștergem tabelul înainte de acest lucru trebuie să dezactivam tabelul și apoi să îl ștergem folosind următoarele comenzi :

“disable ‘tabelTest’ ”

“drop ‘tabelTest’ ”

Apoi se poate ieși din linia de comanda Hbase prin comanda “exit” și se poate închide procesul de funcționare Hbase prin scriptul “stop-hbase.sh”.

Cerințele de sistem pentru instalarea Hbase sunt următoarele :

Hardware

Este destul de greu să spun o configurație exacta pentru un server specific pentru Hbase. De fapt el este conceput să ruleze pe multe tipuri de configurații hardware. în documentația oficiala vedem că este descris că fiind un sistem ce poate rula pe configurații medii. în cele ce urmează voi detalia acest lucru pentru a se înțelege mai bine la ce se refera acest lucru.

In cele ce urmează voi discuta despre mașini de tip server și nu PC-uri obișnuite. Știind că Hbase este scris în Java, un server va trebui să aibă și suport pentru “Java Runtime”. Memoria va fi în general folosita în structurile interne pe serverele de regiune, de exemplu pentru blocurile de cache iar pentru acest lucru este nevoie de un sistem de operare pe 64-biti care să poate avea disponibili cel puțin încă 4GB.

In practica ( la fel și în proiectul meu ) Hbase se instalează odată sau chiar pe aceeași mașină cu Hadoop pentru a putea folosi sistemul de fișier local dar și MapReduce. Acest lucru reduce foarte mult utilizarea rețelei pentru citiri și scrieri și creste viteza de procesare a datelor. Rularea Hbase și a Hadoop pe același server face că cel puțin 3 procese Java să fie pornite și anume : Data Node, Task Tracker și Region Server și pot atinge numere mari atunci când toate sunt în execuție. Dar toate aceste procese au nevoie de un număr minim de memorie, unitate optica de stocare și procesor pentru a fi executate într-un mod normal.

De asemenea daca alocam toata memoria disponibila proceselor de Hbase nu putem spune că facem un lucru bun deoarece sistemul de operare mai are nevoie de ceva memorie libera pentru a lucra eficient. De exemplu bufferele folosite de disk la citire și scriere la sistemul de operare Linux, gestionate de către kernel.

Putem separa cerințele în două categorii și anume : Servere și Rețea. Voi explica aceste două categorii începând prima daca cu partea de Server iar mai apoi voi termina cu explicarea categoriei de rețea.

Serverele:

În Hbase și Hadoop sunt două tipuri de mașini : cele de tip master care conțin Nodul de Nume pentru sistemul de fișiere HDFS, JobTrackerul pentru MapReduce, și Hbase Master. Al doilea tip de mașină sunt cele de tip slave care continu Nodul de Date pentru sistemul de fișiere HDFS, Task Tracker-ul pentru MapReduce dar și Hbase RegionServers. De cele mai multe ori ele nu dispun de configurări de sistem diferite dar este bine de știu că mașină de tip master nu are nevoie de spațiu de stocare la fel de mult că un nod de date deci ar fi logic să nu se folosească la fel de mult disk-uri. Este bine că procesele Java să fie rulate prioritar pe sistemul de operare pe care sunt instalate. O să continui cu câteva specificații mai generice pentru fiecare component care este utilizata și anume :

CPU – Nu este o practica buna să se execute trei sau mai multe procese Java, plus serviciile necesare de către sistemul de operare pe mașini care au în componenta un singur procesor. Pentru producție este necesar să existe un procesor multinucleu. Procesoarele quad-core sunt cele mai bune și pe care ți-l poți permite dar și cele hexa-core devin din ce în ce mai populare. Unele servere suporta și mai multe procesoare, nu doar nuclee mai multe ci și procesoare fizice și pot fi adăugate două de cate 4 nuclee astfel însumate să facă cat un procesor cu opt nuclee.

Pe partea de procesor pot spune că pentru cele două tipuri de mașini pot rula foarte bine aplicațiile pe procesoare de tipul :

Memoria – Primul lucru la care te gândești este să ii oferi unui proces cat mai mult spațiu de memorie. Dar nu întotdeauna acest lucru va face că procesul să ruleze mai rapid. Memoria denumita și Heap atunci când vorbim de limbajul de programare și mașină virtuala Java, poate începe să se fragmenteze, iar în cel mai rău caz întreaga memorie heap ar trebui să fie rescrisa acest lucru fiind similar cu fragmentarea disk-ului de stocare. Java Runtime oprește procesele pentru a putea face curat în memorie . Cu cat memoria este mai mare cu atât procesele vor dura mai mult timp pana la finalizare. Astfel atunci când sunt procese ce nu au nevoie de spațiu prea mare, nu trebuie să li se dea multa memorie tocmai pentru a se evita acest lucru.

In cele ce urmează voi afișa un tabel cu memoria necesara unui cluster cu capacitate de stocare de 800 TB și alocare de memorie necesara fiecărui proces:

Tabel 2-1. Exemplu de memorie alocata proceselor Java într-un cluster de 800 TB de stocare.

De asemenea pentru un cluster exemplar se pot folosi și dimensiuni ale memoriei de pana la 24 de GB.

Disk-ul – datele sunt stocate doar pe DataNodes după cum le spune și numele iar spațiul de stocare trebuie să fie cat mai mare pe aceste mașini. Dar și acestea pot fi utilizate mai intens pentru citire, altele pentru scriere iar altele pentru o procesare mai mare decât pentru operațiile anterioare de I/O. De obicei este bine să avem un nucleu pentru fiecare disk din sistem.

O întrebare ar fi ce tip de configurație ar trebui folosita pentru a putea atașa disk-urile în sistem, RAID sau JBOD? Ei bine pentru mașinile slave nu ar trebui folosit RAID deoarece este mai încet decât disk-urile separate din cauza administrării greoaie și a scrierii de tip “pipeline” și de aceea este indicate folosirea JBOD. Pentru mașină master se poate folosi RAID.

RAID :

“<Redundant Array of Independent Disks>, care înseamnă o configurație (matrice) de discuri dure (HDD) specială, menită să ofere scurtarea timpilor de acces la date precum și toleranță mai bună la erori. “

JBOD:

“ Derivat de la <just a bunch of disks> o arhitectură care implică mai multe hard disk-uri, făcându-le accesibile fie independent de disk-urile fizice, sau că un volum logic unic combinat cu nici o funcționalitate reală RAID.”

Pentru rețea se pot folosi următoarele configurații:

PSU – provine de la “Single Power Supply Unit”

U – “rack units” – de obicei într-un număr mic de unități rack și anume 1U sau 2U.

Software

După ce am stabilit o configurație hardware necesara pentru un cluster de mașini este momentul să ne gândim și la o configurație software și anume la un sistem de operare. Având în vedere că vorbit de sisteme open source ar fi bine că și sistemul de operare să fie la fel iar vorbind de ultimii doi ani se pare că se prefera sistemul de operare Linux pentru Hbase și Hadoop. De fapt aceste două sisteme sunt concepute să lucreze pe Linux sau pe Unix. Atâta timp cat exista suport pentru Java, se poate folosi orice alt sistem de operare, cum ar fi Windows. Dar fiind conceput pentru Linux avem chiar la îndemână și scripturile pentru pornire și oprire procese. și la Linux exista distribuții gratuite dar și unele la care trebuie să plătești pentru a le putea folosi legal. în cele ce urmează voi lista câteva dintre sistemele Linux care le-am găsit că o buna baza pe care poate fi instalat Hbase și Hadoop:

CentOs, Fedora, Debian, Ubuntu, Solaris, RedHat Enterprise Linux.

In licența mea am folosit Ubuntu că sistem de operare suport pentru instalarea de Hbase și Hadoop.

Ubuntu este o distribuție de Linux bazata pe Debian. Este open source și este gratuita pentru descărcare și folosire.

CAPITOLUL 3 – ANALIZĂ, DEFINIRE SPECIFICAȚII ACTUALE

CAPITOLUL 4 – IMPLEMENTARE APLICAȚIE

Înainte de a începe implementarea aplicație a trebuie să îmi aleg sistemul de operare pe care îl voi folosi pentru tehnologiile care le-am prezentat în capitolele anterioare. Astfel am ales sistemul de operare Linux, o distribuție Ubuntu 14.

Arhitectura pe care am folosit-o este următoarea :

Figură 10. Arhitectură de nivel înalt Lucrare de Licență

Primul lucru a fost să configurez clusterul de calculatoare, că mai apoi să instalez Hadoop pentru a putea rula job-uri care să mă ajute în generarea de rapoarte, automat din aplicație.

Pasul 1: Configurări rețea

Pe partea de rețea am folosit IP-uri statice și anume :

MasterPC : 192.168.0.120

Slave1PC : 192.168.0.121

Slave2PC : 192.168.0.122

Slave3PC : 192.168.0.123

Mașina pe care este deployat .WAR-ul ( web archive ) și pe care rulează serverul Tomcat 7 are ip dinamic asignat prin DHCP.

Pasul 2: Stabilire conexiune ssh între mașini pentru a putea comunica fără parola (Atenție, datele sunt criptate, nefolosirea parolei nu duce la un sistem în care lipsește securitatea, la conexiune se folosesc chei ssh atât pentru criptare cat și pentru decriptare)

Pentru acest lucru a fost nevoie de instalarea serverului ssh folosind următoarea comanda:

“sudo apt-get install openssh-server”

După acest lucru am generat o noua cheie ssh și am copiat cheia publica pe toate mașinile la care voiam să mă conectez ulterior.

“ssh keygen

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

ssh-copy-id -i ~/.ssh/id_rsa.pub master@192.168.0.120”

Am modificat fișierul “hosts” astfel încât calculatoarele din rețea să se cunoască și folosind numele pc-ului și nu numai IP-ul :

Am adăugat un fișier de configurare în folderul “.ssh” pentru a nu mai fi nevoie să scriu pe viitor următoare sintaxa pentru conectare “ssh user@host” ci voi scrie direct “ssh host” iar el va ști ce user să folosească pentru fiecare host în parte :

Pasul 3: Instalare JAVA

Acest lucru l-am realizat cu următoare comanda :

“sudo apt-get install openjdk-7-jdk”

Pasul 4: Descărcare Hadoop

“wget http://mirrors.hostingromania.ro/apache.org/hadoop/common/hadoop-2.6.0/hadoop-2.6.0-src.tar.gz”

Pasul 5: Instalare Hadoop

Dezarhivarea pachetului descărcat se face folosind utilitarul “tar”

“tar -zxvf fisier.tar.gz”

După finalizarea dezarhivării, am mutat fișierul în locația dorita și am adăugat în “bash” locația către Hadoop pentru a putea folosi executabilele fără a mai fi nevoie să scriu toata calea către acestea.

Am folosit următoarele comenzi:

“sudo cp -r hadoop-2.6 /usr/local/hadoop

sudo vim $HOME/.bashrc

(la sfârșitul fișierului se adaugă) :

export HADOOP=/usr/local/Hadoop

export PATH=$PATH:$HADOOP/bin

exec bash

$PATH (pentru a putea vedea daca s-a adăugat în variabila PATH noua locație pentru Hadoop)”

Pasul 6: în pasul acesta trebuie să modificam fișierul de configurare “hadoop-env.sh” pentru a seta calea către Mașina Virtuala Java și ai spune să folosească doar protocolul de comunicația în rețea IPV4:

Am folosit următoarele comenzi:

“sudo vim /usr/local/hadoop/etc/hadoop/hadoop-env.sh”

Iar aici am adăugat următoarele linii :

“export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-amd64

export HADOOP_OPTS=-Djava.net.preferIPv4Stack=true”

Pasul 7: Adăugare de proprietăți în fișierele de configurare :

“core-site.xml” : (in funcție de mașină, valoarea caii către fișierul “tmp” diferă.

“hdfs-site.xml”

Proprietatea cu numele : “dfs.replication” setează numărul de replici ale fișierelor din cluster. în mod predefinit el este 3 daca nu este setat aici, eu am folosit 2 pentru economie de spațiu și în scop de testare.

“mapred-site.xml”

“yarn-site.xml”

De asemenea, în documentația oficiala se găsesc toate configurările predefinite ale fișierelor.

Pasul 9: Modificarea fișierului “slaves” pentru a specifica nodurile de date din cluster. în proiectul meu am considerat masterPC și nod de nume și nod de date, iar celelalte 3 mașini sunt doar noduri de date.

“slaves” conține următoarele linii :

Pasul 10: Formatarea nodului de nume, pe mașină masterPC se executa următoarea comanda:

“hadoop namenode -format”

După mesajul de succes ce va și afișat se va trece la pasul următor.

Pasul 11: Pornirea demonilor, și anume cel pentru dfs și cel pentru yarn, executând următoarele comenzi:

“start-dfs.sh”

“start-yarn.sh”

Pasul 12: Verificarea pe fiecare mașină a aplicațiilor care rulează :

Se folosește comanda “jps” iar rezultatul trebuie să fie următorul :

Pe mașină masterPC:

Pe nodurile de date(slave1PC, slave2PC, slave3PC):

La final după execuția tuturor pașilor se poate verifica funcționalitatea clusterului și parametrii de configurare și într-un browser web accesând următorul link :

http://masterPC:50070/explorer.html

Iar rezultatul este :

Figură 11. Interfață Hadoop

Clusterul conține un nod de nume MasterPC și 3 noduri de date Slave1PC, Slave2PC, Slave3PC.

Accesând link-ul pentru verificarea utilitarului YARN :

“http://masterPC:8088/cluster/apps”

Se pot observa toate configurațiile ce au fost făcut în fișierele de configurare dar și joburile ce au fost rulate.

De asemenea sunt detaliate job-urile într-un raport care poate fi văzut în figura următoare:

Figură 12. Interfață YARN

Pentru un fișier de aproximativ 400 de MB, un job de map reduce durează în medie 8 minute, de aceea joburile se executa o data pe zi la o ora în care aplicație este cel mai puțin folosită (noaptea) că mai apoi aplicație să se folosească de datele procesate din cluster.

Am folosit că limbaj de programare JAVA și un framework pentru a mă ajuta să creez o aplicație de tip MVC (Model View Controller) numit SpringMVC. De asemenea pentru a putea crea un formular de login pentru Securitate am folosit Spring Security iar pentru stocarea informațiilor am folosit o baza de date de tipul MySql.

Pentru rularea aplicației am folosit un server Apache Tomcat, iar rezultatul este următorul (partea de administrare):

Figură 13. Interfață administrare aplicație

In proiect am utilizat două baze de date și anume MySql o baza de date relațională pentru stocarea utilizatorilor și a grupurilor din care fac parte pentru a-i putea diferenția în funcție de rolul pe care îl au în companie.

O diagramă a bazei de date relaționale este următoarea și cuprinde tabelele de baza care pot fi extinse în orice moment pentru o dezvoltare ulterioara a aplicației.

Figură 14. Diagramă bază de date SQL

Odată cu aceasta baza de date, pentru a fi mai ușor de utilizat în aplicație și pentru a reuși să modific datele exact cum vreau eu, a fost nevoie de o mapare a acestora în codul Java.

Astfel am creat un model pentru fiecare dintre tabele, iar pentru conexiunea către baza de date am folosit framework-ul Hibernate, o implementare a JPA (Java Persistance API ) o interfață de programare cu ajutorul căruia poți realiza managementul și gestiunea datelor relaționale într-o aplicație ce folosește platforma JAVA.

Modul în care se face conectarea îl voi explica în cele ce urmează precum și realizarea obiectelor ce mapeaza baza de date.

In Anexa se afla o secțiune de cod pentru a înțelege mai bine modul în care obiectele sunt create.

CAPITORUL 5 – INTEGRARE ȘI TESTARE

Pentru a putea testa aplicație și facă a o face într-un mod manual, m-am gândit să folosesc un program cu ajutorul căruia pot dezvolta teste automate care să se execute ori de cate ori am nevoie să verific că aplicație este compatibila cu cerințele și standardele la care a fost dezvoltata.

Astfel m-am gândit să folosesc “Selenium” un software de testare automata, scris și el la rândul lui în Java, având ultima lansare pe piață pe 26 februarie 2015. Aparține tot de către cei de la Apache și este în continua dezvoltare, fiind în general folosit în aplicații web.

Selenium oferă posibilitatea de a înregistra și apoi a rula ceea ai înregistrat anterior pentru a crea teste fără a mai fi nevoie de învățarea unui limbaj de scriere a scripturilor. De asemenea oferă și un limbaj specific utilizat în scrierea testelor (Selenese) folosind un număr variat de limbaje de programare și anume Java, Python, Ruby etc. Testele pot fi apoi rulate pe majoritatea browser-elelor web de la ora actuala și poate fi instalat pe Windows, Linux, Macintosh. Este un program “open-source” și poate fi descărcat fără costuri suplimentare.

In cele ce urmează voi face un scurt istoric despre cum a apărut selenium și cum a evoluat pe parcursul timpului. Selenium a fost dezvoltat inițial de către Jason Huggins în 2004 că o aplicație interna la compania la care lucra “ThoughtWorks”. Mai târziu i s-au alăturat și alți programatori și testeri și au început să lucreze la ceea ce mai târziu s-a numit “Selenium Remote Control” , iar în acel an, aplicație a devenit open-source. In 2005 Dan Fabulich și Nelson Sproul au făcut o ofertă pentru a fi acceptate o serie de noi piese care vor transforma Selenium-RC în ceea ce este cel mai bine cunoscut.

In 2007, Huggings s-a angajat la Google. Împreuna cu alți colegi cum ar fi Jennifer Bevan el a continuat să lucreze la Selenium RC. în același timp Simon Stewart angajat al ThoughtWorks a dezvoltat un program superior de testare automata a browser-elelor web. în 2009 după o conferință a dezvoltatorilor la “Google Test Automation Conference” s-a decis să se unească cele două proiecte, astfel creându-se un nou proiect numit Selenium WebDriver sau Selenium 2.0.

In 2008 Philippe Hanrigou tot un angajat al ThoughtWorks a creat o alta aplicație numita “Selenium Grid” care oferă posibilitatea de a rula mai multe teste în paralel lucru ce aduce o scădere a timpului de execuție al testelor.

Numele de “Selenium” provine dintr-o gluma a angajaților din acea vreme și anume a lui Huggings care într-un email ironic la adresa competitorilor numiți “Mercury” spune că te poți vindeca de otrăvirea cu mercur doar luând pastile cu selenium.

Selenium a devenit un set de unelte și astfel conține următoarele componente de baza :

Selenium IDE :

Seleniun IDE (integrated development environment) în traducere un mediu de dezvoltare integrat folosit în special pentru scrierea testelor. Este implementat special pentru Firefox sub forma de “add-on” și permite înregistrarea, editarea și oferă posibilitatea de depanare a acelor teste care nu trec, sau nu au un rezultat valid. Inițial era cunoscut sub numele de Selenium Recorder și a fost creat de către Shinya Kasatani iar apoi a fost donat către proiectul Selenium în 2006. Scripturile pot fi create și editate automat în Selenese un limbaj specializat în teste.

Selenium Client API :

Ca și o alternativa la limbajul Selenese oferit de către Selenium, testele pot fi scrise și în limbaje de programare obișnuit, cum ar fi Java, Pyhon, Ruby. Aceste teste pot comunica cu Selenium apelând metodele din Selenium Client API.

Selenium Remote Control :

Selenium Remote Control este un server, scris în Java care accepta comenzi pentru browser prin protocolul HTTP. RC face posibila scrierea testelor automate pentru aplicații web în orice limbaj de programare și permite integrarea cu Selenium chiar și a testelor unitare existente.

Selenium Web Driver:

Selenium WebDriver este succesorul lui Selenium RC care accepta comenzi primite prin Selenese sau prin clientul API și le trimite mai departe către browser-ul web.

In 2012 Simon Stewart cel care a creat web driver-ul și David Burns de la Mozilla au fost în negocieri cu W3C ( World Wide Web Consortium ) cu scopul de a face WebDriver un standard pentru internet.

Selenium Grid :

Selenium Grid oferea posibilitatea de a rula mai multe teste în paralel lucru ce aduce o scădere a timpului de execuție al testelor.

CAPITOLUL 6 – ANALIZĂ PERFORMANȚE

CAPITOLUL 7 – CONCLUZII

ANEXE

Model pentru mapare tabela de utilizatori din baza de date relațională MySql:

“UserEntity.java”

package com.licenta.model;

import java.util.HashSet;

import java.util.Set;

import javax.persistence.Column;

import javax.persistence.Entity;

import javax.persistence.FetchType;

import javax.persistence.GeneratedValue;

import javax.persistence.GenerationType;

import javax.persistence.Id;

import javax.persistence.JoinColumn;

import javax.persistence.JoinTable;

import javax.persistence.ManyToMany;

import javax.persistence.Table;

@Entity

@Table(name = "USERS")

public class UserEntity {

@Id

@GeneratedValue(strategy = GenerationType.AUTO)

@Column(name = "USER_ID")

private int userId;

@Column(name = "USERNAME")

private String username;

@Column(name = "EMAIL")

private String eMail;

@Column(name = "PASSWORD")

private String password;

@Column(name = "FIRSTNAME")

private String firstName;

@Column(name = "LASTNAME")

private String lastName;

@Column(name = "ACTIVE")

private boolean active;

@ManyToMany(fetch = FetchType.LAZY)

@JoinTable(name = "USER_GROUP_has_USER", joinColumns = @JoinColumn(name = "USER_ID"),

inverseJoinColumns = @JoinColumn(name = "USER_GROUP_ID"))

private final Set<GroupEntity> groups = new HashSet<GroupEntity>();

public int getUserId() {

return userId;

}

public void setUserId(final int userId) {

this.userId = userId;

}

public String getUsername() {

return username;

}

public void setUsername(final String username) {

this.username = username;

}

public String geteMail() {

return eMail;

}

public void seteMail(final String eMail) {

this.eMail = eMail;

}

public String getPassword() {

return password;

}

public void setPassword(final String password) {

this.password = password;

}

public String getFirstName() {

return firstName;

}

public void setFirstName(final String firstName) {

this.firstName = firstName;

}

public String getLastName() {

return lastName;

}

public void setLastName(final String lastName) {

this.lastName = lastName;

}

public boolean isActive() {

return active;

}

public void setActive(final boolean active) {

this.active = active;

}

public Set<GroupEntity> getGroups() {

return groups;

}

}

Model pentru maparea entității grupuri din baza de date relațională MySql:

“GroupEntity.java”

package com.licenta.model;

import java.util.HashSet;

import java.util.Set;

import javax.persistence.CascadeType;

import javax.persistence.Column;

import javax.persistence.Entity;

import javax.persistence.FetchType;

import javax.persistence.GeneratedValue;

import javax.persistence.GenerationType;

import javax.persistence.Id;

import javax.persistence.JoinColumn;

import javax.persistence.JoinTable;

import javax.persistence.ManyToMany;

import javax.persistence.Table;

@Entity

@Table(name = "USER_GROUPS")

public class GroupEntity {

@Id

@GeneratedValue(strategy = GenerationType.AUTO)

@Column(name = "USER_GROUP_ID")

private int groupID;

@Column(name = "NAME")

private String groupName;

@ManyToMany(cascade = CascadeType.PERSIST, fetch = FetchType.LAZY)

@JoinTable(name = "USER_GROUP_has_USER", joinColumns = @JoinColumn(name = "USER_GROUP_ID"),

inverseJoinColumns = @JoinColumn(name = "USER_ID"))

private final Set<UserEntity> users = new HashSet<UserEntity>();

public int getGroupID() {

return groupID;

}

public void setGroupID(final int groupID) {

this.groupID = groupID;

}

public String getGroupName() {

return groupName;

}

public void setGroupName(final String groupName) {

this.groupName = groupName;

}

public Set<UserEntity> getUsers() {

return users;

}

@Override

public String toString() {

return "GroupEntity [groupID=" + groupID + ", groupName=" + groupName + ", users=" + users

+ "]";

}

}

Fișierul de configurare Hibernate pentru conectarea la baza de date :

“hibernateContext.hml”

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tx="http://www.springframework.org/schema/tx"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.1.xsd

http://www.springframework.org/schema/tx

http://www.springframework.org/schema/tx/spring-tx-3.1.xsd">

<bean id="dataSource"

class="org.springframework.jdbc.datasource.DriverManagerDataSource">

<property name="driverClassName" value="com.mysql.jdbc.Driver" />

<property name="url" value="${db.url}" />

<property name="username" value="${db.user.name}" />

<property name="password" value="${db.user.password}" />

</bean>

<bean id="sessionFactory"

class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">

<property name="dataSource" ref="dataSource" />

<property name="packagesToScan" value="com.licenta.model" />

<property name="hibernateProperties">

<props>

<prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>

<prop key="hibernate.show_sql">true</prop>

<prop key="jadira.usertype.autoRegisterUserTypes">true</prop>

</props>

</property>

</bean>

<tx:annotation-driven transaction-manager="transactionManager" />

<bean id="transactionManager"

class="org.springframework.orm.hibernate4.HibernateTransactionManager">

<property name="sessionFactory" ref="sessionFactory" />

</bean>

</beans>

Fișierul de proprietăți din care citește fișierul anterior “hibernateContext.xml”

“database.properties”

#Database connection URL.

db.url=jdbc:mysql://localhost:3306/licenta

#Database username

db.user.name=root

#Database user password

db.user.password=root

Fișierul cu setările pentru securitate, folosind Spring-Security Framework

“spring-security.xml”

<?xml version="1.0" encoding="UTF-8"?>

<beans:beans xmlns="http://www.springframework.org/schema/security"

xmlns:p="http://www.springframework.org/schema/p" xmlns:beans="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/security

http://www.springframework.org/schema/security/spring-security-3.2.xsd">

<http auto-config="true">

<!– <intercept-url pattern="/**" requires-channel="https" /> –>

<intercept-url pattern="/dashboard**" access="ROLE_ADMIN" />

<intercept-url pattern="/dashboard/users/**" access="ROLE_ADMIN" />

<form-login login-page="/login" authentication-failure-url="/login?error"

username-parameter="username" password-parameter="password" />

<logout logout-success-url="/login?logout" />

<!– enable csrf protection –>

<csrf />

</http>

<global-method-security pre-post-annotations="enabled" />

<beans:bean id="passwordEncoder"

class="org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder" />

<beans:bean id="myUserDetailsServiceImpl"

class="com.licenta.security.service.CustomUserDetailsService" />

<beans:bean id="authenticationProvider"

class="com.licenta.security.service.LoginAuthenticationServiceImpl"

p:userDetailsService-ref="myUserDetailsServiceImpl"

p:passwordEncoder-ref="passwordEncoder">

</beans:bean>

<!– <authentication-manager> <authentication-provider> <user-service> <user

name="mihai" password="123456" authorities="ROLE_ADMIN" /> </user-service>

</authentication-provider> </authentication-manager> –>

<authentication-manager>

<authentication-provider ref="authenticationProvider">

</authentication-provider>

</authentication-manager>

</beans:beans>

BIBLIOGRAFIE

“Gartner Says Solving ‘Big Data’ Challenge Involves More Than Just Managing Volumes Of Data”, 27 iunie 2011

http://www.esri.ro/products/technology-topics/big-data

“Hadoop-Illuminated” – Mark Kerzner, Sujee Maniyam

http://hadoop.apache.org/

http://wiki.apache.org/hadoop/PoweredBy

http://aipi2014.andreirosucojocaru.ro/laboratoare/laborator10

http://ro.wikipedia.org/

http://commons.apache.org/proper/commons-daemon/

http://opensource.com/life/14/8/intro-apache-hadoop-big-data

“The Google File System” – Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung

Steps to install Hadoop 2.x release (Yarn or Next-Gen) on multi-node cluster

https://en.wikipedia.org/wiki/Selenium_(software)

HBase – The definitive Guide – Lars George

BIBLIOGRAFIE

“Gartner Says Solving ‘Big Data’ Challenge Involves More Than Just Managing Volumes Of Data”, 27 iunie 2011

http://www.esri.ro/products/technology-topics/big-data

“Hadoop-Illuminated” – Mark Kerzner, Sujee Maniyam

http://hadoop.apache.org/

http://wiki.apache.org/hadoop/PoweredBy

http://aipi2014.andreirosucojocaru.ro/laboratoare/laborator10

http://ro.wikipedia.org/

http://commons.apache.org/proper/commons-daemon/

http://opensource.com/life/14/8/intro-apache-hadoop-big-data

“The Google File System” – Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung

Steps to install Hadoop 2.x release (Yarn or Next-Gen) on multi-node cluster

https://en.wikipedia.org/wiki/Selenium_(software)

HBase – The definitive Guide – Lars George