Visionneuse Parquet

À propos de la visionneuse Parquet

Apache Parquet est le format de stockage colonnaire de facto pour le big data — créé chez Twitter et Cloudera en 2013, donné à l'Apache Software Foundation, et désormais le format de fichier par défaut pour les stages Snowflake, les data lakes AWS S3, les exports Google BigQuery, Databricks Delta Lake et les modèles dbt. Sa structure colonnaire, sa compression Snappy/ZSTD et ses métadonnées de schéma riches le rendent 3 à 10 fois plus petit que le CSV équivalent tout en supportant le predicate pushdown et le column pruning pour des requêtes analytiques rapides. Mais contrairement au CSV, vous ne pouvez pas ouvrir un fichier Parquet dans Excel ou un éditeur de texte — la disposition binaire requiert un outillage spécialisé. Cette visionneuse utilise la bibliothèque parquet-wasm (une implémentation Rust compilée en WebAssembly) pour lire votre fichier entièrement dans le navigateur, afficher un aperçu en tableur et exporter en CSV ou JSON sans jamais téléverser d'octets vers un serveur.

Qu'est-ce qu'un fichier Parquet ?

Apache Parquet est un format colonne optimisé pour les workloads Big Data. Il offre compression et encodage efficaces, ce qui le rend incontournable pour Spark, Hadoop, Athena ou les data lakes.

Mes données quittent-elles mon appareil ?

Non. L'analyse Parquet se fait localement via WebAssembly (parquet-wasm). Vos fichiers restent privés.

Puis-je modifier les données ?

L'outil est en lecture seule. Exportez en CSV ou JSON pour éditer ensuite avec un autre outil (ex. notre éditeur CSV).

Quelle taille de fichier est supportée ?

Les fichiers de plusieurs dizaines voire centaines de Mo peuvent être ouverts. Limitez le nombre de lignes affichées pour garder de bonnes performances.

Quels formats d'export sont proposés ?

Vous pouvez exporter les données en CSV (séparateur virgule) ou en JSON pour les utiliser dans des tableurs, bases ou apps web.

Pourquoi utiliser Parquet ?

Le stockage colonne maximise la compression et accélère les requêtes analytiques. Parquet est un standard dans la data science, l'ingénierie de données et les entrepôts cloud.

Comment Parquet se compare-t-il à CSV, JSON et Avro ?

CSV est orienté ligne, sans compression, sans typage et lisible par l'humain — parfait pour les petits transferts mais lent et volumineux pour l'analytique. JSON est orienté ligne avec imbrication complète et types, mais verbeux. Avro est un format binaire orienté ligne avec schéma intégré, bon pour les données en streaming (Kafka) où vous écrivez une fois et rejouez séquentiellement. Parquet est colonnaire avec schéma intégré et compression agressive — les fichiers font typiquement 30 à 50% de la taille du CSV gzippé équivalent. L'avantage apparaît dans les requêtes analytiques : SELECT avg(price) FROM 10M lignes lit uniquement la colonne price du disque (column pruning), et le predicate pushdown saute des groupes de lignes entiers qui échouent à la clause WHERE. Pour l'analytique interactive sur >1M lignes, Parquet est 5 à 50 fois plus rapide que CSV. Pour les insertions ligne par ligne ou les recherches d'enregistrement unique, un format orienté ligne ou une base de données reste préférable.

Quels codecs de compression Parquet supporte-t-il ?

Parquet supporte six codecs de compression par column chunk : SNAPPY (par défaut — compression/décompression rapide, ratio modeste), GZIP (fichiers plus petits mais plus lent), ZSTD (moderne, plus rapide que GZIP à ratios similaires — recommandé pour les nouveaux pipelines depuis Parquet 2.4), LZ4_RAW (le plus rapide, ratio le plus bas), BROTLI (meilleur ratio pour les colonnes riches en texte, compression plus lente), et UNCOMPRESSED. La compression est appliquée par colonne, donc un seul fichier peut mélanger les codecs selon ce qui fonctionne le mieux par type de colonne. SNAPPY est devenu le défaut car il offre un bon équilibre vitesse/taille pour les charges analytiques typiques ; ZSTD niveau 3 est maintenant la recommandation pour le stockage froid où la vitesse de lecture importe moins que l'économie de disque.

Quelle est la structure typique d'un fichier Parquet ?

Un fichier Parquet est organisé hiérarchiquement : fichier -> row groups -> column chunks -> pages. Les row groups sont des partitions horizontales (typiquement 128 Mo ou 100k-1M lignes) qui permettent une lecture parallèle. Dans chaque row group, les données pour chaque colonne sont stockées ensemble en column chunks, divisés en pages (généralement 1 Mo). Les statistiques au niveau page (min, max, comptage null) activent le predicate pushdown : une requête comme 'price > 100' peut sauter les pages où max(price) < 100 sans lire les données réelles. Le footer du fichier contient le schéma, les offsets des row groups et les métadonnées — les lecteurs cherchent d'abord la fin pour apprendre la structure, puis lisent uniquement les column chunks pertinents. Cette conception explique pourquoi Parquet est si efficace sur le stockage cloud : la plupart des requêtes ne récupèrent que quelques Mo d'un fichier de plusieurs Go.

Puis-je voir des schémas Parquet imbriqués ou complexes (structs, maps, lists) ?

Oui. Parquet supporte le système de types complet d'Apache Arrow : primitifs (int32, double, string, timestamp, decimal), structs (enregistrements imbriqués), lists (tableaux de longueur variable), maps (paires clé-valeur), et combinaisons arbitraires. Cette visionneuse aplatit les champs imbriqués en utilisant la notation pointée dans les en-têtes de colonnes (user.address.city) et rend les listes/maps en JSON dans leurs cellules. Les schémas complexes sont courants dans la sortie Spark/Databricks, les données VARIANT de Snowflake et les exports d'event-streaming. Si votre fichier utilise des types logiques comme TIMESTAMP_MILLIS, DECIMAL(18,2) ou UUID, la visionneuse les respecte et rend des valeurs lisibles par l'humain. Pour l'inspection schéma uniquement sans voir les données, utilisez 'parquet-tools schema file.parquet' ou l'instruction DESCRIBE de DuckDB : DESCRIBE SELECT * FROM 'file.parquet' LIMIT 0.

Comment cet outil gère-t-il efficacement les gros fichiers Parquet ?

Trois optimisations : (1) la bibliothèque parquet-wasm lit d'abord uniquement les métadonnées du footer (typiquement <100 Ko), donc ouvrir un fichier de 1 Go prend des millisecondes avant que des données de ligne ne soient demandées ; (2) le contrôle 'Nombre max. de lignes' limite combien de lignes sont décodées pour l'aperçu — utile pour les fichiers avec des millions de lignes où vous avez juste besoin de vérifier le schéma et les valeurs d'exemple ; (3) seules les colonnes auxquelles vous faites défiler sont décodées en eager grâce à la disposition colonnaire. Pour les fichiers plus grands que la mémoire du navigateur (>500 Mo sur mobile, >2 Go sur ordinateur), considérez des outils comme DuckDB-WASM qui peut streamer Parquet depuis des URLs sans jamais charger le fichier complet. Pour les charges analytiques de production, interrogez Parquet directement depuis le stockage cloud avec Polars, Pandas read_parquet, Spark, BigQuery external tables ou Athena — ne chargez jamais le fichier en mémoire juste pour l'interroger.