Markedet for distribuert databehandling og big data, iht , vokser med 18-19 % per år. Dette betyr at spørsmålet om valg av programvare for disse formålene fortsatt er relevant. I dette innlegget starter vi med hvorfor distribuert databehandling er nødvendig, går mer i detalj om valg av programvare, snakker om bruk av Hadoop ved bruk av Cloudera, og til slutt snakker vi om valg av maskinvare og hvordan det påvirker ytelsen på ulike måter.
Hvorfor er distribuert databehandling nødvendig i vanlig virksomhet? Alt her er enkelt og komplekst på samme tid. Enkelt – fordi vi i de fleste tilfeller utfører relativt enkle beregninger per informasjonsenhet. Det er vanskelig fordi det er mye slik informasjon. Så mange. Som en konsekvens er det nødvendig . Derfor er brukstilfellene ganske universelle: beregninger kan brukes der det er nødvendig å ta hensyn til et stort antall beregninger på et enda større utvalg av data.
Et av de siste eksemplene: pizzeriakjeden Dodo Pizza basert på en analyse av kundeordredatabasen, at når de velger en pizza med tilfeldig pålegg, opererer brukere vanligvis med kun seks grunnleggende sett med ingredienser pluss et par tilfeldige. I samsvar med dette justerte pizzeriaen sine innkjøp. I tillegg kunne hun bedre anbefale tilleggsprodukter som ble tilbudt til brukere under bestillingsfasen, noe som økte fortjenesten.
Et eksempel til: produktvarer gjorde at H&M-butikken kunne redusere sortimentet i enkeltbutikker med 40 %, samtidig som salgsnivået ble opprettholdt. Dette ble oppnådd ved å ekskludere dårlig solgte varer, og sesongvariasjoner ble tatt med i beregningene.
Verktøyvalg
Bransjestandarden for denne typen databehandling er Hadoop. Hvorfor? Fordi Hadoop er et utmerket, godt dokumentert rammeverk (den samme Habr gir mange detaljerte artikler om dette emnet), som er ledsaget av et helt sett med verktøy og biblioteker. Du kan legge inn enorme sett med både strukturerte og ustrukturerte data, og systemet selv vil fordele det mellom datakraften. Dessuten kan de samme kapasitetene økes eller deaktiveres når som helst - den samme horisontale skalerbarheten i aksjon.
I 2017, det innflytelsesrike konsulentselskapet Gartner at Hadoop snart vil bli foreldet. Årsaken er ganske banal: analytikere tror at selskaper vil migrere massevis til skyen, siden de der vil kunne betale etter hvert som de bruker datakraft. Den andre viktige faktoren som visstnok kan "begrave" Hadoop er hastigheten. Fordi alternativer som Apache Spark eller Google Cloud DataFlow er raskere enn MapReduce, som ligger til grunn for Hadoop.
Hadoop hviler på flere pilarer, hvorav de mest bemerkelsesverdige er MapReduce-teknologier (et system for distribusjon av data for beregninger mellom servere) og HDFS-filsystemet. Sistnevnte er spesielt designet for å lagre informasjon fordelt mellom klyngenoder: hver blokk med fast størrelse kan plasseres på flere noder, og takket være replikering er systemet motstandsdyktig mot feil i individuelle noder. I stedet for en filtabell, brukes en spesiell server kalt NameNode.
Illustrasjonen nedenfor viser hvordan MapReduce fungerer. På det første trinnet deles dataene etter et bestemt kriterium, på det andre trinnet fordeles det etter datakraft, og på det tredje trinnet finner beregningen sted.
MapReduce ble opprinnelig laget av Google for sine søkebehov. Så gikk MapReduce gratis kode, og Apache tok over prosjektet. Vel, Google migrerte gradvis til andre løsninger. En interessant godbit: Google har for tiden et prosjekt kalt Google Cloud Dataflow, plassert som neste trinn etter Hadoop, som en rask erstatning for det.
En nærmere titt viser at Google Cloud Dataflow er basert på en variant av Apache Beam, mens Apache Beam inkluderer det veldokumenterte Apache Spark-rammeverket, som lar oss snakke om nesten samme utførelseshastighet på løsninger. Vel, Apache Spark fungerer perfekt på HDFS-filsystemet, som lar det distribueres på Hadoop-servere.
Legg her til volumet av dokumentasjon og ferdige løsninger for Hadoop og Spark kontra Google Cloud Dataflow, og valget av verktøy blir åpenbart. I tillegg kan ingeniører selv bestemme hvilken kode - for Hadoop eller Spark - de skal kjøre, med fokus på oppgaven, erfaring og kvalifikasjoner.
Cloud eller lokal server
Trenden mot en generell overgang til skyen har til og med gitt opphav til et så interessant begrep som Hadoop-as-a-service. I et slikt scenario ble administrasjonen av tilkoblede servere svært viktig. Fordi, dessverre, til tross for sin popularitet, er ren Hadoop et ganske vanskelig verktøy å konfigurere, siden mye må gjøres for hånd. Konfigurer for eksempel servere individuelt, overvåk ytelsen og konfigurer mange parametere nøye. Generelt er arbeidet for en amatør, og det er stor sjanse for å rote til et sted eller gå glipp av noe.
Derfor har ulike distribusjonssett, som i utgangspunktet er utstyrt med praktiske distribusjons- og administrasjonsverktøy, blitt veldig populære. En av de mest populære distribusjonene som støtter Spark og gjør alt enkelt er Cloudera. Den har både betalte og gratisversjoner – og i sistnevnte er all grunnleggende funksjonalitet tilgjengelig, uten å begrense antall noder.
Under oppsettet vil Cloudera Manager koble til serverne dine via SSH. Et interessant poeng: når du installerer, er det bedre å spesifisere at det skal utføres av den såkalte parseller: spesielle pakker, som hver inneholder alle nødvendige komponenter konfigurert til å fungere med hverandre. I hovedsak er dette en forbedret versjon av pakkebehandlingen.
Etter installasjonen mottar vi en klyngeadministrasjonskonsoll, der du kan se klyngetelemetri, installerte tjenester, pluss at du kan legge til/fjerne ressurser og redigere klyngekonfigurasjonen.
Som et resultat dukker kabinen til raketten som vil ta deg inn i den lyse fremtiden til BigData opp foran deg. Men før vi sier «la oss gå», la oss gå under panseret.
Krav til maskinvare
På nettsiden sin nevner Cloudera ulike mulige konfigurasjoner. De generelle prinsippene som de er bygget etter, er vist i illustrasjonen:
MapReduce kan gjøre dette optimistiske bildet uskarpt. Hvis du ser igjen på diagrammet fra forrige avsnitt, blir det klart at i nesten alle tilfeller kan en MapReduce-jobb støte på en flaskehals ved lesing av data fra disk eller fra nettverket. Dette er også notert i Cloudera-bloggen. Som et resultat, for alle raske beregninger, inkludert gjennom Spark, som ofte brukes til sanntidsberegninger, er I/O-hastighet veldig viktig. Ved bruk av Hadoop er det derfor svært viktig at klyngen inkluderer balanserte og raske maskiner, som mildt sagt ikke alltid er sikret i skyinfrastrukturen.
Balanse i lastfordeling oppnås gjennom bruk av Openstack-virtualisering på servere med kraftige flerkjerne-CPUer. Datanoder får tildelt sine egne prosessorressurser og spesifikke disker. I vår beslutning Atos Codex Data Lake Engine Bred virtualisering oppnås, og det er grunnen til at vi drar nytte både når det gjelder ytelse (påvirkningen av nettverksinfrastrukturen minimeres) og i TCO (ekstra fysiske servere elimineres).
Ved bruk av BullSequana S200-servere får vi en veldig jevn belastning, uten noen flaskehalser. Minimumskonfigurasjonen inkluderer 3 BullSequana S200-servere, hver med to JBOD-er, pluss ytterligere S200-er som inneholder fire datanoder er valgfritt tilkoblet. Her er et eksempel på belastningen i TeraGen-testen:
Tester med forskjellige datavolumer og replikeringsverdier viser de samme resultatene når det gjelder lastfordeling mellom klyngennoder. Nedenfor er en graf over fordelingen av disktilgang etter ytelsestester.
Beregninger ble utført basert på en minimumskonfigurasjon av 3 BullSequana S200-servere. Den inkluderer 9 datanoder og 3 masternoder, samt reserverte virtuelle maskiner i tilfelle utplassering av beskyttelse basert på OpenStack Virtualization. TeraSort-testresultat: blokkstørrelse 512 MB replikeringsfaktor lik tre med kryptering er 23,1 minutter.
Hvordan kan systemet utvides? Det er forskjellige typer utvidelser tilgjengelig for Data Lake Engine:
- Datanoder: for hver 40 TB med brukbar plass
- Analytiske noder med muligheten til å installere en GPU
- Andre alternativer avhengig av forretningsbehov (for eksempel hvis du trenger Kafka og lignende)
Atos Codex Data Lake Engine inkluderer både selve serverne og forhåndsinstallert programvare, inkludert et lisensiert Cloudera-sett; Hadoop selv, OpenStack med virtuelle maskiner basert på RedHat Enterprise Linux-kjernen, datareplikering og backup-systemer (inkludert bruk av en backup-node og Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine ble den første virtualiseringsløsningen som ble sertifisert .
Hvis du er interessert i detaljer, svarer vi gjerne på spørsmålene våre i kommentarfeltet.
Kilde: www.habr.com