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).

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.