-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.qmd
1264 lines (769 loc) · 40.9 KB
/
index.qmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
---
title: Mise en production des projets de data science
subtitle: |
ENSAE 3A - 2023/2024
author:
- Romain Avouac
- Lino Galiana
# date:
slide-number: true
footer: |
Bonnes pratiques pour la mise en production des projets de data science
# uncomment for French presentations:
lang: fr-FR
# for blind readers:
slide-tone: false
chalkboard: # press the B key to toggle chalkboard
theme: whiteboard
# uncomment to use the multiplex mode:
#multiplex: true
format:
# pick the light mode (onyxia-revealjs) or the dark mode (onyxia-dark-revealjs)
onyxia-revealjs:
#onyxia-dark-revealjs:
incremental: true
output-file: index.html
controls: true
css: custom.css
from: markdown+emoji
---
# Introduction
## Ressources associées
:::: {.columns}
::: {.column width="50%"}
### Slides
{{< qrcode https://ensae-reproductibilite.github.io/slides/ qr1 width=400 height=400 >}}
:::
::: {.column width="50%"}
### Site web
{{< qrcode https://ensae-reproductibilite.github.io/website/ qr2 width=400 height=400 >}}
:::
::::
## Contexte
- [**Qui sommes-nous ?**]{.orange}
- des [**data scientists**]{.blue2} de l'Insee
- frustrés par l'[**approche**]{.blue2} souvent purement [**technique**]{.blue2} de la data science
- convaincus que les [**bonnes pratiques de développement**]{.blue2} valent à être enseignées
## Qu'est ce qu'un data scientist ?
{fig-align="center" height=250}
- Tendance à la [**spécialisation**]{.orange} : *data analyst*, *data engineer*, *ML Engineer*...
- Rôle d'[**interface**]{.orange} entre métier et équipes techniques
- [**Compétences mixtes**]{.blue2} : savoir métier, modélisation, IT
## La notion de mise en production
- [**Mettre en production**]{.orange} : faire [**vivre**]{.blue2} une application dans l'espace de ses [**utilisateurs**]{.blue2}
- Notion simple mais mise en oeuvre compliquée !
- [**Dépasser le stade de l'expérimentation**]{.orange}
- Comprendre les [**besoins**]{.blue2} des utilisateurs
- [**Bonnes pratiques**]{.blue2} de développement
- Techniques informatiques d'[**industrialisation**]{.blue2}
## La notion de bonnes pratiques
- [**Origine**]{.blue2} : communauté des développeurs logiciels
- [**Constats**]{.blue2} :
- le [_"code est plus souvent lu qu'écrit"_]{.green2} ([Guido Van Rossum](https://fr.wikipedia.org/wiki/Guido_van_Rossum))
- la maintenance d'un code est très coûteuse
- [**Conséquence**]{.blue2} : un ensemble de [**règles informelles**]{.orange}, conventionnellement acceptées comme produisant des logiciels [**fiables**]{.orange}, [**évolutifs**]{.orange} et [**maintenables**]{.orange}
## Pourquoi s'intéresser aux bonnes pratiques ?
<br>
L'activité du *datascientist* tend à se rapprocher de celle du développeur :
- projets [**intenses en code**]{.blue2}
- [**projets collaboratifs**]{.blue2} et de grande envergure
- [**complexification**]{.blue2} des données et des [**infrastructures**]{.blue2}
- [**déploiement**]{.blue2} d'applications pour valoriser les modèles
## Contenu du cours {.scrollable}
- [**Pré-requis**]{.orange}
- Introduction au terminal `Linux`
- [**Contrôle de version**]{.blue2} avec `Git`
- [**Bonnes pratiques**]{.orange} de développement
- [**Travail collaboratif**]{.blue2} avec `Git`
- [**Qualité**]{.blue2} du code
- [**Structure**]{.blue2} des projets
- Traitement des [**données volumineuses**]{.blue2}
- Favoriser la [**portabilité**]{.blue2} d'une application
- [**Mise en production**]{.orange}
- [**Déploiement**]{.blue2}
- [**MLOps**]{.blue2}
## Site web du cours
- [https://ensae-reproductibilite.github.io/website/](https://ensae-reproductibilite.github.io/website/)
- Tout le contenu du cours est en [***open-source***]{.orange}
- [GitHub](https://github.com/orgs/ensae-reproductibilite/repositories) {{< fa brands github >}}
- *Pull Requests* -> bonus {{< fa comment-dollar >}}
## Modalités pédagogiques
- Apprentissage par la pratique
- [Application](https://ensae-reproductibilite.github.io/website/chapters/application.html) : industrialisation d'un projet de ML
- Langage : `Python` {{< fa brands python >}}
- Langage [**dominant**]{.blue2} dans le monde de la donnée
- Les principes présentés sont [**agnostiques**]{.blue2} au langage
- Environnement d'exécution : [SSP Cloud](https://datalab.sspcloud.fr/)
- Environnement de développement [**normalisé**]{.blue2}
- Véritable environnement de [**production**]{.blue2}
- Acquisition des [**bonnes pratiques**]{.blue2}
## Evaluation
- [**Objectif**]{.orange} : mise en pratique [**réaliste**]{.orange} des notions étudiées
- [**Problématique métier**]{.blue2}
- [**Données réelles**]{.blue2}
- Evaluation en [**deux parties**]{.orange} :
- [**En groupe**]{.blue2} : [**projet**]{.blue2} à construire selon 3 "parcours"
- [**Individuel**]{.blue2} : [**revue de code**]{.blue2} d'un autre projet
# Partie :one: : bonnes pratiques de développement
## Plan de la partie
:one: [**Travail collaboratif**]{.blue2} avec `Git`
:two: [**Qualité**]{.blue2} du code
:three: [**Structure**]{.blue2} des projets
:four: Traitement des [**données volumineuses**]{.blue2}
:five: Favoriser la [**portabilité**]{.blue2} d'une application
# :one: Le travail collaboratif avec `Git`
## Pourquoi utiliser Git ?
](img/timeline.png){fig-align="center" height=475}
## Concepts essentiels
](img/gitallinone.png){height="400" fig-align="center"}
## Bonnes pratiques {auto-animate=true .smaller}
__Que versionne-t-on ?__
- Essentiellement du [**code source**]{.orange}
- [__Pas d'outputs__]{.orange} (fichiers `.html`, `.pdf`, modèles...)
- [__Pas de données__]{.orange}, d'informations locales ou sensibles
. . .
:::{.callout-note}
Pour définir des règles qui évitent de committer tel ou tel fichier, on utilise
un fichier nommé __`.gitignore`__.
Si on mélange du code et des éléments
annexes (_output_, données...) dans un même dossier, il [__faut consacrer du temps à ce fichier__]{.orange}.
Le site [`gitignore.io`](https://www.toptal.com/developers/gitignore) peut vous fournir
des modèles.
N'hésitez pas à y ajouter des règles conservatrices (par exemple `*.csv`),
comme cela est expliqué dans [la documentation `utilitR`](https://www.book.utilitr.org/git.html?q=gitignore#gitignore).
:::
## Bonnes pratiques {auto-animate=true .smaller}
__Format des commits__
::: {layout="[40,60]"}
- [**Fréquence**]{.orange}
- Aussi souvent que possible
- Le lot de modifications doit "faire sens"
- [**Messages**]{.orange}
- Courts et informatifs (comme un titre de mail)
- Décrire [**le pourquoi plutôt que le comment**]{.orange} dans le texte
:::
## Outils pour le travail collaboratif
- L'éco-système `Git` [**facilite** le travail collaboratif]{.blue2}
- `Git` {{< fa brands git-alt >}} : modèle des [__branches__]{.orange}
- `GitHub` {{< fa brands github >}} / `GitLab` {{< fa brands gitlab >}} : [**Issues**, **Pull Requests**, **Forks**]{.orange}
## Le modèle des branches
::: {layout="[[-1], [1], [-1]]"}
](img/branches.png){fig-align="center" height=350}
:::
## Les outils de contribution
- [***Issue***]{.orange} : soumettre un [**problème**]{.blue2} ou une [**suggestion**]{.blue2} aux développeurs d'un projet
- [***Pull Request***]{.orange} : proposer aux développeurs d'un projet d'[**intégrer des modifications**]{.blue2}
- [***Fork***]{.orange} : faire la [**copie**]{.blue2} d'un projet existant dans son espace personnel
- Indispensable pour faire une *pull request* à un dépôt sur lequel on n'a pas les droits
## Une organisation courante : le *GitHub flow*
Description plus détaillée : [ici](https://docs.github.com/en/get-started/quickstart/github-flow)
# :two: Qualité du code
## Enjeux
- D'une vision utilitariste du code à une vision du code comme [**outil de communication**]{.orange}
- Favoriser la [**lisibilité**]{.orange} et la [**maintenabilité**]{.orange}
- Faciliter la [**réutilisation**]{.orange}
## Principes généraux
- Adopter les [**standards communautaires**]{.orange}
- Utiliser des [**fonctions**]{.orange}
- [**(Auto-)documenter**]{.orange} son code
## :one: Standards communautaires
> *"Good coding style is like correct punctuation: you can manage without it, butitsuremakesthingseasiertoread"*
>
> [Tidyverse Style Guide (R)](https://style.tidyverse.org/)
- [**Python**]{.blue2} : [PEP8](https://peps.python.org/pep-0008/), [PEP 257](https://peps.python.org/pep-0257/)
- Des règles *opinionated*, mais [**conventionnelles**]{.blue2}
- La [**cohérence intra-projet**]{.orange} doit toujours primer
## :one: Standards communautaires - Outils {.smaller}
- [**Linters**]{.blue2} : diagnostic de qualité du code
- [Pylint](https://github.com/PyCQA/pylint)
- [**Formatters**]{.blue2} : application automatique des standards
- [Black](https://github.com/psf/black)
. . .
::: {.callout-tip}
- [Exemples d’erreurs repérées]{.blue2} par un _linter_ :
+ lignes de code trop longues ou mal indentées, parenthèses non équilibrées, noms de fonctions mal construits…
- [Exemples d’erreurs __non__ repérées]{.blue2} par un _linter_ :
+ fonctions mal utilisées, arguments mal spécifiés, structure du code incohérente, code insuffisamment documenté…
:::
## :two: Utiliser des fonctions {.smaller}
::: {.callout-important}
## Règle d'or
Il faut utiliser une [**fonction**]{.red2} dès qu'on utilise une même
portion de code plus de deux fois ([**_don't repeat yourself_ (DRY)**]{.red2})
:::
- [**Limite les risques d'erreurs**]{.orange} liés aux copier/coller
- Rend le code [**plus lisible**]{.orange} et [**plus compact**]{.orange}
- [**Un seul endroit**]{.orange} du code à modifier lorsqu'on souhaite modifier le traitement
- Facilite la [**réutilisation**]{.orange} et la [**documentation**]{.orange} du code !
. . .
::: {.callout-tip}
## Règles pour écrire des fonctions **pertinentes**
- Une tâche = une fonction
- Une tâche complexe = un enchaînement de fonctions réalisant chacune une tâche simple
- Limiter l'utilisation de variables globales.
:::
## :three: Documenter son code
- Documenter le [__pourquoi__]{.orange} plutôt que le [__comment__]{.orange}
- Privilégier l'[**auto-documentation**]{.orange} via des nommages pertinents
. . .
::: {.callout-tip}
## Comment bien documenter un script ?
- [**Minimum**]{.orange} 🚦 : décrire ce que le code fait au début du script
- [**Bien**]{.orange} 👍 : commenter les parties "délicates" du code
- [**Idéal**]{.orange} 💪 : documenter ses fonctions avec des *docstrings*
:::
# :three: Structure des projets
## Enjeux
- Favoriser la [**lisibilité**]{.orange} et la [**maintenabilité**]{.orange}
- Enjeux spécifiques à la data science
- [**Expérimentation**]{.blue2}
- [**Non-linéarité**]{.blue2}
- [**Reproductibilité**]{.blue2}
## Principes généraux
- Favoriser une [**structure modulaire**]{.blue2} selon l'état du projet
- [**Exploration**]{.orange} : travail à partir de [**notebooks**]{.blue2}
- [**Industrialisation**]{.orange} : adopter une structure type [**package**]{.blue2}
- Adopter les [**standards communautaires**]{.orange}
- [**(Auto-)documenter**]{.orange} son projet
## :one: Phase d'exploration : *notebooks*
- [**Avantages**]{.orange}
- [**Interactivité**]{.blue2} : idéal pour l'expérimentation
- [**Communication**]{.blue2} : diffusion de résultats sous forme exécutable
- [**Inconvénients**]{.orange}
- [**Reproductibilité**]{.blue2} généralement limitée
- Pas adaptés pour l'[**automatisation**]{.blue2}
- Mal gérés par le [**contrôle de version**]{.blue2}
## :two: Industrialisation : structure modulaire
- [**Premier niveau**]{.orange} : structuration du [**code**]{.orange}
- Adopter une structure type [**package**]{.orange}
- Des [**fonctions**]{.blue2} rangées dans des [**modules**]{.blue2}
- Un script principal (`main`) [**orchestre**]{.blue2} les traitements
- Utilisation de [**chemins relatifs**]{.blue2} uniquement
## :two: Industrialisation : structure modulaire
- [**Deuxième niveau**]{.orange} : structuration du [**projet**]{.orange}
. . .
{fig-align="center" height=350}
## :three: Adopter les standards communautaires
- [**Templates**]{.orange} de projets : [**Cookiecutters**]{.blue2}
- [Cookiecutter Data Science](https://drivendata.github.io/cookiecutter-data-science/)
- [Cookiecutter Python Package](https://py-pkgs.org/03-how-to-package-a-python#creating-a-package-structure)
- La [**cohérence intra-projet**]{.orange} doit toujours primer
## :four: Documenter son projet
- Favoriser l'[**auto-documentation**]{.orange} via des nommages pertinents
## L'auto-documentation : illustration
```
├── report.ipynb
├── correlation.png
├── data.csv
├── data2.csv
├── fig1.png
├── figure 2 (copy).png
├── report.pdf
├── partial data.csv
├── script.py
└── script_final.py
```
- Difficile de rentrer dans le projet...
- Tout au [**même niveau**]{.blue2}
- Titres [**non informatifs**]{.blue2}
## L'auto-documentation : illustration
```
├── data
│ ├── raw
│ │ ├── data.csv
│ │ └── data2.csv
│ └── interim
│ └── partial data.csv
├── notebooks
│ └── report.ipynb
├── src
| ├── script.py
│ └── script_final.py
└── reports
├── report.pdf
└── figures
├── fig1.png
├── figure 2 (copy).png
├── figure10.png
└── correlation.png
```
- Une structure déjà plus lisible !
- Les titres restent [**non informatifs**]{.blue2}
## L'auto-documentation : illustration
```
├── data
│ ├── raw
│ │ ├── dpe_logement_202103.csv
│ │ └── dpe_logement_202003.csv
│ └── interim
│ └── dpe_logement_merged_preprocessed.csv
├── notebooks
│ └── report.ipynb
├── src
| ├── main.R
| ├── preprocessing.R
│ └── generate_plots.R
└── reports
├── report.pdf
└── figures
├── histogram_energy_diagnostic.png
├── barplot_consumption_pcs.png
├── correlation_matrix.png
└── correlation.png
```
- Une structure [**auto-documentée**]{.blue2}
- On comprend le projet sans même lire le code
## :four: Documenter son projet
- Favoriser l'[**auto-documentation**]{.orange} via des nommages pertinents
- Inclure un fichier `README.md` à la racine du projet
- [**Carte d'identité**]{.blue2} et [**vitrine**]{.blue2} du projet
- Présente le [**contexte**]{.blue2} et le [**fonctionnement**]{.blue2} du projet
- Si [**open-source**]{.orange} : inclure une [licence](https://docs.github.com/fr/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository)
# Application
## Bonnes pratiques de développement
- Consignes sur le [site du cours](https://ensae-reproductibilite.github.io/website/chapters/application.html)
- Partie :zero: : initialisation de l'environnement et du projet
- Partie :one: : qualité du code
- Partie :two: : adoption d'une structure modulaire
# :four: Traitement des données volumineuses
## "The obligatory intro slide"
](img/intro-big-data.png){fig-align="center" height=400}
## Enjeux
- Tendance à la [**massification**]{.orange} des données
- Relatif aux [**capacités de stockage et de traitement**]{.blue2}
. . .
](img/vvv.png){fig-align="center" height=350}
## Choisir des technologies adaptées
:one: [**Infrastructures**]{.orange} de données
. . .
:two: [**Formats**]{.orange} de données
. . .
:three: [***Frameworks***]{.orange} de traitement de données
## :one: Infrastructures : historique {.scrollable}
- Historiquement : stockage dans des [**bases de données**]{.orange}
- 80's : essor des [bases de données relationnelles](https://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es_relationnelle)
- Modèle de la [***data warehouse***]{.orange}
. . .
](img/data-warehouse.png){height="250" fig-align="center"}
## :one: Limite des *data warehouses*
- Peu adaptées aux données *big data*
- Passage à l'échelle [**coûteux**]{.blue2}
- Limitées aux [**données structurées**]{.blue2}
- 2010's : modèle du [***data lake***]{.orange}
## :one: Le *data lake* {.scrollable}
- Un stockage [**peu coûteux**]{.orange} fait pour des [**données**]{.orange}
- [**Volumineuses**]{.blue2}
- [**Brutes**]{.blue2}
- Issues de [**sources variées**]{.blue2}
. . .
](img/datalake.png){height="400" fig-align="center"}
## :one: Le stockage objet
- [**Standard**]{.orange} des *data lakes* dans le [***cloud***]{.orange}
- Implémentation dominante : [Amazon S3](https://aws.amazon.com/fr/s3/)
- Implémentation open-source : [MinIO](https://min.io/)
. . .
](img/minio.svg){height="300" fig-align="center"}
## :two: Formats de données
::: {.incremental}
- Le choix d'un format de données répond à un [**arbitrage**]{.orange} entre plusieurs critères :
- [**Public cible**]{.blue2}
- [**Finalité**]{.blue2} (traitement, analyse, diffusion)
- [**Volumétrie**]{.blue2}
- [**Interopérabilité**]{.blue2}
:::
## :two: Limites des formats usuels
- Les [**formats usuels**]{.orange} (`CSV`, `JSON`, `XML`) sont utiles pour :
- Le traitement de [**faibles volumes**]{.blue2} de données
- La [**diffusion**]{.blue2} de données
- [**Limités**]{.orange} pour le traitement de [**données volumineuses**]{.orange}
- [**Non-compressés**]{.blue2} : espace disque élevé
- [**Orientés ligne**]{.blue2} : peu adaptés aux traitements analytiques
## :two: Orientation ligne vs. orientation colonne {.scrollable}
](img/row-column.png){height="350" fig-align="center"}
## :two: `Parquet` : propriétés
- [**Orienté colonne**]{.orange}
- Adapté aux [**traitements analytiques**]{.blue2}
- Conçu pour être écrit une fois mais lu fréquemment
- [**Optimisé**]{.orange}
- [**Compression**]{.blue2} (jusqu'à 87 % moins d'espace qu'un CSV)
- [**Lecture**]{.blue2} du fichier (jusqu'à 34x plus rapide qu'un CSV)
- [**Interopérable**]{.orange}
- Gestion native des [**méta-données**]{.blue2}
## :two: `Parquet` : partitionnement
- [**Division en blocs**]{.orange} des données selon un [**critère**]{.orange}
- [**Optimise la lecture**]{.blue2} pour certaines *queries*
. . .
](img/partitions.png){fig-align="center"}
## :three: Traitement *in-memory*
- `Parquet` ne résout pas tout
- L'espace disque est optimisé
- Les données décompressées doivent [**passer en RAM**]{.blue2}
- Le *framework* adapté dépend de la [**volumétrie**]{.orange}
## :three: Données volumineuses
- Calcul [***larger than memory* optimisé**]{.blue2}
- [Arrow](https://arrow.apache.org/overview/) : orientation fichier (`Parquet`)
- [DuckDB](https://duckdb.org/) : orientation base de données (`SQL`)
- Autre avantage : [**interopérabilité**]{.blue2}
. . .
](img/arrow-interoperability.png){fig-align="center"}
## :three: Données massives
- Calcul [**distribué**]{.blue2} sur un [**cluster**]{.blue2} de machines
- [Spark](https://spark.apache.org/)
- Base : [**paradigme MapReduce**]{.blue2}
. . .
](img/mapreduce.png){fig-align="center" height="350"}
## En résumé : pour traiter la volumétrie
- Utiliser un [**format**]{.orange} de données adapté (`Parquet`)
- Utiliser des [**outils**]{.orange} informatiques adaptés
- Suffisant la plupart du temps : [**calcul *larger than memory* optimisé**]{.blue2} (`Arrow` / `DuckDB`)
- Si volumétrie massive : [**calcul distribué**]{.blue2} (`Spark`)
## "Big Data is dead" ?
- Jordan Tigani : [Big Data is dead](https://motherduck.com/blog/big-data-is-dead/)
- "The big data frontier keeps receding"
- "Most people don't have that much data"
- "Most data is rarely queried"
- Plaidoyer pour une [**parcimonie**]{.orange}...
- ... qui [**facilite la mise en production**]{.blue2} !
# :five: Portabilité
## "It works... on my machine" {.scrollable}
- On a construit un projet [**lisible**]{.orange}, [**structuré**]{.orange} et [**versionné**]{.orange}
- Peut-on [**partager**]{.orange} notre projet ?
- En théorie, oui !
- En pratique, c'est toujours plus compliqué...
. . .
](img/IWOMM.jpg){fig-align="center" height=350}
## Le critère de la portabilité
- Un code ne vit jamais dans une bulle isolée, il contient en général de nombreuses [**adhérences**]{.orange}
- Des [**dépendances**]{.blue2}
- Des [**librairies système**]{.blue2}
- Un code est [**portable**]{.orange} s'il peut être exécuté dans un environnement différent que celui du développement
## Limites du mode de travail usuel
- *Workflow* [**classique**]{.orange}
- Installer une distribution de `Python` sur son poste
- Développer un projet en installant les packages nécessaires
- Passer au projet suivant et ainsi de suite
- Quels [**problèmes**]{.orange} peuvent se poser ?
## Limites du mode de travail usuel
- [**Conflits de version**]{.orange} : différents projets peuvent requérir des versions différentes d'un même *package*
- [**Version de `Python` fixe**]{.orange}, celle de l'installation système
- [**Reproductibilité limitée**]{.orange} : difficile de dire quel projet nécessite quel package
- [**Portabilité limitée**]{.orange} : difficile de fixer dans un fichier les dépendances spécifiques à un projet
## Comment favoriser la portabilité ?
- Enjeu central pour la [**mise en production**]{.orange}
- Passer d'un [**environnement de développement**]{.blue2} à un [**environnement de production**]{.blue2}
- Besoin de [**nouveaux outils**]{.orange}
- Les [**environnements virtuels**]{.blue2}
- Les [**conteneurs**]{.blue2}
## Environnements virtuels : fonctionnement {.scrollable}
- [**Dossier auto-suffisant**]{.orange} qui :
- contient un [**intepréteur**]{.blue2} `Python` et des [**packages**]{.blue2}
- est [**isolé**]{.orange} des autres environnements existants
. . .
](img/venv.png){fig-align="center" height=350}
## Environnements virtuels : implémentations
- Implémentation standard : [venv](https://docs.python.org/fr/3/library/venv.html)
- Une implémentation populaire en data science : [conda](https://docs.conda.io/en/latest/)
- Également un *package manager* (comme [pip](https://pip.pypa.io/en/stable/getting-started/), mais multi-langages)
- D'autres implémentations existent : [virtualenv](https://virtualenv.pypa.io/en/latest/), [pyenv](https://github.com/pyenv/pyenv)...
## `venv` : utilisation
- `venv` fait partie de la librairie standard de `Python`
- Utilisation basique (sous `Linux`)
- [**Créer**]{.orange} un environnement : `python -m venv myenv`
- [**Activer**]{.orange} l'environnement : `source myenv/bin/activate`
- [**Installer**]{.orange} des packages : `pip install scikit-learn`
- [**Quitter**]{.orange} l'environnement : `deactivate`
## Spécifier les dépendances
- Développer dans un [**environnement virtuel**]{.orange} favorise :
- la [**reproductibilité**]{.blue2} : fixer les packages utilisés et leurs versions
- la [**portabilité**]{.blue2} : distribuer ces spécifications
- [**Convention**]{.orange} : fichier `requirements.txt` à la [**racine**]{.blue2} du projet (à *commit* !)
- [**Génération**]{.blue2} : `pip freeze > requirements.txt`
- [**Installation**]{.blue2} : `pip install -r requirements.txt`
## Le fichier `requirements.txt`
```python
beautifulsoup4==4.12.3
expecttest!=0.2.0
networkx>=3.0.0
numpy
pandas
```
- [**Arbitrage**]{.orange} à trouver entre :
- [**Reproductibilité**]{.blue2} : [**spécifier**]{.blue2} finement les versions
- [**Sécurité**]{.blue2} : laisser les versions [**évoluer**]{.blue2}
## Environnements virtuels : limites
- [**Reproductibilité**]{.orange} :
- [**Version de `Python`**]{.blue2} non-gérée
- [**Librairies système**]{.blue2} non-gérées
- Peu adaptés aux environnements de [**production**]{.orange} :
- Reproductibilité limitée -> [**portabilité limitée**]{.blue2}
- [**Lourdeur**]{.blue2} de gestion des environnements
## Le *gold-standard* de la portabilité
- [**Idée**]{.orange} : au lieu de distribuer la recette pour recréer la bonne machine, peut-on [**distribuer directement la bonne machine**]{.orange} ?
- On ne peut pas distribuer des [**machines physiques**]{.blue2}
- Les [**machines virtuelles**]{.blue2} sont [**coûteuses**]{.blue2} à redistribuer
- Les [**conteneurs**]{.orange} offrent le compromis idéal
## Conteneurs vs. machines virtuelles
](img/docker-vm.png)
## Conteneurs : implémentations
- Plusieurs implémentations des conteneurs
- [**`Docker`**]{.blue2} est largement prédominant
. . .
{fig-align="center" height=200}
## `Docker` : installation
- `Docker` : outil en ligne de commande (CLI)
- [Instructions](https://docs.docker.com/get-docker/) selon le système d'exploitation
- Environnement "bac à sable" : [Play with Docker](https://labs.play-with-docker.com/)
. . .
{fig-align="center" height=350}
## Le `Dockerfile`
- Exemple : [conteneurisation d'une API avec FastAPI](https://fastapi.tiangolo.com/deployment/docker/)
. . .
```Dockerfile
# Image Docker de base
FROM python:3.11
# Définition du répertoire de travail
WORKDIR /code
# Copie des fichiers nécessaires sur l'image
COPY requirements.txt /code/requirements.txt
# Installation des dépendances
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt && \
python -m spacy download en_core_web_sm
COPY app/ code/app
# Commande lancée par l'image au runtime
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "80", "--proxy-headers"]
```
## `Docker` : fonctionnement
](img/docker-workflow.png){fig-align="center"}
## `Docker` en pratique
- Présentation détaillée sur la [page du cours](https://ensae-reproductibilite.github.io/website/chapters/portability.html#les-conteneurs)
- [**Concepts**]{.blue2} (*caching*, *buildtime/runtime*)
- [**Commandes**]{.blue2} essentielles
- [**Application**]{.blue2} à un exemple concret
# Application
## Portabilité du projet
- Consignes sur le [site du cours](https://ensae-reproductibilite.github.io/website/chapters/application.html)
- Partie :three: : construction d’un projet [**portable**]{.orange} et [**reproductible**]{.orange}
- Construire un [**environnement virtuel**]{.blue2} pour le projet
- [**Conteneuriser**]{.blue2} l'application avec `Docker`
# Partie :two: : mise en production
## Le "mur de la production"
- La majorité des projets "*data-driven*" [**ne délivrent pas de valeur**]{.blue2} ([1](https://sloanreview.mit.edu/projects/expanding-ais-impact-with-organizational-learning/), [2](https://hdsr.mitpress.mit.edu/pub/2fu65ujf/release/6), [3](https://www.researchgate.net/publication/346647451_Beyond_the_Hype_Why_Do_Data-Driven_Projects_Fail))
- Comment [**dépasser le stade de l'expérimentation**]{.orange} ?
## Mise en production
- [**Mettre en production**]{.orange} : faire [**vivre**]{.blue2} une application dans l'espace de ses [**utilisateurs**]{.blue2}
- [**Servir**]{.orange} : [**déployer**]{.blue2} l'application dans un [**format pertinent**]{.blue2} auprès de ses utilisateurs potentiels
- [**Faire vivre**]{.orange} : gérer le [**cycle de vie**]{.blue2} et favoriser l'[**amélioration continue**]{.blue2}
- [**Multiples dimensions**]{.orange} : connaissance métier, organisation, infrastructure, outils techniques..
## Favoriser la continuité
](img/exploration-production.png){fig-align="center"}
- [**Comment faire ?**]{.orange}
- Application des [**bonnes pratiques**]{.blue2} de développement
- Besoin de [**nouveaux concepts et outils**]{.blue2} : [DataOps](https://dataopsmanifesto.org/fr/)
## Le DataOps
- Origine : mouvement [DevOps](https://fr.wikipedia.org/wiki/Devops)
. . .
](img/devops.png){fig-align="center" height=300}
- [**DataOps**]{.orange} : construction de [**pipelines de données**]{.blue2}
- [**MLOps**]{.orange} : déploiement et maintenance de [**modèles de ML**]{.blue2}
## Plan de la partie
:six: [**Déploiement**]{.blue2}
:seven: [**MLOps**]{.blue2}
# :six: Déploiement
## Un sujet large
- Les [**questions essentielles**]{.orange} à se poser :
- Quel est le [**format**]{.blue2} adapté pour [**valoriser**]{.blue2} le projet ?
- Quelle [**infrastructure de production**]{.blue2} ?
- Comment [**automatiser**]{.blue2} le processus de déploiement ?
- Comment [**suivre**]{.blue2} l'application en production ?
- De [**nombreuses choix possibles**]{.orange}
- Présentation des [**concepts et outils standards**]{.blue2}
## Formats de valorisation
- [**Critères**]{.orange} à prendre en compte :
- Quels sont les [**utilisateurs**]{.blue2} potentiels ?
- Quels sont leurs [**besoins**]{.blue2} ?
- [**Exemple**]{.orange} : mise à disposition d'un [**LLM**]{.orange}
. . .
](img/model-serving.png){fig-align="center" height=250}
## Cas d'usage
- Servir un modèle de ML via une API
## Les APIs
> Une API (application programming interface ou « interface de programmation d’application ») est une interface logicielle qui permet de « connecter » un logiciel ou un service à un autre logiciel ou service afin d’échanger des données et des fonctionnalités.
>
> [CNIL](https://www.cnil.fr/fr/definition/interface-de-programmation-dapplication-api)
- Définition peu informative
- `Python`, `scikit-learn`, `Docker`, etc. sont des APIs
- En pratique, on signifie généralement une [**API REST**]{.blue2}
## Les APIs REST
- [**API RESTful**]{.orange} : API conforme au style d'architecture [REST](https://fr.wikipedia.org/wiki/Representational_state_transfer)
- Communication via le [**protocole HTTP**]{.blue2}
- En pratique :
- On requête un [**endpoint**]{.blue2} (ex : [l'API de la BAN](https://api-adresse.data.gouv.fr/search/))
- Avec des [**requêtes HTTP**]{.blue2} (`GET`, `POST`, etc.) (ex : [rues contenant "comédie"](https://api-adresse.data.gouv.fr/search/?q=comédie&type=street))
## Architecture cible
- Construire une [**API**]{.orange} pour [**servir**]{.orange} le modèle
- [**Interface**]{.blue2} entre [**l'utilisateur**]{.blue2} et le [**modèle**]{.blue2} entraîné
. . .
{fig-align="center" height=400}
## Environnement de production
- Dépend essentiellement de l'infrastructure à disposition
- [**Propriétés recherchées**]{.orange} :
- Adapter les ressources ([**scaler**]{.blue2}) selon les besoins