Características de Apache Parquet son :

  • Auto-descripción
  • Columnas formato
  • Independiente del lenguaje

En comparación a los Avro, en la Secuencia de Archivos, Archivo RC etc. Quiero un resumen de los formatos. Ya he leído : Cómo Impala Trabaja con los Formatos de Archivo de Hadoop , da algunas ideas sobre los formatos, pero me gustaría saber cómo tener acceso a los datos y aplicaciones; el almacenamiento de datos se realiza en cada uno de estos formatos. Cómo parquet tiene una ventaja sobre los demás?

  • Un buen resumen puede encontrarse en esta presentación: enlace
  • El enlace está muerto.
  • actualizado.
InformationsquelleAutor Ani Menon | 2016-04-24

3 Comentarios

  1. 224

    Creo que la principal diferencia que puedo describir se refiere a grabar orientada al frente de la columna de formatos orientados. Registro de formatos orientados son lo que todos estamos acostumbrados a — archivos de texto delimitado formatos como CSV, TSV. AVRO es ligeramente más frescas que las de porque puede cambiar de esquema a lo largo del tiempo, por ejemplo, agregar o quitar columnas de un registro. Otros trucos de varios formatos (incluyendo especialmente las de compresión) implican que un formato puede ser dividido, es decir, se puede leer un bloque de registros desde cualquier lugar en el conjunto de datos y aún así saber que su esquema? Pero aquí hay más detalles sobre columnas de formatos como de Parquet.

    De Parquet, y otros formatos de columnas de manejar un común Hadoop situación de manera muy eficiente. Es común tener tablas (conjuntos de datos), teniendo muchas más columnas de las que cabría esperar en un buen diseño de base de datos relacional — cien o doscientas columnas no es inusual. Esto es así, ya que a menudo el uso de Hadoop como un lugar para denormalize de datos relacional de formatos, sí, usted recibe un montón de valores repetidos y muchas tablas, todos acoplan en una sola. Pero se hace mucho más fácil la consulta ya que todas las combinaciones que se trabajó. Hay otras ventajas tales como la retención de estado en el tiempo de los datos. Así que de todos modos es común tener una gran cantidad de columnas de una tabla.

    Digamos que hay 132 columnas, y algunos de ellos son realmente los campos de texto largo, cada una diferente de la columna uno detrás de otro y el uso de hasta quizás 10K por cada registro.

    Al consultar estas tablas es fácil con SQL punto de vista, es común que usted desea obtener un rango de registros basados en sólo unos pocos de los cientos de-más columnas. Por ejemplo, usted puede desear que todos los registros en febrero y Marzo para los clientes con ventas > $500.

    Para hacer esto en un formato de fila de la consulta sería necesario analizar todos los registros del conjunto de datos. Leer la primera fila, analizar el registro en los campos (columnas) y obtener la fecha y la venta de las columnas, incluir en sus resultados, si se cumple la condición. Repita. Si usted tiene 10 años (120 meses) de la historia, está la lectura de cada registro que se acaba de encontrar a 2 de esos meses. Por supuesto, esta es una gran oportunidad para utilizar una partición en el año y el mes, pero aún así, estás de lectura y análisis de 10K de cada registro o fila para esos dos meses para determinar si las ventas a clientes son > $500.

    En un formato columnar, cada columna (campo) de un registro que se almacena con otros de su especie, todos repartidos en muchos de los diferentes bloques en el disco — columnas para el año juntos, columnas para el mes juntos, columnas para el cliente manual del empleado (o a otro tipo de texto), y todos los demás que hacen esos registros tan enorme en su propio lugar separado en el disco, y por supuesto las columnas para las ventas en conjunto. Así diablos, fecha y meses son números, y también lo son las ventas, son sólo unos pocos bytes. ¿No sería genial si sólo teníamos que leer un par de bytes para cada registro para determinar qué registros coincidentes nuestra consulta? Columnas de almacenamiento para el rescate!

    Incluso sin particiones, la exploración de las pequeñas campos necesarios para satisfacer nuestra consulta es super-rápido-todos ellos están en el orden de su registro, y todas del mismo tamaño, por lo que el disco trata sobre mucho menos la comprobación de datos para incluyeron registros. No hay necesidad de leer a través de ese manual del empleado y otros campos de texto largo — simplemente los ignoran. Así, mediante la agrupación de columnas con cada uno de los otros, en lugar de filas, casi siempre se puede escanear menos datos. Ganar!

    Pero espere, se pone mejor. Si su consulta no sólo es necesario conocer los valores y unos pocos más (digamos 10 de 132 columnas) y no me importaba lo que el manual del empleado de la columna, una vez que se había recogido el derecho de los registros para volver, ahora sólo tienes que ir a las 10 columnas que se necesitan para procesar los resultados, ignorando a las demás 122 de 132 en nuestra base de datos. De nuevo, nos saltamos un montón de lectura.

    (Nota: por esta razón, columnas formatos son una pésima elección cuando se hace directamente de las transformaciones, por ejemplo, si va a unir dos tablas en una grande(ger) conjunto de resultados que vas a guardar como una nueva tabla, las fuentes que se van a obtener escaneado completamente de todos modos, así que no hay mucho beneficio en el rendimiento de la lectura, y porque columnar formatos necesidad de recordar más acerca de la donde la materia es, que utiliza más memoria que una similar formato de fila).

    Un beneficio más de las columnas: los datos se extiende a su alrededor. Para obtener un único registro, no se puede tener 132 trabajadores de cada lectura (y escritura) los datos desde/a 132 diferentes lugares en 132 bloques de datos. Yay para la paralelización!

    Y ahora para la cubierta: algoritmos de compresión funcionan mucho mejor cuando se pueden encontrar patrones que se repiten. Usted puede comprimir AABBBBBBCCCCCCCCCCCCCCCC como 2A6B16C pero ABCABCBCBCBCCCCCCCCCCCCCC no se como pequeños (bueno, en realidad, en este caso sería, pero confía en mí 🙂 ). Así que, otra vez, menos la lectura. Y la escritura.

    Lo leemos mucho menos datos para dar respuesta a las consultas más comunes, es potencialmente más rápido a leer y escribir en paralelo, y la compresión tiende a funcionar mucho mejor.

    Columnar es grande cuando su entrada es grande, y su salida es un subconjunto filtrado: de lo grande a lo pequeño es grande. No es tan beneficiosa cuando la entrada y las salidas son de aproximadamente la misma.

    Pero en nuestro caso, Impala tomó nuestro viejo consultas de Hive que corrió en 5, 10, 20 o 30 minutos, y terminó más en unos pocos segundos o un minuto.

    Espero que esto ayude a responder, al menos, parte de su pregunta!

    • Excelente. Gracias. Es un resumen muy valioso que la falta de muchos de apache proyecto docs.. Que mencionas: «campos pequeños … todos están en el orden de su registro». Supongamos que tengo una tabla simple de id de usuario:tiempo y la edad:int, y quiero encontrar a todos los usuarios entre algunos de la edad. Aquí tengo dos columnas. Qué necesito para especificar cuándo es el índice para el ordenamiento, o son TODAS las columnas de manera eficiente intercambiables?
    • Uno de los mejores que he leído hasta ahora. Gracias Tom !!!
    • Lo que si puedo usar parquet para un unicc? Varias columnas (100+), cada columna de un sensor de datos con diferente frecuencia (100 hz a 0,25 hz). Sería una decisión inteligente?
  2. 37

    Avro es una basada en la fila del formato de almacenamiento para Hadoop.

    Parquet es una columna basada en el formato de almacenamiento para Hadoop.

    Si el caso de uso, normalmente se escanea o se recupera todos los campos en una fila en cada consulta, Avro es generalmente la mejor opción.

    Si el conjunto de datos tiene muchas columnas, y el caso de uso, normalmente implica trabajar con un subconjunto de las columnas en lugar de registros completos, Parquet está optimizado para ese tipo de trabajo.

    Fuente

  3. 18

    De Tom respuesta es bastante detallada y exhaustiva, pero usted también podría estar interesado en este sencillo estudio acerca de Parquet vs Avro hecho en Allstate Insurance, se resumen aquí:

    «En general, Parquet demostraron resultados similares o mejores en cada prueba [de Avro]. La consulta de las diferencias de rendimiento en los conjuntos de datos más grandes de Parquet, a favor son, en parte debido a la compresión de los resultados; cuando se consulta el amplio conjunto de datos, la Chispa tenía que leer 3.5 x menos datos para Parquet de Avro. Avro no funcionan bien al procesar el conjunto de datos completo, como se sospecha.»

Dejar respuesta

Please enter your comment!
Please enter your name here