hadoop - Parquet vs ORC vs ORC con Snappy

hive

Question

Estoy ejecutando algunas pruebas en los formatos de almacenamiento disponibles con Hive y usando Parquet y ORC como opciones principales. Incluí ORC una vez con compresión predeterminada y una vez con Snappy.

He leído muchos documentos que indican que Parquet es mejor en complejidad de tiempo / espacio en comparación con ORC, pero mis pruebas son opuestas a los documentos que revisé.

Sigue algunos detalles de mis datos.

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

El parquet fue peor en lo que respecta a la compresión de mi mesa.

Mis pruebas con las tablas anteriores arrojaron los siguientes resultados.

Operación de conteo de filas

Text Format Cumulative CPU - 123.33 sec

Parquet Format Cumulative CPU - 204.92 sec

ORC Format Cumulative CPU - 119.99 sec 

ORC with SNAPPY Cumulative CPU - 107.05 sec

Suma de una operación de columna

Text Format Cumulative CPU - 127.85 sec   

Parquet Format Cumulative CPU - 255.2 sec   

ORC Format Cumulative CPU - 120.48 sec   

ORC with SNAPPY Cumulative CPU - 98.27 sec

Promedio de una operación de columna

Text Format Cumulative CPU - 128.79 sec

Parquet Format Cumulative CPU - 211.73 sec    

ORC Format Cumulative CPU - 165.5 sec   

ORC with SNAPPY Cumulative CPU - 135.45 sec 

Seleccionar 4 columnas de un rango dado usando la cláusula where

Text Format Cumulative CPU -  72.48 sec 

Parquet Format Cumulative CPU - 136.4 sec       

ORC Format Cumulative CPU - 96.63 sec 

ORC with SNAPPY Cumulative CPU - 82.05 sec 

¿Eso significa que ORC es más rápido que Parquet? ¿O hay algo que puedo hacer para que funcione mejor con el tiempo de respuesta de consulta y la relación de compresión?

¡Gracias!

Answer 1

Ambos tienen sus ventajas. Usamos Parquet en el trabajo junto con Hive e Impala, pero solo queríamos señalar algunas ventajas de ORC sobre Parquet: durante consultas de ejecución prolongada, cuando Hive consulta las tablas de ORC GC se llama aproximadamente 10 veces con menos frecuencia . Puede que no sea nada para muchos proyectos, pero podría ser crucial para otros.

ORC también toma mucho menos tiempo, cuando necesita seleccionar solo unas pocas columnas de la tabla. Algunas otras consultas, especialmente con combinaciones, también toman menos tiempo debido a la ejecución de consultas vectorizadas, que no está disponible para Parquet

Además, la compresión ORC es a veces un poco aleatoria, mientras que la compresión Parquet es mucho más consistente. Parece que cuando la tabla ORC tiene muchas columnas numéricas, no se comprime tan bien. Afecta tanto a zlib como a la compresión rápida

Answer 2

Estás viendo esto porque:

• Hive tiene un lector ORC vectorizado pero no tiene un lector de parquet vectorizado.

• Spark tiene un lector de parquet vectorizado y no tiene un lector ORC vectorizado.

• Spark funciona mejor con parquet, colmena funciona mejor con ORC.

He visto diferencias similares al ejecutar ORC y Parquet con Spark.

La vectorización significa que las filas se decodifican en lotes, mejorando drásticamente la ubicación de la memoria y la utilización de la caché.

(correcto a partir de Hive 2.0 y Spark 2.1)

Answer 3

Hicimos algunos puntos de referencia comparando los diferentes formatos de archivo (Avro, JSON, ORC y Parquet) en diferentes casos de uso.

https://www.slideshare.net/oom65/file-format-benchmarks-avro-json-orc-parquet

Todos los datos están disponibles públicamente y el código de referencia es de código abierto en:

https://github.com/apache/orc/tree/branch-1.4/java/bench

Answer 4

Tanto Parquet como ORC tienen sus propias ventajas y desventajas. Pero simplemente trato de seguir una simple regla general: "Qué tan anidados están sus datos y cuántas columnas hay" . Si sigues el Google Dremel , puedes encontrar cómo está diseñado el parquet. Utilizan una estructura jerárquica en forma de árbol para almacenar datos. Más la anidación más profunda del árbol.

Pero ORC está diseñado para un almacén de archivos aplanado. Entonces, si sus datos se aplanan con menos columnas, puede usar ORC; de lo contrario, el parquet estaría bien para usted. La compresión en datos aplanados funciona increíblemente en ORC.

Hicimos algunas evaluaciones comparativas con un archivo plano más grande, lo convertimos en Dataframe y lo almacenamos en formato parquet y ORC en S3 y realizamos consultas con ** Redshift-Spectrum **.

Size of the file in parquet: ~7.5 GB and took 7 minutes to write
Size of the file in ORC: ~7.1. GB and took 6 minutes to write
Query seems faster in ORC files.

Pronto haremos una evaluación comparativa de los datos anidados y actualizaremos los resultados aquí.

Answer 5

Yo diría que ambos formatos tienen sus propias ventajas.

El parquet podría ser mejor si tiene datos altamente anidados, porque almacena sus elementos como un árbol como lo hace Google Dremel ( ver aquí ).
Apache ORC podría ser mejor si su estructura de archivos se aplana.

Y que yo sepa, el parquet todavía no es compatible con los índices. ORC viene con un índice liviano y, desde Hive 0.14, un filtro Bloom adicional que podría ser útil para un mejor tiempo de respuesta de la consulta, especialmente cuando se trata de operaciones de suma.

La compresión predeterminada de Parquet es SNAPPY. ¿Las tablas A - B - C y D tienen el mismo conjunto de datos? Si es así, parece que hay algo turbio al respecto, cuando solo se comprime a 1.9 GB