La merkato por distribuita komputado kaj grandaj datumoj, laŭ , kreskas je 18-19% jare. Ĉi tio signifas, ke la demando pri elekto de programaro por ĉi tiuj celoj restas grava. En ĉi tiu afiŝo, ni komencos kun kial ni bezonas distribuitan komputadon, ni pli detale detale pri la elekto de programaro, ni parolos pri uzado de Hadoop kun Cloudera, kaj fine ni parolos pri la elekto de aparataro kaj kiel ĝi influas la rendimenton. en malsamaj manieroj.
Kial ni bezonas distribuitan komputadon en ordinara komerco? Ĉio estas simpla kaj komplika samtempe. Simpla - ĉar en la plej multaj kazoj ni faras relative simplajn kalkulojn po unuo de informo. Malfacile - ĉar ekzistas multe da tiaj informoj. Tiom da. Sekve, ĝi devas . Tiel, la uzkazoj estas sufiĉe universalaj: kalkuloj povas esti aplikitaj kie ajn ĝi estas postulata por enkalkuli grandan nombron da metrikoj sur eĉ pli granda datumtabelo.
Unu lastatempa ekzemplo: Dodo Pizza surbaze de analizo de la klienta mendobazo, ke elektante picon kun arbitraj kompletaĵoj, uzantoj kutime funkcias kun nur ses bazaj aroj da ingrediencoj plus kelkaj hazardaj. Sekve, la picejo alĝustigis aĉetojn. Krome, ĝi povis pli bone rekomendi pliajn produktojn proponitajn en la menda stadio al uzantoj, kio pliigis profitojn.
Alia ekzemplo: varo permesis al H&M redukti la sortimenton en individuaj butikoj je 40%, konservante la nivelon de vendo. Ĉi tio estis atingita ekskludante malbone vendantajn poziciojn, kaj laŭsezoneco estis konsiderata en la kalkuloj.
Elekto de iloj
La industria normo por ĉi tiu speco de komputado estas Hadoop. Kial? Ĉar Hadoop estas bonega, bone dokumentita kadro (la sama Habr eldonas multajn detalajn artikolojn pri ĉi tiu temo), kiu estas akompanata de tuta aro da utilecoj kaj bibliotekoj. Vi povas sendi grandegajn arojn de ambaŭ strukturitaj kaj nestrukturitaj datumoj kiel enigaĵon, kaj la sistemo mem disdonos ilin inter komputika potenco. Plie, ĉi tiuj samaj kapacitoj povas esti pliigitaj aŭ malebligitaj iam ajn - tiu sama horizontala skaleblo en ago.
En 2017, la influa konsilanta kompanio Gartner ke Hadoop baldaŭ malnoviĝos. La kialo estas sufiĉe banala: analizistoj kredas, ke kompanioj amase migras al la nubo, ĉar tie ili povos pagi surbaze de la uzo de komputika potenco. La dua grava faktoro supozeble kapabla "entombigi" Hadoop estas la rapideco de laboro. Ĉar opcioj kiel Apache Spark aŭ Google Cloud DataFlow estas pli rapidaj ol la MapReduce subesta Hadoop.
Hadoop ripozas sur pluraj kolonoj, la plej rimarkindaj el kiuj estas MapReduce-teknologioj (sistemo por distribuado de datumoj por kalkuloj inter serviloj) kaj la dosiersistemo HDFS. Ĉi-lasta estas specife desegnita por stoki informojn distribuitajn inter grapolnodoj: ĉiu bloko de fiksa grandeco povas esti metita sur plurajn nodojn, kaj danke al reproduktado, la sistemo estas imuna al misfunkciadoj de individuaj nodoj. Anstataŭ dosiertabelo, speciala servilo nomata NameNode estas uzata.
La suba ilustraĵo montras kiel MapReduce funkcias. En la unua etapo, la datumoj estas dividitaj laŭ certa atributo, en la dua etapo ĝi estas distribuita per komputa potenco, en la tria etapo la kalkulo okazas.
MapReduce estis origine kreita de Google por la bezonoj de sia serĉo. Tiam MapReduce eniris liberan kodon, kaj Apache transprenis la projekton. Nu, Google iom post iom migris al aliaj solvoj. Interesa nuanco: nuntempe, Google havas projekton nomitan Google Cloud Dataflow, poziciigita kiel la sekva paŝo post Hadoop, kiel ĝia rapida anstataŭaĵo.
Pli proksima rigardo montras, ke Google Cloud Dataflow baziĝas sur variaĵo de Apache Beam, dum Apache Beam inkluzivas la bone dokumentitan Apache Spark-kadron, kiu ebligas al ni paroli pri preskaŭ la sama rapideco de solvo-ekzekuto. Nu, Apache Spark funkcias bone en la dosiersistemo HDFS, kiu permesas vin disfaldi ĝin sur Hadoop-serviloj.
Aldonu ĉi tie la volumon de dokumentado kaj pretaj solvoj por Hadoop kaj Spark kontraŭ Google Cloud Dataflow, kaj la elekto de ilo evidentiĝas. Krome, inĝenieroj povas decidi mem, kiun kodon - sub Hadoop aŭ Spark - ili plenumos, koncentriĝante al la tasko, sperto kaj kvalifikoj.
Nuba aŭ loka servilo
La tendenco al la ĝenerala transiro al la nubo eĉ kaŭzis tian interesan terminon kiel Hadoop-as-a-service. En tia scenaro, la administrado de konektitaj serviloj fariĝis tre grava. Ĉar, ve, malgraŭ ĝia populareco, pura Hadoop estas sufiĉe malfacila ilo por agordi, ĉar vi devas fari multon mane. Ekzemple, vi povas agordi servilojn individue, kontroli ilian agadon kaj agordi multajn parametrojn. Ĝenerale, laboru por amatoro kaj estas granda ŝanco ie fuŝi aŭ maltrafi ion.
Sekve, diversaj distribuoj fariĝis tre popularaj, kiuj komence estas ekipitaj per oportunaj deplojoj kaj administraj iloj. Unu el la plej popularaj distribuoj, kiuj subtenas Spark kaj faciligas aferojn, estas Cloudera. Ĝi havas kaj pagitajn kaj senpagajn versiojn - kaj en ĉi-lasta, ĉiuj ĉefaj funkcioj estas disponeblaj, kaj sen limigi la nombron da nodoj.
Dum aranĝo, Cloudera Manager konektos per SSH al viaj serviloj. Interesa punkto: kiam oni instalas, estas pli bone specifi, ke ĝi estu efektivigita de la tn pakaĵoj: specialaj pakaĵoj, ĉiu el kiuj enhavas ĉiujn necesajn komponantojn agorditajn por labori unu kun la alia. Fakte, ĉi tio estas tia plibonigita versio de la pakadministranto.
Post instalado, ni ricevas konzolon pri administrado de grapoloj, kie vi povas vidi telemetrion por aretoj, instalitaj servoj, krome vi povas aldoni / forigi rimedojn kaj redakti la agordon de la grapo.
Kiel rezulto, la tranĉo de tiu raketo aperas antaŭ vi, kiu kondukos vin al la brila estonteco de BigData. Sed antaŭ ol ni diras "ni iru", ni rapide antaŭen sub la kapuĉo.
aparataj postuloj
En ilia retejo, Cloudera mencias malsamajn eblajn agordojn. La ĝeneralaj principoj laŭ kiuj ili estas konstruitaj estas montritaj en la ilustraĵo:
MapReduce povas malklarigi ĉi tiun optimisman bildon. Rigardante denove la diagramon en la antaŭa sekcio, evidentiĝas, ke en preskaŭ ĉiuj kazoj, MapReduce-laboro povas trafi botelon dum legado de datumoj de disko aŭ reto. Ĉi tio ankaŭ estas notita en la Cloudera blogo. Kiel rezulto, por iuj rapidaj kalkuloj, inkluzive de Spark, kiu estas ofte uzata por realtempaj kalkuloj, I/O-rapido estas tre grava. Sekve, kiam vi uzas Hadoop, estas tre grave, ke ekvilibraj kaj rapidaj maŝinoj eniru la areton, kiu, por iomete diri, ne ĉiam estas provizita en la nuba infrastrukturo.
Ekvilibro en ŝarĝa distribuo estas atingita per la uzo de Openstack-virtualigo sur serviloj kun potencaj multkernaj CPUoj. Datennodoj estas asignitaj siaj propraj procesorresursoj kaj certaj diskoj. En nia decido Atos Codex Data Lake Engine larĝa virtualigo estas atingita, tial ni gajnas kaj laŭ rendimento (la efiko de la reto-infrastrukturo estas minimumigita) kaj TCO (ekstra fizikaj serviloj estas forigitaj).
En la kazo de uzado de serviloj BullSequana S200, ni ricevas tre unuforman ŝarĝon, sen iuj el la boteloj. La minimuma agordo inkluzivas 3 BullSequana S200-servilojn, ĉiu kun du JBOD-oj, kaj pliaj S200-oj enhavantaj kvar datennodojn estas laŭvole konektitaj. Jen ekzemplo de ŝarĝo en TeraGen-testo:
Testoj kun malsamaj datumvolumoj kaj reproduktaj valoroj montras la samajn rezultojn laŭ ŝarĝa distribuo tra grapolnodoj. Malsupre estas grafikaĵo de la distribuado de disko-aliro per agado-testoj.
Kalkuloj estas bazitaj sur minimuma agordo de 3 BullSequana S200-serviloj. Ĝi inkludas 9 datennodojn kaj 3 majstrajn nodojn, same kiel rezervitajn virtualajn maŝinojn en kazo de deplojo de protekto bazita sur OpenStack Virtualization. TeraSort-testrezulto: 512 MB blokgrandeco de reproduktadfaktoro de tri kun ĉifrado estas 23,1 minutoj.
Kiel la sistemo povas esti vastigita? Diversaj specoj de etendaĵoj haveblas por la Data Lake Engine:
- Datumaj nodoj: por ĉiu 40 TB de uzebla spaco
- Analizaj nodoj kun la kapablo instali GPU
- Aliaj ebloj depende de komercaj bezonoj (ekzemple, se vi bezonas Kafka kaj similaj)
La komplekso de Atos Codex Data Lake Engine inkluzivas kaj la servilojn mem kaj antaŭinstalitan programaron, inkluzive de la ilaro Cloudera kun permesilo; Hadoop mem, OpenStack kun virtualaj maŝinoj bazitaj sur la RedHat Enterprise Linux-kerno, reproduktado de datumoj kaj rezervaj sistemoj (inkluzive de uzado de rezerva nodo kaj Cloudera BDR - Rezerva kaj Disaster Recovery). Atos Codex Data Lake Engine estas la unua virtualiga solvo estanta atestita .
Se vi interesiĝas pri la detaloj, ni volonte respondos niajn demandojn en la komentoj.
fonto: www.habr.com