Tregu i komputimeve të shpërndara dhe të dhënave të mëdha, nëse besoni , po rritet me 18-19% në vit. Kjo nënkupton se çështja e zgjedhjes së softuerit për këto qëllime mbetet e rëndësishme. Në këtë post, do të fillojmë me arsyet e nevojës për komputime të shpërndara, do të ndalemi më në detay në zgjedhjen e software-it, do të flasim për përdorimin e Hadoop me Cloudera dhe në fund, do të diskutojmë se si zgjedhja e harduerit ndikon në performancë në mënyra të ndryshme.
Pse janĂ« tĂ« nevojshme komputimet e shpĂ«rndara nĂ« biznesin e zakonshĂ«m? KĂ«tu Ă«shtĂ« e thjeshtĂ« dhe e komplikuar njĂ«kohĂ«sisht. E thjeshtĂ« â sepse nĂ« shumicĂ«n e rasteve ne kryejmĂ« llogaritje relativisht tĂ« thjeshta pĂ«r njĂ«si informacioni. E komplikuar â sepse ka shumĂ« informacion. ShumĂ« shumĂ«. Si pasojĂ«, na nevojitet . KĂ«shtu, skenarĂ«t e pĂ«rdorimit janĂ« mjaft universale: llogaritjet mund tĂ« pĂ«rdoren kudo ku kĂ«rkohet tĂ« merret parasysh njĂ« numĂ«r i madh metrikash mbi njĂ« grumbull akoma mĂ« tĂ« madh tĂ« dhĂ«nash.
Një nga shembujt e fundit: rrjeti i picerive Dodo Pizza bazuar në analizën e bazës së porosive të klientëve, që gjatë zgjedhjes së picës me përbërje të rastësishme, përdoruesit zakonisht operojnë vetëm me gjashtë grupe bazike përbërësish plus disa të rastësishme. Në përputhje me këtë, piceria ka rregulluar blerjet. Për më tepër, ajo ka arritur të rekomandojë më mirë produkte shtesë për përdoruesit në fazën e porosisë, gjë që ka rritur fitimet.
Një tjetër shembull: pozitat e produkteve kanë lejuar dyqanin H&M të reduktojë asortimentin në dyqane të caktuara me 40%, duke ruajtur njëkohësisht nivelin e shitjeve. Këto rezultate janë arritur duke përjashtuar pozitat me shitje të dobëta, duke marrë parasysh sezonin.
Zgjedhja e mjetit
Standardi industrial pĂ«r llogaritjet e kĂ«tij lloji Ă«shtĂ« Hadoop. Pse? Sepse Hadoop Ă«shtĂ« njĂ« strukturĂ« e shkĂ«lqyer, e dokumentuar mirĂ« (po aty Habr jep shumĂ« artikuj tĂ« detajuar mbi kĂ«tĂ« temĂ«), e cila shoqĂ«rohet me njĂ« grup tĂ« tĂ«rĂ« utilitarĂ«sh dhe bibliotekash. Ju mund tĂ« jepni nĂ« hyrje grumbuj tĂ« mĂ«dha si tĂ« dhĂ«nash tĂ« strukturuara ashtu edhe tĂ« pa strukturuara, dhe sistemi do t'i shpĂ«rndajĂ« vetĂ« ato mes kapaciteteve tĂ« llogaritjes. Plus, kĂ«to kapacitete mund tĂ« rriten ose çaktivizohen nĂ« çdo moment â ajo qĂ« quhet shkallĂ«zim horizontal nĂ« veprim.
NĂ« vitin 2017, kompania e njohur e konsulencĂ«s Gartner , tha se Hadoop do tĂ« zgjidhte vetveten. Arsyetimi Ă«shtĂ« mjaft banal: analistĂ«t mendojnĂ« se kompanitĂ« do tĂ« migrojnĂ« masivisht nĂ« re, pĂ«r shkak se aty mund tĂ« paguajnĂ« sipas pĂ«rdorimit tĂ« kapaciteteve tĂ« llogaritjes. Faktori i dytĂ« i rĂ«ndĂ«sishĂ«m, qĂ« mund tĂ« "varrosĂ«" Hadoop â Ă«shtĂ« shpejtĂ«sia e punĂ«s. Sepse opsionet si Apache Spark ose Google Cloud DataFlow punojnĂ« mĂ« shpejt se MapReduce, qĂ« Ă«shtĂ« baza e Hadoop.
Hadoop mbështetet në disa shtylla, më të dukshmet prej të cilave janë teknologjitë MapReduce (sistemi i shpërndarjes së të dhënave për llogaritje mes serverëve) dhe sistemi i skedarëve HDFS. Ky i fundit është posaçërisht i dizajnuar për ruajtjen e informacionit të shpërndarë mes nyjave të klasterit: çdo bllok me një madhësi fikse mund të vendoset në disa nyje, dhe përmes replikimit sigurohet që sistemi është i qëndrueshëm ndaj dështimeve të nyjeve të veçanta. Në vend të tabelës së skedave, përdoret një server i veçantë, i quajtur NameNode.
NĂ« ilustrimin mĂ« poshtĂ« Ă«shtĂ« paraqitur skema e punĂ«s sĂ« MapReduce. NĂ« fazĂ«n e parĂ« tĂ« dhĂ«nat ndahen sipas njĂ« kriteri tĂ« caktuar, nĂ« tĂ« dytĂ«n â ndahen mes kapaciteteve tĂ« llogaritjes, dhe nĂ« tĂ« tretĂ«n â kryhet llogaritja.
Fillimisht MapReduce u krijua nga Google për nevojat e kërkimit të tij. Më pas MapReduce kaloi në kodin e lirë, dhe projekti u mor nga Apache. Ndërsa Google gradualisht migroi në zgjidhje të tjera. Një detaj interesant: aktualisht Google ka një projekt, të quajtur Google Cloud Dataflow, i pozicionuar si hapi pasues pas Hadoop, si një zëvendësim të shpejtë.
Me një vështrim më të afërt, vërehet se Google Cloud Dataflow bazohet në një lloj të Apache Beam, ndërsa në Apache Beam përfshihet një strukturë e dokumentuar mirë, Apache Spark, që lejon të flitet për shpejtësi të ngjashme në zgjidhje. Ndërsa Apache Spark punon shkëlqyeshëm në sistemin e skedarëve HDFS, çka lejon ta zhvillosh atë në serverat Hadoop.
ShtojmĂ« kĂ«tu sasinĂ« e dokumentacionit dhe zgjidhjeve tĂ« gatshme pĂ«r Hadoop dhe Spark krahasuar me Google Cloud Dataflow, dhe zgjedhja e mjetit bĂ«het e qartĂ«. MĂ« shumĂ«, inxhinierĂ«t mund tĂ« vendosin vetĂ« se cilin kod â nĂ«n Hadoop ose Spark â duhet tĂ« kryejnĂ«, duke u bazuar nĂ« detyrĂ«n, pĂ«rvojĂ«n dhe kualifikimin.
Re ose server lokal
Tendenca për kalimin në cloud ka sjellë një term interesant si Hadoop-as-a-service. Në këtë skenar, administrimi i serverëve të lidhur është bërë shumë i rëndësishëm. Sepse, fatkeqësisht, megjithëse është i njohur, Hadoop i pastër është një mjet mjaft i komplikuar për t'u konfiguruar, duke pasur parasysh se shumë gjëra duhet të bëhen manualisht. Për shembull, konfigurimi i veçantë i serverëve, monitorimi i treguesve të tyre, dhe përshtatja me kujdes e shumë parametrave. Në përgjithësi, është punë për entuziastë dhe ka një shans të madh që ndonjëherë të gabosh ose të humbasësh diçka.
Prandaj, janë bërë shumë të njohura distribucione të ndryshme, të cilat fillimisht vijnë me mjete të përshtatshme për shpërndarje dhe administrim. Një nga distribucionet më të njohura që mbështet Spark dhe e thjeshton gjërat është Cloudera. Ai ka versione si të paguara, ashtu edhe falas - dhe versioni falas ofron gjithë funksionalitetin kryesor, pa kufizim në numrin e nodave.
Gjatë konfigurimit, Cloudera Manager do të lidhë përmes SSH me serverët tuaj. Një pikë interesante: gjatë instalimit, është më mirë të specifikohet që ky proces të zhvillohet me atë që quhet paketë: paketa speciale, në secilën prej të cilave përfshihen të gjithë komponentët e nevojshëm, të konfiguruar për të punuar përkrah njëri-tjetrit. Në thelb, kjo është një version i përmirësuar i menaxherit të paketave.
Pas instalimit, ne marrim një konsol menaxhimi për klasterin, ku mund të shihni telemetrinë për klasteret, shërbimet e instaluara, plus mund të shtoni/hiqni burime dhe të redaktoni konfigurimin e klasterit.
Si rezultat, para jush shfaqet një model i raketës që do t'ju çojë në të ardhmen e ndritur të Big Data. Por para se të themi "lemë", le të hedhim një vështrim nën kapak.
Kërkesat për harduer
Në faqen e saj, Cloudera përmend konfigurime të ndryshme të mundshme. Parimet e përgjithshme mbi të cilat ato ndërtohen janë paraqitur në ilustrim:
Një tablo optimiste mund të prishë MapReduce. Nëse e shqyrtojmë sërish skemën nga seksioni i mëparshëm, bëhet e qartë se për pothuajse çdo rast, detyra MapReduce mund të hasë një "grykë" kur lexon të dhëna nga disku ose nga rrjeti. Kjo gjithashtu është përmendur në blogun e Cloudera. Si rezultat, për çdo llogaritje të shpejtë, përfshirë edhe përmes Spark, i cili përdoret shpesh për llogaritje në kohë reale, është shumë e rëndësishme shpejtësia e hyrjes/daljes. Prandaj, kur përdoren Hadoop, është shumë e rëndësishme që klasteri të përfshijë makina të balancuara dhe të shpejta, gjë që, ndër të tjera, nuk është gjithmonë e garantuar në infrastrukturën cloud.
Balancimi në shpërndarjen e ngarkesave arrihet duke përdorur virtualizimin Openstack në serverë me CPU të fuqishme me shumë bërthamë. Nody të dhëna kanë burimet e tyre procesor dhe disqe të caktuara. Në zgjidhjen tonë Atos Codex Data Lake Engine arrihet një virtualizim i gjerë, nga i cili përfitojmë si në performancë (minimizohet ndikimi i infrastrukturës rrjetë) ashtu edhe në TCO (eleminohet nevoja për serverë fizikë të tepërt).
Nëse përdoren serverët BullSequana S200, ne marrim një ngarkesë shumë të balancuar, të liruar nga disa ngushtica. Konfigurimi minimal përfshin 3 serverë BullSequana S200, secili me dy JBOD, plus munden të lidhen opsionalisht S200 shtesë me katër nodë të dhënash secili. Ky është një shembull i ngarkesës në testin TeraGen:
Testet me sasi të ndryshme të të dhënave dhe vlera replikimi tregojnë rezultate të njëjta në lidhje me shpërndarjen e ngarkesës midis nodave të klasterit. Më poshtë është grafiku i shpërndarjes së qasjes në disk për testet e performancës.
Llogaritjet janë kryer në bazën e konfigurimit minimal prej 3 serverësh BullSequana S200. Ajo përfshin 9 nodë të dhënash dhe 3 nodë kryesore, si dhe makina virtuale të rezervuara në rast se dëshirohet implementimi i mbrojtjes përmes Virtualizimit OpenStack. Rezultati i testit TeraSort: madhësia e bllokut 512 MB me faktor replikimi tre me enkriptim është 23.1 minuta.
Si mund të zgjerohet sistemi? Për Data Lake Engine janë të disponueshme lloje të ndryshme zgjerimesh:
- Nodët e transferimit të të dhënave: për çdo 40 TB hapësirë të dobishme
- Nodë analitike me mundësi për instalimin e grafikeve të procesorëve
- Mundësi të tjera në varësi të nevojave të biznesit (për shembull, nëse nevojitet Kafka dhe gjëra të tilla)
Kompleksi Atos Codex Data Lake Engine pĂ«rfshin si serverĂ«t ashtu edhe softuerin e instaluar paraprakisht, duke pĂ«rfshirĂ« paketĂ«n Cloudera me licencĂ«; Hadoop vetĂ«, OpenStack me mahnitĂ« virtuale tĂ« bazuara nĂ« kernelin RedHat Enterprise Linux, sistemet e replikimit tĂ« tĂ« dhĂ«nave dhe backup-it (pĂ«rfshirĂ« ndihmĂ«sin e rezervimit dhe Cloudera BDR â Backup dhe Rikuperim nga FatkeqĂ«sitĂ«). Atos Codex Data Lake Engine u bĂ« zgjidhja e parĂ« qĂ« pĂ«rdor virtualizimin dhe u certifikua. .
Nëse jeni të interesuar për detaje, do të jemi të lumtur të përgjigjemi në pyetjet tuaja në komentet.
Burimi: habr.com
