Komprimering av data i Hadoop - dummies

De enorme dataene som er realiteter i en typisk Hadoop-distribusjon, gjør komprimering en nødvendighet. Datakomprimering sparer deg definitivt mye lagringsplass og er sikker på å øke bevegelsen av dataene i hele klyngen din. Ikke overraskende, finnes en rekke tilgjengelige kompresjonsordninger, kalt codecs, der ute for å vurdere.

I en Hadoop-distribusjon handler du (potensielt) med ganske mange individuelle slave noder, som hver har en rekke store diskstasjoner. Det er ikke uvanlig at en individuell slaveknute har opptil 45 TB rå lagringsplass tilgjengelig for HDFS.

For det første er noen grunnleggende termer: A

codec, som er en forkortet form av co mpressor / dec ompressor, er teknologi (programvare eller maskinvare, eller begge) for å komprimere og dekomprimere data; Det er implementeringen av en komprimerings- / dekomprimeringsalgoritme.

Du må vite at noen kodeker støtter noe kalt splittable komprimering, og at kodekene varierer i både hastigheten som de kan komprimere og dekomprimere data og i hvilken grad de kan komprimere den.

Splittable compression

er et viktig konsept i en Hadoop-kontekst. Måten Hadoop jobber på, er at filene er delt hvis de er større enn filens blokkstørrelsesinnstilling, og individuelle filspalt kan behandles parallelt med forskjellige mapper.

Med de fleste kodeker kan ikke tekstfilspaltene dekomprimeres uavhengig av andre splitter fra samme fil, så disse kodekene sies å være ikke-splittbare, så MapReduce-behandling er begrenset til en enkelt mapper.

Siden filen kun kan dekomprimeres i sin helhet, og ikke som individuelle deler basert på splitter, kan det ikke være noen parallell behandling av en slik fil, og ytelsen kan ta en stor suksess når en jobb venter på en enkelt mapper til behandle flere datablokker som ikke kan dekomprimeres uavhengig.

Splittable-komprimering er bare en faktor for tekstfiler. For binære filer komprimerer Hadoop-komprimeringskodene data i en binærkodet container, avhengig av filtypen (for eksempel en SequenceFile, Avro eller ProtocolBuffer).

Når det gjelder ytelse, er det en kostnad (når det gjelder behandling av ressurser og tid) knyttet til å komprimere dataene som skrives til Hadoop-klyngen.

Med datamaskiner, som med livet, er ingenting gratis. Når du komprimerer data, bytter du behandlingssykluser for diskplass. Og når dataene blir lest, er det en kostnad forbundet med dekomprimering av dataene også. Pass på å veie fordelene med lagringsbesparelser mot ekstra ytelse.

Hvis inngangsfilen til en MapReduce-jobb inneholder komprimerte data, er tiden som trengs for å lese dataene fra HDFS, redusert, og jobbytelsen er forbedret. Inndataene dekomprimeres automatisk når den leses av MapReduce.

Filnavnet for utvidelse bestemmer hvilken støttet kodek som brukes til automatisk dekomprimering av dataene. For eksempel a. gz-utvidelsen identifiserer filen som en gzip-komprimert fil.

Det kan også være nyttig å komprimere mellomproduksjonen av kartfasen i MapReduce-prosesseringsflyten. Fordi kartfunksjonen er skrevet til disk og sendt over nettverket for å redusere oppgavene, kan komprimering av produksjonen resultere i betydelige ytelsesforbedringer.

Og hvis du vil lagre MapReduce-utgangen som historiefiler for fremtidig bruk, kan komprimere disse dataene betydelig redusere mengden nødvendig plass i HDFS.

Det finnes mange forskjellige komprimeringsalgoritmer og verktøy, og deres egenskaper og styrker varierer. Den vanligste avstanden er mellom kompresjonsforholdene (i hvilken grad en fil er komprimert) og komprimerer / dekomprimerer hastigheter. Hadoop-rammen støtter flere kodeker. Rammene gjennomsiktig komprimerer og dekomprimerer de fleste inngangs- og utdatafilformater.

Følgende liste identifiserer noen vanlige kodeker som støttes av Hadoop-rammen. Pass på å velge kodek som passer best til kravene til ditt spesielle brukstilfelle (for eksempel med arbeidsbelastning hvor hastigheten på behandlingen er viktig, valgte en kodek med høy dekompresjonshastighet):

Gzip:

• En komprimering verktøy som ble vedtatt av GNU prosjektet, Gzip (kort for GNU zip) genererer komprimerte filer som har a. gz forlengelse. Du kan bruke kommandoen gunzip til å dekomprimere filer som ble opprettet av en rekke komprimeringsverktøy, inkludert Gzip. Bzip2:

• Fra et brukssynspunkt er Bzip2 og Gzip like. Bzip2 genererer et bedre kompresjonsforhold enn Gzip, men det er mye tregere. Faktisk, av alle tilgjengelige komprimeringskodene i Hadoop, er Bzip2 langt den langsomste. Hvis du setter opp et arkiv som du sjelden trenger å spørre om, og rommet har høy premie, kan det være at Bzip2 er verdt å vurdere.

  Snappy:

• Snappy-kodeken fra Google gir beskjedne kompresjonsforhold, men hurtige komprimerings- og dekompresjonshastigheter. (Faktisk har den den raskeste dekompresjonshastigheten, noe som gjør det svært ønskelig for datasett som sannsynligvis vil bli forespurt ofte.) Snappy codec er integrert i Hadoop Common, et sett av fellesverktøy som støtter andre Hadoop-delprosjekter. Du kan bruke Snappy som et tillegg for nyere versjoner av Hadoop som ennå ikke gir Snappy codec-støtte.

  LZO:

• I likhet med Snappy, gir LZO (kort for Lempel-Ziv-Oberhumer, trioen av datavitenskapere som kom opp med algoritmen) beskjedne kompresjonsforhold, men hurtige komprimerings- og dekompresjonshastigheter. LZO er lisensiert under GNU Public License (GPL). LZO støtter splittable komprimering, som muliggjør parallell behandling av komprimerte tekstfilsklover med MapReduce-jobber. LZO må opprette en indeks når den komprimerer en fil, fordi med komprimeringsblokker med variabel lengde er det nødvendig med en indeks for å fortelle mappen der den trygt kan dele den komprimerte filen. LZO er bare virkelig ønskelig hvis du trenger å komprimere tekstfiler.

  Hadoop Codecs

Codec

Filforlengelse	Splittable?	Komprimeringsgrad	Komprimeringshastighet	Gzip
. gz	No	Middels	Middels	Bzip2
. BZ2	Ja	High	Sakte	Kvikk
. irritabel	Nei	Medium	Fast	LZO
. lzo	Nei, med mindre indeksert	Medium	Fast	Alle komprimeringsalgoritmer må gjøre avveier mellom kompresjonsgraden og kompressionshastigheten som de kan oppnå. Kodene som er oppført, gir deg litt kontroll over hva balansen mellom kompresjonsforhold og hastighet skal være på kompresjonstid.

Gzip lar deg for eksempel regulere kompresjonshastigheten ved å angi et negativt heltall (eller søkeord), der -1 angir det raskeste komprimeringsnivået, og -9 angir det sakte komprimeringsnivået. Standard komprimeringsnivå er -6.