Qu’est-ce qu’un flat file ?
(evidence.dev)- Un flat file est un format très courant en analyse de données
- Ce guide complet explique ce qu’est un flat file, quels types existent, lequel choisir, ainsi que ses cas d’usage, les caractéristiques des formats et une comparaison avec les bases de données non flat file et les SGBDR
Difficile à définir
- Un flat file est principalement utilisé lorsqu’on extrait des données d’une base de données pour les traiter
- Il se présente sous la forme d’un simple fichier texte comme un CSV, où chaque ligne représente un enregistrement et les champs sont séparés par des virgules
- Cependant, la définition de « flat file » n’est pas claire, même si l’on retrouve généralement les caractéristiques suivantes :
- Texte uniquement : stocke uniquement du texte et des nombres, pas de données binaires (Blob)
- Format tabulaire : une table par fichier, avec des enregistrements organisés par lignes
- Portable : facile à afficher, modifier et traiter sans logiciel spécialisé
- Non structuré : en général, pas de hiérarchie ni de relations entre les enregistrements
- Sans compression : pas de compression intelligente par défaut (même si DuckDB, Spark, etc. acceptent les fichiers zip)
- Sans index : aucun index intégré pour retrouver un enregistrement précis
- Sans description : généralement sans métadonnées ni informations de schéma
- JSON et YAML sortent de cette définition, car ils peuvent inclure une hiérarchie et un schéma
- Le fait qu’ils puissent être utilisés dans des cas d’usage très variés n’aide pas vraiment non plus
- CSV : format de stockage et d’échange de données
- JSON : échange de données à grande échelle, gestion de configuration, format de retour d’API
- YAML : gestion de configuration et fichiers de définition de pipelines
Types de flat files
- Il existe plusieurs types selon la manière dont les données sont organisées et stockées
- Organisation des champs et des enregistrements
- Flat file non structuré : structure en table unique comme CSV
- Flat file structuré : JSON, YAML, XML, etc. possèdent une structure hiérarchique
- Type de séparateur de champs
- Une ligne représente un enregistrement et les champs sont séparés par un délimiteur
- Virgule(
,), tabulation(\t), barre verticale(|)
- Format à largeur fixe vs largeur variable
- Le format à largeur fixe attribue une longueur constante aux champs → traitement plus rapide
- Le format à largeur variable offre davantage de souplesse de traitement
- Délimiteurs de données
- Le CSV peut stocker des tabulations et des sauts de ligne (avec échappement)
- Le TSV ne peut pas contenir de tabulations ni de sauts de ligne
- Lisibilité humaine
- Les flat files sont souvent lisibles par des humains
- Sur certaines plateformes, les fichiers Excel sont aussi classés comme flat files
- Présence de métadonnées
- Les fichiers comme CSV n’ont pas de métadonnées
- JSON peut inclure ses propres métadonnées et un schéma
Cas d’usage des flat files
- Stockage et échange
- Échange de données : CSV et JSON sont utiles pour échanger des données entre différentes plateformes
- Intégration de données dans l’ETL : les flat files sont souvent utilisés comme données source et cible dans les processus ETL
- Archivage et sauvegarde : les flat files, basés sur du texte, sont pratiques pour la conservation à long terme
- Usage utilitaire
- Gestion de configuration : YAML, JSON, INI, etc. servent aux variables d’environnement, connexions aux bases de données, etc.
- Définition de pipelines de données : JSON, YAML, etc. servent à définir la structure des pipelines
- Métadonnées de datasets : JSON peut définir la transformation et la validation d’un CSV
Exemples de flat files
CSV (Comma-Separated Values)
- Extension :
.csv - Séparateur : virgule
, - Structure : plate (flat)
- Facile à lire pour un humain
- Exemple :
name, country, age Alice, USA, 22 Bob, Canada, 34 Charlie, UK, 28 - À choisir si :
- adapté aux données structurées en format tabulaire
- utile pour les exports depuis des systèmes BI, Excel/Google Sheets
- À éviter si :
- inadapté lorsqu’une structure hiérarchique complexe est nécessaire
- peut poser problème avec des données contenant des virgules
TSV (Tab-Separated Values)
- Extension :
.tsv - Séparateur : tabulation
\t - Structure : plate (flat)
- Facile à lire pour un humain
- Exemple :
name country age Alice USA 22 Bob Canada 34 Charlie UK 28 - À choisir si :
- utile lorsqu’il faut traiter des données contenant des virgules
- facile à manipuler avec les outils CLI Unix
- À éviter si :
- pose problème avec des données contenant des tabulations
JSON (JavaScript Object Notation)
- Extension :
.json - Structure : hiérarchique
- Facile à lire pour un humain
- Exemple :
[ {"name": "Alice", "country": "USA", "age": 22}, {"name": "Bob", "country": "Canada", "age": 34}, {"name": "Charlie", "country": "UK", "age": 28} ] - À choisir si :
- adapté lorsqu’une structure de données hiérarchique est nécessaire
- À éviter si :
- inadapté si la vitesse de traitement est prioritaire
YAML (YAML Ain’t Markup Language)
- Extension : .yaml
- Structure : hiérarchique
- Facile à lire pour un humain
- Exemple :
name: Alice country: USA age: 22 - À choisir si :
- adapté lorsqu’il faut des fichiers de configuration faciles à lire
- À éviter si :
- inadapté au stockage de gros volumes de données
Fichiers ENV
- Extension : .env
- Structure : plate (flat)
- Facile à lire pour un humain
- Exemple :
APP_NAME=MyApp ENVIRONMENT=production - À choisir si :
- adapté lorsqu’il faut des fichiers de configuration pour le déploiement et les environnements locaux
- À éviter si :
- inadapté au stockage de structures de données complexes
Comparaison flat file vs non-flat file vs SGBD
Les flat files sont souvent comparés aux bases de données relationnelles (SGBDR), et il existe aussi des formats intermédiaires comme Avro, Parquet et ORC. Voici une comparaison des principales caractéristiques :
-
Mode d’organisation des enregistrements
- CSV : stockage des données par lignes (row-based)
- JSON : stockage basé sur des paires clé-valeur
- Parquet : stockage par colonnes (column-based)
- SGBDR relationnel : stockage des données par lignes (row-based)
-
Format lisible par un humain ou non
- CSV et JSON : basés sur du texte → faciles à lire
- Parquet et SGBD : basés sur du binaire → difficiles à lire
-
Portabilité
- CSV, JSON, Parquet : forte compatibilité entre plateformes
- SGBD : utilisable uniquement avec un logiciel spécifique
-
Prise en charge de la hiérarchie
- CSV : pas de structure hiérarchique
- JSON : prend en charge la hiérarchie
- Parquet : prend en charge les structures imbriquées
- SGBD : prend en charge plusieurs tables et une structure relationnelle
-
Scalabilité
- CSV et JSON : faible scalabilité
- Parquet et SGBD : forte scalabilité
-
Prise en charge des index
- CSV et JSON : pas d’index
- Parquet : permet une recherche rapide grâce aux métadonnées au niveau du fichier et des colonnes
- SGBD : prise en charge des index
-
Prise en charge du schéma
- CSV : pas de schéma
- JSON : peut inclure un schéma
- Parquet et SGBD : schéma appliqué de manière stricte
- Parquet n’utilise pas d’index B-Tree ni d’index de hachage. À la place, il accélère la recherche de données grâce aux métadonnées au niveau du fichier, des groupes de lignes et des colonnes
Choisir le bon format de flat file
- CSV, TSV → pour l’archivage des données ou leur transfert entre plateformes, ainsi que pour l’échange et le stockage simples
- JSON → à utiliser lorsqu’un format auto-descriptif avec structure hiérarchique est nécessaire
- YAML → adapté à la configuration et au paramétrage des pipelines
- Parquet → à envisager lorsqu’il faut des fichiers compacts, des requêtes rapides et la prise en charge de types de données complexes
Aucun commentaire pour le moment.