Formats & stockage : parquet, arrow, object storage
Ligne vs colonne : le choix qui change tout
Un CSV/JSON stocke par ligne : parfait pour lire un enregistrement complet (ton OLTP). L'analytique et le ML lisent quelques colonnes de millions de lignes (« moyenne du montant par pays ») : il faut du stockage par colonne.
Parquet est le standard : chaque colonne stockée (et compressée) séparément, avec des statistiques par bloc (min/max) qui permettent de sauter des blocs entiers au filtrage (predicate pushdown).
| CSV | Parquet | |
|---|---|---|
| Lire 2 colonnes sur 40 | tout lire puis jeter | ne lit QUE les 2 colonnes |
| Types | devinés (bonjour les dates) | schéma embarqué, typé |
| Compression | fichier entier | par colonne (10-20× souvent) |
WHERE date > X | scan complet | blocs sautés via min/max |
Arrow : le format en mémoire
Apache Arrow est le pendant en mémoire de parquet : une représentation colonne standardisée que pandas, polars, DuckDB et Spark partagent sans copie ni sérialisation (zero-copy). C'est lui qui a tué les allers-retours pickle/CSV entre outils.
Le data lake : object storage + partitions
Le pattern universel : les données vivent en parquet sur object storage (S3/GCS/Scaleway), organisées en partitions par les colonnes de filtrage :
s3://lake/commandes/annee=2026/mois=07/part-000.parquet
Un moteur (DuckDB, Spark, BigQuery externe) lit directement ces fichiers et ne parcourt que les partitions utiles. DuckDB mérite ta curiosité immédiate : un « SQLite analytique » qui requête des parquet locaux ou S3 en SQL — l'outil parfait pour explorer un lake sans infra.
Au-dessus de ça, les formats de table (Iceberg, Delta) ajoutent transactions, schéma évolutif et time-travel — la couche « ACID » du lake.
Pourquoi parquet est-il plus rapide que CSV pour « moyenne d'une colonne sur 100 M de lignes » ?