Csapat ajánlatok Rahul Bhatia mérnök a Clairvoyanttól arról, hogy milyen fájlformátumok vannak a big data-ban, melyek a Hadoop formátumok leggyakoribb jellemzői, és melyik formátumot érdemes használni.
Miért van szükség különböző fájlformátumokra?
A HDFS-kompatibilis alkalmazások, például a MapReduce és a Spark egyik fő teljesítménybeli szűk keresztmetszete az adatok kereséséhez, olvasásához és írásához szükséges idő. Ezeket a problémákat tetézi a nagy adatkészletek kezelésének nehézsége, ha nem rögzített, hanem fejlődő sémánk van, vagy ha vannak bizonyos tárolási korlátozások.
A nagyméretű adatok feldolgozása megnöveli a tárolási alrendszer terhelését – a Hadoop redundánsan tárolja az adatokat a hibatűrés érdekében. A lemezeken kívül betöltődik a processzor, a hálózat, a bemeneti/kimeneti rendszer stb. Az adatok mennyiségének növekedésével a feldolgozás és tárolás költsége is nő.
Különféle fájlformátumok pontosan ezeknek a problémáknak a megoldására találták ki. A megfelelő fájlformátum kiválasztása jelentős előnyökkel járhat:
- Gyorsabb olvasási idő.
- Gyorsabb felvételi idő.
- Megosztott fájlok.
- A séma evolúciójának támogatása.
- Kibővített tömörítési támogatás.
Egyes fájlformátumok általános használatra készültek, mások konkrétabb felhasználásra, néhány pedig meghatározott adatjellemzőknek felel meg. Szóval tényleg elég nagy a választék.
Avro fájlformátum
mert adatsorosítás Az Avro-t széles körben használják - ez karakterlánc alapú, vagyis egy karakterlánc adattárolási formátum a Hadoopban. A sémát JSON formátumban tárolja, így bármely program könnyen olvasható és értelmezhető. Maga az adat bináris formátumú, kompakt és hatékony.
Az Avro szerializációs rendszere nyelvsemleges. A fájlok többféle nyelven dolgozhatók fel, jelenleg C, C++, C#, Java, Python és Ruby.
Az Avro kulcsfontosságú jellemzője az idővel változó, azaz fejlődő adatsémák erőteljes támogatása. Az Avro megérti a sémamódosításokat – a mezők törlését, hozzáadását vagy módosítását.
Az Avro számos adatstruktúrát támogat. Létrehozhat például egy rekordot, amely egy tömböt, egy felsorolt típust és egy alrekordot tartalmaz.
Ez a formátum ideális egy adattó leszálló (átmeneti) zónájába való íráshoz (, vagy data lake – példányok gyűjteménye különféle típusú adatok tárolására az adatforrásokon kívül).
Tehát ez a formátum a legalkalmasabb egy adattó leszállózónájába való íráshoz a következő okok miatt:
- Az ebből a zónából származó adatokat általában teljes egészében kiolvassák a későbbi rendszerek további feldolgozása céljából – és ebben az esetben a soralapú formátum hatékonyabb.
- A downstream rendszerek könnyen lekérhetik a sématáblázatokat a fájlokból – nincs szükség a sémákat külön tárolni a külső metatárolóban.
- Az eredeti séma bármely módosítása könnyen feldolgozható (séma evolúció).
Parketta fájlformátum
A Parquet egy nyílt forráskódú fájlformátum a Hadoop számára, amely tárolja beágyazott adatszerkezetek lapos oszlopos formátumban.
A hagyományos soros megközelítéshez képest a Parketta hatékonyabb tárolási és teljesítménybeli szempontból.
Ez különösen hasznos azoknál a lekérdezéseknél, amelyek egy széles (sok oszlopos) táblából bizonyos oszlopokat olvasnak be. A fájlformátumnak köszönhetően csak a szükséges oszlopok kerülnek beolvasásra, így az I/O a minimálisra csökken.
Egy kis kitérő és magyarázat: Hogy jobban megértsük a Hadoop Parquet fájlformátumát, nézzük meg, mi az az oszlopalapú - azaz oszlopos - formátum. Ez a formátum minden oszlophoz hasonló értékeket tárol együtt.
, a rekord tartalmazza az ID, Név és Osztály mezőket. Ebben az esetben az összes ID oszlop értéke együtt kerül tárolásra, csakúgy, mint a Név oszlop értékei stb. A táblázat valahogy így fog kinézni:
ID
Név
osztály
1
emp1
d1
2
emp2
d2
3
emp3
d3
Karakterlánc formátumban az adatok mentése a következőképpen történik:
1
emp1
d1
2
emp2
d2
3
emp3
d3
Oszlopos fájlformátumban ugyanazok az adatok a következőképpen kerülnek mentésre:
1
2
3
emp1
emp2
emp3
d1
d2
d3
Az oszlopos formátum hatékonyabb, ha több oszlopot kell lekérdeznie egy táblázatból. Csak a szükséges oszlopokat olvassa be, mert szomszédosak. Ily módon az I/O műveletek minimálisra csökkenthetők.
Például csak a NÉV oszlopra van szüksége. BAN BEN Az adatkészlet minden rekordját be kell tölteni, mezőnként elemezni, majd ki kell bontani a NAME adatokat. Az oszlopformátum lehetővé teszi, hogy közvetlenül a Név oszlopig részletezzen, mivel az oszlop összes értéke együtt van tárolva. Nem kell a teljes felvételt beszkennelni.
Így az oszlopos formátum javítja a lekérdezés teljesítményét, mivel kevesebb keresési időt igényel a szükséges oszlopokhoz való eljutáshoz, és csökkenti az I/O műveletek számát, mivel csak a kívánt oszlopok kerülnek beolvasásra.
Az egyik egyedi tulajdonság hogy ebben a formátumban lehet beágyazott struktúrákkal tárolja az adatokat. Ez azt jelenti, hogy egy Parquet fájlban még a beágyazott mezők is külön-külön olvashatók anélkül, hogy a beágyazott struktúra összes mezőjét be kellene olvasni. A Parquet aprítási és összeszerelési algoritmust használ a beágyazott szerkezetek tárolására.
A Hadoop Parquet fájlformátumának megértéséhez ismernie kell a következő kifejezéseket:
- Húrok csoportja (sorcsoport): az adatok logikai vízszintes felosztása sorokra. Egy sorcsoport az adatkészlet minden oszlopának töredékéből áll.
- Oszloptöredék (oszlopdarab): Egy adott oszlop töredéke. Ezek az oszloptöredékek egy meghatározott sorcsoportban élnek, és garantáltan egybefüggőek a fájlban.
- Oldal (oldal): Az oszloptöredékek egymás után írt oldalakra vannak osztva. Az oldalak közös címet viselnek, így olvasás közben kihagyhatod a feleslegeseket.
Itt a cím csak a varázsszámot tartalmazza PAR1 (4 bájt), amely a fájlt Parquet fájlként azonosítja.
A lábléc a következőket írja:
- Fájl metaadatok, amelyek az egyes oszlopok metaadatainak kezdőkoordinátáit tartalmazzák. Olvasáskor először el kell olvasnia a fájl metaadatait, hogy megtalálja az összes érdekes oszloprészletet. Az oszloprészeket ezután sorban kell olvasni. Az egyéb metaadatok közé tartozik a formátum verziója, a séma és minden további kulcs-érték pár.
- A metaadat hossza (4 bájt).
- varázslatos szám PAR1 (4 bájt).
ORC fájlformátum
Optimalizált sor-oszlop fájlformátum (Optimalizált soroszlop, ) nagyon hatékony módot kínál az adatok tárolására, és úgy tervezték, hogy legyőzze más formátumok korlátait. Tökéletesen kompakt formában tárolja az adatokat, lehetővé téve a szükségtelen részletek kihagyását – anélkül, hogy nagy, összetett vagy manuálisan karbantartott indexeket kellene létrehozni.
Az ORC formátum előnyei:
- Minden feladat kimenete egy fájl, ami csökkenti a NameNode (névcsomópont) terhelését.
- Hive adattípusok támogatása, beleértve a DateTime, decimális és összetett adattípusokat (struktúra, lista, térkép és unió).
- Ugyanazon fájl egyidejű olvasása különböző RecordReader folyamatokkal.
- Fájlok felosztása markerek keresése nélkül.
- Az olvasási/írási folyamatok maximális lehetséges kupacmemória-foglalásának becslése a fájl láblécében található információk alapján.
- A metaadatok a Protocol Buffers bináris szerializációs formátumban tárolódnak, amely lehetővé teszi mezők hozzáadását és eltávolítását.
Az ORC egyetlen fájlban tárolja a karakterlánc-gyűjteményeket, a gyűjteményen belül pedig a karakterlánc-adatokat oszlopos formátumban tárolja.
Az ORC-fájl csíkoknak nevezett sorcsoportokat és támogató információkat tárol a fájl láblécében. A fájl végén található Postscript tartalmazza a tömörítési paramétereket és a tömörített lábléc méretét.
Az alapértelmezett csíkméret 250 MB. Az ilyen nagy csíkok miatt a HDFS-ből történő olvasás hatékonyabban történik: nagy összefüggő blokkokban.
A fájl lábléce rögzíti a fájl sávjainak listáját, a sávonkénti sorok számát és az egyes oszlopok adattípusát. Az egyes oszlopokhoz tartozó count, min, max és sum eredő értéke szintén oda van írva.
A szalag láblécében található az adatfolyam helyeinek könyvtára.
A táblázatok szkennelésekor soradatokat használnak.
Az indexadatok tartalmazzák az egyes oszlopok minimális és maximális értékét, valamint a sorok helyzetét az egyes oszlopokban. Az ORC indexek csak csíkok és sorcsoportok kiválasztására szolgálnak, lekérdezések megválaszolására nem.
Különböző fájlformátumok összehasonlítása
Avro a Parkettához képest
- Az Avro egy sor tárolási formátum, míg a Parquet oszlopokban tárolja az adatokat.
- A parketta jobban megfelel az analitikus lekérdezéseknek, vagyis az olvasási műveletek és az adatok lekérdezése sokkal hatékonyabb, mint az írás.
- Az Avro-ban az írási műveletek hatékonyabban hajthatók végre, mint a Parquet-ban.
- Az Avro érettebben foglalkozik az áramkörök evolúciójával. A Parquet csak a séma hozzáadását támogatja, míg az Avro a többfunkciós evolúciót, vagyis az oszlopok hozzáadását vagy megváltoztatását.
- A parketta ideális az oszlopok részhalmazának lekérdezésére egy többoszlopos táblázatban. Az Avro alkalmas ETL műveletekre, ahol minden oszlopot lekérdezünk.
ORC vs parketta
- A parketta jobban tárolja a beágyazott adatokat.
- Az ORC jobban megfelel a predikátum lenyomására.
- Az ORC támogatja az ACID tulajdonságokat.
- Az ORC jobban tömöríti az adatokat.
Mit kell még olvasni a témában:
- .
- .
- .
Forrás: will.com