Piața de calcul distribuit și big data, conform , este în creștere cu 18-19% pe an. Aceasta înseamnă că problema alegerii software-ului în aceste scopuri rămâne relevantă. În această postare, vom începe cu de ce este nevoie de calcularea distribuită, vom detalia mai multe despre alegerea software-ului, vom vorbi despre utilizarea Hadoop folosind Cloudera și, în sfârșit, vom vorbi despre alegerea hardware-ului și modul în care acesta afectează performanța în moduri diferite.
De ce este nevoie de calculul distribuit în afacerile obișnuite? Totul aici este simplu și complex în același timp. Simplu - pentru că în majoritatea cazurilor efectuăm calcule relativ simple pe unitatea de informație. Este dificil pentru că există o mulțime de astfel de informații. Asa de mult. În consecință, este necesar . Astfel, cazurile de utilizare sunt destul de universale: calculele pot fi folosite oriunde este necesar să se ia în considerare un număr mare de metrici pe o gamă și mai mare de date.
Unul dintre exemplele recente: lanțul de pizzerii Dodo Pizza Pe baza unei analize a bazei de date a comenzilor clienților, atunci când aleg o pizza cu topping aleatoriu, utilizatorii operează de obicei cu doar șase seturi de bază de ingrediente plus câteva aleatorii. În conformitate cu aceasta, pizzeria și-a ajustat achizițiile. În plus, ea a putut să recomande mai bine produse suplimentare oferite utilizatorilor în etapa de comandă, ceea ce a crescut profiturile.
Încă un exemplu: articolele de produs au permis magazinului H&M să reducă sortimentul din magazinele individuale cu 40%, menținând în același timp nivelurile de vânzări. Acest lucru a fost realizat prin excluderea articolelor slab vândute, iar sezonalitatea a fost luată în considerare în calcule.
Selectarea instrumentului
Standardul industrial pentru acest tip de calcul este Hadoop. De ce? Pentru că Hadoop este un cadru excelent, bine documentat (același Habr oferă multe articole detaliate pe această temă), care este însoțit de un întreg set de utilități și biblioteci. Puteți introduce seturi uriașe de date structurate și nestructurate, iar sistemul însuși le va distribui între puterea de calcul. În plus, aceleași capacități pot fi mărite sau dezactivate în orice moment - aceeași scalabilitate orizontală în acțiune.
În 2017, influența companie de consultanță Gartner că Hadoop va deveni în curând învechit. Motivul este destul de banal: analiștii cred că companiile vor migra în masă către cloud, deoarece acolo vor putea plăti pe măsură ce folosesc puterea de calcul. Al doilea factor important care se presupune că poate „îngropa” Hadoop este viteza acestuia. Pentru că opțiuni precum Apache Spark sau Google Cloud DataFlow sunt mai rapide decât MapReduce, care stă la baza Hadoop.
Hadoop se sprijină pe câțiva piloni, dintre care cei mai notați sunt tehnologiile MapReduce (un sistem de distribuire a datelor pentru calcule între servere) și sistemul de fișiere HDFS. Acesta din urmă este special conceput pentru stocarea informațiilor distribuite între nodurile cluster: fiecare bloc de o dimensiune fixă poate fi plasat pe mai multe noduri, iar datorită replicării, sistemul este rezistent la defecțiunile nodurilor individuale. În loc de un tabel de fișiere, se folosește un server special numit NameNode.
Ilustrația de mai jos arată cum funcționează MapReduce. În prima etapă, datele sunt împărțite după un anumit criteriu, în a doua etapă sunt distribuite în funcție de puterea de calcul, iar în a treia etapă are loc calculul.
MapReduce a fost creat inițial de Google pentru nevoile sale de căutare. Apoi MapReduce a devenit cod gratuit, iar Apache a preluat proiectul. Ei bine, Google a migrat treptat către alte soluții. O informație interesantă: Google are în prezent un proiect numit Google Cloud Dataflow, poziționat ca următorul pas după Hadoop, ca înlocuitor rapid al acestuia.
O privire mai atentă arată că Google Cloud Dataflow se bazează pe o variantă a Apache Beam, în timp ce Apache Beam include cadrul bine documentat Apache Spark, care ne permite să vorbim despre aproape aceeași viteză de execuție a soluțiilor. Ei bine, Apache Spark funcționează perfect pe sistemul de fișiere HDFS, ceea ce îi permite să fie implementat pe serverele Hadoop.
Adăugați aici volumul de documentație și soluții gata făcute pentru Hadoop și Spark versus Google Cloud Dataflow și alegerea instrumentului devine evidentă. Mai mult, inginerii pot decide singuri ce cod - pentru Hadoop sau Spark - ar trebui să ruleze, concentrându-se pe sarcină, experiență și calificări.
Cloud sau server local
Tendința către o tranziție generală către cloud a dat naștere chiar și la un termen atât de interesant precum Hadoop-as-a-service. Într-un astfel de scenariu, administrarea serverelor conectate a devenit foarte importantă. Pentru că, din păcate, în ciuda popularității sale, Hadoop pur este un instrument destul de dificil de configurat, deoarece multe trebuie făcute manual. De exemplu, configurați serverele individual, monitorizați performanța acestora și configurați cu atenție mulți parametri. În general, munca este pentru un amator și există șanse mari să dai peste cap undeva sau să ratezi ceva.
Prin urmare, diverse kituri de distribuție, care sunt echipate inițial cu instrumente convenabile de implementare și administrare, au devenit foarte populare. Una dintre cele mai populare distribuții care acceptă Spark și face totul ușor este Cloudera. Are atât versiuni plătite, cât și versiuni gratuite - iar în cea din urmă toate funcționalitățile de bază sunt disponibile, fără a limita numărul de noduri.
În timpul configurării, Cloudera Manager se va conecta prin SSH la serverele dvs. Un punct interesant: la instalare, este mai bine să specificați că acesta să fie efectuat de așa-numitul pătrunseluri: pachete speciale, fiecare dintre ele conținând toate componentele necesare configurate pentru a funcționa între ele. În esență, aceasta este o versiune îmbunătățită a managerului de pachete.
După instalare, primim o consolă de gestionare a clusterului, unde puteți vedea telemetria clusterului, serviciile instalate, plus puteți adăuga/elimina resurse și puteți edita configurația clusterului.
Drept urmare, în fața ta apare cabina rachetei care te va duce în viitorul strălucit al BigData. Dar înainte să spunem „să mergem”, să trecem sub capotă.
Cerințe hardware
Pe site-ul său, Cloudera menționează diferite configurații posibile. Principiile generale după care sunt construite sunt prezentate în ilustrație:
MapReduce poate estompa această imagine optimistă. Dacă te uiți din nou la diagrama din secțiunea anterioară, devine clar că în aproape toate cazurile, un job MapReduce poate întâmpina un blocaj la citirea datelor de pe disc sau din rețea. Acest lucru este menționat și în blogul Cloudera. Ca rezultat, pentru orice calcule rapide, inclusiv prin Spark, care este adesea folosit pentru calcule în timp real, viteza I/O este foarte importantă. Prin urmare, atunci când utilizați Hadoop, este foarte important ca clusterul să includă mașini echilibrate și rapide, ceea ce, pentru a spune ușor, nu este întotdeauna asigurat în infrastructura cloud.
Echilibrul în distribuția sarcinii este atins prin utilizarea virtualizării Openstack pe servere cu procesoare multi-core puternice. Nodurilor de date li se alocă propriile resurse de procesor și discuri specifice. În decizia noastră Motorul Atos Codex Data Lake Se realizează o virtualizare largă, motiv pentru care beneficiem atât din punct de vedere al performanței (impactul infrastructurii de rețea este minimizat), cât și din punct de vedere al TCO (serverele extra fizice sunt eliminate).
Când folosim servere BullSequana S200, obținem o încărcare foarte uniformă, lipsită de unele blocaje. Configurația minimă include 3 servere BullSequana S200, fiecare cu două JBOD, plus S200-uri suplimentare care conțin patru noduri de date sunt conectate opțional. Iată un exemplu de încărcare din testul TeraGen:
Testele cu diferite volume de date și valori de replicare arată aceleași rezultate în ceea ce privește distribuția sarcinii între nodurile clusterului. Mai jos este un grafic al distribuției accesului la disc în funcție de testele de performanță.
Calculele au fost efectuate pe baza unei configurații minime de 3 servere BullSequana S200. Include 9 noduri de date și 3 noduri master, precum și mașini virtuale rezervate în cazul implementării protecției bazate pe OpenStack Virtualization. Rezultatul testului TeraSort: dimensiunea blocului 512 MB factor de replicare egal cu trei cu criptare este de 23,1 minute.
Cum poate fi extins sistemul? Există diferite tipuri de extensii disponibile pentru Data Lake Engine:
- Noduri de date: pentru fiecare 40 TB de spațiu utilizabil
- Noduri analitice cu capacitatea de a instala un GPU
- Alte opțiuni în funcție de nevoile afacerii (de exemplu, dacă aveți nevoie de Kafka și altele asemenea)
Motorul Atos Codex Data Lake include atât serverele în sine, cât și software-ul preinstalat, inclusiv un kit licențiat Cloudera; Hadoop în sine, OpenStack cu mașini virtuale bazate pe kernelul RedHat Enterprise Linux, sisteme de replicare a datelor și backup (inclusiv utilizarea unui nod de rezervă și Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine a devenit prima soluție de virtualizare certificată .
Dacă sunteți interesat de detalii, vom fi bucuroși să răspundem la întrebările noastre în comentarii.
Sursa: www.habr.com