Paskirstytų kompiuterių ir didelių duomenų rinka, pasak , kasmet auga 18-19%. Tai reiškia, kad programinės įrangos pasirinkimo šiems tikslams klausimas išlieka aktualus. Šiame įraše pradėsime nuo to, kodėl mums reikalingas paskirstytasis kompiuteris, plačiau apsistosime ties programinės įrangos pasirinkimu, kalbėsime apie Hadoop naudojimą su Cloudera ir galiausiai pakalbėsime apie aparatinės įrangos pasirinkimą ir kaip tai veikia našumą. įvairiais būdais.
Kodėl įprastame versle mums reikia paskirstytų kompiuterių? Viskas paprasta ir sudėtinga tuo pačiu metu. Paprasta – nes dažniausiai atliekame gana paprastus skaičiavimus vienam informacijos vienetui. Sunku – nes tokios informacijos daug. Tiek daug. Dėl to žmogus turi . Taigi, naudojimo atvejai yra gana universalūs: skaičiavimai gali būti taikomi visur, kur reikia atsižvelgti į daugybę metrikų dar didesniame duomenų masyve.
Vienas iš naujausių pavyzdžių: Dodo pica Remiantis klientų užsakymų bazės analize, vartotojai, rinkdamiesi picą su savavališkais priedais, paprastai naudoja tik šešis pagrindinius ingredientų rinkinius ir keletą atsitiktinių ingredientų. Atitinkamai picerija pakoregavo pirkimus. Be to, ji galėjo geriau rekomenduoti vartotojams užsakymo etape siūlomus papildomus produktus, o tai padidino pelną.
Dar vienas pavyzdys: prekės leido H&M sumažinti asortimentą atskirose parduotuvėse 40%, išlaikant pardavimų lygį. Tai buvo pasiekta atmetus prastai parduodamas pozicijas, o skaičiuojant buvo atsižvelgta į sezoniškumą.
Įrankio pasirinkimas
Tokio tipo skaičiavimo pramonės standartas yra „Hadoop“. Kodėl? Kadangi „Hadoop“ yra puiki, gerai dokumentuota sistema (tas pats Habras pateikia daug išsamių straipsnių šia tema), kurį lydi daugybė paslaugų ir bibliotekų. Galite pateikti didžiulius struktūrizuotų ir nestruktūruotų duomenų rinkinius kaip įvestį, o pati sistema juos paskirstys tarp skaičiavimo galių. Be to, tuos pačius pajėgumus galima bet kada padidinti arba išjungti – veikia tas pats horizontalus mastelio keitimas.
Įtakinga konsultacijų bendrovė „Gartner“ 2017 m kad Hadoop greitai pasens. Priežastis gana banali: analitikai mano, kad įmonės masiškai migruos į debesį, nes ten galės mokėti pagal skaičiavimo galią. Antras svarbus veiksnys, tariamai galintis „palaidoti“ Hadoop, yra darbo greitis. Kadangi tokios parinktys kaip „Apache Spark“ arba „Google Cloud DataFlow“ yra greitesnės nei „MapReduce“, kuri yra pagrindinė „Hadoop“.
„Hadoop“ remiasi keliais ramsčiais, iš kurių žymiausi yra „MapReduce“ technologijos (sistema, skirta duomenų paskirstymui skaičiavimams tarp serverių) ir HDFS failų sistema. Pastaroji specialiai skirta saugoti tarp klasterio mazgų paskirstytą informaciją: kiekvienas fiksuoto dydžio blokas gali būti dedamas ant kelių mazgų, o replikacijos dėka sistema yra atspari atskirų mazgų gedimams. Vietoj failų lentelės naudojamas specialus serveris, vadinamas NameNode.
Toliau pateiktoje iliustracijoje parodyta, kaip veikia MapReduce. Pirmajame etape duomenys skirstomi pagal tam tikrą požymį, antrajame – paskirstomi pagal skaičiavimo galią, trečiame etape vyksta skaičiavimas.
„MapReduce“ iš pradžių sukūrė „Google“ savo paieškos reikmėms. Tada „MapReduce“ perėjo į nemokamą kodą, o „Apache“ perėmė projektą. Na, „Google“ palaipsniui perėjo prie kitų sprendimų. Įdomus niuansas: šiuo metu „Google“ turi projektą „Google Cloud Dataflow“, kuris yra kitas žingsnis po „Hadoop“, kaip greitą jo pakeitimą.
Atidžiau pažvelgus matyti, kad „Google Cloud Dataflow“ yra pagrįsta „Apache Beam“ variantu, o „Apache Beam“ apima gerai dokumentuotą „Apache Spark“ sistemą, kuri leidžia kalbėti apie beveik tą patį sprendimo vykdymo greitį. Na, „Apache Spark“ puikiai veikia HDFS failų sistemoje, kuri leidžia ją įdiegti „Hadoop“ serveriuose.
Pridėkite čia daug dokumentų ir paruoštų sprendimų, skirtų Hadoop ir Spark prieš Google Cloud Dataflow, ir įrankio pasirinkimas taps akivaizdus. Be to, inžinieriai gali patys nuspręsti, kurį kodą – naudodami „Hadoop“ ar „Spark“ – vykdys, sutelkdami dėmesį į užduotį, patirtį ir kvalifikaciją.
Debesis arba vietinis serveris
Dėl bendro perėjimo prie debesies tendencijos netgi atsirado toks įdomus terminas kaip „Hadoop-as-a-service“. Esant tokiam scenarijui, labai svarbus tapo prijungtų serverių administravimas. Nes, deja, nepaisant populiarumo, gryną „Hadoop“ yra gana sunku konfigūruoti įrankį, nes daug ką reikia padaryti rankomis. Pavyzdžiui, galite individualiai konfigūruoti serverius, stebėti jų veikimą ir patikslinti daugybę parametrų. Apskritai dirbi mėgėjiškai ir yra didelė tikimybė kur nors susisukti ar ką nors praleisti.
Todėl labai išpopuliarėjo įvairūs platinimai, kurie iš pradžių aprūpinti patogiais diegimo ir administravimo įrankiais. Vienas iš populiaresnių paskirstymų, palaikančių „Spark“ ir palengvinančių darbą, yra „Cloudera“. Jis turi ir mokamą, ir nemokamą versiją – o pastarojoje pasiekiamos visos pagrindinės funkcijos, ir neribojant mazgų skaičiaus.
Sąrankos metu „Cloudera Manager“ prisijungs prie jūsų serverių per SSH. Įdomus momentas: montuojant geriau nurodyti, kad tai atliktų vadinamasis siuntinių: specialūs paketai, kurių kiekviename yra visi reikalingi komponentai, sukonfigūruoti veikti vienas su kitu. Tiesą sakant, tai yra tokia patobulinta paketų tvarkyklės versija.
Įdiegę gauname klasterių valdymo pultą, kuriame galite matyti klasterių telemetriją, įdiegtas paslaugas, taip pat galite pridėti / pašalinti išteklius ir redaguoti klasterio konfigūraciją.
Dėl to prieš jus iškyla tos raketos pjovimas, kuris nuves jus į šviesią BigData ateitį. Bet prieš sakydami „einam“, pasukime į priekį po gaubtu.
techninės įrangos reikalavimus
Savo svetainėje „Cloudera“ mini įvairias galimas konfigūracijas. Bendrieji principai, pagal kuriuos jie sukurti, parodyti iliustracijoje:
„MapReduce“ gali sulieti šį optimistinį vaizdą. Dar kartą pažvelgus į ankstesniame skyriuje pateiktą diagramą, tampa aišku, kad beveik visais atvejais MapReduce užduotis gali patekti į kliūtį nuskaitant duomenis iš disko ar tinklo. Tai taip pat pažymima „Cloudera“ tinklaraštyje. Todėl atliekant bet kokius greitus skaičiavimus, įskaitant „Spark“, kuris dažnai naudojamas realaus laiko skaičiavimams, įvesties / išvesties greitis yra labai svarbus. Todėl naudojant Hadoop labai svarbu, kad į klasterį patektų subalansuotos ir greitos mašinos, kurios, švelniai tariant, ne visada yra numatytos debesų infrastruktūroje.
Apkrovos paskirstymo balansas pasiekiamas naudojant Openstack virtualizaciją serveriuose su galingais kelių branduolių procesoriais. Duomenų mazgams yra skiriami savo procesoriaus ištekliai ir tam tikri diskai. Mūsų sprendime „Atos Codex Data Lake“ variklis pasiekiama plati virtualizacija, todėl laimime tiek pagal našumą (minimizuojamas tinklo infrastruktūros poveikis), tiek pagal TCO (pašalinami papildomi fiziniai serveriai).
Naudodami BullSequana S200 serverius gauname labai vienodą apkrovą, kurioje nėra kai kurių kliūčių. Minimalią konfigūraciją sudaro 3 BullSequana S200 serveriai, kurių kiekvienas turi du JBOD, taip pat pasirinktinai prijungiami papildomi S200 su keturiais duomenų mazgais. Štai „TeraGen“ testo apkrovos pavyzdys:
Testai su skirtingais duomenų kiekiais ir replikacijos reikšmėmis rodo tuos pačius rezultatus, kalbant apie apkrovos pasiskirstymą tarp klasterio mazgų. Žemiau pateikiamas prieigos prie disko pasiskirstymo pagal našumo testus grafikas.
Skaičiavimai pagrįsti mažiausiai 3 BullSequana S200 serverių konfigūracija. Jį sudaro 9 duomenų mazgai ir 3 pagrindiniai mazgai, taip pat rezervuotos virtualios mašinos, jei būtų įdiegta apsauga, pagrįsta OpenStack virtualizavimu. TeraSort testo rezultatas: 512 MB bloko dydis trijų replikacijos koeficiento su šifravimu yra 23,1 minutės.
Kaip galima išplėsti sistemą? „Data Lake Engine“ galimi įvairių tipų plėtiniai:
- Duomenų mazgai: už kiekvieną 40 TB naudingos vietos
- Analitiniai mazgai su galimybe įdiegti GPU
- Kiti variantai, priklausantys nuo verslo poreikių (pavyzdžiui, jei reikia Kafka ir pan.)
„Atos Codex Data Lake Engine“ komplekse yra ir patys serveriai, ir iš anksto įdiegta programinė įranga, įskaitant „Cloudera“ rinkinį su licencija; Pats „Hadoop“, „OpenStack“ su virtualiomis mašinomis, pagrįstomis „RedHat Enterprise Linux“ branduoliu, duomenų replikavimo ir atsarginių kopijų kūrimo sistemomis (įskaitant atsarginio mazgo ir „Cloudera BDR“ – atsarginį kopijavimą ir atkūrimą iš nelaimių) naudojimą. „Atos Codex Data Lake Engine“ yra pirmasis sertifikuotas virtualizacijos sprendimas .
Jei jus domina detalės, mielai atsakysime į klausimus komentaruose.
Šaltinis: www.habr.com