Equip ofertes l'enginyer Rahul Bhatia de Clairvoyant sobre quins formats de fitxer hi ha en el big data, quines són les característiques més comunes dels formats Hadoop i quin format és millor utilitzar.
Per què es necessiten diferents formats de fitxer?
Un coll d'ampolla de rendiment important per a aplicacions habilitats per HDFS com MapReduce i Spark és el temps que triga a cercar, llegir i escriure dades. Aquests problemes es veuen agreujats per la dificultat de gestionar grans conjunts de dades si tenim un esquema en evolució en lloc d'un de fix, o si hi ha algunes limitacions d'emmagatzematge.
El processament de grans dades augmenta la càrrega del subsistema d'emmagatzematge: Hadoop emmagatzema les dades de manera redundant per aconseguir tolerància a errors. A més dels discs, es carreguen el processador, la xarxa, el sistema d'entrada/sortida, etc. A mesura que creix el volum de dades, també augmenta el cost de processar-les i emmagatzemar-les.
Diversos formats de fitxer en inventat per resoldre precisament aquests problemes. La selecció del format de fitxer adequat pot proporcionar alguns avantatges importants:
- Temps de lectura més ràpid.
- Temps de gravació més ràpid.
- Fitxers compartits.
- Suport per a l'evolució d'esquemes.
- Suport de compressió ampliat.
Alguns formats de fitxer estan pensats per a un ús general, d'altres per a usos més específics i alguns estan dissenyats per complir característiques específiques de dades. Així que l'elecció és realment bastant gran.
Format de fitxer Avro
Per serialització de dades Avro s'utilitza àmpliament - això basat en cordes, és a dir, un format d'emmagatzematge de dades de cadena a Hadoop. Emmagatzema l'esquema en format JSON, de manera que és fàcil de llegir i interpretar per qualsevol programa. Les dades en si estan en format binari, compactes i eficients.
El sistema de serialització d'Avro és neutre en el llenguatge. Els fitxers es poden processar en diversos idiomes, actualment C, C++, C#, Java, Python i Ruby.
Una característica clau d'Avro és el seu suport robust per als esquemes de dades que canvien amb el temps, és a dir, evolucionen. Avro entén els canvis d'esquema: suprimir, afegir o canviar camps.
Avro admet una varietat d'estructures de dades. Per exemple, podeu crear un registre que contingui una matriu, un tipus enumerat i un subregistre.
Aquest format és ideal per escriure a la zona d'aterratge (transició) d'un llac de dades (, o llac de dades: una col·lecció d'instàncies per emmagatzemar diversos tipus de dades a més de fonts de dades directament).
Per tant, aquest format és el més adequat per escriure a la zona d'aterratge d'un llac de dades pels motius següents:
- Les dades d'aquesta zona es llegeixen en la seva totalitat per a un posterior processament pels sistemes posteriors, i un format basat en files és més eficient en aquest cas.
- Els sistemes posteriors poden recuperar fàcilment les taules d'esquemes dels fitxers, sense necessitat d'emmagatzemar esquemes per separat en un metaemmagatzematge extern.
- Qualsevol canvi a l'esquema original es processa fàcilment (evolució de l'esquema).
Format d'arxiu de parquet
Parquet és un format de fitxer de codi obert per a Hadoop que emmagatzema estructures de dades imbricades en format de columna plana.
En comparació amb l'enfocament tradicional de fila, Parquet és més eficient en termes d'emmagatzematge i rendiment.
Això és especialment útil per a consultes que llegeixen columnes específiques d'una taula àmplia (moltes columnes). Gràcies al format de fitxer, només es llegeixen les columnes necessàries, de manera que l'E/S es redueix al mínim.
Una petita digressió i explicació: Per entendre millor el format de fitxer Parquet a Hadoop, vegem què és un format basat en columnes, és a dir, en columna. Aquest format emmagatzema valors similars per a cada columna junts.
, el registre inclou els camps ID, Nom i Departament. En aquest cas, tots els valors de la columna ID s'emmagatzemaran junts, igual que els valors de la columna Nom, etc. La taula tindrà un aspecte semblant a això:
ID
Nom
departament
1
emp1
d1
2
emp2
d2
3
emp3
d3
En format de cadena, les dades es desaran de la següent manera:
1
emp1
d1
2
emp2
d2
3
emp3
d3
En un format de fitxer de columna, les mateixes dades es desaran de la següent manera:
1
2
3
emp1
emp2
emp3
d1
d2
d3
El format de columna és més eficient quan necessiteu consultar diverses columnes d'una taula. Només llegirà les columnes necessàries perquè són adjacents. D'aquesta manera, les operacions d'E/S es mantenen al mínim.
Per exemple, només necessiteu la columna NOM. EN Cada registre del conjunt de dades s'ha de carregar, analitzar per camp i després extreure les dades de NOM. El format de columna us permet profunditzar directament a la columna Nom perquè tots els valors d'aquesta columna s'emmagatzemen junts. No cal escanejar tota la gravació.
Per tant, el format de columna millora el rendiment de la consulta perquè requereix menys temps de cerca per arribar a les columnes requerides i redueix el nombre d'operacions d'E/S perquè només es llegeixen les columnes desitjades.
Una de les característiques úniques és que en aquest format es pot emmagatzemar dades amb estructures imbricades. Això vol dir que en un fitxer Parquet, fins i tot els camps imbricats es poden llegir individualment sense haver de llegir tots els camps de l'estructura imbricada. Parquet utilitza un algorisme de trituració i muntatge per emmagatzemar estructures imbricades.
Per entendre el format del fitxer Parquet a Hadoop, heu de conèixer els termes següents:
- Grup de cordes (grup de files): divisió horitzontal lògica de dades en files. Un grup de files consta d'un fragment de cada columna del conjunt de dades.
- Fragment de columna (column chunk): un fragment d'una columna específica. Aquests fragments de columna viuen en un grup específic de files i es garanteix que siguin contigus al fitxer.
- Pàgina (pàgina): els fragments de columna es divideixen en pàgines escrites una darrere l'altra. Les pàgines tenen un títol comú, de manera que podeu saltar-ne les innecessàries en llegir.
Aquí el títol només conté el número màgic PAR1 (4 bytes) que identifica el fitxer com a fitxer Parquet.
El peu de pàgina diu el següent:
- Fitxer de metadades que conté les coordenades inicials de les metadades de cada columna. Quan llegiu, primer heu de llegir les metadades del fitxer per trobar tots els fragments de columna d'interès. Aleshores, les parts de la columna s'han de llegir seqüencialment. Altres metadades inclouen la versió del format, l'esquema i qualsevol parell clau-valor addicional.
- Longitud de metadades (4 bytes).
- nombre màgic PAR1 (4 bytes).
Format de fitxer ORC
Format de fitxer fila-columna optimitzat (Columna de fila optimitzada, ) ofereix una manera molt eficient d'emmagatzemar dades i va ser dissenyat per superar les limitacions d'altres formats. Emmagatzema les dades en una forma perfectament compacta, la qual cosa us permet ometre detalls innecessaris, sense requerir la construcció d'índexs grans, complexos o mantinguts manualment.
Avantatges del format ORC:
- Un fitxer és la sortida de cada tasca, la qual cosa redueix la càrrega del NameNode (node del nom).
- Compatibilitat amb els tipus de dades Hive, inclosos els tipus de dades DateTime, decimals i complexos (estructura, llista, mapa i unió).
- Lectura simultània d'un mateix fitxer per diferents processos de RecordReader.
- Possibilitat de dividir fitxers sense buscar marcadors.
- Estimació de l'assignació màxima possible de memòria d'emmagatzematge dinàmic per als processos de lectura/escriptura basada en la informació del peu de pàgina del fitxer.
- Les metadades s'emmagatzemen en el format de serialització binari Protocol Buffers, que permet afegir i eliminar camps.
ORC emmagatzema col·leccions de cadenes en un únic fitxer i, dins de la col·lecció, les dades de cadenes s'emmagatzemen en un format de columna.
Un fitxer ORC emmagatzema grups de línies anomenats ratlles i informació de suport al peu de pàgina del fitxer. El Postscript al final del fitxer conté paràmetres de compressió i la mida del peu de pàgina comprimit.
La mida de banda predeterminada és de 250 MB. A causa de les franges tan grans, la lectura de HDFS es realitza de manera més eficient: en grans blocs contigus.
El peu de pàgina del fitxer registra la llista de carrils del fitxer, el nombre de files per carril i el tipus de dades de cada columna. Allà també s'escriu el valor resultant de count, min, max i suma per a cada columna.
El peu de pàgina de la tira conté un directori d'ubicacions del flux.
Les dades de fila s'utilitzen quan s'escanegen taules.
Les dades de l'índex inclouen els valors mínims i màxims de cada columna i la posició de les files de cada columna. Els índexs ORC només s'utilitzen per seleccionar ratlles i grups de files, no per respondre consultes.
Comparació de diferents formats de fitxer
Avro en comparació amb Parquet
- Avro és un format d'emmagatzematge de files, mentre que Parquet emmagatzema dades en columnes.
- Parquet és més adequat per a consultes analítiques, és a dir, les operacions de lectura i la consulta de dades són molt més eficients que les escriptures.
- Les operacions d'escriptura a Avro es realitzen de manera més eficient que a Parquet.
- Avro tracta l'evolució del circuit de manera més madura. Parquet només admet l'addició d'esquemes, mentre que Avro admet l'evolució multifuncional, és a dir, afegir o canviar columnes.
- Parquet és ideal per consultar un subconjunt de columnes en una taula de diverses columnes. Avro és adequat per a operacions ETL on consultem totes les columnes.
ORC vs Parquet
- Parquet emmagatzema millor les dades imbricades.
- L'ORC és més adequat per a l'impuls de predicats.
- ORC admet propietats ACID.
- ORC comprimeix millor les dades.
Què més llegir sobre el tema:
- .
- .
- .
Font: www.habr.com