Filformater i big data: et kort pedagogisk program

Værguden av Remarin

Lag Mail.ru skyløsninger tilbud artikkeloversettelse ingeniør Rahul Bhatia fra Clairvoyant om hvilke filformater det finnes i big data, hva som er de vanligste funksjonene til Hadoop-formater og hvilket format som er bedre å bruke.

Hvorfor trengs forskjellige filformater?

En stor flaskehals i ytelsen for HDFS-aktiverte applikasjoner som MapReduce og Spark er tiden det tar å søke, lese og skrive data. Disse problemene forsterkes av vanskelighetene med å administrere store datasett hvis vi har et utviklende skjema i stedet for et fast, eller hvis det er noen lagringsbegrensninger.

Behandling av store data øker belastningen på lagringsundersystemet – Hadoop lagrer data redundant for å oppnå feiltoleranse. I tillegg til disker, lastes prosessoren, nettverket, input/output-systemet og så videre. Etter hvert som datavolumet vokser, øker også kostnadene ved å behandle og lagre dem.

Ulike filformater i Hadoop oppfunnet for å løse nettopp disse problemene. Å velge riktig filformat kan gi noen betydelige fordeler:

1. Raskere lesetid.
2. Raskere opptakstid.
3. Delte filer.
4. Støtte for skjemautvikling.
5. Utvidet kompresjonsstøtte.

Noen filformater er ment for generell bruk, andre for mer spesifikke bruksområder, og noen er designet for å møte spesifikke dataegenskaper. Så utvalget er egentlig ganske stort.

Avro filformat

For dataserialisering Avro er mye brukt - det strengbasert, det vil si et strengdatalagringsformat i Hadoop. Den lagrer skjemaet i JSON-format, noe som gjør det enkelt å lese og tolke av ethvert program. Selve dataene er i binært format, kompakte og effektive.

Avros serialiseringssystem er språknøytralt. Filer kan behandles på en rekke språk, for tiden C, C++, C#, Java, Python og Ruby.

En nøkkelfunksjon ved Avro er dens robuste støtte for dataskjemaer som endrer seg over tid, det vil si utvikler seg. Avro forstår skjemaendringer – sletter, legger til eller endrer felt.

Avro støtter en rekke datastrukturer. Du kan for eksempel opprette en post som inneholder en matrise, en opplistet type og en underpost.

Dette formatet er ideelt for å skrive til landingssonen (overgang) til en datainnsjø (datainnsjø, eller datainnsjø - en samling forekomster for lagring av ulike typer data i tillegg til datakilder direkte).

Så dette formatet er best egnet for å skrive til landingssonen til en datainnsjø av følgende grunner:

1. Data fra denne sonen leses vanligvis i sin helhet for videre behandling av nedstrømssystemer – og et radbasert format er mer effektivt i dette tilfellet.
2. Nedstrømssystemer kan enkelt hente skjematabeller fra filer – det er ikke nødvendig å lagre skjemaer separat i ekstern metalagring.
3. Enhver endring av det originale skjemaet behandles enkelt (skjemaevolusjon).

Parkett filformat

Parkett er et åpen kildekode-filformat for Hadoop som lagrer nestede datastrukturer i flatt søyleformat.

Sammenlignet med den tradisjonelle radtilnærmingen er Parkett mer effektiv når det gjelder lagring og ytelse.

Dette er spesielt nyttig for spørringer som leser spesifikke kolonner fra en bred (mange kolonner) tabell. Takket være filformatet leses kun de nødvendige kolonnene, så I/O holdes på et minimum.

En liten digresjon og forklaring: For å bedre forstå Parquet-filformatet i Hadoop, la oss se hva et kolonnebasert - dvs. kolonneformat - er. Dette formatet lagrer lignende verdier for hver kolonne sammen.

For eksempel, inkluderer posten ID-, Navn- og Avdeling-feltene. I dette tilfellet vil alle ID-kolonneverdiene lagres sammen, det samme vil verdiene for Navn-kolonnen, og så videre. Tabellen vil se omtrent slik ut:

ID
Navn
Avdeling

1
emp1
d1

2
emp2
d2

3
emp3
d3

I strengformat vil dataene lagres som følger:

1
emp1
d1
2
emp2
d2
3
emp3
d3

I et kolonneformet filformat vil de samme dataene lagres slik:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Kolonneformatet er mer effektivt når du trenger å spørre etter flere kolonner fra en tabell. Den vil bare lese de nødvendige kolonnene fordi de er tilstøtende. På denne måten holdes I/O-operasjoner på et minimum.

Du trenger for eksempel bare NAME-kolonnen. I strengformat Hver post i datasettet må lastes, analyseres etter felt, og deretter trekkes ut NAME-dataene. Kolonneformatet lar deg gå ned direkte til Navn-kolonnen fordi alle verdiene for den kolonnen er lagret sammen. Du trenger ikke å skanne hele opptaket.

