veilletech.frCe qui se passe
Le parcours est toujours le même : Excel, puis Pandas vers le gigaoctet, qui tient jusqu'à quelques dizaines de gigaoctets — et là, la mémoire sature. Le réflexe suivant est de passer à Spark, Databricks, Snowflake ou Dask.
L'argument d'Eddie Atkinson n'est pas que Pandas est lent. C'est que sa falaise arrive bien avant le point où un système distribué devient nécessaire, et que l'intervalle entre les deux est large.
Combien de Big Data existe réellement
Amazon a publié en 2024 un papier intitulé Why TPC is not enough: An analysis of the Amazon Redshift fleet, avec les statistiques de son parc : durées de requêtes et tailles de tables. En posant deux hypothèses — une ligne à 1 Ko, et des clusters de 10 machines avalant 8 Go/s depuis S3 —, l'auteur en tire :
- 94,68 % des tables contiennent moins de 100 Go ;
- 86,9 % des requêtes travaillent sur 80 Go ou moins.
Les hypothèses sont assumées, et le calcul est détaillé dans l'article. Même en prenant 10 Ko par ligne, le seuil monte à 1 To — loin du territoire où un cluster se justifie.
La mesure
Le 1 Billion Row Challenge — min, moyenne et max sur un CSV d'un milliard de
lignes — sur une instance AWS m7a.8xlarge, 32 cœurs, 128 Go, Debian 12. Deux
itérations de préchauffe, 30 répétitions, métriques relevées toutes les 50 ms avec
psutil :
| Bibliothèque | Durée médiane | CPU max | Mémoire max (USS) |
|---|---|---|---|
| Pandas | 4 min 28 s | 113,0 % | 38,12 Go |
| Polars | 5,04 s | 3202,60 % | 18,02 Go |
| DuckDB | 5,19 s | 3174,64 % | 1,93 Go |
La meilleure implémentation Java du concours tournait en 1,5 s : les deux outils en sont à portée, sans réglage.
Sur un portable — Framework 13, i5-1135G7, 8 cœurs, 16 Go — l'écart devient brutal : Pandas met 12 min 15 s et réclame 21,02 Go de swap, contre 39 s pour Polars (35,85 Mo de swap) et 47 s pour DuckDB.
Deuxième jeu de données, les trajets de taxis new-yorkais (~3 Go de Parquet) :
| Approche | Durée médiane | Mémoire max (USS) |
|---|---|---|
| Pandas seul | 41,88 s | 14,52 Go |
| DuckDB lit, Pandas calcule | 28,39 s | 14,79 Go |
| Pandas lit, DuckDB calcule | 29,25 s | 12,39 Go |
| DuckDB seul | 21,70 s | 216,76 Mo |
Dès que Pandas entre dans la chaîne, la mémoire grimpe.
Pourquoi l'écart est structurel
Polars et DuckDB construisent un plan de requête avant d'exécuter. scan_csv
est paresseux, .collect(new_streaming=True) déclenche le pipeline, et
.explain(streaming=True) affiche le plan optimisé — avec predicate pushdown,
donc les filtres appliqués avant l'agrégation. DuckDB fait la même chose en
SQL, y compris sur un objet Python en mémoire.
Pandas, lui, exécute chaque étape de façon séquentielle et immédiate : il charge tout le jeu de données, groupe, puis agrège.
À retenir
L'auteur liste lui-même les raisons de ne pas le suivre : le coût de migration peut être trop élevé dans un écosystème très intégré à Pandas, et Pandas s'améliore. Le choix entre Polars et DuckDB dépend du profil — les ingénieurs data penchent vers SQL, les développeurs vers Polars.
Ce qu'il faut éviter, en revanche, est clair : prendre un système distribué et sa complexité parce que Pandas rame, alors que la probabilité d'en avoir réellement besoin est faible. Avant le prochain cluster, mesurez ce que donne un scan paresseux sur votre plus grosse table.