IA & Data

Calcul distribué avec Python

3 jour(s) • 21h

Description

Cette formation de trois jours permet à des ingénieurs déjà autonomes en Python de choisir et mettre en œuvre la bonne stratégie de parallélisation ou de distribution selon la nature de leurs traitements et le matériel disponible. L'objectif n'est pas de couvrir un outil unique, mais de donner une méthode d'arbitrage entre multithreading, programmation asynchrone, multiprocessing, calcul distribué avec Dask et calcul sur GPU, en s'appuyant sur une démarche de diagnostic préalable.

Objectifs pédagogiques

Identifier la nature d'un traitement (CPU-bound, I/O-bound, memory-bound) à partir d'une démarche de profilage
Diagnostiquer un goulot d'étranglement avant toute tentative de parallélisation
Choisir le modèle d'exécution adapté parmi multithreading, asynchrone, multiprocessing, Dask et GPU selon le type de tâche et le matériel disponible
Implémenter un traitement avec Dask sur des volumes importants, y compris dans des scénarios dépassant la mémoire disponible
Comparer les performances des différentes approches sur des cas représentatifs du métier
Évaluer l'opportunité d'un portage de calcul sur GPU et en mesurer les conditions et les limites

Public concerné

Ingénieurs d'études exploitant Python au quotidien

Profils data scientist / data analyst

Développeurs scientifiques et géomaticiens amenés à paralléliser ou distribuer des traitements Python

Prérequis

Pratiquer Python au quotidien et maîtriser son écosystème scientifique (NumPy, Pandas)

Avoir un usage, même empirique, de la librairie multiprocessing

Être à l'aise avec les notions de données volumineuses et de traitement par lots

Déroulé du programme

Séquence 1 : Concurrence, parallélisme et GIL (1h30)

Rappels structurants : processus vs threads, concurrence vs parallélisme, latence vs débit
Le GIL (Global Interpreter Lock) : rôle, mécanisme, ce qu'il autorise et ce qu'il empêche réellement
Conséquences concrètes sur le choix d'une stratégie de parallélisation
Distinction CPU-bound vs I/O-bound comme critère de décision déterminant
Évolutions récentes autour du GIL, notamment les builds free-threaded (Python 3.13+) : intérêt, limites, maturité et impact réel en production
TP : classer une série de traitements représentatifs selon leur nature (CPU-bound / I/O-bound) et anticiper la stratégie adaptée

Séquence 2: Profilage et diagnostic avant parallélisation (1h30)

Pourquoi mesurer avant de paralléliser : éviter d'optimiser au mauvais endroit
Mesure des temps d'exécution : time, timeit, profileurs (cProfile, line_profiler)
Identification de la nature de la charge : CPU-bound, I/O-bound, memory-bound
Repérage des coûts cachés : sérialisation, copies de données inutiles, transferts mémoire
Notion de granularité de tâche : équilibre entre parallélisme et surcoût de coordination
TP : profilage d'un traitement représentatif, identification du goulot d'étranglement

Séquence 3: Multithreading et programmation asynchrone (2h00)

threading : cas d'usage pertinents (I/O-bound), synchronisation, limites liées au GIL
asyncio : boucle d'événements, coroutines, async / await, cas d'usage adaptés
concurrent.futures : interface haut niveau pour threads et processus
Positionnement clair : outils d'arbitrage pour les cas I/O, non solution au calcul CPU intensif
TP : parallélisation d'un traitement I/O-bound, mesure du gain réel

Séquence 4 : Multiprocessing raisonné (2h00)

Le module multiprocessing: Process, Pool, map/apply
Contournement du GIL par la multiplication des processus pour les tâches CPU-bound
Consolidation de la pratique existante : passage d'un usage empirique à un usage argumenté
TP: parallélisation d'un traitement CPU-bound, comparaison des temps selon le nombre de processus

Séquence 5 : Multiprocessing avancé et limites du modèle mono-machine (1h30)

