Parquet vs ORC vs ORC con Snappy

87

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!

hadoop  hive  parquet  snappy  orc 
— Rahul
fuente
1
¿Podría compartir un algoritmo genérico utilizado para hacer ese experimento? Sin embargo, es necesario utilizar los mismos datos. Pero compartir todo lo demás para lograr los mismos resultados con diferentes conjuntos de datos puede ser muy útil para darle una mejor respuesta o para demostrar que tiene un muy buen punto y cambiar el mundo para siempre.
— Mestre San
¿Tienes algún resultado de spark vs tez usando orc vs parquet? por lo que he visto, parece que tez es más rápido (3 veces más rápido) cuando se usa el formato orc.
— David H
+1 por su agradable descripción general de la evaluación comparativa. De todos modos, ¿existe la posibilidad de que pueda proporcionar una versión actualizada ya que algunos aspectos técnicos detrás de escena han cambiado (por ejemplo, como se discutió en la respuesta de @jonathanChap)?
— Markus

Respuestas:

52

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

— PhanThomas
fuente
2
Tabla A - Formato de archivo de texto - Sin compresión ......... Tabla B - Formato de archivo ORC con compresión ZLIB ......... Tabla C - ORC con Snappy ....... Tabla D - Parquet con Snappy ..... Trabajé en otra tabla con ~ 150 columnas y ~ 160 GB de tamaño para comprobar cómo funcionan los formatos de archivo allí. Parquet tomó 35 GB para almacenar esos datos de 160 GB mientras que ORC con snappy tomó 39 GB ... La compresión se veía mucho mejor para Parquet en comparación con la prueba publicada en cuestión, pero el rendimiento volvió a ser similar ... ORC brilló aquí con incluso mejor rendimiento que la combinación ORC + SNAPPY.
— Rahul
1
La estructura de datos para mis casos de uso fue más plana sin ningún anidamiento. Estoy de acuerdo con su comentario de indexación sobre Parquet vs ORC y eso realmente marca la diferencia. ¿Tiene algún resultado para compartir de la comparación de rendimiento de ambos? Eso podría ayudar a calmar mi conciencia de que estoy implementando los formatos correctamente. :)
— Rahul
Nunca probé mi conjunto de datos en Parquet porque el índice era un requisito necesario y también tenemos una estructura de datos plana sin información anidada. Lo que descubrí es que, dependiendo de dónde almacene sus archivos, necesita una banda y un tamaño de archivo diferentes para obtener los mejores resultados. Cuando almacena sus archivos de forma permanente en HDFS, es mejor tener archivos y bandas más grandes. "set mapred.max.split.size = 4096000000" fue el parámetro que usé para influir en el tamaño del archivo y dejé el tamaño de la franja a su valor predeterminado. Con esta configuración, me dio un 94% de aumento de consulta y compresión.
— PhanThomas
Si desea almacenar sus archivos en Amazon S3 como almacenamiento en frío, un archivo mucho más pequeño y un tamaño de banda me dieron resultados mucho mejores. Usé archivos del tamaño de 40-60 MB que contienen una sola banda.
— PhanThomas
44

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)

— JonathanChap
fuente
18
A partir de 2.3.0, la chispa no tiene un lector de ORC vectorizado: issues.apache.org/jira/browse/SPARK-16060
— Steen
6
Hive 2.3.0 ha vectorizado el lector de parquet - issues.apache.org/jira/browse/HIVE-14815
— ruhong
Desde Spark 2.3, Spark admite un lector ORC vectorizado spark.apache.org/docs/latest/sql-data-sources-orc.html
— Anurag Sharma
10

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í.

— james.bondu
fuente
6

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

— Owen O'Malley
fuente
5
Esto es realmente útil, pero debería haber un descargo de responsabilidad de que @Owen trabaja para Horton Works, que originalmente desarrolló el formato de archivo ORC
— Daniel Kats
1
¡Gracias! Pero el segundo eslabón está roto. ¿Puedes arreglarlo o eliminarlo de tu respuesta?
— Danilo Gomes
3

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

— Hasan Ammori
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.