Guide des formats de sérialisation de données : Parquet, Avro, Proto, etc.
Dans le monde de l'ingénierie des données et du développement logiciel, la manière dont nous stockons et transmettons les données est cruciale. Si le JSON est le roi des API web en raison de sa lisibilité, il est souvent trop volumineux ou trop lent pour le traitement de données massives, la messagerie à haute fréquence ou le débogage spécialisé.
Ce guide explore les extensions de fichiers spécialisées utilisées pour la sérialisation des données au-delà du JSON et du CSV de base.
Tableau de référence rapide : Formats de sérialisation de données
| Extension | Nom complet | Format | Cas d'utilisation principal |
|---|---|---|---|
.ndjson, .jsonl |
JSON délimité par des retours à la ligne | Texte (ASCII) | Fichiers de log, streaming de données, imports big data |
.parquet |
Apache Parquet | Binaire (Colonnaire) | Analyse Big Data (Hadoop, Spark, AWS S3) |
.avro |
Apache Avro | Binaire (Basé sur les lignes) | Sérialisation de données avec schémas (Kafka) |
.proto |
Protocol Buffers | Texte (DSL) | Définition d'interfaces gRPC et de structures de données |
.bson |
Binary JSON | Binaire | Stockage et échange de données MongoDB |
.cbor |
Concise Binary Object Representation | Binaire | IoT, environnements à faible bande passante |
.har |
Archive HTTP | Texte (JSON) | Débogage des requêtes réseau dans les navigateurs |
.edn |
Extensible Data Notation | Texte (type Lisp) | Écosystème Clojure, configuration de métadonnées |
1. JSON adapté au streaming (.ndjson, .jsonl)
Le JSON standard nécessite que l'intégralité d'un fichier soit lue en mémoire pour être analysée (il commence par [ et se termine par ]). C'est impossible pour des fichiers de log de 100 Go.
- NDJSON / JSONL : Chaque ligne est un objet JSON valide et indépendant.
- Pourquoi l'utiliser ? Vous pouvez lire un fichier ligne par ligne sans charger l'intégralité du contenu. Si le fichier est tronqué ou corrompu, vous ne perdez que la dernière ligne, pas l'ensemble des données.
2. Stockage colonnaire Big Data (.parquet, .orc)
Les bases de données traditionnelles stockent les données ligne par ligne. Les bases de données analytiques préfèrent souvent le stockage colonnaire.
- Parquet : Le standard de l'industrie pour le Big Data. Comme il stocke les données par colonne, il peut compresser les données beaucoup plus efficacement et vous permet de "sauter" les colonnes dont vous n'avez pas besoin pour une requête spécifique.
- ORC : Optimized Row Columnar. Similaire au Parquet mais principalement utilisé dans l'écosystème Apache Hive.
3. Sérialisation basée sur le schéma (.avro, .proto)
Contrairement au JSON où les noms des clés ("first_name") sont répétés dans chaque enregistrement, les formats basés sur le schéma séparent les "règles" des "données".
- Avro : Le schéma est stocké en JSON, mais les données sont binaires. C'est le standard pour Apache Kafka car il est rapide et prend en charge l'évolution du schéma.
- Protobuf (.proto) : Développé par Google. Vous définissez votre structure de données dans un fichier
.proto, puis un compilateur génère le code pour votre langage préféré. C'est l'épine dorsale de gRPC.
4. Alternatives binaires au JSON (.bson, .cbor, .msgpack)
Si vous aimez la flexibilité du JSON mais avez besoin de plus de vitesse ou de fichiers plus petits, les formats binaires sont la solution.
- BSON : Utilisé en interne par MongoDB. Il prend en charge plus de types de données que le JSON (comme les dates et les données binaires).
- CBOR : Conçu pour être extrêmement petit et efficace. Il est largement utilisé dans les appareils IoT (Internet des objets) où chaque octet de bande passante compte.
- MessagePack : Semblable au CBOR, il est "comme le JSON mais rapide et petit".
5. Formats spécialisés (.har, .edn)
- HAR (HTTP Archive) : Si vous avez déjà "exporté" une trace réseau à partir des outils de développement de Chrome ou Firefox, il s'agit d'un fichier
.har. En réalité, il ne s'agit que d'un énorme fichier JSON contenant chaque en-tête, cookie et corps de réponse de votre session de navigation. - EDN : Utilisé principalement dans le monde Clojure. Il est plus puissant que le JSON car il prend en charge nativement les types personnalisés (tags) et des structures de données plus complexes.
Comment visualiser ces fichiers
- NDJSON/JSONL : Utilisez n'importe quel éditeur de texte ou l'outil en ligne de commande
jq. - Parquet : Nécessite des visualiseurs spécialisés ou des bibliothèques Python (comme
pandasoufastparquet). - Protobuf : Vous avez généralement besoin du fichier de définition
.protopour décoder les données binaires. - HAR : Vous pouvez le glisser-déposer dans les outils de développement de Chrome/Firefox ou utiliser un visualiseur HAR en ligne.
Questions fréquentes (FAQ)
Q : Pourquoi mon fichier Parquet est-il plus petit que mon CSV ?
R : Parquet utilise des techniques de compression avancées telles que le "codage par dictionnaire" et le "codage par longueur de plage". Comme il stocke les données par colonne, les valeurs d'une colonne (comme "Pays") sont souvent identiques, ce qui permet des taux de compression massifs par rapport aux fichiers texte.
Q : Puis-je modifier un fichier .proto ?
R : Oui, les fichiers .proto sont des fichiers texte lisibles par l'homme dans lesquels vous définissez vos structures de données. Cependant, vous ne pouvez pas directement "modifier" les données binaires produites à partir de celui-ci — vous devez utiliser le code compilé.
Q : Le .bson est-il identique au JSON ?
R : Pas tout à fait. Le BSON est une représentation binaire qui inclut des données de type JSON mais ajoute également des types tels que Buffer, Long et Decimal128 que le JSON standard ne prend pas en charge.
Outils connexes sur Tool3M
- Convertisseur JSON en CSV : Convertissez vos données structurées en un tableau plat.
- Guide de sérialisation binaire : En savoir plus sur Protobuf et MessagePack.