In tegenstelling tot elk I/O-subsysteem, wordt Hadoop ook geleverd met een reeks primitieven. Deze primitieve overwegingen, hoewel generiek van aard, passen natuurlijk ook bij het Hadoop IO-systeem met een speciale connotatie. Hadoop werkt met datasets van meerdere terabytes; een speciale overweging van deze primitieven zal een idee geven hoe Hadoop omgaat met gegevensinvoer en -uitvoer. Dit artikel gaat snel over deze primitieven heen om een perspectief te geven op het Hadoop input-outputsysteem.
Gegevensintegriteit
Gegevensintegriteit betekent dat gegevens nauwkeurig en consistent moeten blijven tijdens alle opslag-, verwerkings- en ophaalactiviteiten. Om ervoor te zorgen dat er geen gegevens verloren gaan of beschadigd raken tijdens persistentie en verwerking, handhaaft Hadoop strikte beperkingen op de gegevensintegriteit. Elke lees-/schrijfbewerking vindt plaats in schijven, meer nog via het netwerk is gevoelig voor fouten. En de hoeveelheid gegevens die Hadoop verwerkt, verergert de situatie alleen maar. De gebruikelijke manier om corrupte gegevens te detecteren is door middel van controlesommen. Een controlesom wordt berekend wanneer gegevens voor het eerst het systeem binnenkomen en tijdens het ophaalproces over het kanaal worden verzonden. Het ophalende einde berekent de controlesom opnieuw en komt overeen met de ontvangen. Als het exact overeenkomt, worden de gegevens als foutvrij beschouwd, anders bevat het een fout. Maar het probleem is:wat als de verzonden controlesom zelf corrupt is? Dit is hoogst onwaarschijnlijk omdat het om kleine gegevens gaat, maar het is geen onmiskenbare mogelijkheid. Het gebruik van de juiste hardware zoals ECC-geheugen kan worden gebruikt om de situatie te verlichten.
Dit is louter detectie. Om de fout te corrigeren, wordt daarom een andere techniek gebruikt, CRC (Cyclic Redundancy Check) genaamd.
Hadoop gaat verder en maakt een aparte controlesom voor elke 512 (standaard) bytes aan gegevens. Omdat CRC-32 slechts 4 bytes is, is de opslagoverhead geen probleem. Alle gegevens die het systeem binnenkomen, worden geverifieerd door de datanodes voordat ze worden doorgestuurd voor opslag of verdere verwerking. Gegevens die naar de datanode-pijplijn worden verzonden, worden geverifieerd door middel van checksums en elke gevonden corruptie wordt onmiddellijk aan de client gemeld met ChecksumException . De client die van de datanode wordt gelezen, doorloopt ook dezelfde oefening. De datanodes houden een logboek bij van checksum-verificatie om het geverifieerde blok bij te houden. Het logboek wordt bijgewerkt door de datanode bij ontvangst van een successignaal voor blokverificatie van de client. Dit soort statistieken helpt om de slechte schijven op afstand te houden.
Afgezien hiervan wordt een periodieke verificatie op de blokwinkel uitgevoerd met behulp van DataBlockScanner loopt samen met de datanode-thread op de achtergrond. Dit beschermt gegevens tegen corruptie in de fysieke opslagmedia.
Hadoop onderhoudt een kopie of replica's van gegevens. Dit wordt specifiek gebruikt om gegevens te herstellen van massale corruptie. Zodra de client een fout ontdekt tijdens het lezen van een blok, rapporteert het onmiddellijk aan de datanode over het slechte blok van de namenode voordat ChecksumException wordt gegooid . De namenode markeert het vervolgens als een slecht blok en plant elke verdere verwijzing naar het blok naar zijn replica's. Op deze manier wordt de replica onderhouden met andere replica's en wordt het gemarkeerde slechte blok uit het systeem verwijderd.
Voor elk bestand gemaakt in het Hadoop LocalFileSystem , een verborgen bestand met dezelfde naam in dezelfde map met de extensie .
Compressie
Rekening houdend met de hoeveelheid gegevens waarmee Hadoop te maken heeft, is compressie geen luxe maar een vereiste. Er zijn veel voor de hand liggende voordelen van bestandscompressie die terecht door Hadoop wordt gebruikt. Het bespaart opslagvereisten en is een onmisbare mogelijkheid om gegevensoverdracht via het netwerk en schijven te versnellen. Er zijn veel tools, technieken en algoritmen die vaak worden gebruikt door Hadoop. Velen van hen zijn behoorlijk populair en zijn door de eeuwen heen gebruikt bij bestandscompressie. Bijvoorbeeld gzip, bzip2, LZO, zip, enzovoort worden vaak gebruikt.
Serialisatie
Het proces dat gestructureerde objecten omzet in een stroom van bytes wordt serialisatie genoemd . Dit is met name vereist voor gegevensoverdracht via het netwerk of het bewaren van onbewerkte gegevens op schijven. Deserialisatie is gewoon het omgekeerde proces, waarbij een stroom van bytes wordt omgezet in een gestructureerd object. Dit is met name vereist voor objectimplementatie van de onbewerkte bytes. Daarom is het niet verwonderlijk dat gedistribueerde computing dit op een aantal verschillende gebieden gebruikt:communicatie tussen processen en gegevenspersistentie.
Hadoop gebruikt RPC (Remote Procedure Call) om interprocescommunicatie tussen knooppunten tot stand te brengen. Daarom gebruikt het RPC-protocol het proces van serialisatie en deserialisatie om een bericht naar de stroom van bytes en vice versa weer te geven en het over het netwerk te verzenden. Het proces moet echter compact genoeg zijn om de netwerkbandbreedte optimaal te gebruiken, en ook snel, interoperabel en flexibel om protocolupdates in de loop van de tijd mogelijk te maken.
Hadoop heeft zijn eigen compacte en snelle serialisatie-indeling, Writables , die MapReduce-programma's gebruiken om sleutels en waardetypes te genereren.
Gegevensstructuur van bestanden
Er zijn een aantal containers op hoog niveau die de gespecialiseerde gegevensstructuur in Hadoop uitwerken om speciale soorten gegevens te bevatten. Om bijvoorbeeld een binair logboek bij te houden, gebruikt de SequenceFile container biedt de gegevensstructuur om binaire sleutel-waardeparen te behouden. We kunnen dan de sleutel gebruiken, zoals een tijdstempel vertegenwoordigd door LongWritable en waarde door Beschrijfbaar , wat verwijst naar gelogde hoeveelheid.
Er is nog een container, een gesorteerde afleiding van SequenceFile , genaamd MapFile . Het biedt een index voor gemakkelijke opzoekingen per sleutel.
Deze twee containers zijn interoperabel en kunnen van en naar elkaar worden omgebouwd.
Conclusie
Dit is slechts een kort overzicht van het input/output-systeem van Hadoop. We zullen in volgende artikelen ingaan op veel ingewikkelde details. Het is niet erg moeilijk om het Hadoop input/output-systeem te begrijpen als men een basiskennis heeft van I/O-systemen in het algemeen. Hadoop heeft er gewoon wat extra sap aan toegevoegd om gelijke tred te houden met de gedistribueerde aard die op enorme schaal aan gegevens werkt. Dat is alles.
Referentie
Wit, Tom. Hadoop, de definitieve gids, 2009 . O'Reilly-publicaties.