De markt voor gedistribueerd computergebruik en big data, aldus , groeit met 18-19% per jaar. Dit betekent dat de kwestie van het kiezen van software voor deze doeleinden relevant blijft. In dit bericht beginnen we met waarom gedistribueerd computergebruik nodig is, gaan we dieper in op het kiezen van software, praten we over het gebruik van Hadoop met Cloudera en praten we ten slotte over het kiezen van hardware en hoe dit de prestaties op verschillende manieren beïnvloedt.
Waarom is gedistribueerd computergebruik nodig in het reguliere bedrijfsleven? Alles is hier eenvoudig en complex tegelijk. Eenvoudig - omdat we in de meeste gevallen relatief eenvoudige berekeningen per informatie-eenheid uitvoeren. Het is moeilijk omdat er veel van dergelijke informatie is. Zo veel. Als gevolg hiervan is het noodzakelijk . De gebruiksscenario's zijn dus vrij universeel: berekeningen kunnen overal worden gebruikt waar het nodig is om rekening te houden met een groot aantal metrieken op een nog grotere reeks gegevens.
Een van de recente voorbeelden: de pizzeriaketen Dodo Pizza Gebaseerd op een analyse van de database met klantenbestellingen, blijkt dat gebruikers bij het kiezen van een pizza met een willekeurige topping meestal slechts zes basissets met ingrediënten gebruiken plus een paar willekeurige. In overeenstemming hiermee heeft de pizzeria haar aankopen aangepast. Bovendien kon ze tijdens de bestelfase aanvullende producten die aan gebruikers werden aangeboden, beter aanbevelen, waardoor de winst toenam.
Nog een voorbeeld: Dankzij de productartikelen kon de H&M-winkel het assortiment in individuele winkels met 40% verminderen, terwijl de verkoopniveaus op peil bleven. Dit werd bereikt door slecht verkopende artikelen uit te sluiten, en bij de berekeningen werd rekening gehouden met seizoensinvloeden.
Gereedschap selectie
De industriestandaard voor dit type computergebruik is Hadoop. Waarom? Omdat Hadoop een uitstekend, goed gedocumenteerd raamwerk is (dezelfde Habr biedt veel gedetailleerde artikelen over dit onderwerp), dat vergezeld gaat van een hele reeks hulpprogramma's en bibliotheken. U kunt enorme hoeveelheden zowel gestructureerde als ongestructureerde gegevens invoeren, en het systeem zelf zal deze onder de rekenkracht verdelen. Bovendien kunnen deze zelfde capaciteiten op elk moment worden vergroot of uitgeschakeld - dezelfde horizontale schaalbaarheid in actie.
In 2017 lanceerde het invloedrijke adviesbureau Gartner dat Hadoop binnenkort verouderd zal zijn. De reden is nogal banaal: analisten denken dat bedrijven massaal naar de cloud zullen migreren, omdat ze daar zullen kunnen betalen naarmate ze rekenkracht gebruiken. De tweede belangrijke factor die Hadoop zogenaamd kan ‘begraven’ is de snelheid. Omdat opties als Apache Spark of Google Cloud DataFlow sneller zijn dan MapReduce, dat ten grondslag ligt aan Hadoop.
Hadoop berust op verschillende pijlers, waarvan de meest opvallende de MapReduce-technologieën zijn (een systeem voor het distribueren van gegevens voor berekeningen tussen servers) en het HDFS-bestandssysteem. Deze laatste is speciaal ontworpen voor het opslaan van informatie verdeeld over clusterknooppunten: elk blok van een vaste grootte kan op meerdere knooppunten worden geplaatst en dankzij replicatie is het systeem bestand tegen storingen van individuele knooppunten. In plaats van een bestandstabel wordt een speciale server genaamd NameNode gebruikt.
Onderstaande afbeelding laat zien hoe MapReduce werkt. In de eerste fase worden de gegevens verdeeld volgens een bepaald criterium, in de tweede fase worden ze verdeeld op basis van rekenkracht en in de derde fase vindt de berekening plaats.
MapReduce is oorspronkelijk door Google gemaakt voor zijn zoekbehoeften. Vervolgens ging MapReduce over op gratis code en nam Apache het project over. Welnu, Google migreerde geleidelijk naar andere oplossingen. Een interessant weetje: Google heeft momenteel een project genaamd Google Cloud Dataflow, gepositioneerd als de volgende stap na Hadoop, als een snelle vervanging ervan.
Bij nadere beschouwing blijkt dat Google Cloud Dataflow gebaseerd is op een variant van Apache Beam, terwijl Apache Beam het goed gedocumenteerde Apache Spark-framework bevat, waardoor we kunnen praten over vrijwel dezelfde uitvoeringssnelheid van oplossingen. Welnu, Apache Spark werkt perfect op het HDFS-bestandssysteem, waardoor het op Hadoop-servers kan worden geïmplementeerd.
Voeg hier de hoeveelheid documentatie en kant-en-klare oplossingen voor Hadoop en Spark versus Google Cloud Dataflow toe, en de keuze voor de tool wordt duidelijk. Bovendien kunnen engineers zelf beslissen welke code – voor Hadoop of Spark – ze moeten draaien, waarbij ze zich richten op de taak, ervaring en kwalificaties.
Cloud- of lokale server
De trend naar een algemene transitie naar de cloud heeft zelfs aanleiding gegeven tot zo’n interessante term als Hadoop-as-a-service. In een dergelijk scenario werd het beheer van verbonden servers erg belangrijk. Omdat pure Hadoop, ondanks zijn populariteit, helaas een nogal moeilijke tool is om te configureren, omdat er veel met de hand moet worden gedaan. Configureer bijvoorbeeld servers afzonderlijk, controleer hun prestaties en configureer zorgvuldig veel parameters. Over het algemeen is het werk voor een amateur en is de kans groot dat je ergens iets verprutst of iets mist.
Daarom zijn verschillende distributiekits, die aanvankelijk zijn uitgerust met handige implementatie- en beheertools, erg populair geworden. Een van de meest populaire distributies die Spark ondersteunt en alles gemakkelijk maakt, is Cloudera. Het heeft zowel betaalde als gratis versies - en in de laatste is alle basisfunctionaliteit beschikbaar, zonder het aantal knooppunten te beperken.
Tijdens de installatie maakt Cloudera Manager via SSH verbinding met uw servers. Een interessant punt: bij de installatie is het beter om te specificeren dat dit wordt uitgevoerd door de zogenaamde peterselie: speciale pakketten, die elk alle benodigde componenten bevatten die zijn geconfigureerd om met elkaar te werken. In wezen is dit een verbeterde versie van de pakketbeheerder.
Na de installatie ontvangen we een clusterbeheerconsole, waar u clustertelemetrie en geïnstalleerde services kunt zien, bronnen kunt toevoegen/verwijderen en de clusterconfiguratie kunt bewerken.
Als resultaat verschijnt voor je de cabine van de raket die je meeneemt naar de mooie toekomst van BigData. Maar voordat we zeggen ‘laten we gaan’, gaan we even onder de motorkap kijken.
Hardwarevereisten
Op haar website vermeldt Cloudera verschillende mogelijke configuraties. De algemene principes waarmee ze zijn gebouwd, worden weergegeven in de afbeelding:
MapReduce kan dit optimistische beeld vervagen. Als je nog eens naar het diagram uit de vorige sectie kijkt, wordt het duidelijk dat een MapReduce-taak in bijna alle gevallen een knelpunt kan tegenkomen bij het lezen van gegevens van schijf of van het netwerk. Dit wordt ook opgemerkt in de Cloudera-blog. Als gevolg hiervan is I/O-snelheid voor snelle berekeningen, ook via Spark, dat vaak wordt gebruikt voor realtime berekeningen, erg belangrijk. Daarom is het bij het gebruik van Hadoop erg belangrijk dat het cluster gebalanceerde en snelle machines bevat, wat, op zijn zachtst gezegd, niet altijd gegarandeerd is in de cloudinfrastructuur.
Balans in de verdeling van de belasting wordt bereikt door het gebruik van OpenStack-virtualisatie op servers met krachtige multi-core CPU's. Gegevensknooppunten krijgen hun eigen processorbronnen en specifieke schijven toegewezen. Bij ons besluit Atos Codex Data Lake-engine Er wordt brede virtualisatie bereikt en daarom profiteren we zowel op het gebied van prestaties (de impact van de netwerkinfrastructuur wordt geminimaliseerd) als op het gebied van TCO (extra fysieke servers worden geëlimineerd).
Wanneer we BullSequana S200-servers gebruiken, krijgen we een zeer uniforme belasting, zonder enkele knelpunten. De minimale configuratie omvat 3 BullSequana S200-servers, elk met twee JBOD's, plus extra S200's met vier dataknooppunten die optioneel kunnen worden aangesloten. Hier is een voorbeeld van de belasting in de TeraGen-test:
Tests met verschillende datavolumes en replicatiewaarden laten dezelfde resultaten zien in termen van belastingverdeling tussen clusternodes. Hieronder ziet u een grafiek van de verdeling van schijftoegang volgens prestatietests.
Berekeningen zijn uitgevoerd op basis van een minimale configuratie van 3 BullSequana S200-servers. Het omvat 9 dataknooppunten en 3 masterknooppunten, evenals gereserveerde virtuele machines in het geval van implementatie van bescherming op basis van OpenStack Virtualization. TeraSort-testresultaat: blokgrootte 512 MB replicatiefactor gelijk aan drie met encryptie is 23,1 minuten.
Hoe kan het systeem worden uitgebreid? Er zijn verschillende soorten extensies beschikbaar voor Data Lake Engine:
- Dataknooppunten: voor elke 40 TB bruikbare ruimte
- Analytische knooppunten met de mogelijkheid om een GPU te installeren
- Andere opties afhankelijk van de zakelijke behoeften (bijvoorbeeld als u Kafka en dergelijke nodig heeft)
De Atos Codex Data Lake Engine omvat zowel de servers zelf als vooraf geïnstalleerde software, inclusief een gelicentieerde Cloudera-kit; Hadoop zelf, OpenStack met virtuele machines gebaseerd op de RedHat Enterprise Linux-kernel, datareplicatie en back-upsystemen (inclusief het gebruik van een back-upknooppunt en Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine werd de eerste virtualisatie-oplossing die werd gecertificeerd .
Als u geïnteresseerd bent in details, beantwoorden wij onze vragen graag in de opmerkingen.
Bron: www.habr.com