Dermed forbedrer kolonneformatet søkeytelsen fordi det krever mindre oppslagstid for å komme til de nødvendige kolonnene og reduserer antall I/O-operasjoner fordi bare de ønskede kolonnene leses.

En av de unike egenskapene parkett er at i dette formatet kan det lagre data med nestede strukturer. Dette betyr at i en Parkett-fil kan til og med nestede felt leses enkeltvis uten å måtte lese alle feltene i den nestede strukturen. Parkett bruker en makulerings- og monteringsalgoritme for å lagre nestede strukturer.

For å forstå Parquet-filformatet i Hadoop, må du kjenne til følgende begreper:

1. Radgruppe (radgruppe): logisk horisontal inndeling av data i rader. En radgruppe består av et fragment av hver kolonne i datasettet.
2. Kolonnefragment (kolonneklump): Et fragment av en spesifikk kolonne. Disse kolonnefragmentene lever i en bestemt gruppe rader og er garantert sammenhengende i filen.
3. Side (side): Spaltefragmenter er delt inn i sider skrevet etter hverandre. Sidene har en felles tittel, slik at du kan hoppe over unødvendige når du leser.

Her inneholder tittelen bare det magiske tallet PAR1 (4 byte) som identifiserer filen som en parkettfil.

Bunnteksten sier følgende:

1. Filmetadata som inneholder startkoordinatene til hver kolonnes metadata. Når du leser, må du først lese filens metadata for å finne alle kolonnefragmentene av interesse. Kolonnedelene bør deretter leses sekvensielt. Andre metadata inkluderer formatversjonen, skjemaet og eventuelle ekstra nøkkelverdi-par.
2. Metadatalengde (4 byte).
3. magisk tall PAR1 (4 byte).

ORC filformat

Optimalisert rad-kolonne filformat (Optimalisert radkolonne, ORC) tilbyr en svært effektiv måte å lagre data på og ble designet for å overvinne begrensningene til andre formater. Lagrer data i en perfekt kompakt form, slik at du kan hoppe over unødvendige detaljer - uten å kreve konstruksjon av store, komplekse eller manuelt vedlikeholdte indekser.

Fordeler med ORC-formatet:

1. Én fil er utdata fra hver oppgave, noe som reduserer belastningen på NameNode (navnenoden).
2. Støtte for Hive-datatyper, inkludert DateTime, desimal og komplekse datatyper (struct, list, map og union).
3. Samtidig lesing av den samme filen av forskjellige RecordReader-prosesser.
4. Evne til å dele filer uten å skanne etter markører.
5. Estimering av maksimalt mulig heap-minneallokering for lese-/skriveprosesser basert på informasjon i filbunnteksten.
6. Metadata lagres i Protocol Buffers binære serialiseringsformat, som lar felt legges til og fjernes.

ORC lagrer samlinger av strenger i en enkelt fil, og innenfor samlingen lagres strengdata i et kolonneformat.

En ORC-fil lagrer grupper av linjer kalt striper og støtteinformasjon i bunnteksten til filen. Postscript på slutten av filen inneholder komprimeringsparametere og størrelsen på den komprimerte bunnteksten.

Standard stripestørrelse er 250 MB. På grunn av så store striper utføres lesing fra HDFS mer effektivt: i store sammenhengende blokker.

Filbunnteksten registrerer listen over felt i filen, antall rader per felt og datatypen for hver kolonne. Den resulterende verdien av count, min, max og sum for hver kolonne er også skrevet der.

Bunnteksten på stripen inneholder en katalog med strømplasseringer.

Raddata brukes ved skanning av tabeller.

Indeksdata inkluderer minimums- og maksimumsverdier for hver kolonne og posisjonen til radene i hver kolonne. ORC-indekser brukes bare for å velge striper og radgrupper, ikke for å svare på spørsmål.

Sammenligning av forskjellige filformater

Avro sammenlignet med parkett

1. Avro er et radlagringsformat, mens Parkett lagrer data i kolonner.
2. Parkett er bedre egnet for analytiske spørringer, noe som betyr at leseoperasjoner og spørredata er mye mer effektive enn skriving.
3. Skriveoperasjoner i Avro utføres mer effektivt enn i Parkett.
4. Avro håndterer kretsutviklingen mer modent. Parkett støtter kun skjematillegg, mens Avro støtter multifunksjonell evolusjon, det vil si å legge til eller endre kolonner.
5. Parkett er ideell for å spørre et undersett av kolonner i en flerkolonnetabell. Avro er egnet for ETL-operasjoner der vi spørre alle kolonner.

ORC vs parkett

1. Parkett lagrer nestede data bedre.
2. ORC er bedre egnet til å predikere pushdown.
3. ORC støtter ACID-egenskaper.
4. ORC komprimerer data bedre.

Hva annet å lese om emnet:

1. Big data-analyse i skyen: hvordan en bedrift kan bli dataorientert.
2. En ydmyk guide til databaseskjemaer.
3. Vår telegramkanal om digital transformasjon.

Kilde: www.habr.com