¿Qué es Parquet? Almacenamiento en columnas, esquema y casos de uso

La API de raspado sin desperdicio devuelve datos web estructurados en JSON o CSV que las canalizaciones de análisis pueden validar y convertir en Apache Parquet para consultas repetidas orientadas a columnas.

¿Qué es Apache Parquet?

Apache Parquet es un formato de archivo de datos de código abierto, orientado a columnas, para almacenamiento y recuperación eficientes. En lugar de escribir cada campo de un registro juntos, Parquet organiza los valores por columna dentro de grupos de filas limitados. Los motores analíticos pueden leer solo las columnas necesarias para una consulta en lugar de escanear cada campo en cada registro.

El documentación de Apache Parquet enlaza la especificación del formato, conceptos, detalles del formato de archivo y recursos de implementación. El formato es compatible con motores y lenguajes de procesamiento de datos, lo que lo convierte en un límite de almacenamiento común para lagos de datos, almacenes, canalizaciones de características y conjuntos de datos analíticos archivados.

Parquet es binario. No está destinado a ser abierto y editado en un editor de texto. Una biblioteca de lectura utiliza metadatos almacenados en el archivo para localizar fragmentos de columna, decodificar páginas, aplicar códecs de compresión y reconstruir filas o vectores de columnas.

Por qué importa el almacenamiento en columnas

Considera un conjunto de datos con ID de cliente, país, categoría, descripción, precio y tiempo de evento. Una consulta que calcula el precio promedio por país necesita solo tres columnas. En un archivo de texto orientado a filas, el motor aún lee a través de descripciones y otros campos no utilizados. En Parquet, el motor puede seleccionar los fragmentos de columna necesarios.

Los valores de columna también tienden a parecerse a sus vecinos. Una columna de países puede repetir un pequeño conjunto de códigos, una columna booleana tiene una baja cardinalidad, y las marcas de tiempo ordenadas pueden tener pequeñas diferencias. Las codificaciones y compresión pueden aprovechar esos patrones de manera más efectiva que un diseño donde los tipos de campo no relacionados alternan en cada fila.

El almacenamiento en columnas no hace que cada operación sea más rápida. Reconstruir un registro individual completo puede tocar muchos fragmentos de columna. Actualizar un registro suele significar reescribir datos del archivo en lugar de cambiar una línea en su lugar. Parquet favorece escaneos, agregaciones, filtrado y proyecciones selectivas sobre actualizaciones de filas transaccionales.

Cómo se organiza un archivo Parquet

Un archivo Parquet contiene metadatos y datos codificados organizados a través de varias capas:

• Metadatos del archivo. El pie de página registra el esquema, grupos de filas, ubicaciones de columnas, codificaciones, información de compresión y metadatos clave-valor opcionales.
• Grupos de filas. Un grupo de filas es una partición horizontal de filas. Cada columna en ese rango de filas se almacena como un fragmento de columna.
• Fragmentos de columna. Un fragmento contiene los valores de una columna dentro de un grupo de filas y se divide en páginas.
• Páginas. Las páginas son la unidad donde se aplican y leen codificaciones, compresión y algunas estadísticas.
• Pie de página. Los metadatos al final del archivo permiten a un lector descubrir el diseño antes de seleccionar qué rangos de datos obtener.

Las estructuras detalladas y codificaciones viven en el repositorio de especificación del formato Apache Parquet. Las implementaciones pueden soportar diferentes subconjuntos o características opcionales, por lo que una canalización debería probar la compatibilidad entre sus escritores y lectores.

Tipos físicos y lógicos

Parquet define tipos físicos que controlan el almacenamiento de bajo nivel, incluidos enteros, valores de punto flotante, arreglos de bytes y arreglos de bytes de longitud fija. Las anotaciones de tipo lógico añaden significado de dominio como cadena, decimal, fecha, hora, marca de tiempo, UUID, lista, mapa y anchos enteros.

Un valor decimal ilustra por qué la distinción es importante. Sus bytes físicos pueden almacenarse como un entero o arreglo de bytes, mientras que la anotación lógica suministra precisión y escala. Los lectores necesitan ambas capas para reconstruir el valor previsto correctamente.

El diseño del esquema debe preservar la semántica empresarial. Las marcas de tiempo necesitan una interpretación de zona horaria documentada. La precisión decimal debe cubrir los valores esperados. Los identificadores que parecen numéricos pueden pertenecer a un tipo de cadena. Un escritor no debe inferir un tipo estrecho de una pequeña muestra si los archivos posteriores pueden contener valores más grandes.

Datos anidados en Parquet

Parquet puede representar registros anidados, listas y mapas en lugar de forzar cada conjunto de datos en una tabla plana. Utiliza niveles de definición y repetición para codificar si los campos anidados están presentes y dónde pertenecen los valores repetidos en la estructura reconstruida.

Esta capacidad hace que Parquet sea un destino natural para registros JSON validados que contienen arreglos u objetos hijos. La conversión aún necesita un esquema estable. Si un registro almacena un campo como una cadena y otro almacena un objeto bajo el mismo nombre, el escritor debe resolver ese conflicto antes de producir un conjunto de datos confiable.

Las columnas anidadas pueden reducir los datos de padre repetidos en comparación con aplanar cada hijo en una fila. También pueden complicar consultas e interoperabilidad cuando los motores exponen estructuras anidadas de manera diferente. Prueba las formas exactas de lista y mapa utilizadas por la canalización.

Parquet vs CSV y JSON

Compresión, codificación y estadísticas

Parquet separa la codificación de la compresión. La codificación representa valores de manera eficiente antes de que un códec de compresión procese los bytes de la página. Las implementaciones pueden elegir codificación por diccionario, técnicas de longitud de ejecución, empacar bits, codificaciones delta o representación simple según el tipo y los datos.

