SQLite, CSV, Parquet, Avro, ORC, Arrow : quel format choisir pour stocker ou échanger des données

Ces formats stockent ou transportent tous des données structurées, mais aucun n’est un vrai substitut aux autres : le choix dépend surtout de ce qu’on va faire des données, et notamment si elles doivent être stockées durablement ou seulement échangées le temps d’un calcul.

Format	Organisation	Requêtable en SQL	Meilleur usage
CSV	Texte, ligne par ligne	Non	Échange simple, petits volumes
SQLite	Base relationnelle en un seul fichier	Oui, nativement	Base embarquée dans une application
Parquet	Colonne par colonne, compressé	Non (nécessite un moteur, ex. Spark)	Analyse de gros volumes de données au repos
Avro	Ligne par ligne, schéma embarqué	Non (nécessite un moteur)	Écriture en flux, streaming (Kafka)
ORC	Colonne par colonne, compressé	Non (nécessite un moteur, ex. Hive)	Analytique dans l'écosystème Hadoop/Hive
Arrow / Feather	Colonne par colonne, non compressé	Non (nécessite un moteur, ex. DuckDB)	Échange rapide en mémoire entre programmes

Le CSV représente des données tabulaires en texte brut, une ligne par enregistrement, des valeurs séparées par une virgule ou un point-virgule. Normalisé a posteriori par la RFC 4180 en 2005 après des décennies d’usage informel, il n’a aucune signature binaire ni structure d’en-tête : rien ne le distingue d’un fichier texte brut ordinaire. Sa simplicité en fait le format d’échange le plus universellement accepté, au prix d’incompatibilités classiques liées au séparateur, à l’encodage ou au format des nombres décimaux selon la locale.

Le SQLite est une base de données relationnelle complète tenant dans un seul fichier, sans serveur ni processus séparé à administrer. Sa signature textuelle “SQLite format 3” est directement lisible en tête de fichier. C’est le bon choix quand l’application a besoin de requêtes SQL, d’index ou de contraintes d’intégrité sur des données qui évoluent, pas seulement de les transporter d’un point A à un point B.

Le Parquet stocke les données non pas ligne par ligne comme un CSV, mais colonne par colonne, une organisation particulièrement efficace pour les requêtes analytiques qui ne portent que sur certaines colonnes d’un très gros jeu de données. Sa chaîne de signature “PAR1”, présente à la fois en début et en fin de fichier, permet de vérifier qu’un fichier n’a pas été tronqué lors d’un transfert. C’est le format de référence du traitement de données à grande échelle (Apache Spark, Hadoop, entrepôts cloud), mais il nécessite un outil dédié pour être exploité, contrairement au CSV lisible par n’importe qui.

L’Avro partage avec Parquet l’embarquement du schéma dans le fichier, mais reste organisé ligne par ligne plutôt qu’en colonnes, un choix qui le rend plus adapté à l’écriture et la lecture séquentielle complète d’un flux d’événements qu’à des requêtes analytiques ne portant que sur quelques champs. Le Schema Registry de Confluent, composant central de nombreuses architectures Apache Kafka, s’appuie sur l’Avro par défaut pour cette raison, ainsi que pour sa gestion explicite de l’évolution du schéma dans le temps.

L’ORC (Optimized Row Columnar) rivalise directement avec le Parquet sur le même terrain (un stockage colonne par colonne pensé pour l’analytique à grande échelle), mais né dans l’écosystème Hadoop/Hive plutôt que dans celui de Spark. Il intègre des statistiques précalculées par bloc (valeurs min/max par colonne) que le moteur de requête consulte pour ignorer entièrement des blocs qui ne peuvent pas contenir de résultat pertinent, et reste depuis Hive 3 le seul format pris en charge pour les tables transactionnelles ACID de Hive, un cas d’usage où le Parquet, pourtant très répandu par ailleurs, ne peut pas servir de socle. Le choix entre les deux dépend surtout de l’écosystème logiciel déjà en place plutôt que d’une différence technique tranchée.

L’Arrow, lui, ne vise pas le stockage durable mais l’échange à très haute vitesse entre programmes : sa structure colonnaire est identique en mémoire et sur disque, ce qui évite toute étape de décompression ou de réanalyse au chargement, contrairement au Parquet qui privilégie une compression maximale au repos. Le Feather en est aujourd’hui un simple alias : depuis sa version 2, c’est très exactement la même sérialisation Arrow sur disque, seul le nom d’usage change selon l’outil (pandas en Python, le package arrow en R). De nombreux moteurs d’analyse (Pandas, Spark, DuckDB) l’utilisent comme représentation interne même quand les données finissent archivées en Parquet.

Choisir CSV pour l’échange simple et universel de petits jeux de données, SQLite pour une base de données embarquée dans une application avec des requêtes SQL, Parquet pour l’analyse de gros volumes de données tabulaires dans l’écosystème Spark/cloud, ORC pour ce même usage analytique dans l’écosystème Hadoop/Hive, Avro pour l’écriture en flux continu (streaming, Kafka) où le schéma doit voyager avec les données sans requête analytique par colonne, Arrow (ou Feather, son alias) pour échanger rapidement un jeu de données en mémoire entre deux programmes sans étape de conversion.