Team biedt engineer Rahul Bhatia van Clairvoyant over welke bestandsformaten er zijn in big data, wat de meest voorkomende kenmerken zijn van Hadoop-formaten en welk formaat beter te gebruiken is.
Waarom zijn verschillende bestandsformaten nodig?
Een belangrijk prestatieknelpunt voor HDFS-compatibele applicaties zoals MapReduce en Spark is de tijd die nodig is om gegevens te zoeken, lezen en schrijven. Deze problemen worden nog verergerd door de moeilijkheid bij het beheren van grote datasets als we een evoluerend schema hebben in plaats van een vast schema, of als er bepaalde opslagbeperkingen zijn.
Het verwerken van big data verhoogt de belasting van het opslagsubsysteem - Hadoop slaat gegevens redundant op om fouttolerantie te bereiken. Naast schijven worden ook de processor, het netwerk, het invoer-/uitvoersysteem, enzovoort geladen. Naarmate de hoeveelheid gegevens groeit, stijgen ook de kosten voor de verwerking en opslag ervan.
Diverse bestandsformaten in uitgevonden om precies deze problemen op te lossen. Het selecteren van het juiste bestandsformaat kan een aantal belangrijke voordelen opleveren:
- Snellere leestijd.
- Snellere opnametijd.
- Gedeelde bestanden.
- Ondersteuning voor schema-evolutie.
- Uitgebreide compressieondersteuning.
Sommige bestandsformaten zijn bedoeld voor algemeen gebruik, andere voor meer specifiek gebruik, en sommige zijn ontworpen om aan specifieke gegevenskenmerken te voldoen. De keuze is dus eigenlijk best groot.
Avro-bestandsformaat
Voor serialisatie van gegevens Avro wordt veel gebruikt - het op basis van tekenreeksen, dat wil zeggen een opslagformaat voor tekenreeksgegevens in Hadoop. Het slaat het schema op in JSON-indeling, waardoor het door elk programma gemakkelijk kan worden gelezen en geïnterpreteerd. De gegevens zelf zijn in binair formaat, compact en efficiënt.
Het serialisatiesysteem van Avro is taalneutraal. Bestanden kunnen in verschillende talen worden verwerkt, momenteel C, C++, C#, Java, Python en Ruby.
Een belangrijk kenmerk van Avro is de robuuste ondersteuning voor gegevensschema's die in de loop van de tijd veranderen, dat wil zeggen evolueren. Avro begrijpt schemawijzigingen: velden verwijderen, toevoegen of wijzigen.
Avro ondersteunt een verscheidenheid aan datastructuren. U kunt bijvoorbeeld een record maken die een array, een opgesomd type en een subrecord bevat.
Dit formaat is ideaal voor het schrijven naar de landingszone (overgangszone) van een datameer (of data lake - een verzameling instanties voor het rechtstreeks opslaan van verschillende soorten gegevens naast gegevensbronnen).
Dit formaat is dus het meest geschikt voor het schrijven naar de landingszone van een datameer om de volgende redenen:
- Gegevens uit deze zone worden meestal in hun geheel gelezen voor verdere verwerking door downstream-systemen - en een op rijen gebaseerd formaat is in dit geval efficiënter.
- Downstream-systemen kunnen eenvoudig schematabellen uit bestanden ophalen; het is niet nodig om schema's afzonderlijk op te slaan in externe meta-opslag.
- Elke wijziging aan het oorspronkelijke schema kan eenvoudig worden verwerkt (schema-evolutie).
Parquet-bestandsindeling
Parquet is een open source-bestandsindeling voor Hadoop waarin geneste datastructuren in plat kolomformaat.
Vergeleken met de traditionele rijbenadering is Parquet efficiënter op het gebied van opslag en prestaties.
Dit is vooral handig voor query's die specifieke kolommen uit een brede tabel (veel kolommen) lezen. Dankzij het bestandsformaat worden alleen de noodzakelijke kolommen gelezen, waardoor I/O tot een minimum wordt beperkt.
Een kleine uitweiding en uitleg: Laten we, om de Parquet-bestandsindeling in Hadoop beter te begrijpen, eens kijken wat een op kolommen gebaseerd (d.w.z. kolomvormig) formaat is. Dit formaat slaat vergelijkbare waarden voor elke kolom bij elkaar op.
, bevat de record de velden ID, Naam en Afdeling. In dit geval worden alle ID-kolomwaarden samen opgeslagen, evenals de Naam-kolomwaarden, enzovoort. De tabel zal er ongeveer zo uitzien:
ID
Naam
afdeling
1
emp1
d1
2
emp2
d2
3
emp3
d3
In stringformaat worden de gegevens als volgt opgeslagen:
1
emp1
d1
2
emp2
d2
3
emp3
d3
In een kolomvormig bestandsformaat worden dezelfde gegevens als volgt opgeslagen:
1
2
3
emp1
emp2
emp3
d1
d2
d3
De kolomindeling is efficiënter als u meerdere kolommen uit een tabel moet opvragen. Het leest alleen de vereiste kolommen omdat ze aangrenzend zijn. Op deze manier worden I/O-bewerkingen tot een minimum beperkt.
U hebt bijvoorbeeld alleen de kolom NAAM nodig. IN Elke record in de dataset moet worden geladen, per veld worden geparseerd en vervolgens de NAME-gegevens worden geëxtraheerd. Dankzij de kolomindeling kunt u rechtstreeks inzoomen op de kolom Naam, omdat alle waarden voor die kolom bij elkaar worden opgeslagen. Je hoeft niet de hele opname te scannen.
Het kolomformaat verbetert dus de prestaties van de query omdat er minder opzoektijd nodig is om bij de vereiste kolommen te komen, en het aantal I/O-bewerkingen wordt verminderd omdat alleen de gewenste kolommen worden gelezen.
Eén van de unieke kenmerken is dat het in dit formaat kan gegevens opslaan met geneste structuren. Dit betekent dat in een Parquet-bestand zelfs geneste velden afzonderlijk kunnen worden gelezen zonder dat alle velden in de geneste structuur moeten worden gelezen. Parquet gebruikt een versnipper- en assemblage-algoritme om geneste structuren op te slaan.
Om de Parquet-bestandsindeling in Hadoop te begrijpen, moet u de volgende termen kennen:
- Groep snaren (rijgroep): logische horizontale verdeling van gegevens in rijen. Een rijgroep bestaat uit een fragment van elke kolom in de dataset.
- Kolomfragment (kolomstuk): Een fragment van een specifieke kolom. Deze kolomfragmenten bevinden zich in een specifieke groep rijen en zijn gegarandeerd aaneengesloten in het bestand.
- Pagina (pagina): Kolomfragmenten worden verdeeld in na elkaar geschreven pagina's. De pagina's hebben een gemeenschappelijke titel, zodat u tijdens het lezen onnodige titels kunt overslaan.
Hier bevat de titel alleen het magische getal PAR1 (4 bytes), wat het bestand identificeert als een Parquet-bestand.
In de voettekst staat het volgende:
- Metagegevens van bestanden die de startcoördinaten van de metagegevens van elke kolom bevatten. Bij het lezen moet u eerst de metagegevens van het bestand lezen om alle interessante kolomfragmenten te vinden. De kolomgedeelten moeten vervolgens opeenvolgend worden gelezen. Andere metagegevens omvatten de indelingsversie, het schema en eventuele aanvullende sleutel-waardeparen.
- Lengte van metadata (4 bytes).
- magisch nummer PAR1 (4 bytes).
ORC-bestandsindeling
Geoptimaliseerd rij-kolom bestandsformaat (Geoptimaliseerde rijkolom, ) biedt een zeer efficiënte manier om gegevens op te slaan en is ontworpen om de beperkingen van andere formaten te overwinnen. Slaat gegevens op in een perfect compacte vorm, waardoor u onnodige details kunt overslaan - zonder dat u grote, complexe of handmatig onderhouden indexen hoeft te bouwen.
Voordelen van het ORC-formaat:
- Eén bestand is de uitvoer van elke taak, waardoor de belasting van de NameNode (naamknooppunt) wordt verminderd.
- Ondersteuning voor Hive-gegevenstypen, waaronder DateTime, decimale en complexe gegevenstypen (struct, list, map en union).
- Gelijktijdig lezen van hetzelfde bestand door verschillende RecordReader-processen.
- Mogelijkheid om bestanden te splitsen zonder naar markeringen te scannen.
- Schatting van de maximaal mogelijke heap-geheugentoewijzing voor lees-/schrijfprocessen op basis van informatie in de bestandsvoettekst.
- Metagegevens worden opgeslagen in het binaire serialisatieformaat Protocol Buffers, waardoor velden kunnen worden toegevoegd en verwijderd.
ORC slaat verzamelingen strings op in één enkel bestand, en binnen de verzameling worden stringgegevens opgeslagen in een kolomvormig formaat.
Een ORC-bestand slaat groepen regels op die strepen worden genoemd en ondersteunende informatie in de voettekst van het bestand. Het Postscript aan het einde van het bestand bevat compressieparameters en de grootte van de gecomprimeerde voettekst.
De standaard stripegrootte is 250 MB. Vanwege zulke grote strepen wordt het lezen van HDFS efficiënter uitgevoerd: in grote aaneengesloten blokken.
In de voettekst van het bestand wordt de lijst met rijstroken in het bestand, het aantal rijen per rij en het gegevenstype van elke kolom vastgelegd. De resulterende waarde van aantal, min, max en som voor elke kolom wordt daar ook geschreven.
De voettekst van de strip bevat een map met streamlocaties.
Rijgegevens worden gebruikt bij het scannen van tabellen.
Indexgegevens omvatten de minimum- en maximumwaarden voor elke kolom en de positie van de rijen in elke kolom. ORC-indexen worden alleen gebruikt voor het selecteren van strepen en rijgroepen, niet voor het beantwoorden van vragen.
Vergelijking van verschillende bestandsformaten
Avro vergeleken met parket
- Avro is een rijopslagindeling, terwijl Parquet gegevens in kolommen opslaat.
- Parquet is beter geschikt voor analytische query's, wat betekent dat leesbewerkingen en het opvragen van gegevens veel efficiënter zijn dan schrijfbewerkingen.
- Schrijfbewerkingen in Avro worden efficiënter uitgevoerd dan in Parquet.
- Avro gaat volwassener om met circuitevolutie. Parquet ondersteunt alleen het toevoegen van schema's, terwijl Avro multifunctionele evolutie ondersteunt, dat wil zeggen het toevoegen of wijzigen van kolommen.
- Parquet is ideaal voor het opvragen van een subset van kolommen in een tabel met meerdere kolommen. Avro is geschikt voor ETL-bewerkingen waarbij we alle kolommen bevragen.
ORC versus parket
- Parquet slaat geneste gegevens beter op.
- ORC is beter geschikt voor predicaat-pushdown.
- ORC ondersteunt ACID-eigenschappen.
- ORC comprimeert gegevens beter.
Wat nog meer te lezen over het onderwerp:
- .
- .
- .
Bron: www.habr.com