Mastering Modern Pandas

Salut, c'est Alex de DEV STORIES DOT EU. Maîtriser pandas moderne, épisode 1 sur 8. Tu extrais deux colonnes de données financières, tu les additionnes, et la somme finale n'a aucun sens. Les lignes se sont décalées, et tu viens juste d'ajouter le prix de clôture d'hier au volume d'aujourd'hui. C'est ce qui arrive quand tu traites les données comme une simple grille au lieu de t'appuyer sur l'abstraction fondamentale : les DataFrames et l'alignement des labels. On regarde souvent pandas en pensant que c'est juste un tableur programmable ou un array NumPy en deux dimensions classique. Ce n'est pas le cas. Un array NumPy classique repose sur un indexing positionnel strict. Si tu additionnes deux arrays, l'élément à la position zéro s'ajoute à l'élément à la position zéro. S'il manque une ligne dans tes données, tout se décale, et tes calculs sont corrompus silencieusement. Pandas résout exactement ce problème en découplant les données de leur position physique en mémoire. Il utilise un data alignment intrinsèque, ce qui veut dire qu'il aligne les données par labels, jamais par position. Pour comprendre ça, regarde la base de la library, la Series. Une Series est un array en une dimension qui peut contenir n'importe quel type de données. Contrairement à une list standard, chaque élément d'une Series est solidement attaché à un label. Ces labels forment collectivement ce que pandas appelle l'index. Tu peux utiliser des entiers comme labels, mais le plus souvent, tu utilises des strings ou des timestamps. Un DataFrame est simplement une collection de ces objets Series qui agissent comme des colonnes, partageant tous le même index, placés côte à côte. Voici le point clé. Quand tu fais une opération dans pandas, l'index dicte le comportement. Disons que tu as deux Series de rendements boursiers quotidiens. La Series A a des données pour lundi, mardi, mercredi et jeudi. La Series B a des données pour mercredi, jeudi et vendredi. Si tu demandes à pandas d'additionner ces deux Series, il ignore leur ordre physique. Il regarde les labels de date. Il trouve mercredi dans la Series A et l'ajoute à mercredi dans la Series B, même si mercredi est le troisième élément dans le premier dataset et le tout premier élément dans le deuxième dataset. Ça soulève le problème des jours qui ne se chevauchent pas. Lundi existe dans la première Series mais pas dans la deuxième. Vendredi existe dans la deuxième mais pas dans la première. Pandas ne crashe pas, et il ne devine certainement pas de valeur. À la place, il crée un nouvel index qui est l'union de tous les labels des deux inputs. Pour tout label qui n'existe pas aux deux endroits, pandas insère un NaN, ce qui veut dire Not a Number. L'opération se termine avec succès, et tu peux voir immédiatement où tes données sont incomplètes. Tu n'as jamais besoin d'écrire une loop pour vérifier si les dates correspondent. L'alignement est automatique, intégré directement dans la structure de données elle-même. Cette même logique s'applique directement aux DataFrames. Un DataFrame s'aligne sur les deux dimensions simultanément. Quand tu fais une opération sur deux DataFrames, pandas fait correspondre label de ligne avec label de ligne, et nom de colonne avec nom de colonne. Il aligne parfaitement toute la structure avant d'exécuter une seule opération mathématique. Tout ce qui ne se chevauche pas à la fois sur les lignes et les colonnes est marqué comme missing data. La vraie puissance de pandas, ce ne sont pas les maths qu'il effectue, mais le fait que le label voyage toujours avec la donnée, rendant les incohérences de position structurellement impossibles. Si tu veux soutenir l'émission, tu peux nous trouver en cherchant DevStoriesEU sur Patreon. Merci pour ton écoute, et happy coding à tous !