Las estadísticas de metadatos pueden incluir valores mínimos y máximos, conteos nulos y otros índices. Un motor de consultas puede utilizarlos para omitir un grupo de filas cuyo rango de valores no puede satisfacer un filtro. Esto es empuje de predicados o poda en la capa de almacenamiento. Reduce el I/O cuando la organización de datos y las estadísticas se alinean con los predicados de consulta.

Las estadísticas no son un sustituto del control de acceso y pueden revelar rangos de valores o conteos a cualquiera que pueda leer los metadatos del archivo. Los conjuntos de datos sensibles necesitan permisos de almacenamiento, controles de cifrado y gobernanza en las capas de objeto y catálogo.

Particiones, Archivos y el problema de archivos pequeños

A menudo, los conjuntos de datos colocan archivos Parquet en directorios particionados por un valor filtrado con frecuencia, como la fecha o la región. Un motor de consultas puede omitir rutas completas antes de abrir los metadatos del archivo. Los campos de partición deben tener cardinalidad controlada; crear un directorio por usuario o solicitud puede producir un número inmanejable de pequeñas particiones.

Muchos archivos pequeños añaden planificación, listado, conexión y sobrecarga de metadatos. También reducen la cantidad de datos disponibles para una compresión efectiva dentro de cada archivo. Los pipelines comúnmente compactan salidas pequeñas en archivos dimensionados para su motor de consultas y almacenamiento de objetos, mientras preservan los límites de partición que soportan la poda.

No hay un tamaño de archivo universal que se ajuste a cada sistema. Elija según el comportamiento de almacenamiento de objetos, concurrencia de consultas, ancho de fila, límites de memoria, cadencia de escritura y orientación del motor. Mida el tiempo de planificación así como el rendimiento de escaneo.

Parquet No Es un Formato de Tabla

Un archivo Parquet describe los datos dentro de ese archivo. No proporciona por sí mismo un registro de transacciones a través de miles de archivos, aislamiento de instantáneas, compromisos atómicos de múltiples archivos, cambios a nivel de fila o un catálogo de qué archivos pertenecen al estado actual de la tabla.

Una plataforma de datos puede gestionar esas preocupaciones a través de su catálogo y capa de tabla. Esta distinción es importante durante actualizaciones y cambios de esquema. Listar cada objeto en un directorio y tratarlo como datos actuales puede incluir archivos obsoletos o parcialmente escritos a menos que el sistema circundante defina las semánticas de compromiso.

Evolución del esquema

Añadir una columna opcional suele ser manejable porque los archivos más antiguos simplemente carecen de ella y los lectores pueden proporcionar nulo. Cambiar el nombre de una columna es más difícil porque un lector basado en nombre puede ver dos campos diferentes. Algunos ecosistemas rastrean identificadores de campo estables, pero el soporte debe ser consistente entre escritores, lectores y la capa de la tabla.

Cambiar un tipo físico o lógico requiere un plan de compatibilidad. Ampliar un entero puede funcionar en algunos lectores; cambiar una cadena a un registro anidado es una ruptura semántica. Almacene las versiones del esquema, valide los nuevos archivos antes de la publicación y pruebe las lecturas de versiones mixtas.

No confíe en el esquema de un archivo como el contrato del conjunto de datos completo. Un directorio puede contener archivos escritos por diferentes trabajos o en diferentes momentos. El esquema de catálogo y la validación de ingestión deben definir lo que se acepta.

Casos de uso comunes de Parquet

Cuándo No Usar Parquet

Parquet no es adecuado para un documento que las personas necesitan editar manualmente, una respuesta de API pública o una secuencia de mensajes independientes pequeños. También es incómodo para actualizaciones frecuentes de una sola fila y búsquedas directas clave-valor sin un índice o motor de tabla.

CSV puede ser mejor para una entrega simple a un analista. JSON o NDJSON pueden ser mejores para servicios y procesamiento de eventos. Una base de datos transaccional puede ser mejor para un estado operativo mutable. La misma canalización puede recibir entradas sin procesar en un formato y publicar una capa analítica curada en Parquet.

Cómo Crear Datos Parquet Confiables

1. Defina el esquema canónico. Especifique anulabilidad, tipos lógicos, semánticas de marca de tiempo, precisión decimal y estructuras anidadas.
2. Valide los registros entrantes. Resuelva conflictos de tipo y valores mal formados antes de escribir archivos.
3. Elija grupos de filas y objetivos de archivo por medición. Equilibre memoria, compresión, paralelismo y sobrecarga de metadatos.
4. Particione para filtros reales. Evite rutas de alta cardinalidad y particiones vacías.
5. Pruebe cada lector. Confirme tipos anidados, anotaciones lógicas, códecs de compresión y la evolución del esquema a través del conjunto de motores desplegados.
6. Publique de manera atómica a través de la capa de conjunto de datos. Haga invisibles los archivos incompletos hasta que la validación y las actualizaciones del catálogo se completen.

Conclusión

Apache Parquet convierte registros tipados en un archivo orientado a columnas que los sistemas analíticos pueden leer selectivamente. Su esquema, codificaciones, compresión, estadísticas y soporte de datos anidados reducen I/O innecesario para muchas cargas de trabajo centradas en escaneos. Esos beneficios dependen de un buen diseño del conjunto de datos: esquemas controlados, archivos y grupos de filas sensatos, particiones útiles, lectores compatibles y una capa de tabla cuando las transacciones o instantáneas son importantes. Parquet es más fuerte como el destino analítico curado, no como un reemplazo universal para JSON, CSV, bases de datos o formatos de eventos.