hadoop - textuales - tipos de formatos de texto y sus caracteristicas

¿Por qué el parquet es más lento para mí que el formato de archivo de texto en la colmena?

Question

¡DE ACUERDO! Así que decidí usar Parquet como formato de almacenamiento para las tablas de colmenas y, antes de implementarlo en mi clúster, decidí ejecutar algunas pruebas. Sorprendentemente, Parquet fue más lento en mis pruebas en comparación con la idea general de que es más rápido que los archivos de texto sin formato.

Tenga en cuenta que estoy usando Hive-0.13 en MapR

Sigue el flujo de mis operaciones

Tabla A

Formato - Formato de texto

Tamaño de la mesa: 2.5 Gb

Tabla B

Formato - Parquet

Tamaño de la mesa: 1.9 Gb

[Crear tabla B almacenada como parquet como seleccionar * de A]

Tabla C

Formato - Parquet con compresión rápida

Tamaño de la mesa: 1.9 Gb

[Crear tabla C almacenada como parquet tblproperties ("parquet.compression" = "SNAPPY") como seleccionar * de A]

Ahora realicé algunas pruebas en las tablas mencionadas anteriormente y sigo los detalles.

• Operación de conteo de filas

Tabla A

Mapa - 15

Reducir - 1

CPU acumulada: 123,33 seg

Tiempo de espera: 59.057 segundos

Tabla B

Mapa - 8

Reducir - 1

CPU acumulada: 204.92 segundos

Tiempo necesario: 50.33 segundos

• Selección de una sola fila

Tabla A

Mapa - 15

Reducir - 0

CPU acumulada: 51.18 seg

Tiempo de espera: 25.296 segundos

Tabla B

Mapa - 8

Reducir - 0

CPU acumulada: 117,08 seg

Tiempo necesario - 27.448 segundos

• Selección de múltiples filas usando la cláusula Where [1000 filas recuperadas]

Tabla A

Mapa - 15

Reducir - 0

CPU acumulada - 57.55 segundos

Tiempo necesario: 20.254 segundos

Tabla B

Mapa - 8

Reducir - 0

CPU acumulada: 113,97 segundos

Tiempo necesario: 27.678 segundos

• Selección de múltiples filas [con solo 4 columnas] Uso de la cláusula Where [1000 filas recuperadas]

Tabla A

Mapa - 15

Reducir - 0

CPU acumulada - 57.55 segundos

Tiempo necesario: 20.254 segundos

Tabla B

Mapa - 8

Reducir - 0

CPU acumulada: 113,97 segundos

Tiempo necesario: 27.678 segundos

• Operación de agregación [Usar la función de suma en una columna dada]

Tabla A

Mapa - 15

Reducir - 1

CPU acumulada: 127,85 segundos

Tiempo de espera: 29.68 segundos

Tabla B

Mapa - 8

Reducir - 1

CPU acumulada: 255.2 segundos

Tiempo de toma - 41.025 segundos

Puede ver que en casi todas las operaciones que he aplicado en ambas tablas, Parquet se está quedando atrás en términos de tiempo necesario para ejecutar la consulta con la excepción de la operación de recuento de filas.

También utilicé la tabla C para realizar las operaciones antes mencionadas, pero los resultados fueron casi en líneas similares, y el formato TextFile nuevamente fue más ágil de los dos.

¿Puede alguien por favor decirme qué estoy haciendo mal?

¡Gracias!

EDITAR

Agregué ORC a la lista de formatos de almacenamiento y volví a ejecutar las pruebas. Sigue los detalles

Operación de conteo de filas

CPU acumulada de formato de texto: 123,33 seg

CPU acumulativa del formato del parquet - 204.92 sec

CPU acumulada de formato ORC: 119,99 segundos

ORC con CPU acumulativa SNAPPY: 107,0 segundos

Suma de una operación de columna

CPU acumulativa de formato de texto: 127,85 segundos

CPU acumulativa del formato del parquet - 255.2 sec

CPU acumulada de formato ORC: 120,48 segundos

ORC con SNAPPY CPU acumulativa - 98.27 sec

Promedio de una operación de columna

Formato de texto CPU acumulativa - 128.79 seg

CPU acumulativa del formato del parquet - 211.73 sec

CPU acumulada de formato ORC: 165.5 segundos

ORC con CPU acumulativa SNAPPY: 135,45 segundos

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

Formato de texto CPU acumulativa: 72,48 segundos

CPU acumulativa del formato del parquet - 136.4 sec

CPU acumulada de formato ORC: 96.63 segundos

ORC con SNAPPY CPU acumulativa - 82.05 segundos

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

¡Gracias!