Salut, c'est Alex de DEV STORIES DOT EU. Maîtriser le pandas moderne, épisode 2 sur 8. Tu extrais une slice de tes données, tu mets à jour une seule valeur, et soudain, ton dataset d'origine est corrompu. Pire encore, tu te prends un warning imprévisible et tu n'as aucune idée si ton update s'est appliqué à la slice ou à la source. La version 3.0 résout enfin ce chaos en faisant du Copy-on-Write le comportement par défaut. Le Copy-on-Write réécrit fondamentalement la façon dont pandas gère la mémoire. Dans les versions précédentes, pandas faisait fréquemment des copies défensives pour t'éviter de modifier accidentellement le dataset d'origine. Si tu filtrais un dataset, pandas le copiait. Si tu droppais une colonne, pandas copiait le reste. Ça gaspillait des quantités massives de mémoire et de cycles CPU. Quand il ne copiait pas, il renvoyait une view, ce qui voulait dire que modifier le nouvel objet altérait silencieusement le parent. Sous Copy-on-Write, tout DataFrame ou Series dérivé d'un autre partage exactement la même mémoire sous-jacente. Ça veut dire que prendre un subset, dropper une colonne ou faire un reset d'index est presque instantané. Aucune donnée n'est dupliquée au préalable. Voici le point clé. Ne confonds pas une view legacy avec une lazy copy Copy-on-Write. Dans une view traditionnelle, le parent et l'enfant pointent vers la même mémoire, et un changement sur l'un modifie l'autre. Le Copy-on-Write est différent. La mémoire partagée est temporaire et strictement protégée. Le partage dure seulement jusqu'à ce que tu essaies de modifier quelque chose. Prenons un scénario concret. Tu as un DataFrame qui contient des profils utilisateurs. Tu sélectionnes la colonne age et tu l'assignes à une nouvelle variable appelée age subset. À ce moment précis, age subset ne prend absolument aucune mémoire supplémentaire. Il pointe directement vers le DataFrame d'origine des profils utilisateurs. Ensuite, tu mets à jour la première valeur dans ton age subset à 99. C'est là que la partie write du Copy-on-Write intervient. Pandas détecte la modification. Avant d'exécuter ton update, il vérifie si un autre objet partage ce bloc de données spécifique. Comme le DataFrame parent l'utilise encore, pandas alloue instantanément de la nouvelle mémoire, copie les données, puis écrit la valeur 99 à ce nouvel emplacement. Ton DataFrame parent reste intact en toute sécurité. Muter un subset ne mute jamais le parent. Ce mécanisme se propage parfaitement à travers les opérations chaînées. Quand tu enchaînes des opérations comme le drop de lignes vides, le remplacement de valeurs et le renommage de colonnes, les anciennes versions de pandas créaient une copie physique à chaque étape. Sous Copy-on-Write, ces étapes intermédiaires partagent simplement la mémoire. Une copie physique est déclenchée uniquement quand une étape mute réellement les arrays de données sous-jacents. Si une opération ne fait que réorganiser les références, aucune copie ne se produit. Ça élimine complètement la corruption accidentelle de données. Tu n'as plus à deviner si une opération a renvoyé une view ou une copie, et tu ne verras plus jamais le warning Setting With Copy. La règle est absolue : un objet parent et un objet enfant ne se modifieront jamais l'un l'autre. En différant les copies jusqu'à la milliseconde exacte où une modification se produit, pandas t'offre les performances rapides et la faible empreinte mémoire des views, associées à la sécurité stricte des deep copies. C'est tout pour cette fois. Merci d'avoir écouté, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. Maîtriser Pandas moderne, épisode 3 sur 8. Tu charges un dataset avec quelques millions de lignes, et soudain, ton utilisation de la mémoire explose. Les nombres passent bien, mais les colonnes de texte et les valeurs manquantes détruisent silencieusement ta RAM. La solution est un changement fondamental dans la façon dont pandas stocke les données, et c’est exactement le sujet de cet épisode : la salle des machines du PyArrow engine. Si tu as entendu parler d’Apache Arrow, tu penses peut-être que c'est strictement réservé aux gros systèmes distribués comme Spark ou Hadoop. Ce n’est pas le cas. Arrow est maintenant un memory format et un execution engine natif de premier plan, directement à l'intérieur de pandas. Pendant des années, pandas s’est entièrement reposé sur NumPy. NumPy est incroyablement rapide pour les calculs numériques denses, mais il a un énorme angle mort en ce qui concerne les données manquantes. NumPy n'a pas de concept natif pour un integer manquant ou un boolean manquant. Si tu as une colonne d'integers et qu'une seule valeur manque, pandas a historiquement été forcé de convertir toute la colonne en nombres floating-point juste pour pouvoir utiliser le marqueur Not a Number. Ça modifie tes data types, ça ruine les correspondances exactes et ça consomme plus de mémoire. PyArrow résout ça en utilisant une validity bitmap. Au lieu de changer le data type pour gérer une valeur manquante, Arrow garde tes integers en tant qu'integers. Il ajoute un array caché et hautement compressé de 1 et de 0 à côté de tes données. Un 1 indique que la valeur est valide. Un 0 indique qu'elle est manquante. Ton data type reste intact, et le suivi des valeurs manquantes ne coûte presque rien en mémoire. Voici le point clé. Les économies de mémoire sont encore plus extrêmes quand on traite du texte. Traditionnellement, pandas stocke les strings en utilisant le object data type de NumPy. Ça veut dire que la colonne ne contient pas vraiment ton texte. Elle contient des memory pointers. Chaque ligne pointe vers un string object Python standard, dispersé quelque part d'autre dans la mémoire de ton ordinateur. Si tu as dix millions de lignes de texte, tu as dix millions de pointers et dix millions de string objects séparés. L'overhead mémoire est colossal, et itérer dessus est terriblement lent. PyArrow change complètement l'architecture. Quand tu configures tes colonnes pandas pour utiliser un string data type PyArrow, le texte est stocké dans un seul bloc de mémoire contigu. La colonne garde juste la trace des byte offsets. Elle enregistre exactement où chaque mot commence et s'arrête dans ce grand bloc continu. Imagine un dataset à forte cardinalité. Tu as une colonne de strings de user agents ou de transaction IDs uniques. Beaucoup de lignes sont vides. Si tu lis ça dans pandas de la manière traditionnelle, ça utilise par défaut un object array NumPy. Maintenant, dis à pandas d'utiliser plutôt le PyArrow engine, en assignant explicitement un string data type basé sur PyArrow pendant ton étape de lecture. Instantanément, l'empreinte mémoire chute, souvent de cinquante pour cent ou plus. L'amélioration va au-delà des limites de la RAM. Parce que les données sont maintenant regroupées de manière compacte dans une structure conçue pour l'analytique, les opérations de string matching accélèrent. Si tu lances une recherche par regular expression sur cette colonne, le Arrow engine traite les raw bytes directement au niveau du système. Il contourne complètement le lent overhead des objects Python. Tu obtiens des colonnes d'integers qui restent vraiment des integers quand des données manquent, et des opérations sur les strings qui ne mettent pas ton matériel à genoux. Si tu traites du texte ou des données sales, te reposer sur le object array de NumPy est obsolète. Utiliser des data types basés sur PyArrow est le moyen le plus rapide de rendre un pipeline pandas lourd instantanément plus léger. Merci d'avoir écouté, et happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. Maîtriser Pandas moderne, épisode 4 sur 8. Tu as un fichier Parquet de plusieurs gigaoctets avec une centaine de colonnes. Tu n'as besoin que de quatre d'entre elles pour faire tourner tes metrics. Si ton premier réflexe est de charger l'intégralité du fichier dans un dataframe, puis de filtrer les colonnes, tu gaspilles énormément de RAM et de cycles CPU avant même que ton analyse ne commence. La solution réside dans la maîtrise de l'ingestion de données moderne. Le principal bottleneck de l'ingestion de données, ce sont les inputs et outputs disque. Les fonctions read de Pandas, comme read underscore csv et read underscore parquet, scannent les données du disque vers la mémoire. Pour minimiser ce transfert, tu utilises un argument appelé usecols. Tu passes une liste contenant les noms exacts des colonnes que tu veux. Le parser ne lit alors que ces colonnes spécifiques depuis le fichier. Le gain de performance que tu observes dépend fortement de ton format de fichier. Les fichiers CSV stockent les données ligne par ligne. Quand tu utilises usecols avec un CSV, le parser doit quand même parcourir l'intégralité du fichier texte ligne par ligne, mais il ignore immédiatement les colonnes inutiles avant d'allouer de la mémoire pour le dataframe. Les fichiers Parquet, en revanche, stockent les données colonne par colonne. Pour un fichier Parquet de cent colonnes où tu n'as besoin que de quatre colonnes de metrics, passer usecols signifie que le parser ignore complètement les blocs du fichier contenant les quatre-vingt-seize autres colonnes. Il ne lit sur le disque que les octets dont il a absolument besoin. Cela réduit considérablement ton temps de lecture et ton empreinte mémoire. Restreindre les colonnes n'est que la première étape. L'optimisation suivante se passe dans la façon dont Pandas stocke ces colonnes en mémoire. Historiquement, Pandas reposait entièrement sur des arrays NumPy. NumPy est excellent pour le calcul numérique dense, mais il a du mal avec les données textuelles et les valeurs manquantes. Il stocke les strings comme des objets Python dispersés en mémoire, et il force les colonnes d'entiers à devenir des floats juste pour représenter les données manquantes. Pour résoudre ça, Pandas a introduit l'argument dtype backend. Quand tu définis cet argument sur la string pyarrow, Pandas utilise Apache Arrow comme backend pour tes données à la place. Arrow stocke les strings dans des blocs mémoire contigus très performants et utilise un bitmask séparé pour traquer les valeurs manquantes, gardant ainsi tes entiers intacts. Voici le point essentiel. Tu pourrais penser que Pandas lit d'abord les données dans des arrays NumPy, puis les convertit en Arrow. Ce n'est pas ce qui se passe. Quand tu spécifies le backend PyArrow pendant la fonction read, Pandas contourne complètement NumPy pendant la phase de parse. Les données vont directement du fichier sur le disque vers les arrays PyArrow en mémoire. Cela évite la sévère pénalité de performance des allocations mémoire intermédiaires. Regardons la pipeline complète. Tu appelles read underscore parquet. Premièrement, tu passes ton chemin de fichier. Deuxièmement, tu passes usecols avec une liste de tes quatre colonnes de metrics. Troisièmement, tu définis l'argument dtype backend sur pyarrow. Le parser saute directement aux quatre colonnes sur le disque, les extrait et les stream directement dans la mémoire gérée par Arrow. Tu te retrouves avec un dataframe léger et ultra-rapide contenant exactement ce dont tu as besoin, utilisant des types de données modernes. Filtrer les colonnes au niveau de la couche IO plutôt qu'à la couche application est le moyen le plus efficace d'éviter les crashes out-of-memory dans Pandas. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. Maîtriser le Pandas moderne, épisode 5 sur 8. Tu as une liste de dix millions de transactions, et chacune n'a qu'un customer ID. Tu as besoin des vrais noms des clients attachés à ces transactions. Si tu écris une boucle Python ou que tu utilises un mapping de dictionnaire pour faire correspondre ces IDs aux noms, tu gaspilles des cycles CPU et de la mémoire. Pandas a un moteur optimisé spécialement conçu pour les opérations de type SQL en une seule ligne. Aujourd'hui, on parle d'algèbre relationnelle : Merge et Join. Avant d'aller plus loin, clarifions une confusion fréquente. On confond souvent le merge avec la concaténation. La concaténation, c'est juste empiler physiquement des arrays les uns sur les autres ou côte à côte. Le merge est complètement différent. Le merge sert aux joins de bases de données relationnelles. Il aligne les lignes de deux tables différentes en fonction des valeurs de clés partagées. La fonction principale pour ça, c'est pandas point merge. Elle prend deux DataFrames, qu'on appelle la table left et la table right. Repense à notre scénario de transactions. Ton DataFrame left est une énorme fact table contenant des millions d'achats. Ton DataFrame right est une dimension table plus petite contenant les détails des clients, comme les noms et les adresses e-mail. Les deux tables partagent une colonne appelée customer ID. Cette configuration spécifique s'appelle un many-to-one join. Tu as plusieurs transactions qui appartiennent à un seul client. Quand tu les merges en utilisant la clé customer ID, pandas prend l'enregistrement client unique de la table right et le broadcast sur toutes les transactions correspondantes dans la table left. Voici le point clé. Le paramètre le plus critique que tu contrôles, c'est l'argument how. C'est lui qui dicte quelles clés survivent au merge et se retrouvent dans le résultat final. Par défaut, pandas utilise un inner join. Si tu ne spécifies pas l'argument how, le résultat garde uniquement les lignes où le customer ID existe dans les deux tables. Si un client a fait une transaction mais que son enregistrement a été supprimé de la base de données client, cette transaction disparaît complètement de ton résultat mergé. Pour éviter de perdre des données de ta table principale, tu utilises un left join. En passant left à l'argument how, pandas garde chaque ligne de ta table left, qui est ta liste massive de transactions. Si une transaction a un customer ID qui n'existe pas dans la table right, pandas garde quand même la ligne de la transaction mais remplit les détails client manquants avec des valeurs Not a Number. C'est exactement la logique que tu veux quand tu attaches des détails de dimension à une fact table principale. L'exact opposé, c'est un right join. Passer right garde toutes les lignes de la dimension table des clients, peu importe si elles ont des transactions correspondantes dans la table left. Tu te retrouves avec une liste de tous les clients, et ceux qui n'ont rien acheté affichent simplement des valeurs manquantes pour les données de transaction. Enfin, il y a le outer join. Passe outer à l'argument how, et pandas garde tout. Il fait l'union des clés des deux frames. Chaque transaction et chaque client se retrouvent dans le dataset final, avec des valeurs manquantes pour combler les trous là où un match parfait n'est pas trouvé. Le inner join par défaut supprime silencieusement les données non matchées, donc à moins que tu veuilles explicitement filtrer des lignes, tu devrais toujours spécifier un left join quand tu attaches des lookup tables à ton dataset principal. C'est tout pour cet épisode. Merci de ton écoute, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. Maîtriser le Pandas moderne, épisode 6 sur 8. Tu penses probablement que grouper des données, c'est juste compiler des nombres pour trouver un total ou une moyenne. Mais que faire si tu as besoin d'évaluer une seule ligne en fonction du comportement du groupe auquel elle appartient, sans perdre la forme originale de ton dataset ? Ça demande d'aller au-delà des simples résumés et d'utiliser le pattern Split-Apply-Combine. Quand tu appelles une méthode groupby dans pandas, tu déclenches un processus séquentiel en trois étapes. D'abord, il y a le split. Pandas prend tout ton dataset et le divise en groupes indépendants selon une clé que tu fournis. Ensuite, c'est l'étape apply, où une fonction est exécutée sur chaque groupe de façon totalement indépendante des autres. Enfin, l'étape combine prend les résultats de chaque groupe et les assemble pour former une seule structure de données. Beaucoup de développeurs pensent que l'étape apply sert uniquement à l'agrégation. L'agrégation prend un groupe de valeurs et renvoie un seul nombre, comme la somme ou la moyenne. Si tu groupes un dataset de support client par agent et que tu demandes le temps de résolution moyen, tu obtiens un nouveau dataset avec une ligne par agent. C'est utile, mais ce n'est qu'un tiers de l'histoire. Voici le point clé. L'étape apply est tout aussi souvent utilisée pour la transformation et le filtrage. Une transformation effectue un calcul sur le groupe, mais renvoie un objet qui est indexé exactement comme les données d'origine. Elle ne réduit pas le nombre de lignes. Reprenons notre dataset de support client. Tu veux savoir si un ticket spécifique a mis un temps anormalement long à être résolu. Mais un temps inhabituel pour un agent junior peut être un temps normal pour un agent senior qui gère des problèmes très complexes. Tu as besoin du z-score du temps de résolution, par rapport uniquement à la moyenne historique de cet agent spécifique. Tu split les données par agent, et tu appliques une fonction de transformation qui calcule le z-score. Pandas calcule la moyenne et l'écart type pour l'agent A, standardise les tickets de l'agent A, fait exactement la même chose pour l'agent B, puis les combine. Tu récupères ton dataset d'origine, ligne par ligne, mais maintenant chaque ticket a un score standardisé basé strictement sur le contexte de son groupe spécifique. La troisième application principale, c'est le filtrage. Ça te permet d'éliminer des groupes entiers en fonction d'une propriété collective, plutôt que d'évaluer des lignes individuelles. Supposons que tu veuilles analyser ces z-scores de tickets, mais que certains agents dans ton dataset n'aient traité que deux ou trois tickets. Leurs moyennes n'ont aucun sens statistiquement. Tu peux utiliser une fonction filter sur ton objet groupé pour vérifier la taille de chaque groupe. Si un groupe a moins de dix tickets, la logique du filter renvoie false, et pandas supprime chaque ligne appartenant à cet agent. L'étape combine renvoie ensuite un dataset contenant uniquement les tickets des agents avec une taille d'échantillon valide. Tu split les données selon une clé, tu appliques une règle logique qui évalue le groupe, et tu combines les survivants. L'agrégation réduit les données. La transformation standardise les données dans leur contexte local. Le filtrage élimine les données en fonction des règles du groupe. La véritable puissance du pattern split-apply-combine, c'est qu'il te permet de manipuler des lignes individuelles en utilisant le contexte au niveau du groupe, sans jamais écrire de loop manuelle. Si tu trouves ces analyses approfondies utiles et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. Je voudrais prendre un moment pour te remercier de ton écoute, ça nous aide beaucoup. Passe une excellente journée !

