Creo que la principal diferencia que puedo describir se relaciona con los formatos orientados a registros frente a los orientados a columnas. Estamos acostumbrados a formatos orientados a registros: archivos de texto, formatos delimitados como CSV, TSV. AVRO es un poco más frío que esos porque puede cambiar el esquema con el tiempo, por ejemplo, agregar o eliminar columnas de un registro. Otros trucos de varios formatos (especialmente la compresión) implican si un formato se puede dividir, es decir, ¿puede leer un bloque de registros desde cualquier parte del conjunto de datos y aún así saber que es un esquema? Pero aquí hay más detalles sobre formatos de columnas como Parquet.
El parquet y otros formatos de columnas manejan una situación común de Hadoop de manera muy eficiente. Es común tener tablas (conjuntos de datos) que tengan muchas más columnas de las que cabría esperar en una base de datos relacional bien diseñada; cien o doscientas columnas no son inusuales. Esto es así porque a menudo usamos Hadoop como un lugar para desnormalizar datos de formatos relacionales: sí, obtienes muchos valores repetidos y muchas tablas aplanadas en una sola. Pero se vuelve mucho más fácil consultar ya que todas las uniones están resueltas. Hay otras ventajas, como la retención de datos del estado en el tiempo. De todos modos, es común tener un montón de columnas en una tabla.
Digamos que hay 132 columnas, y algunas de ellas son campos de texto realmente largos, cada columna diferente una detrás de la otra y usan quizás 10K por registro.
Si bien consultar estas tablas es fácil con el punto de vista SQL, es común que desee obtener un rango de registros basado en solo unas pocas de esas más de cien columnas. Por ejemplo, es posible que desee todos los registros en febrero y marzo para clientes con ventas> $ 500.
Para hacer esto en un formato de fila, la consulta necesitaría escanear cada registro del conjunto de datos. Lea la primera fila, analice el registro en campos (columnas) y obtenga las columnas de fecha y ventas, inclúyalo en su resultado si cumple la condición. Repetir. Si tiene 10 años (120 meses) de historia, está leyendo cada registro solo para encontrar 2 de esos meses. Por supuesto, esta es una gran oportunidad para usar una partición en año y mes, pero aun así, está leyendo y analizando 10K de cada registro / fila durante esos dos meses solo para averiguar si las ventas del cliente son> $ 500.
En un formato de columnas, cada columna (campo) de un registro se almacena con otras de su tipo, distribuidas en muchos bloques diferentes en el disco: columnas para un año, columnas para un mes, columnas para el manual del empleado del cliente (u otro texto largo), y todos los demás que hacen que esos registros sean tan grandes, todo en su propio lugar separado en el disco y, por supuesto, las columnas para ventas juntas. Bueno, la fecha y los meses son números, y también lo son las ventas, son solo unos pocos bytes. ¿No sería genial si solo tuviéramos que leer unos pocos bytes para cada registro para determinar qué registros coincidían con nuestra consulta? Almacenamiento en columnas al rescate!
Incluso sin particiones, el escaneo de los pequeños campos necesarios para satisfacer nuestra consulta es súper rápido: todos están ordenados por registro y tienen el mismo tamaño, por lo que el disco busca mucho menos verificación de datos para los registros incluidos. No es necesario leer el manual del empleado y otros campos de texto largos, simplemente ignórelos. Entonces, al agrupar columnas entre sí, en lugar de filas, casi siempre puede escanear menos datos. ¡Ganar!
Pero espera, se pone mejor. Si su consulta solo necesitara conocer esos valores y algunos más (digamos 10 de las 132 columnas) y no le importara la columna del manual del empleado, una vez que haya elegido los registros correctos para regresar, ahora solo tendría que ir volviendo a las 10 columnas que necesitaba para representar los resultados, ignorando los otros 122 de los 132 en nuestro conjunto de datos. Nuevamente, nos saltamos mucha lectura.
(Nota: por esta razón, los formatos de columnas son una pésima opción al hacer transformaciones rectas, por ejemplo, si está uniendo todas las dos tablas en un conjunto de resultados grande (ger) que está guardando como una nueva tabla, las fuentes de todos modos, se escanearán por completo, por lo que no hay muchos beneficios en el rendimiento de lectura, y debido a que los formatos de columnas deben recordar más sobre dónde están las cosas, usan más memoria que un formato de fila similar).
Un beneficio más de columnar: los datos se distribuyen. Para obtener un solo registro, puede hacer que 132 trabajadores lean (y escriban) datos de / a 132 lugares diferentes en 132 bloques de datos. ¡Yay para la paralelización!
Y ahora para el factor decisivo: los algoritmos de compresión funcionan mucho mejor cuando pueden encontrar patrones repetitivos. Se podría comprimir AABBBBBBCCCCCCCCCCCCCCCCcomo 2A6B16C, pero ABCABCBCBCBCCCCCCCCCCCCCCno conseguiría tan pequeño (bueno, en realidad, en este caso se haría, pero confía en mí :-)). Así que una vez más, menos lectura. Y escribiendo también.
Entonces leemos muchos menos datos para responder consultas comunes, es potencialmente más rápido leer y escribir en paralelo, y la compresión tiende a funcionar mucho mejor.
Columnar es excelente cuando su lado de entrada es grande y su salida es un subconjunto filtrado: de grande a pequeño es excelente. No es tan beneficioso cuando la entrada y las salidas son casi iguales.
Pero en nuestro caso, Impala tomó nuestras viejas consultas de Hive que se ejecutaron en 5, 10, 20 o 30 minutos, y terminaron la mayoría en unos segundos o un minuto.
Espero que esto ayude a responder al menos parte de su pregunta.