Markedet for distribueret computing og big data, iflg , vokser med 18-19 % om året. Det betyder, at spørgsmålet om valg af software til disse formål fortsat er relevant. I dette indlæg vil vi starte med, hvorfor distribueret databehandling er nødvendig, gå mere i detaljer om valg af software, tale om brug af Hadoop ved hjælp af Cloudera og til sidst tale om valg af hardware, og hvordan det påvirker ydeevnen på forskellige måder.
Hvorfor er der behov for distribueret databehandling i almindelig virksomhed? Alt her er enkelt og komplekst på samme tid. Simpelt – fordi vi i de fleste tilfælde udfører relativt simple beregninger per informationsenhed. Det er svært, fordi der er mange sådanne oplysninger. Så mange. Som en konsekvens er det nødvendigt . Brugstilfældene er således ret universelle: beregninger kan bruges overalt, hvor det er nødvendigt at tage højde for et stort antal målinger på en endnu større række af data.
Et af de seneste eksempler: pizzeriakæden Dodo Pizza baseret på en analyse af kundeordredatabasen, at når man vælger en pizza med tilfældig topping, opererer brugere normalt med kun seks basissæt ingredienser plus et par tilfældige. I overensstemmelse hermed justerede pizzeriaet sine indkøb. Derudover var hun i stand til bedre at anbefale yderligere produkter, der blev tilbudt brugerne i bestillingsfasen, hvilket øgede fortjenesten.
Et andet eksempel: produktvarer gjorde det muligt for H&M-butikken at reducere sortimentet i de enkelte butikker med 40 % og samtidig bevare salgsniveauet. Dette er opnået ved at ekskludere dårligt sælgende varer, og sæsonbetinget var taget i betragtning i beregningerne.
Værktøjsvalg
Branchestandarden for denne type databehandling er Hadoop. Hvorfor? Fordi Hadoop er en fremragende, veldokumenteret ramme (den samme Habr giver mange detaljerede artikler om dette emne), som er ledsaget af et helt sæt hjælpeprogrammer og biblioteker. Du kan indtaste enorme sæt af både strukturerede og ustrukturerede data, og systemet selv vil fordele det blandt computerkraften. Desuden kan de samme kapaciteter øges eller deaktiveres til enhver tid - den samme horisontale skalerbarhed i aktion.
I 2017, den indflydelsesrige konsulentvirksomhed Gartner at Hadoop snart bliver forældet. Årsagen er ret banal: analytikere mener, at virksomheder vil migrere i massevis til skyen, da de dér vil være i stand til at betale, når de bruger computerkraft. Den anden vigtige faktor, der angiveligt kan "begrave" Hadoop, er dens hastighed. Fordi muligheder som Apache Spark eller Google Cloud DataFlow er hurtigere end MapReduce, som ligger til grund for Hadoop.
Hadoop hviler på flere søjler, hvoraf de mest bemærkelsesværdige er MapReduce-teknologier (et system til fordeling af data til beregninger mellem servere) og HDFS-filsystemet. Sidstnævnte er specielt designet til lagring af information fordelt mellem klynge noder: hver blok af en fast størrelse kan placeres på flere noder, og takket være replikering er systemet modstandsdygtigt over for fejl i individuelle noder. I stedet for en filtabel bruges en speciel server kaldet NameNode.
Illustrationen nedenfor viser, hvordan MapReduce virker. På det første trin opdeles dataene efter et bestemt kriterium, på det andet trin fordeles det efter regnekraft, og på det tredje trin finder beregningen sted.
MapReduce blev oprindeligt skabt af Google til dets søgebehov. Så gik MapReduce gratis kode, og Apache overtog projektet. Nå, Google migrerede gradvist til andre løsninger. En interessant godbid: Google har i øjeblikket et projekt kaldet Google Cloud Dataflow, placeret som det næste trin efter Hadoop, som en hurtig erstatning for det.
Et nærmere kig viser, at Google Cloud Dataflow er baseret på en variation af Apache Beam, mens Apache Beam inkluderer det veldokumenterede Apache Spark framework, som giver os mulighed for at tale om næsten samme udførelseshastighed af løsninger. Nå, Apache Spark fungerer perfekt på HDFS-filsystemet, som gør det muligt at implementere det på Hadoop-servere.
Tilføj her mængden af dokumentation og færdige løsninger til Hadoop og Spark kontra Google Cloud Dataflow, og valget af værktøj bliver indlysende. Desuden kan ingeniører selv bestemme, hvilken kode - for Hadoop eller Spark - de skal køre, med fokus på opgaven, erfaring og kvalifikationer.
Cloud eller lokal server
Tendensen mod en generel overgang til skyen har endda givet anledning til et så interessant udtryk som Hadoop-as-a-service. I et sådant scenarie blev administrationen af tilsluttede servere meget vigtig. Fordi, desværre, på trods af sin popularitet, er ren Hadoop et ret svært værktøj at konfigurere, da meget skal gøres manuelt. Konfigurer for eksempel servere individuelt, overvåg deres ydeevne og konfigurer mange parametre omhyggeligt. Generelt er arbejdet for en amatør, og der er en stor chance for at rode et sted eller gå glip af noget.
Derfor er forskellige distributionssæt, som oprindeligt er udstyret med praktiske implementerings- og administrationsværktøjer, blevet meget populære. En af de mest populære distributioner, der understøtter Spark og gør alt nemt, er Cloudera. Den har både betalte og gratis versioner – og i sidstnævnte er al grundlæggende funktionalitet tilgængelig, uden at begrænse antallet af noder.
Under opsætningen vil Cloudera Manager oprette forbindelse via SSH til dine servere. Et interessant punkt: ved installation er det bedre at specificere, at det udføres af den såkaldte parseller: specielle pakker, som hver indeholder alle de nødvendige komponenter, der er konfigureret til at arbejde med hinanden. I bund og grund er dette en forbedret version af pakkehåndteringen.
Efter installationen modtager vi en klyngestyringskonsol, hvor du kan se klyngetelemetri, installerede tjenester, plus at du kan tilføje/fjerne ressourcer og redigere klyngekonfigurationen.
Som et resultat dukker kabinen af raketten, der vil tage dig ind i BigDatas lyse fremtid, op foran dig. Men før vi siger "lad os gå", lad os bevæge os under hætten.
Hardwarekrav
På sin hjemmeside nævner Cloudera forskellige mulige konfigurationer. De generelle principper, som de er bygget efter, er vist i illustrationen:
MapReduce kan sløre dette optimistiske billede. Hvis du igen ser på diagrammet fra det foregående afsnit, bliver det klart, at et MapReduce-job i næsten alle tilfælde kan støde på en flaskehals ved læsning af data fra disk eller fra netværket. Dette er også bemærket i Cloudera-bloggen. Som følge heraf er I/O-hastigheden meget vigtig for hurtige beregninger, herunder gennem Spark, som ofte bruges til realtidsberegninger. Når man bruger Hadoop, er det derfor meget vigtigt, at klyngen indeholder afbalancerede og hurtige maskiner, som mildt sagt ikke altid er sikret i cloud-infrastrukturen.
Balance i belastningsfordeling opnås ved brug af Openstack-virtualisering på servere med kraftfulde multi-core CPU'er. Data noder tildeles deres egne processorressourcer og specifikke diske. I vores beslutning Atos Codex Data Lake Engine Der opnås bred virtualisering, hvorfor vi drager fordel både i forhold til ydeevne (påvirkningen af netværksinfrastrukturen minimeres) og i TCO (ekstra fysiske servere elimineres).
Når vi bruger BullSequana S200-servere, får vi en meget ensartet belastning, blottet for nogle flaskehalse. Minimumskonfigurationen inkluderer 3 BullSequana S200-servere, hver med to JBOD'er, plus yderligere S200'er, der indeholder fire dataknuder, er valgfrit forbundet. Her er et eksempel på belastningen i TeraGen-testen:
Tests med forskellige datavolumener og replikationsværdier viser de samme resultater med hensyn til belastningsfordeling mellem klynge noder. Nedenfor er en graf over fordelingen af diskadgang ved præstationstest.
Beregninger blev udført baseret på en minimumskonfiguration af 3 BullSequana S200-servere. Det inkluderer 9 dataknuder og 3 masterknuder samt reserverede virtuelle maskiner i tilfælde af implementering af beskyttelse baseret på OpenStack Virtualization. TeraSort-testresultat: blokstørrelse 512 MB replikeringsfaktor lig med tre med kryptering er 23,1 minutter.
Hvordan kan systemet udvides? Der er forskellige typer udvidelser tilgængelige for Data Lake Engine:
- Data noder: for hver 40 TB brugbar plads
- Analytiske noder med mulighed for at installere en GPU
- Andre muligheder afhængigt af forretningsbehov (for eksempel hvis du har brug for Kafka og lignende)
Atos Codex Data Lake Engine inkluderer både selve serverne og forudinstalleret software, inklusive et licenseret Cloudera-kit; Hadoop selv, OpenStack med virtuelle maskiner baseret på RedHat Enterprise Linux-kernen, datareplikering og backup-systemer (inklusive brug af en backup-node og Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine blev den første virtualiseringsløsning, der blev certificeret .
Hvis du er interesseret i detaljer, vil vi med glæde besvare vores spørgsmål i kommentarerne.
Kilde: www.habr.com