Coût de la sérialisation (pickle) et du transfert de données entre processus
Partage de données : Queue, Pipe, mémoire partagée
Consommation mémoire, granularité des tâches, plafond de scalabilité sur une seule machine
Identification du moment où le multiprocessing atteint ses limites et où la distribution devient nécessaire
TP : mise en évidence du surcoût de sérialisation sur un cas concret

Séquence 6: Dask, concepts fondamentaux (2h00)

Positionnement de Dask : bibliothèque de calcul parallèle et distribué, au-delà de la mémoire et de la machine unique
Graphe de tâches et évaluation paresseuse (lazy evaluation)
Les schedulers Dask (local threads, local processus, distribué) et leurs usages respectifs
Le tableau de bord (dashboard) pour visualiser et diagnostiquer l'exécution
TP : construction et exécution d'un graphe de calcul, lecture du dashboard

Séquence 7: Dask Array et Dask DataFrame (2h00)

Dask Array : parallélisation des opérations de type NumPy, notion de chunks et dimensionnement
Dask DataFrame : parallélisation des opérations de type Pandas, notion de partitions
Bonnes pratiques : dimensionnement des chunks et partitions, opérations coûteuses à éviter
TP : traitement d'un jeu de données volumineux, comparaison avec l'approche Pandas / NumPy classique

Séquence 8: TP métier, traitement volumineux appliqué (1h30)

Mise en situation sur une chaîne de traitement inspirée de cas géomatiques : données raster, vectorielles ou tabulaires volumineuses (lecture de formats vectoriels via Fiona, manipulation avec GeoPandas / Shapely, données raster avec Rasterio)
Application concrète des bonnes pratiques de dimensionnement vues précédemment
TP: confrontation des choix d'architecture (chunks, partitions) à un cas proche du métier des apprenants

Séquence 9: Opportunité du calcul sur GPU (1h30)

Modèle d'exécution GPU : architecture massivement parallèle, notion de kernel
Types de calculs qui bénéficient du GPU et ceux qui n'en tirent aucun gain
Coût de transfert des données entre CPU (hôte) et GPU, et son impact sur le bilan de performance
Critères de décision pour envisager un portage sur GPU dans un contexte data science et géomatique
TP : analyse d'un cas de traitement pour statuer sur la pertinence d'un portage GPU

Séquence 10 : CuPy, RAPIDS et PyTorch (2h00)

CuPy: équivalent GPU de NumPy, portage de code existant, points de compatibilité et limites
Écosystème RAPIDS : cuDF (traitement DataFrame proche de Pandas), cuML (ML accéléré, API proche de scikit-learn)
Articulation avec PyTorch, déjà utilisé par les apprenants : manipulation de tenseurs, exécution de calculs GPU au-delà du strict cadre deep learning
Point d'attention sur l'environnement : dépendance à la version CUDA, aux drivers Nvidia, à Python et à l'OS ; l'installation de RAPIDS / CuPy nécessite un environnement validé au préalable
TP: portage d'un calcul NumPy vers CuPy et lecture comparative des résultats

Séquence 11 : Démonstration ou TP GPU selon environnement disponible (1h30)

Portage d'un calcul NumPy vers CuPy et comparaison de performance
Modalité conditionnée à la disponibilité d'un environnement GPU Nvidia préconfiguré et validé : démonstration, ou TP si l'environnement est prêt
Lecture critique des résultats : gain réel, coût de transfert, cas où le GPU n'apporte pas d'avantage
TP ou démonstration : mesure comparative CPU / GPU sur un traitement représentatif

Séquence 12: Cas métier et grille d'arbitrage (2h00)

Application aux traitements réels des apprenants : traitement d'images (OpenCV), calcul vectoriel et géospatial, machine learning
Exemples inspirés de l'écosystème géomatique (GeoPandas, Shapely, Fiona, Rasterio), du traitement d'images (OpenCV) et scientifique (SciPy, scikit-learn)
Synthèse transversale : grille d'arbitrage entre profilage, multithreading, asyncio, multiprocessing, Dask et GPU
TP : sur un cas métier apporté, choisir et justifier la stratégie de parallélisation la plus adaptée