Parquet vs ORC vs ORC con Snappy

Estoy realizando 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 afirman 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 recuento 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 pueda hacer para que funcione mejor con el tiempo de respuesta de la consulta y la relación de compresión?

¡Gracias!

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

Parquet podría ser mejor si tiene datos muy 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 es plana.

Y que yo sepa, el parquet todavía no es compatible con los índices. ORC viene con un índice de peso ligero y, desde Hive 0.14, un filtro Bloom adicional que podría ser útil para mejorar el 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

Estás viendo esto porque:

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

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

• Spark funciona mejor con parquet, Hive 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)

Tanto Parquet como ORC tienen sus propias ventajas y desventajas. Pero simplemente trato de seguir una regla simple: "¿Qué tan anidados están sus datos y cuántas columnas hay?" . Si sigues la Dremel de Google podrás descubrir cómo se diseña el parquet. Usan una estructura jerárquica similar a un á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 plano. Entonces, si sus datos se aplanan con menos columnas, puede optar por ORC; de lo contrario, el parquet estaría bien para usted. La compresión de datos aplanados funciona asombrosamente en ORC.

Hicimos algunas evaluaciones comparativas con un archivo aplanado más grande, lo convertimos a Spark 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í.

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

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 larga ejecución, cuando Hive consulta tablas ORC GC se llama aproximadamente 10 veces menos frecuentemente . Puede que no sea nada para muchos proyectos, pero puede ser crucial para otros.

ORC también toma mucho menos tiempo, cuando necesita seleccionar solo algunas 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 a veces es 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 también. Afecta tanto a la compresión zlib como a la rápida