Tregu për informatikë të shpërndarë dhe të dhëna të mëdha, sipas , po rritet me 18-19% në vit. Kjo do të thotë se çështja e zgjedhjes së softuerit për këto qëllime mbetet e rëndësishme. Në këtë postim, do të fillojmë me arsyen pse kemi nevojë për llogaritjen e shpërndarë, do të ndalemi më në detaje në zgjedhjen e softuerit, do të flasim për përdorimin e Hadoop me Cloudera dhe në fund do të flasim për zgjedhjen e harduerit dhe si ndikon në performancën në mënyra të ndryshme.
Pse na duhet llogaritja e shpërndarë në biznesin e zakonshëm? Gjithçka është e thjeshtë dhe e ndërlikuar në të njëjtën kohë. E thjeshtë - sepse në shumicën e rasteve ne kryejmë llogaritje relativisht të thjeshta për njësi informacioni. Vështirë - sepse ka shumë informacione të tilla. Shume. Si pasojë, duhet . Kështu, rastet e përdorimit janë mjaft universale: llogaritjet mund të aplikohen kudo që kërkohet për të marrë parasysh një numër të madh metrikash në një grup edhe më të madh të dhënash.
Një shembull i fundit: Dodo Pizza bazuar në një analizë të bazës së porosive të klientëve, që kur zgjedhin një picë me mbushje arbitrare, përdoruesit zakonisht veprojnë me vetëm gjashtë grupe bazë përbërësish plus disa të rastësishëm. Prandaj, piceri përshtati blerjet. Përveç kësaj, ajo ishte në gjendje të rekomandonte më mirë produkte shtesë të ofruara në fazën e porosisë për përdoruesit, gjë që rriti fitimet.
Edhe një shembull: mallrat i lejuan H&M të reduktonte asortimentin në dyqane individuale me 40%, duke ruajtur nivelin e shitjeve. Kjo u arrit duke përjashtuar pozicionet e dobëta të shitjes dhe sezonaliteti është marrë parasysh në llogaritje.
Zgjedhja e mjeteve
Standardi i industrisë për këtë lloj informatikë është Hadoop. Pse? Sepse Hadoop është një kornizë e shkëlqyer, e mirë-dokumentuar (i njëjti Habr jep shumë artikuj të detajuar mbi këtë temë), i cili shoqërohet nga një grup i tërë shërbimesh dhe bibliotekash. Ju mund të paraqisni grupe të mëdha të të dhënave të strukturuara dhe të pastrukturuara si hyrje, dhe vetë sistemi do t'i shpërndajë ato midis fuqisë llogaritëse. Për më tepër, të njëjtat kapacitete mund të rriten ose çaktivizohen në çdo kohë - e njëjta shkallëzim horizontal në veprim.
Në vitin 2017, kompania konsulente me ndikim Gartner se Hadoop së shpejti do të vjetërohet. Arsyeja është mjaft banale: analistët besojnë se kompanitë do të migrojnë masivisht në cloud, pasi atje do të jenë në gjendje të paguajnë bazuar në përdorimin e fuqisë kompjuterike. Faktori i dytë i rëndësishëm që supozohet se mund të "varrosë" Hadoop është shpejtësia e punës. Për shkak se opsionet si Apache Spark ose Google Cloud DataFlow janë më të shpejta se Hadoop-i themelor i MapReduce.
Hadoop mbështetet në disa shtylla, më të dukshmet prej të cilave janë teknologjitë MapReduce (një sistem për shpërndarjen e të dhënave për llogaritjet ndërmjet serverëve) dhe sistemi i skedarëve HDFS. Ky i fundit është krijuar posaçërisht për të ruajtur informacionin e shpërndarë midis nyjeve të grupimit: çdo bllok me një madhësi fikse mund të vendoset në disa nyje, dhe falë përsëritjes, sistemi është rezistent ndaj dështimeve të nyjeve individuale. Në vend të një tabele skedari, përdoret një server i veçantë i quajtur NameNode.
Ilustrimi më poshtë tregon se si funksionon MapReduce. Në fazën e parë, të dhënat ndahen sipas një atributi të caktuar, në fazën e dytë shpërndahen nga fuqia llogaritëse, në fazën e tretë bëhet llogaritja.
MapReduce u krijua fillimisht nga Google për nevojat e kërkimit të tij. Pastaj MapReduce hyri në kod falas dhe Apache mori përsipër projektin. Epo, Google gradualisht migroi në zgjidhje të tjera. Një nuancë interesante: për momentin, Google ka një projekt të quajtur Google Cloud Dataflow, i pozicionuar si hapi tjetër pas Hadoop, si zëvendësim i shpejtë i tij.
Një vështrim më i afërt tregon se Google Cloud Dataflow bazohet në një variant të Apache Beam, ndërsa Apache Beam përfshin kornizën e mirë-dokumentuar Apache Spark, e cila na lejon të flasim për pothuajse të njëjtën shpejtësi të ekzekutimit të zgjidhjeve. Epo, Apache Spark funksionon mirë në sistemin e skedarëve HDFS, i cili ju lejon ta vendosni atë në serverët Hadoop.
Shtoni këtu vëllimin e dokumentacionit dhe zgjidhjet e gatshme për Hadoop dhe Spark kundër Google Cloud Dataflow dhe zgjedhja e mjetit bëhet e qartë. Për më tepër, inxhinierët mund të vendosin vetë se cilin kod - nën Hadoop ose Spark - do të ekzekutojnë, duke u fokusuar në detyrën, përvojën dhe kualifikimet.
Cloud ose server lokal
Tendenca drejt tranzicionit të përgjithshëm në cloud ka shkaktuar madje një term kaq interesant si Hadoop-as-a-service. Në një skenar të tillë, administrimi i serverëve të lidhur është bërë shumë i rëndësishëm. Sepse, mjerisht, megjithë popullaritetin e tij, Hadoop i pastër është një mjet mjaft i vështirë për t'u konfiguruar, pasi duhet të bëni shumë me dorë. Për shembull, ju mund të konfiguroni serverët individualisht, të monitoroni performancën e tyre dhe të rregulloni shumë parametra. Në përgjithësi, punoni për një amator dhe ka një shans të madh për të prishur diku ose për të humbur diçka.
Prandaj, shpërndarjet e ndryshme janë bërë shumë të njohura, të cilat fillimisht janë të pajisura me mjete të përshtatshme vendosjeje dhe administrimi. Një nga shpërndarjet më të njohura që mbështet Spark dhe i lehtëson gjërat është Cloudera. Ka versione të paguara dhe falas - dhe në këtë të fundit, i gjithë funksionaliteti kryesor është i disponueshëm, dhe pa kufizuar numrin e nyjeve.
Gjatë konfigurimit, Cloudera Manager do të lidhet nëpërmjet SSH me serverët tuaj. Një pikë interesante: kur instaloni, është më mirë të specifikoni që ajo të kryhet nga të ashtuquajturat parcelat: paketa speciale, secila prej të cilave përmban të gjithë komponentët e nevojshëm të konfiguruar për të punuar me njëri-tjetrin. Në fakt, ky është një version kaq i përmirësuar i menaxherit të paketave.
Pas instalimit, ne marrim një tastierë për menaxhimin e grupimeve, ku mund të shihni telemetrinë për grupimet, shërbimet e instaluara, plus mund të shtoni / hiqni burime dhe të modifikoni konfigurimin e grupit.
Si rezultat, prerja e asaj rakete shfaqet para jush, e cila do t'ju çojë në të ardhmen e ndritur të BigData. Por para se të themi "le të shkojmë", le të ecim përpara nën kapuç.
kërkesat e harduerit
Në faqen e tyre të internetit, Cloudera përmend konfigurime të ndryshme të mundshme. Parimet e përgjithshme me të cilat ato janë ndërtuar janë paraqitur në ilustrim:
MapReduce mund ta turbullojë këtë pamje optimiste. Duke parë përsëri diagramin në seksionin e mëparshëm, bëhet e qartë se pothuajse në të gjitha rastet, një punë e MapReduce mund të godasë një pengesë kur lexon të dhëna nga disku ose rrjeti. Kjo vërehet edhe në blogun Cloudera. Si rezultat, për çdo llogaritje të shpejtë, përfshirë përmes Spark, i cili shpesh përdoret për llogaritjet në kohë reale, shpejtësia e hyrjes / daljes është shumë e rëndësishme. Prandaj, kur përdorni Hadoop, është shumë e rëndësishme që makinat e balancuara dhe të shpejta të futen në grup, i cili, për ta thënë butë, nuk ofrohet gjithmonë në infrastrukturën cloud.
Bilanci në shpërndarjen e ngarkesës arrihet përmes përdorimit të virtualizimit Openstack në serverë me CPU të fuqishme me shumë bërthama. Nyjeve të të dhënave u ndahen burimet e tyre të procesorit dhe disqeve të caktuara. Në zgjidhjen tonë Motori i liqenit të të dhënave Atos Codex arrihet virtualizimi i gjerë, prandaj fitojmë si për nga performanca (ndikimi i infrastrukturës së rrjetit minimizohet) ashtu edhe për TCO (serverët fizikë shtesë eliminohen).
Në rastin e përdorimit të serverëve BullSequana S200, marrim një ngarkesë shumë uniforme, pa disa nga pengesat. Konfigurimi minimal përfshin 3 serverë BullSequana S200, secili me dy JBOD, plus S200 shtesë që përmbajnë katër nyje të dhënash janë të lidhura opsionalisht. Këtu është një shembull i ngarkesës në një test TeraGen:
Testet me vëllime të ndryshme të të dhënave dhe vlera të përsëritjes tregojnë të njëjtat rezultate për sa i përket shpërndarjes së ngarkesës nëpër nyjet e grupimeve. Më poshtë është një grafik i shpërndarjes së aksesit në disk sipas testeve të performancës.
Llogaritjet bazohen në një konfigurim minimal prej 3 serverësh BullSequana S200. Ai përfshin 9 nyje të dhënash dhe 3 nyje kryesore, si dhe makina virtuale të rezervuara në rast të vendosjes së mbrojtjes bazuar në Virtualizimin OpenStack. Rezultati i testit TeraSort: Madhësia e bllokut 512 MB e një faktori replikimi prej tre me kriptim është 23,1 minuta.
Si mund të zgjerohet sistemi? Lloje të ndryshme shtesash janë të disponueshme për Data Lake Engine:
- Nyjet e të dhënave: për çdo 40 TB hapësirë të përdorshme
- Nyjet analitike me aftësinë për të instaluar një GPU
- Opsione të tjera në varësi të nevojave të biznesit (për shembull, nëse keni nevojë për Kafka dhe të ngjashme)
Kompleksi Atos Codex Data Lake Engine përfshin si vetë serverët ashtu edhe softuerin e parainstaluar, duke përfshirë kompletin Cloudera me licencë; Vetë Hadoop, OpenStack me makina virtuale të bazuara në kernelin RedHat Enterprise Linux, riprodhimin e të dhënave dhe sistemet rezervë (përfshirë përdorimin e një nyje rezervë dhe Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine është zgjidhja e parë e virtualizimit që është certifikuar .
Nëse jeni të interesuar për detajet, ne do të jemi të lumtur t'u përgjigjemi pyetjeve tona në komente.
Burimi: www.habr.com