Marknaden för distribuerad datoranvändning och big data, enligt , växer med 18-19 % per år. Detta innebär att frågan om val av programvara för dessa ändamål förblir relevant. I det här inlägget börjar vi med varför distribuerad datoranvändning behövs, går in mer i detalj på val av mjukvara, pratar om att använda Hadoop med Cloudera och slutligen pratar vi om att välja hårdvara och hur det påverkar prestanda på olika sätt.
Varför behövs distribuerad datoranvändning i vanliga företag? Allt här är enkelt och komplext på samma gång. Enkelt – eftersom vi i de flesta fall utför relativt enkla beräkningar per informationsenhet. Det är svårt eftersom det finns mycket sådan information. Så många. Som en konsekvens är det nödvändigt . Användningsfallen är alltså ganska universella: beräkningar kan användas varhelst det är nödvändigt att ta hänsyn till ett stort antal mätvärden på en ännu större mängd data.
Ett av de senaste exemplen: pizzeriakedjan Dodo Pizza baserat på en analys av kundorderdatabasen, att när man väljer en pizza med en slumpmässig topping, använder användarna vanligtvis endast sex grundläggande uppsättningar ingredienser plus ett par slumpmässiga. I enlighet med detta anpassade pizzerian sina inköp. Dessutom kunde hon bättre rekommendera ytterligare produkter som erbjuds användarna under beställningsfasen, vilket ökade vinsten.
Ett annat exempel: produktvaror gjorde att H&M-butiken kunde minska sortimentet i enskilda butiker med 40 %, samtidigt som försäljningsnivåerna bibehölls. Detta uppnåddes genom att utesluta dåligt sålda varor och säsongsvariationer togs med i beräkningarna.
Verktygsval
Branschstandarden för denna typ av datorer är Hadoop. Varför? Eftersom Hadoop är ett utmärkt, väldokumenterat ramverk (samma Habr tillhandahåller många detaljerade artiklar om detta ämne), som åtföljs av en hel uppsättning verktyg och bibliotek. Du kan mata in enorma uppsättningar av både strukturerad och ostrukturerad data, och systemet självt kommer att fördela det mellan datorkraften. Dessutom kan samma kapacitet ökas eller inaktiveras när som helst - samma horisontella skalbarhet i aktion.
2017, det inflytelserika konsultföretaget Gartner att Hadoop snart kommer att bli föråldrad. Anledningen är ganska banal: analytiker tror att företag kommer att migrera en masse till molnet, eftersom de där kommer att kunna betala när de använder datorkraft. Den andra viktiga faktorn som förmodligen kan "begrava" Hadoop är dess hastighet. Eftersom alternativ som Apache Spark eller Google Cloud DataFlow är snabbare än MapReduce, som ligger bakom Hadoop.
Hadoop vilar på flera pelare, varav de mest anmärkningsvärda är MapReduce-teknologier (ett system för att distribuera data för beräkningar mellan servrar) och HDFS-filsystemet. Den senare är speciellt utformad för att lagra information fördelad mellan klusternoder: varje block av en fast storlek kan placeras på flera noder, och tack vare replikering är systemet motståndskraftigt mot fel i enskilda noder. Istället för en filtabell används en speciell server som heter NameNode.
Illustrationen nedan visar hur MapReduce fungerar. I det första steget delas data upp enligt ett visst kriterium, i det andra steget fördelas det efter beräkningskraft och i det tredje steget sker beräkningen.
MapReduce skapades ursprungligen av Google för dess sökbehov. Sedan gick MapReduce gratiskod, och Apache tog över projektet. Nåväl, Google migrerade gradvis till andra lösningar. En intressant godbit: Google har för närvarande ett projekt som heter Google Cloud Dataflow, placerat som nästa steg efter Hadoop, som en snabb ersättning för det.
En närmare titt visar att Google Cloud Dataflow är baserat på en variant av Apache Beam, medan Apache Beam inkluderar det väldokumenterade Apache Spark-ramverket, som låter oss prata om nästan samma exekveringshastighet för lösningar. Tja, Apache Spark fungerar perfekt på HDFS-filsystemet, vilket gör att det kan distribueras på Hadoop-servrar.
Lägg här till mängden dokumentation och färdiga lösningar för Hadoop och Spark kontra Google Cloud Dataflow, så blir valet av verktyg självklart. Dessutom kan ingenjörer själva bestämma vilken kod - för Hadoop eller Spark - de ska köra, med fokus på uppgiften, erfarenheten och kvalifikationerna.
Moln eller lokal server
Trenden mot en generell övergång till molnet har till och med gett upphov till en så intressant term som Hadoop-as-a-service. I ett sådant scenario blev administrationen av anslutna servrar mycket viktig. För, tyvärr, trots sin popularitet, är ren Hadoop ett ganska svårt verktyg att konfigurera, eftersom mycket måste göras manuellt. Konfigurera till exempel servrar individuellt, övervaka deras prestanda och noggrant konfigurera många parametrar. I allmänhet är arbetet för en amatör och det finns en stor chans att stöka till någonstans eller missa något.
Därför har olika distributionssatser, som initialt är utrustade med praktiska distributions- och administrationsverktyg, blivit mycket populära. En av de mest populära distributionerna som stöder Spark och gör allt enkelt är Cloudera. Den har både betal- och gratisversioner – och i den senare finns all grundläggande funktionalitet tillgänglig, utan att begränsa antalet noder.
Under installationen kommer Cloudera Manager att ansluta via SSH till dina servrar. En intressant punkt: vid installation är det bättre att ange att det ska utföras av den så kallade parseller: specialpaket, som vart och ett innehåller alla nödvändiga komponenter konfigurerade för att fungera med varandra. Detta är i huvudsak en förbättrad version av pakethanteraren.
Efter installationen får vi en klusterhanteringskonsol, där du kan se klustertelemetri, installerade tjänster, plus att du kan lägga till/ta bort resurser och redigera klusterkonfigurationen.
Som ett resultat dyker raketkabinen som tar dig in i BigDatas ljusa framtid upp framför dig. Men innan vi säger "låt oss gå", låt oss gå under huven.
Hårdvarukrav
På sin hemsida nämner Cloudera olika möjliga konfigurationer. De allmänna principerna för de är byggda visas i illustrationen:
MapReduce kan sudda ut denna optimistiska bild. Om man tittar igen på diagrammet från föregående avsnitt blir det tydligt att i nästan alla fall kan ett MapReduce-jobb stöta på en flaskhals när man läser data från disk eller från nätverket. Detta noteras också i Cloudera-bloggen. Som ett resultat av detta, för alla snabba beräkningar, inklusive genom Spark, som ofta används för realtidsberäkningar, är I/O-hastigheten mycket viktig. När man använder Hadoop är det därför mycket viktigt att klustret inkluderar balanserade och snabba maskiner, vilket milt uttryckt inte alltid är säkerställt i molninfrastrukturen.
Balans i lastfördelning uppnås genom användning av Openstack-virtualisering på servrar med kraftfulla flerkärniga processorer. Datanoder tilldelas sina egna processorresurser och specifika diskar. I vårt beslut Atos Codex Data Lake Engine Bred virtualisering uppnås, varför vi gynnas både när det gäller prestanda (påverkan av nätverksinfrastrukturen minimeras) och i TCO (extra fysiska servrar elimineras).
När vi använder BullSequana S200-servrar får vi en mycket enhetlig belastning, utan några flaskhalsar. Minimikonfigurationen inkluderar 3 BullSequana S200-servrar, var och en med två JBODs, plus ytterligare S200:er som innehåller fyra datanoder är valfritt anslutna. Här är ett exempel på belastningen i TeraGen-testet:
Tester med olika datavolymer och replikeringsvärden visar samma resultat när det gäller belastningsfördelning mellan klusternoder. Nedan är en graf över fördelningen av diskåtkomst genom prestandatester.
Beräkningar utfördes baserat på en minsta konfiguration av 3 BullSequana S200-servrar. Den innehåller 9 datanoder och 3 masternoder, samt reserverade virtuella maskiner i händelse av distribution av skydd baserat på OpenStack Virtualization. TeraSort-testresultat: blockstorlek 512 MB replikeringsfaktor lika med tre med kryptering är 23,1 minuter.
Hur kan systemet byggas ut? Det finns olika typer av tillägg tillgängliga för Data Lake Engine:
- Datanoder: för varje 40 TB användbart utrymme
- Analytiska noder med möjlighet att installera en GPU
- Andra alternativ beroende på affärsbehov (till exempel om du behöver Kafka och liknande)
Atos Codex Data Lake Engine inkluderar både själva servrarna och förinstallerad programvara, inklusive ett licensierat Cloudera-kit; Hadoop själv, OpenStack med virtuella maskiner baserade på RedHat Enterprise Linux-kärnan, datareplikering och säkerhetskopieringssystem (inklusive användning av en backupnod och Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine blev den första virtualiseringslösningen som certifierades .
Om du är intresserad av detaljer svarar vi gärna på våra frågor i kommentarerna.
Källa: will.com