la cantidad de Datos Creciendo exponencialmente en los últimos años, uno de los mayores desafíos se ha convertido en la forma más óptima de almacenar varios sabores de datos. A diferencia del pasado (no hasta ahora), cuando las bases de datos relacionales se consideraban el único camino a seguir, las organizaciones ahora quieren realizar un análisis sobre datos sin procesar: piense en el análisis de sentimientos en las redes sociales, los archivos de audio/video, y así sucesivamente, que generalmente no podrían almacenarse de una manera tradicional (relacional) o que los almacenaría de una manera tradicional requeriría un esfuerzo y tiempo significativos, que aumentan el análisis de tiempo general.
Otro desafío era seguir de alguna manera un enfoque tradicional para que los datos se almacenen de manera estructurada, pero sin la necesidad de diseñar cargas de trabajo ETL complejas y que llevan mucho tiempo para mover estos datos al almacén de datos empresariales. Además, ¿qué pasa si la mitad de los profesionales de datos en su organización son competentes con, digamos, Python (científicos de datos, ingenieros de datos) y la otra mitad (ingenieros de datos, analistas de datos) con SQL? ¿Insistiría en que los “pitonistas” aprendan SQL? ¿O viceversa?
O, ¿preferiría una opción de almacenamiento que pueda jugar con las fortalezas de todo su equipo de datos? Tengo buenas noticias para ti, algo como esto ya ha existido desde 2013, y se llama Apache Parquet!
Formato de archivo parquet en pocas palabras
Antes de mostrarle los entresijos del formato de archivo Parquet, hay (al menos) cinco razones principales por las cuales Parquet se considera un estándar de facto para almacenar datos hoy en día:
- Compresión de datos – Al aplicar varios algoritmos de codificación y compresión, el archivo Parquet proporciona un consumo de memoria reducido
- Almacenamiento columnar – Esto es de suma importancia en las cargas de trabajo analíticas, donde la operación rápida de lectura de datos es el requisito clave. Pero, más sobre eso más adelante en el artículo …
- Lenguaje agnóstico – Como ya se mencionó anteriormente, los desarrolladores pueden usar diferentes lenguajes de programación para manipular los datos en el archivo de Parquet
- Formato de código abierto – Es decir, no estás bloqueado con un proveedor específico
- Soporte para tipos de datos complejos
Tienda de hileras vs columna-tienda
Ya hemos mencionado que Parquet es un formato de almacenamiento basado en columnas. Sin embargo, para comprender los beneficios de usar el formato de archivo Parquet, primero debemos dibujar la línea entre las formas basadas en filas y basadas en columnas de almacenar los datos.
En el almacenamiento tradicional basado en la fila, los datos se almacenan como una secuencia de filas. Algo como esto:
Ahora, cuando estamos hablando de Olap Escenarios, algunas de las preguntas comunes que pueden hacer sus usuarios son:
- ¿Cuántas bolas vendimos?
- ¿Cuántos usuarios de los EE. UU. Compraron una camiseta?
- ¿Cuál es la cantidad total gastada por el cliente Maria Adams?
- ¿Cuántas ventas tuvimos el 2 de enero?
Para poder responder cualquiera de estas preguntas, ¡el motor debe escanear todas y cada una de las filas desde el principio hasta el final! Entonces, para responder a la pregunta: cuántos usuarios de los EE. UU. Compraron una camiseta, el motor tiene que hacer algo como esto:
Esencialmente, solo necesitamos la información de dos columnas: producto (camisetas) y país (EE. UU.), ¡Pero el motor escaneará las cinco columnas! Esta no es la solución más eficiente, creo que podemos estar de acuerdo en eso …
Columna
Examinemos ahora cómo funciona la tienda de columnas. Como supondrá, el enfoque es de 180 grados diferentes:
En este caso, cada columna es una entidad separada, lo que significa que cada columna se separa físicamente de otras columnas! Volviendo a nuestra pregunta comercial anterior: el motor ahora puede escanear solo las columnas que necesitan la consulta (producto y país), mientras que escaneo de saltos Las columnas innecesarias. Y, en la mayoría de los casos, esto debería mejorar el rendimiento de las consultas analíticas.
Ok, eso es bueno, pero la tienda de columnas existía antes de Parquet y todavía existe fuera de Parquet también. Entonces, ¿qué tiene de especial el formato del parquet?
Parquet es un formato columnar que almacena los datos en los grupos de filas
Espera, ¿qué? ¿No fue lo suficientemente complicado incluso antes de esto? No te preocupes, es mucho más fácil de lo que parece 🙂
Volvamos a nuestro ejemplo anterior y representemos cómo Parquet almacenará esta misma parte de los datos:
Detengamos por un momento y expliquemos la ilustración anterior, ya que esta es exactamente la estructura del archivo parquet (algunas cosas adicionales se omitieron intencionalmente, pero pronto también lo explicaremos). Las columnas todavía se almacenan como unidades separadas, pero Parquet presenta estructuras adicionales, llamadas Row Group.
¿Por qué esta estructura adicional es súper importante?
Tendrás que esperar una respuesta por un momento :). En escenarios OLAP, nos preocupa principalmente dos conceptos: proyección y predicados (s). La proyección se refiere a un SELECCIONAR Declaración en el lenguaje SQL: qué columnas necesitan la consulta. Volviendo a nuestro ejemplo anterior, solo necesitamos las columnas del producto y el país, para que el motor pueda saltar escaneando los restantes.
Predicados (s) referirse a la DÓNDE Cláusula en el lenguaje SQL, que las filas satisfacen los criterios definidos en la consulta. En nuestro caso, estamos interesados solo en camisetas, por lo que el motor puede omitir completamente el grupo de filos de escaneo 2, ¡donde todos los valores en la columna del producto son igual a calcetines!
Vamos a detener rápidamente aquí, ya que quiero que se dé cuenta de la diferencia entre varios tipos de almacenamiento en términos del trabajo que debe realizar el motor:
- Almacén de filas: el motor necesita escanear las 5 columnas y las 6 filas
- Tienda de columnas: el motor necesita escanear 2 columnas y las 6 filas
- Almacén de columnas con grupos de fila: el motor necesita escanear 2 columnas y 4 filas
Obviamente, este es un ejemplo excesivamente simplificado, con solo 6 filas y 5 columnas, donde definitivamente no verá ninguna diferencia en el rendimiento entre estas tres opciones de almacenamiento. Sin embargo, en la vida real, cuando se trata de cantidades mucho mayores de datos, la diferencia se hace más evidente.
Ahora, la pregunta justa sería: ¿Cómo “sabe” Parquet qué grupo de filas saltar/escanear?
El archivo de parquet contiene metadatos
Esto significa que cada archivo de parquet contiene “datos sobre datos”, información como valores mínimos y máximos en una columna específica dentro de un determinado grupo de filas. Además, cada archivo de parquet contiene un pie de página, que mantiene la información sobre la versión de formato, la información del esquema, los metadatos de columna, etc. Puede encontrar más detalles sobre los tipos de metadatos de Parquet aquí.
Importante: Para optimizar el rendimiento y eliminar las estructuras de datos innecesarias (grupos de filas y columnas), el motor primero debe “familiarizarse” con los datos, por lo que primero lee los metadatos. No es una operación lenta, pero aún requiere una cierta cantidad de tiempo. Por lo tanto, si consulta los datos de múltiples archivos de parquet pequeños, el rendimiento de la consulta puede degradarse, porque el motor tendrá que leer metadatos de cada archivo. Por lo tanto, debería ser mejor fusionar múltiples archivos más pequeños en un archivo más grande (pero aún no demasiado grande 🙂 …
Te escucho, te escucho: Nikola, ¿qué es “pequeño” y qué es “grande”? Desafortunadamente, no hay un solo número “dorado” aquí, pero por ejemplo, Microsoft Azure Synapse Analytics recomienda que el archivo de parquet individual tenga al menos unos pocos cientos de MB de tamaño.
¿Qué más hay ahí?
Aquí hay una ilustración simplificada de alto nivel del formato de archivo Parquet:
¿Puede ser mejor que esto? Sí, con compresión de datos
Ok, hemos explicado cómo omitir el escaneo de las estructuras de datos innecesarias (grupos de filas y columnas) puede beneficiar sus consultas y aumentar el rendimiento general. Pero, no se trata solo de eso, recuerde cuando le dije desde el principio que una de las principales ventajas del formato del parquet es la huella de memoria reducida del archivo. Esto se logra aplicando varios algoritmos de compresión.
Ya he escrito sobre varios tipos de compresión de datos en Power BI (y el modelo tabular en general) aquíentonces, tal vez sea una buena idea comenzar leyendo este artículo.
Hay dos tipos de codificación principales que permiten a Parquet comprimir los datos y lograr ahorros sorprendentes en el espacio:
- Codificación de diccionario – Parquet crea un diccionario de los valores distintos en la columna, y luego reemplaza los valores “reales” con valores de índice del diccionario. Volviendo a nuestro ejemplo, este proceso se parece a esto:
Puede pensar: ¿Por qué esta sobrecarga, cuando los nombres de productos son bastante cortos, ¿verdad? Ok, pero ahora imagine que almacena la descripción detallada del producto, como: “Camiseta de brazo largo con aplicación en el cuello”. E, ahora imagine que tiene este producto vendido millones de veces … sí, en lugar de tener un millón de veces repetir el valor “brazo largo … bla bla”, el parquet almacenará solo el valor del índice (entero en lugar de texto).
¿Puede ser mejor que esto? Sí, con el formato de archivo del lago Delta
Ok, ¿qué diablos es ahora un formato del lago Delta? Este es el artículo sobre Parquet, ¿verdad?
Entonces, para ponerlo en inglés simple: Delta Lake no es más que el formato de parquet “sobre esteroides”. Cuando digo “esteroides”, el principal es el verso de los archivos de Parquet. También almacena un registro de transacciones para habilitar el seguimiento de todos los cambios aplicados al archivo Parquet. Esto también se conoce como Transacciones que cumplen con el ácido.
Dado que admite no solo transacciones ácidas, sino que también admite declaraciones de viaje en el tiempo (reversiones, senderos de auditoría, etc.) y DML (lenguaje de manipulación de datos), como insertar, actualizar y eliminar, no se equivocará si piensa en el lago Delta como un “almacén de datos en el lago de datos” (quién dijo: Lakehouse😉😉😉). Examinar los pros y los contras del concepto de Lakehouse está fuera del alcance de este artículo, pero si tiene curiosidad por profundizar en esto, le sugiero que lea Este artículo de Databricks.
Conclusión
¡Evolucionamos! Igual que nosotros, los datos también están evolucionando. Por lo tanto, los nuevos sabores de datos requerían nuevas formas de almacenarlo. El formato de archivo Parquet es una de las opciones de almacenamiento más eficientes en el panorama de datos actual, ya que proporciona múltiples beneficios, tanto en términos de consumo de memoria, al aprovechar varios algoritmos de compresión y un procesamiento rápido de consultas al permitir que el motor saltee escaneo de datos innecesarios.
¡Gracias por leer!