Salut, c'est Alex de DEV STORIES DOT EU. Maîtriser le Pandas moderne, épisode 7 sur 8. Coder tes propres agrégations temporelles à la main, c'est un vrai cauchemar avec les intervalles manquants, les années bissextiles et la logique des business days. Si tu te retrouves à écrire du code custom pour arrondir des timestamps bruts dans des buckets réguliers, tu te compliques beaucoup trop la vie. La solution, c'est de maîtriser les time series en utilisant les structures temporelles natives de pandas. L'élément central des fonctionnalités de time series dans pandas, c'est le DatetimeIndex. Au lieu des numéros de ligne entiers classiques, l'index de ton dataframe devient une séquence stricte de timestamps précis. Passer ton index en DatetimeIndex change fondamentalement le comportement du dataframe, en donnant à toute la structure une vraie notion du temps. Ça permet de faire du slicing temporel natif. Si tu as juste besoin des données d'octobre 2023, tu passes la simple string 2023-10 au row locator. Pandas calcule automatiquement les limites exactes à la microseconde pour ce mois et te renvoie le bon subset. Tu peux passer des strings de date partielles jusqu'à l'heure ou la minute, et l'index gère les calculs de timestamps sous-jacents. Une fois que tes données ont cette notion du temps, tu as généralement besoin de les agréger. Beaucoup de développeurs confondent le resampling temporel avec un simple group-by. Ils essaient d'appliquer des opérations de group-by standards sur une colonne de dates. Cette approche ne marche pas quand on gère des time series réelles et désordonnées. Un group-by standard regarde uniquement les lignes explicitement présentes dans ton dataframe. Si un serveur se met hors ligne pendant une heure, une opération de group-by standard va juste sauter cette heure complètement. Ta timeline de sortie aura un trou caché, ce qui va fausser tous tes calculs temporels suivants. Voici le point clé. La méthode point resample est fondamentalement différente parce qu'elle comprend nativement la logique calendaire. Elle projette une grille temporelle rigide et continue sur tes données. Si tu fais un resample par intervalles de dix minutes, et qu'aucune donnée n'arrive pendant une fenêtre spécifique de dix minutes, pandas génère quand même ce bucket. Il laisse les valeurs vides, ce qui préserve la stricte intégrité mathématique de ta timeline. Le resampling comprend intrinsèquement les intervalles vides, les longueurs de mois irrégulières et les calendriers de business days qui excluent les week-ends et les jours fériés. Prends le scénario d'un analyste quantitatif qui traite des données de trading. Tu reçois des données de ticks à haute fréquence depuis une bourse. Les trades individuels arrivent à des intervalles complètement irréguliers, parfois trois par microseconde, parfois aucun pendant vingt secondes. Ton modèle de pricing ne peut pas consommer ce chaos. Il a besoin de bars de cinq minutes parfaitement alignées. Comme les prix de tes trades sont mappés sur un DatetimeIndex, tu appelles la méthode point resample sur ton dataframe et tu passes la string de fréquence 5min. Ça mappe chaque tick erratique sur une grille stricte de cinq minutes. Pour alimenter un modèle financier, tu as spécifiquement besoin des prix Open, High, Low et Close pour chaque bucket. Au lieu d'écrire des fonctions custom pour extraire le premier trade, le maximum, le minimum et le dernier trade de chaque fenêtre, tu chaînes la méthode point ohlc directement sur ton appel resample. Pandas calcule les quatre métriques d'un coup, et sort un dataset proprement structuré de bars de cinq minutes. Les intervalles vides dont on a parlé plus tôt restent intacts dans cet output. Tu peux ensuite chaîner une autre méthode pour faire un forward-fill des prix de clôture précédents dans les trous vides, pour t'assurer que ton modèle a toujours des données valides. Le resampling transforme des enregistrements erratiques et event-driven en une timeline prévisible et mathématiquement solide, sans que tu aies besoin d'écrire une seule ligne de logique calendaire. Merci de m'avoir écouté. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. Maîtriser Pandas moderne, épisode 8 sur 8. Avant de demander une instance cloud massive ou de te tourner vers un cluster de calcul distribué, tu seras peut-être surpris d'apprendre que tu peux traiter des téraoctets de data directement sur ton laptop. La plupart des erreurs out-of-memory ne nécessitent pas un nouveau framework, elles demandent juste de changer ta façon de lire les fichiers. Aujourd'hui, on parle du scaling pour les datasets out-of-core. Le processing out-of-core, ça veut tout simplement dire travailler avec des datasets qui sont plus gros que la mémoire système disponible. Une réaction classique face à un crash out-of-memory, c'est de supposer que pandas a atteint sa limite absolue. Les gens se précipitent souvent pour réécrire leurs pipelines en PySpark ou Dask. Mais pandas peut gérer de la data massive nativement si tu arrêtes d'essayer de charger tout le dataset en RAM d'un seul coup. De simples patterns de générateurs résolvent la grande majorité de ces problèmes de scaling. Le mécanisme principal pour le processing out-of-core, c'est le chunking. Si tu bosses avec un seul fichier texte massif, la fonction read standard accepte un argument chunk size. Quand tu fournis cet argument, pandas arrête de renvoyer un DataFrame. À la place, il renvoie un itérateur. À chaque fois que ton code fait avancer l'itérateur, pandas lit uniquement le nombre de lignes spécifié sur le disque et les renvoie sous forme de DataFrame normal. Tu appliques ta logique à ce chunk, tu extrais le résultat, et tu supprimes le chunk. Comme l'ancienne data est effacée de la mémoire avant que le batch suivant soit lu, ton utilisation de la mémoire reste complètement plate, peu importe la taille du fichier de base. C'est là que ça devient intéressant. L'infrastructure de data moderne repose rarement sur un seul fichier texte géant. En général, les gros datasets sont stockés sous forme de répertoires contenant des centaines de petits fichiers partitionnés, typiquement dans un format binaire comme Parquet. Les fichiers Parquet sont très compressés et se chargent très vite, mais tu ne peux toujours pas charger cinquante gigaoctets de fichiers Parquet dans seize gigaoctets de RAM. Pour gérer ça, tu appliques le concept de chunking manuellement sur l'ensemble des fichiers. Imagine que tu as un répertoire de fichiers Parquet annuels et que tu veux calculer la fréquence totale des catégories sur tout le dataset historique. Tu construis une simple boucle itérative. D'abord, tu initialises une Series pandas vide. Ça servira d'accumulateur pour tes totaux globaux. Ensuite, tu itères sur ton répertoire fichier par fichier. À l'intérieur de la boucle, tu lis le fichier actuel dans un DataFrame. Maintenant, tu lances la fonction value counts sur la colonne spécifique que tu analyses. Ça te donne une Series contenant les fréquences juste pour cette année spécifique. L'étape cruciale, c'est de combiner ce résultat local avec ton accumulateur global. Tu fais ça en appelant la méthode add sur ta Series globale et en lui passant la Series locale. Comme certaines catégories peuvent exister dans un fichier mais pas dans un autre, tu dois définir l'argument fill value à zéro. Ça garantit que pandas aligne correctement les index et additionne les totaux sans introduire de valeurs manquantes. Une fois que la boucle a fini de traiter ce fichier, elle passe au suivant. Python va automatiquement garbage collect l'ancien DataFrame. En fait, tu es en train de streamer un dataset massif à travers la mémoire, un fichier à la fois, en construisant une agrégation globale continue. Le processing out-of-core, ce n'est pas juste balancer du hardware sur un problème. C'est plutôt garder ton état actif petit et descendre les agrégations mathématiques au niveau de chaque chunk individuel. Comme c'est la fin de la série, je t'encourage vivement à explorer la documentation officielle de pandas sur le scaling et à tester ces patterns toi-même avec ta propre data. Si tu as des sujets que tu veux qu'on aborde dans de futures séries, visite devstories dot eu et dis-le-nous. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.