Team erbjuder ingenjör Rahul Bhatia från Clairvoyant om vilka filformat det finns i big data, vilka som är de vanligaste funktionerna i Hadoop-format och vilket format som är bättre att använda.
Varför behövs olika filformat?
En stor prestandaflaskhals för HDFS-aktiverade applikationer som MapReduce och Spark är den tid det tar att söka, läsa och skriva data. Dessa problem förvärras av svårigheten att hantera stora datamängder om vi har ett utvecklande schema snarare än ett fast, eller om det finns några lagringsbegränsningar.
Bearbetning av big data ökar belastningen på lagringsundersystemet - Hadoop lagrar data redundant för att uppnå feltolerans. Förutom diskar laddas processorn, nätverket, input/output-systemet och så vidare. I takt med att mängden data växer ökar också kostnaden för att bearbeta och lagra den.
Olika filformat i uppfanns för att lösa just dessa problem. Att välja rätt filformat kan ge några betydande fördelar:
- Snabbare lästid.
- Snabbare inspelningstid.
- Delade filer.
- Stöd för schemautveckling.
- Utökat kompressionsstöd.
Vissa filformat är avsedda för allmän användning, andra för mer specifik användning, och vissa är utformade för att uppfylla specifika dataegenskaper. Så valet är egentligen ganska stort.
Avro filformat
för data serialisering Avro används flitigt - det strängbaserad, det vill säga ett strängdatalagringsformat i Hadoop. Den lagrar schemat i JSON-format, vilket gör det lätt att läsa och tolka av vilket program som helst. Själva data är i binärt format, kompakt och effektiv.
Avros serialiseringssystem är språkneutralt. Filer kan bearbetas på en mängd olika språk, för närvarande C, C++, C#, Java, Python och Ruby.
En nyckelfunktion hos Avro är dess robusta stöd för datascheman som förändras över tiden, det vill säga utvecklas. Avro förstår schemaändringar – ta bort, lägga till eller ändra fält.
Avro stöder en mängd olika datastrukturer. Du kan till exempel skapa en post som innehåller en array, en uppräknad typ och en underpost.
Detta format är idealiskt för att skriva till landningszonen (övergångszonen) för en datasjö (, eller datasjö - en samling instanser för att lagra olika typer av data utöver datakällor direkt).
Så det här formatet är bäst lämpat för att skriva till landningszonen för en datasjö av följande skäl:
- Data från denna zon läses vanligtvis i sin helhet för vidare bearbetning av nedströmssystem – och ett radbaserat format är mer effektivt i detta fall.
- Nedströmssystem kan enkelt hämta schematabeller från filer – inget behov av att lagra scheman separat i extern metalagring.
- Varje ändring av det ursprungliga schemat är lätt att bearbeta (schemautveckling).
Filformat för parkett
Parkett är ett filformat med öppen källkod för Hadoop som lagrar kapslade datastrukturer i platt kolumnformat.
Jämfört med den traditionella radmetoden är Parkett mer effektiv när det gäller förvaring och prestanda.
Detta är särskilt användbart för frågor som läser specifika kolumner från en bred (många kolumner) tabell. Tack vare filformatet läses endast nödvändiga kolumner, så I/O hålls till ett minimum.
En liten avvikelse och förklaring: För att bättre förstå Parquet-filformatet i Hadoop, låt oss se vad ett kolumnbaserat - d.v.s. kolumnformat - format är. Detta format lagrar liknande värden för varje kolumn tillsammans.
, innehåller posten fälten ID, Namn och Avdelning. I det här fallet kommer alla ID-kolumnsvärden att lagras tillsammans, liksom Name-kolumnvärdena och så vidare. Tabellen kommer att se ut ungefär så här:
ID
Namn
Avdelning
1
emp1
d1
2
emp2
d2
3
emp3
d3
I strängformat kommer data att sparas enligt följande:
1
emp1
d1
2
emp2
d2
3
emp3
d3
I ett kolumnärt filformat kommer samma data att sparas så här:
1
2
3
emp1
emp2
emp3
d1
d2
d3
Kolumnformatet är mer effektivt när du behöver fråga flera kolumner från en tabell. Den kommer bara att läsa de obligatoriska kolumnerna eftersom de ligger intill. På så sätt hålls I/O-operationerna till ett minimum.
Till exempel behöver du bara kolumnen NAME. I Varje post i datamängden måste laddas, analyseras efter fält och sedan extraheras NAME-data. Kolumnformatet låter dig gå ner direkt till kolumnen Namn eftersom alla värden för den kolumnen lagras tillsammans. Du behöver inte skanna hela inspelningen.
Således förbättrar det kolumnära formatet frågeprestanda eftersom det kräver mindre uppslagstid för att komma till de obligatoriska kolumnerna och minskar antalet I/O-operationer eftersom endast de önskade kolumnerna läses.
En av de unika egenskaperna är att i detta format kan det lagra data med kapslade strukturer. Det betyder att i en Parquet-fil kan även kapslade fält läsas individuellt utan att behöva läsa alla fält i den kapslade strukturen. Parkett använder en fragmenterings- och monteringsalgoritm för att lagra kapslade strukturer.
För att förstå filformatet Parkett i Hadoop behöver du känna till följande termer:
- Grupp av strängar (radgrupp): logisk horisontell uppdelning av data i rader. En radgrupp består av ett fragment av varje kolumn i datamängden.
- Kolumnfragment (kolumn chunk): Ett fragment av en specifik kolumn. Dessa kolumnfragment lever i en specifik grupp av rader och är garanterat sammanhängande i filen.
- Sida (sida): Kolumnfragment är uppdelade i sidor skrivna efter varandra. Sidorna har en gemensam titel, så du kan hoppa över onödiga när du läser.
Här innehåller titeln bara det magiska numret PAR1 (4 byte) som identifierar filen som en parkettfil.
Sidfoten säger följande:
- Filmetadata som innehåller startkoordinaterna för varje kolumns metadata. När du läser måste du först läsa filens metadata för att hitta alla kolumnfragment av intresse. Kolumnfragmenten ska sedan läsas sekventiellt. Andra metadata inkluderar formatversionen, schemat och eventuella ytterligare nyckel-värdepar.
- Metadatalängd (4 byte).
- Magiskt nummer PAR1 (4 bytes).
ORC-filformat
Optimerat rad-kolumn filformat (Optimerad radkolumn, ) erbjuder ett mycket effektivt sätt att lagra data och designades för att övervinna begränsningarna hos andra format. Lagrar data i en perfekt kompakt form, så att du kan hoppa över onödiga detaljer - utan att behöva bygga stora, komplexa eller manuellt underhållna index.
Fördelar med ORC-formatet:
- En fil är utdata från varje uppgift, vilket minskar belastningen på NameNode (namnnoden).
- Stöd för Hive-datatyper, inklusive DateTime, decimala och komplexa datatyper (struct, list, map och union).
- Samtidig läsning av samma fil med olika RecordReader-processer.
- Möjlighet att dela filer utan att skanna efter markörer.
- Uppskattning av maximalt möjliga heap-minnestilldelning för läs-/skrivprocesser baserat på information i sidfoten.
- Metadata lagras i det binära serialiseringsformatet Protocol Buffers, vilket gör att fält kan läggas till och tas bort.
ORC lagrar samlingar av strängar i en enda fil, och inom samlingen lagras strängdata i ett kolumnformat.
En ORC-fil lagrar grupper av rader som kallas ränder och stödjande information i filens sidfot. Postscriptet i slutet av filen innehåller komprimeringsparametrar och storleken på den komprimerade sidfoten.
Standardrandstorleken är 250 MB. På grund av så stora ränder utförs läsning från HDFS mer effektivt: i stora sammanhängande block.
Filsidfoten registrerar listan över filer i filen, antalet rader per fil och datatypen för varje kolumn. Det resulterande värdet av count, min, max och summa för varje kolumn skrivs också där.
Sidfoten på remsan innehåller en katalog med strömningsplatser.
Raddata används vid skanning av tabeller.
Indexdata inkluderar lägsta och högsta värden för varje kolumn och positionen för raderna i varje kolumn. ORC-index används endast för att välja ränder och radgrupper, inte för att svara på frågor.
Jämförelse av olika filformat
Avro jämfört med Parkett
- Avro är ett radlagringsformat, medan Parquet lagrar data i kolumner.
- Parkett lämpar sig bättre för analytiska frågor, vilket innebär att läsoperationer och sökning av data är mycket effektivare än att skriva.
- Skrivoperationer i Avro utförs mer effektivt än i Parkett.
- Avro hanterar kretsutveckling mer moget. Parkett stöder endast schematillägg, medan Avro stöder multifunktionell evolution, det vill säga att lägga till eller ändra kolumner.
- Parkett är idealiskt för att fråga en delmängd av kolumner i en tabell med flera kolumner. Avro lämpar sig för ETL-operationer där vi frågar alla kolumner.
ORC vs Parkett
- Parkett lagrar kapslade data bättre.
- ORC är bättre lämpad att predika pushdown.
- ORC stöder ACID-egenskaper.
- ORC komprimerar data bättre.
Vad mer att läsa om ämnet:
- .
- .
- .
Källa: will.com