Equipo ofertas o enxeñeiro Rahul Bhatia de Clairvoyant sobre os formatos de ficheiro que hai en big data, cales son as características máis comúns dos formatos Hadoop e que formato é mellor usar.
Por que son necesarios diferentes formatos de ficheiro?
Un importante pescozo de botella de rendemento para aplicacións compatibles con HDFS como MapReduce e Spark é o tempo que leva buscar, ler e escribir datos. A estes problemas súmase a dificultade de xestionar grandes conxuntos de datos se temos un esquema en evolución máis que un fixo, ou se hai algunhas limitacións de almacenamento.
O procesamento de grandes datos aumenta a carga do subsistema de almacenamento: Hadoop almacena os datos de forma redundante para lograr tolerancia a fallos. Ademais dos discos, cárganse o procesador, a rede, o sistema de entrada/saída, etc. A medida que crece o volume de datos, tamén aumenta o custo de procesalos e almacenalos.
Varios formatos de ficheiro en inventado para resolver precisamente estes problemas. A selección do formato de ficheiro axeitado pode proporcionar algúns beneficios significativos:
- Tempo de lectura máis rápido.
- Tempo de gravación máis rápido.
- Ficheiros compartidos.
- Soporte para a evolución do esquema.
- Soporte de compresión ampliado.
Algúns formatos de ficheiro están pensados para uso xeral, outros para usos máis específicos e algúns están deseñados para cumprir características específicas de datos. Entón, a elección é realmente moi grande.
Formato de ficheiro Avro
Para serialización de datos Avro é amplamente utilizado - iso baseado en cadeas, é dicir, un formato de almacenamento de datos de cadea en Hadoop. Almacena o esquema en formato JSON, facilitando a súa lectura e interpretación por calquera programa. Os datos en si están en formato binario, compactos e eficientes.
O sistema de serialización de Avro é neutral na linguaxe. Os ficheiros pódense procesar nunha variedade de linguaxes, actualmente C, C++, C#, Java, Python e Ruby.
Unha característica fundamental de Avro é o seu sólido soporte para esquemas de datos que cambian co paso do tempo, é dicir, evolucionan. Avro comprende os cambios de esquema: eliminar, engadir ou cambiar campos.
Avro admite unha variedade de estruturas de datos. Por exemplo, pode crear un rexistro que conteña unha matriz, un tipo enumerado e un subrexistro.
Este formato é ideal para escribir na zona de aterraxe (transición) dun lago de datos (, ou data lake: unha colección de instancias para almacenar varios tipos de datos ademais das fontes de datos directamente).
Polo tanto, este formato é o máis adecuado para escribir na zona de aterraxe dun lago de datos polos seguintes motivos:
- Os datos desta zona adoitan lerse na súa totalidade para o seu procesamento posterior polos sistemas posteriores, e neste caso é máis eficiente un formato baseado en filas.
- Os sistemas posteriores poden recuperar facilmente táboas de esquemas dos ficheiros, sen necesidade de almacenar esquemas por separado nun metaalmacenamento externo.
- Calquera cambio no esquema orixinal é facilmente procesado (evolución do esquema).
Formato de ficheiro de parquet
Parquet é un formato de ficheiro de código aberto para Hadoop que almacena estruturas de datos anidadas en formato de columna plana.
En comparación co enfoque tradicional de filas, o parquet é máis eficiente en termos de almacenamento e rendemento.
Isto é especialmente útil para consultas que len columnas específicas dunha táboa ampla (moitas columnas). Grazas ao formato de ficheiro, só se len as columnas necesarias, polo que a E/S é reducida ao mínimo.
Unha pequena digresión e explicación: Para comprender mellor o formato de ficheiro Parquet en Hadoop, vexamos que é un formato baseado en columnas, é dicir, en columnas. Este formato almacena valores similares para cada columna xuntos.
, o rexistro inclúe os campos ID, Nome e Departamento. Neste caso, todos os valores da columna ID almacenaranse xuntos, así como os valores da columna Nome, etc. A táboa terá un aspecto así:
ID
nome
departamento
1
emp1
d1
2
emp2
d2
3
emp3
d3
En formato de cadea, os datos gardaranse do seguinte xeito:
1
emp1
d1
2
emp2
d2
3
emp3
d3
Nun formato de ficheiro de columnas, os mesmos datos gardaranse así:
1
2
3
emp1
emp2
emp3
d1
d2
d3
O formato de columnas é máis eficiente cando precisa consultar varias columnas dunha táboa. Só lerá as columnas necesarias porque están adxacentes. Deste xeito, as operacións de E/S mantéñense ao mínimo.
Por exemplo, só precisa a columna NOME. EN Cada rexistro do conxunto de datos debe cargarse, analizarse por campo e, a continuación, extraer os datos de NOME. O formato de columna permítelle acceder directamente á columna Nome porque todos os valores desa columna almacénanse xuntos. Non tes que escanear toda a gravación.
Así, o formato columnar mellora o rendemento da consulta porque require menos tempo de busca para chegar ás columnas necesarias e reduce o número de operacións de E/S porque só se len as columnas desexadas.
Unha das características únicas é que neste formato pode almacenar datos con estruturas anidadas. Isto significa que nun ficheiro Parquet, mesmo os campos aniñados pódense ler individualmente sen ter que ler todos os campos da estrutura aniñada. Parquet usa un algoritmo de trituración e montaxe para almacenar estruturas aniñadas.
Para comprender o formato de ficheiro Parquet en Hadoop, cómpre coñecer os seguintes termos:
- Grupo de filas (grupo de filas): división horizontal lóxica dos datos en filas. Un grupo de filas consiste nun fragmento de cada columna do conxunto de datos.
- Fragmento de columna (anaco de columna): fragmento dunha columna específica. Estes fragmentos de columna viven nun grupo específico de filas e están garantidos para ser contiguos no ficheiro.
- Páx (páxina): os fragmentos de columna divídense en páxinas escritas unha tras outra. As páxinas teñen un título común, polo que podes saltar as innecesarias ao ler.
Aquí o título só contén o número máxico PAR1 (4 bytes) que identifica o ficheiro como un ficheiro Parquet.
O pé de páxina di o seguinte:
- Ficheiro de metadatos que contén as coordenadas iniciais dos metadatos de cada columna. Ao ler, primeiro debes ler os metadatos do ficheiro para atopar todos os fragmentos de columna de interese. As partes das columnas deberían lerse de forma secuencial. Outros metadatos inclúen a versión do formato, o esquema e calquera outro par clave-valor.
- Lonxitude de metadatos (4 bytes).
- Número máxico PAR1 (4 bytes).
Formato de ficheiro ORC
Formato de ficheiro fila-columna optimizado (Columna de fila optimizada, ) ofrece unha forma moi eficiente de almacenar datos e foi deseñado para superar as limitacións doutros formatos. Almacena os datos nunha forma perfectamente compacta, o que lle permite omitir detalles innecesarios, sen necesidade de construír índices grandes, complexos ou mantidos manualmente.
Vantaxes do formato ORC:
- Un ficheiro é a saída de cada tarefa, o que reduce a carga no NameNode (nodo do nome).
- Compatibilidade con tipos de datos Hive, incluídos os tipos de datos DateTime, decimais e complexos (estrutura, lista, mapa e unión).
- Lectura simultánea dun mesmo ficheiro por diferentes procesos de RecordReader.
- Capacidade de dividir ficheiros sen buscar marcadores.
- Estimación da máxima asignación de memoria de pila posible para os procesos de lectura/escritura baseada na información do pé de ficheiro.
- Os metadatos almacénanse no formato de serialización binaria Protocol Buffers, que permite engadir e eliminar campos.
ORC almacena coleccións de cadeas nun único ficheiro e, dentro da colección, os datos das cadeas gárdanse nun formato columnar.
Un ficheiro ORC almacena grupos de liñas chamadas franxas e información de apoio no pé de páxina do ficheiro. O Postscript ao final do ficheiro contén parámetros de compresión e o tamaño do pé de páxina comprimido.
O tamaño de banda predeterminado é de 250 MB. Debido a franxas tan grandes, a lectura de HDFS realízase de forma máis eficiente: en grandes bloques contiguos.
O pé do ficheiro rexistra a lista de carrís do ficheiro, o número de filas por carril e o tipo de datos de cada columna. Tamén se escribe alí o valor resultante de count, min, max e sum para cada columna.
O pé da tira contén un directorio de localizacións de fluxos.
Os datos de fila úsanse ao escanear táboas.
Os datos do índice inclúen os valores mínimos e máximos de cada columna e a posición das filas en cada columna. Os índices ORC só se utilizan para seleccionar franxas e grupos de filas, non para responder consultas.
Comparación de diferentes formatos de ficheiros
Avro en comparación co parquet
- Avro é un formato de almacenamento de filas, mentres que Parquet almacena os datos en columnas.
- Parquet é máis axeitado para consultas analíticas, o que significa que as operacións de lectura e consulta de datos son moito máis eficientes que as escrituras.
- As operacións de escritura en Avro realízanse de forma máis eficiente que en Parquet.
- Avro trata a evolución dos circuítos de forma máis madura. Parquet só admite a adición de esquemas, mentres que Avro admite a evolución multifuncional, é dicir, engadir ou cambiar columnas.
- Parquet é ideal para consultar un subconxunto de columnas nunha táboa de varias columnas. Avro é axeitado para operacións ETL nas que consultamos todas as columnas.
ORC vs Parquet
- Parquet almacena mellor os datos anidados.
- ORC é máis adecuado para o pushdown de predicados.
- ORC admite propiedades ACID.
- ORC comprime mellor os datos.
Que máis ler sobre o tema:
- .
- .
- .
Fonte: www.habr.com