Big Data a devenit unul dintre cele mai folosite cuvinte din domeniul IT; poate fi considerat chiar un buzzword, iar pe internet găsim sute de articole care definesc cuvântul și îi stabilesc sensurile. Dar trecând peste toate acestea, noile paradigme impuse de acest concept și tehnologia care îl face posibil continuă să se dezvolte ca exponenți, ducând și la dezvoltarea companiilor care le adoptă.
Dacă vorbim despre Big Data și despre tehnologiile din spate, trebuie să vorbim și despre Hadoop, care este baza pentru multe dintre acestea.
Hadoop este unul dintre proiectele principale ale Apache Software Foundation și există pe piața IT de aproape zece ani. Inițial, a fost proiectat pentru a distribui un alt proiect născut în incubatorul de idei Apache, un web-crawler numit Nutch, fiind inspirat de progresul de la Google, care a devenit public datorită articolului MapReduce: Simplified Data Processing on Large Clusters din 2004. Zece ani mai târziu, această pagină reprezintă dovada că Hadoop a fost adoptat pe piața tehnologică din prezent.
Scopul acestui articol prin urmare, având în vedere că a fost conceput din perspectiva unui administrator de sistem, este de a clarifica unele aspecte legate de instalarea, configurarea și administrarea unui cluster Hadoop, dar și de a sublinia progresul uimitor înregistrat în acest domeniu, care face ca adoptarea unei asemenea tehnologii să fie mult mai simplă.
Să luăm lucrurile pe rând. Cum funcționează ? Acest articol se va axa pe ramura 2.x a Hadoop deoarece are cea mai activă comunitate în prezent și deoarece pe aceasta ramură s-a dezvoltat ecosistemul cel mai mult.
Hadoop are două componente principale: HDFS (Hadoop Distributed File System) și YARN (Yet Another Resource Negotiator) și, după cum am lăsat să se înțeleagă mai sus, folosește paradigma computațională MapReduce. Această paradigmă reprezintă baza Hadoop, deoarece sistemul a fost conceput în jurul ideii de data locality, în sensul că este mult mai rapid și mai ușor să trimiți computații - gândiți-vă la jars sau chiar scripturi bash- unde se află datele decât să aduci sau imporți datele - gândiți-vă la dimensiuni de ordinul terabiților- prin rețea unde se află aceste scripturi. Prin urmare, decizia de design de a avea două subsisteme principale devine mai clară, deoarece ai nevoie de un sistem care să se ocupe de date și un altul care să se ocupe de computație, dar și de managementul resurselor, după cum vom vedea imediat.
Fără a mai face alte precizări, să discutăm puțin despre componenta HDFS. După cum sugerează și numele, HDFS este un sistem distribuit de fișiere care implementează un standard POSIX "relaxat" și care a fost conceput pentru a fi rulat pe commodity hardware. Cea mai simplă versiune a unui cluster HDFS are două tipuri de daemons: Namenode și Datanode, într-o arhitectură de tip master-slave. HDFS expune fișierele care sunt păstrate ca blocuri de 128MB pe Datanodes. De obicei, în cluster există un singur Namenode, al cărui rol este de a păstra metadata din sistemul de fișiere. El reglementează accesul utilizatorilor la fișiere, dar și operațiuni precum deschiderea, închiderea și numirea de fișiere. Totodată, menține o mapare a blocurilor aflate pe Datanodes. Datanodes mențin toate block-urile din care este compus sistemul de fișiere și sunt responsabili pentru managementul cererilor de scriere și de citire.
HDFS a fost conceput cu o mare toleranță la greșeli și este implementat după cum puteți vedea în imagine, prin replicarea de block-uri între Datanodes, un concept de design care ajută și la distribuția computațiilor, dar despre acest subiect vom vorbi mai târziu. HDFS poate fi configurat cu High Availability, care presupune posibilitatea de "rolling restarts" și totodată împiedică apariția de downtime în cazul unui downtime neplănuit al Namenode-ului.
A doua componentă Hadoop, care se ocupă de computații, este YARN (cunoscută și sub numele de MapReduce 2.0). Este disponibilă doar în varianta 2.x. YARN își împarte funcționalitatea între trei tipuri de daemons: ResourceManager, NodeManager și ApplicationMaster. Arhitectura YARN funcționează de asemenea pe principiul master/slave deoarece cluster-ul are un singur ResourceManager care deservește nevoile resurselor (memorie și CPU-uri de la 2.6) pentru întregul cluster, pe când NodeManager-ii sunt răspândiți la nivelul tuturor host-urilor din cluster. În linii mari, ne putem gândi la ResourceManager ca la planificatorul CPU al unui sistem de operare și la NodeManagers ca la procesele unui sistem, care cer timp pe procesor, un concept cunoscut și ca Datacenter as a Computer.
Pentru a vedea toate părțile ca ansamblu, putem analiza ciclul de viață al unui task din YARN. Unitatea computațională din YARN este container-ul care este un JVM în esență. Acest container poate prelua două funcții: poate fi un mapper sau poate fi un reducer. Odată ce task-ul este trimis spre execuție, ResourceManager alocă un ApplicationMaster pe unul din nodurile din cluster, care devine la rândul său responsabil de execuția task-ului. ApplicationMaster negociază cu ResourceManager pentru și mai multe resurse, dar și cu NodeManagers care lansează container-ele necesare pentru a finaliza task-ul. Din cauza principiului de locație a datelor, ApplicationMaster poate cere ca diferiți NodeManagers să lucreze la același task (dacă NodeManagers se găsesc pe noduri cu date duplicat). Această abordare este și mai utilă în cluster-e mari, care au o rată de eșec mai mare, deoarece face ca aceste eșecuri să fie invizibile pentru task-urile date. Și NodeManagers interacționează cu ResourceManager, dar numai pentru a oferi informații despre resursele disponibile.
Unele trăsături ale YARN care merită amintite sunt posibilitatea de configurare a cluster-ului, cu High Availability, o posibilitate care, începând cu lansarea 2.6 transferă și statutul task-urilor de la ResourceManagerul activ la cel pasiv în cazul unui eșec; aceasta înseamnă că acel cluster poate opera la parametri normali în timpul unui rolling restart sau al unui downtime neprevăzut. O altă trăsătură ar fi existența cozilor care permit cluster-ului să fie folosit în echipe diferite deodată, cu unele garanții.
După o introducere mai extinsă, ajungem la miezul problemei: crearea unui cluster Hadoop și menținerea lui, sau cu alte cuvinte provocarea infrastructurii. Această provocare poate fi împărțită în trei provocări mai mici: instalarea cluster-ului, configurarea lui și nu în ultimul rând menținerea lui. Aici avem mai mulți competitori care oferă soluții menite să rezolve această problemă, cum ar fi Hortonworks, Cloudera și chiar Oracle. Eu am ales soluția oferită de Hortonworks, numită Ambari.
Să începem cu instalarea cluster-ului Hadoop. Ambari se bazează pe o arhitectură de tip master/slave, unde master-ul are o interfață care permite utilizatorului să controleze cluster-ul, pe când "sclavii" sunt poziționați pe toate nodurile care compun cluster-ul Hadoop și care execută acțiunile comandate de master. Instalarea Ambari e destul de simplă, în sensul că trebuie să adaugi "the repository" pentru distribuția linux și apoi să instalezi pachetul Ambari-server prin managerul de pachete. Odată instalat, trebuie să configurați autentificarea prin chei ssh de la host-ul ambari spre toate nodurile din cluster, iar de aici înainte toate interacțiunile vor fi făcute prin interfața web Ambari. Dacă aveți un cluster deja configurat și trebuie să adăugați mai multe noduri, interacțiunea este aceeași: adăugați cheia ssh publică pe noul server (sau faceți un deploy cu ajutorul puppet) și apoi din interfața web Ambari, trebuie doar să adăugați nodul la cluster și Ambari are grijă de partea de deployment. Acestea fiind spuse, prima dintre provocări este rezolvată.
Pentru partea de configurare, Ambari expune toate fișierele de configurație prezente într-un cluster Hadoop în interfața sa web, oferindu-vă posibilitatea de a le edita. Începând cu versiunea 2.1.2 de la Ambari, unele proprietăți sunt prezentate într-o manieră mai prietenoase utilizând slider-e. O caracteristică menită să ușureze munca de integrare necesară pentru cluster este versionarea configurațiilor Ambari. Orice modificare adusă configurațiilor generează o nouă versiune a acelei configurații, deci poți să mergi înapoi și prin câteva click-uri recuperezi totul dacă a apărut o eroare. Acestea fiind spuse, am acoperit și cea de-a doua provocare mai mică.
Ultimul aspect analizat este legat de mentenanța cluster-ului, aspect pe care Ambari încearcă să îl simplifice. Permite un control granulat asupra tuturor proceselor și serviciilor ce funcționează în cluster, astfel că poți să le pornești sau să le oprești, dar oferă și posibilitatea de a porni și de a opri componente mai mari, cum ar fi subsistemul YARN sau HDFS. Orice modificare a configurației necesită un restart de la daemon-ii corespondenți și Ambari îi marchează pe cei care rulează cu stale configs și furnizează și posibilitatea de a restarta numai componentele afectate. Adăugarea unui serviciu nou (cum ar fi Spark, Oozie, Scoop) se face din cadrul interfeței web într-o manieră foarte directă și simplă. Începând cu versiunea 2.0, are un sistem de monitorizare și alertă integrat, numit ambari-metrics, care din nou ușurează munca de integrare care ar fi fost necesară dacă foloseam Nagios sau Graphite. Metricile poti fi adaptate și organizate în interfața web. Un alt avantaj al Ambari care merită menționat este că are suport pentru actualizarea stack-ului Hadoop în timp ce rulează, ușurând mult sarcina unui cluster maintainer. Având în vedere toate acestea putem considera provocarea infrastructurii drept rezolvată, sau cel puțin adusă foarte aproape de finalitate.
Ca un bonus, aș dori să menționez un alt tool care există în ecosistemul Hadoop și acesta este Hue. Hue este un proiect open-source al cărui scop este de a simplifica interacțiunile cu cluster-ul din punctul de vedere al unui developer. Integrează multe dintre proiectele dezvoltate sub Hadoop într-o singură interfață și îi permite developer-ului să lucreze mai repede și într-un mod mai vizual.
Trăsătura care este cea mai importantă din punctul de vedere al unui developer este integrarea cu OOZIE. Să presupunem că ați vrea să folosiți un cluster Hadoop și să rulați o serie de task-uri care presupun mai mulți pași , cum ar fi obținerea de date din surse externe, prelucrarea lor și apoi transmiterea lor înapoi într-o sursă externă. Într-un setup Hadoop normal, aceasta ar presupune niște script-uri sau comenzi de la linia de comandă sau niște task-uri duse la capăt cu Jenkins, dar cu Hue puteți să încărcați script-urile pe HDFS și să creați un workflow de tipul drag and drop, care poate fi salvat și rulat de mai multe ori. Oferă și posibilitatea de a planifica joburi prin coordonatorul său. Alte avantaje care sunt foarte folositoare ar fi: o interacțiune a sistemelor de fișiere mult mai bună de la interfața web decât cea oferită de Hadoop, dar și controlul asupra task-urilor oferit prin interfața web, care la fel este mult mai bun decât ceea ce oferă Hadoop by default, deoarece îți permite să oprești task-uri folosind interfața. Hue poate fi integrat cu LDAP, ceea ce înseamnă că fiecare developer care interacționează cu cluster-ul prin Hue vede doar propriul context, adică propriul lui home directory în HDFS și propriile task-uri în YARN.
Scopul acestui articol a fost acela de a oferi o privire de ansamblu asupra cerințelor de arhitectură implicate de un cluster Hadoop și de a propune o soluție pentru a le rezolva în ideea de a încuraja și de a ușura adoptarea acestei tehnologii noi. Era o părere personală a mea că oamenii sunt interesați de Hadoop și MapReduce, dar că se simt intimidați de necesitățile de infrastructură pentru a rula un cluster. Consider că am demonstrat că datorită ecosistemului care s-a format în jurul Hadoop, aceste necesități nu mai pot fi privite ca impedimente.