Bonnes pratiques pour les projets statistiques

Une formation aux bonnes pratiques avec Git et R

Introduction

  • Version courte de la formation aux bonnes pratiques avec R et Git (page d’accueil)

Introduction

La notion de bonnes pratiques

  • Origine : communauté des développeurs logiciels

  • Constats :

    • le “code est plus souvent lu qu’écrit” (Guido Van Rossum)
    • la maintenance d’un code est très coûteuse

  • Conséquence : un ensemble de règles informelles, conventionnellement acceptées comme produisant des logiciels fiables, évolutifs et maintenables

Pourquoi s’intéresser aux bonnes pratiques ?


L’activité du statisticien / datascientist tend à se rapprocher de celle du développeur :

  • projets intenses en code

  • projets collaboratifs et de grande envergure

  • complexification des données et donc des infrastructures

  • déploiement d’applications pour valoriser les analyses

Bonnes pratiques et reproductibilité

Source : Peng R., Reproducible Research in Computational Science, Science (2011)

  • Une reproductibilité parfaite est coûteuse

  • Git est un standard atteignable et efficient

Note

Quel socle de bonnes pratiques pour les projets statistiques en ?

Horizon de cette formation

Un point de départ commun

Horizon de cette formation

Un point de départ commun

Une structuration de projet plus viable

Partie 1 : contrôle de version avec Git

Plan de la partie

1️⃣ Le contrôle de version : pourquoi faire ?

2️⃣ Le contrôle de version avec Git

I- Le contrôle de version : pourquoi faire ?

1️⃣ Archiver son code proprement

pour en finir avec ça :

1️⃣ Archiver son code proprement

ou ça :

1️⃣ Archiver son code proprement

ou encore ça :

prior <- read_csv(prior_path)
prior <- prior |>
    select(id, proba_inter, proba_build, proba_rfl) |>
    separate(id, into = c('nidt', 'grid_id'), sep = ":") |>
    group_by(nidt) |>
    mutate(
        proba_build = proba_build/sum(proba_build),
        proba_rfl = proba_rfl/sum(proba_rfl),
        ) |>
    unite(col = "id", nidt, grid_id, sep = ":")

# Test
# prior_test <- prior |>
#    mutate(
#        proba_inter = round(proba_inter, 4)
#        proba_build = round(proba_build, 4)
#        proba_rfl = round(proba_rfl, 4)
#    )

write_csv(prior_round, "~/prior.csv")

1️⃣ Archiver son code proprement

Pour arriver à ça :

Source : ThinkR

2️⃣ Voyager dans le temps (de votre projet)

3️⃣ Une collaboration simplifiée et efficace

Un modèle distribué

Source : specbee.com

3️⃣ Une collaboration simplifiée et efficace

Qui permet l’expérimentation en toute sécurité

Source : lutece.paris.fr

3️⃣ Une collaboration simplifiée et efficace

Quel que soit l’environnement de travail

3️⃣ Une collaboration simplifiée et efficace

Avec des outils pour faciliter la collaboration

4️⃣ Partager son code à un public large

Une vitrine pour les projets et l’organisation

En résumé

  • Construire et naviguer à travers l’historique de son projet

  • La collaboration rendue simple et efficace

  • Améliorer la reproductibilité de ses projets

  • Améliorer la visibilité de ses projets

II- Le contrôle de version avec Git

⚠️ Git est complexe

L’utilisation de Git nécessite certaines notions préalables:

  • Fonctionnement d’un filesystem
  • Connaissance basique du terminal Linux
  • Potentiellement, un grand nombre de commandes

Source : iulianacosmina.com

⚠️ Git est complexe

Mais

  • L’usage quotidien n’implique que quelques commandes
  • Les messages de Git sont très informatifs
  • Enormément de ressources disponibles sur internet
  • Des interfaces visuelles (ex: RStudio, Sublime Merge, VS Code) qui facilitent l’apprentissage
  • Un petit investissement individuel pour de gros gains collectifs

Concepts

Git, GitHub, GitLab… quelles différences ?

  • Git est un logiciel ;
  • Utilisation en ligne de commandes
  • Différentes interfaces graphiques (RStudio, VS Code…)

Concepts

Git, GitHub, GitLab… quelles différences ?

  • GitHub et GitLab sont des forges logicielles
  • Forge: espace d’archivage de code
  • Des fonctionalités supplémentaires : réseau social du code

Astuce

  • GitHub : utilisation pour les projets open-source
  • GitLab : utilisation pour les projets internes

Concepts

Dépôt local / dépôt distant (remote)

  • Par défaut, le dépôt distant porte l’alias origin

Concepts

Workflow local

Source : Git Documentation

Concepts

Workflow complet

Source : itnext.io

Commandes essentielles


Action Commande
Cloner un projet git clone [url-to-git-repo]
Afficher les changements git status
Retrouver l’URL du dépôt distant git remote -v

Commandes essentielles


Action Commande
Ajouter des changements à l’index de Git (stage fixes) Un seul fichier : git add <file-name>
Tous les fichiers déjà indexés : git add -u
Tous les fichiers ⚠️ : git add -A


Warning

La méthode git add -A peut amener à suivre les modifications de fichiers qui ne devraient pas l’être (par exemple, des données).

Il est recommandé de bien réfléchir avant de l’utiliser (ou d’avoir un bon .gitignore)

Commandes essentielles


Action Commande
Faire un commit git commit -m "message"
Pousser les changements locaux vers le dépôt distant (branche master) git push origin master
Récupérer les changements sur le dépôt distant (branche master) git pull origin master

Modes d’authentification

  • https
    • git clone https://github.com/username/projet.git
    • simple à utiliser
    • authentification username + password (ou token) à chaque push
  • ssh
    • git clone git@github.com:username/projet.git
    • (plus) complexe à initialiser
    • authentification automatique
  • https
    • git clone https://gitlab.insee.fr/username_or_groupname/projet.git
    • simple à utiliser
    • authentification username + password (ou token) à chaque push
  • ssh
    • git clone git@gitlab.insee.fr:username_or_groupname/projet.git
    • (plus) complexe à initialiser
    • authentification automatique

Application 0

Préparation de l’environnement de travail

  1. Créer un compte GitHub
  2. Créer un nouveau dépôt privé sur GitHub en incluant un fichier README
  3. Créer un compte sur le SSP Cloud
  4. Lancer un service RStudio. Dans l’onglet de configuration Git du service, fixer la durée du Cache pour le stockage des identifiants GitHub à une valeur suffisamment élevée
  5. Cloner le dépôt distant sur votre environnement local (ici, le RStudio du Datalab):
    • File → New project → Version Control → Git
  6. Générer un token (jeton d’authentification) sur GitHub
  7. Stocker le token sur le SSP Cloud (ou un gestionnaire de mot de passe) :
    • Mon Compte -> Git -> Token d'accès personnel pour Forge Git
  8. Terminer la procédure de clonage en fournissant le nom d’utilisateur GitHub et le token

Préparation de l’environnement de travail

  1. Compte déjà créé sur le gitlab interne
  2. Créer un nouveau dépôt privé sur gitlab.insee.fr
  3. Créer un compte sur LS3 via AUS.
  4. Lancer un service RStudio. Dans l’onglet de configuration Git du service, fixer la durée du Cache pour le stockage des identifiants Gitlab à une valeur suffisamment élevée
  5. Cloner le dépôt distant sur votre environnement local (ici, le RStudio de la plateforme LS3):
    • File → New project → Version Control → Git
  6. Générer un token (jeton d’authentification) sur gitlab.insee.fr
  7. Stocker le token sur LS3 (ou un gestionnaire de mot de passe) :
    • Mon Compte -> Git -> Token d'accès personnel pour Forge Git
  8. Terminer la procédure de clonage en fournissant le nom d’utilisateur (IDEP) et le token

❓ Question : qu’est ce qui différencie le projet cloné d’un projet quelconque ?

Application 1

Premiers commits

  1. Créer un dossier 📁 scripts
  2. Y créer les fichiers script1.R et script2.R, chacun contenant quelques commandes R de votre choix
  3. Ajouter ces fichiers à la zone de staging de Git en les cochant dans l’interface RStudio
  4. Effectuer un commit, auquel on donnera un message descriptif pertinent
  5. Supprimer le fichier script1.R et modifier le contenu du fichier script2.R
  6. Analyser ce qui se passe lorsque l’on coche ces fichiers dans l’interface RStudio
  7. Effectuer un nouveau commit pour ajouter ces modifications à l’historique
  8. Visualiser l’historique du projet à partir de l’interface graphique de RStudio

❓ Question : à ce stade, le dépôt du projet sur GitHub / Gitlab (remote) a-t-il été modifié ?

Application 2

Interactions avec le dépôt distant

  1. Effectuer un push pour intégrer les changements locaux au projet distant
  2. Parcourir l’historique du projet sur GitHub / Gitlab
    1. Faire apparaître les différences entre deux versions consécutives du projet
    2. Afficher une version passée du projet

Bonnes pratiques

Que versionne-t-on ?

  • Essentiellement du code source
  • Pas d’outputs (fichiers .html, .pdf, modèles…)
  • Pas de données, d’informations locales ou sensibles

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.

Des modèles de .gitignore existent sur internet, par exemple celui-ci pour les projets .

N’hésitez pas à y ajouter des règles conservatrices (par exemple *.csv), comme cela est expliqué dans la documentation utilitR.

Bonnes pratiques

Format des commits

  • Fréquence
    • Aussi souvent que possible
    • Le lot de modifications doit “avoir du sens”
  • Messages
    • Courts et informatifs (comme un titre de mail)
    • Décrire le pourquoi plutôt que le comment dans le texte

Application 3

Le fichier .gitignore

L’objectif de cette application est de créer le fichier .gitignore, qui permet de spécifier l’ensemble des fichiers et/ou dossiers que l’on souhaite exclure de l’indexation faite par Git. Il doit se situer à la racine du projet.

  1. S’il n’existe pas, créer un fichier texte nommé .gitignore à la racine du projet (attention à ne pas ajouter d’extension au fichier, type .txt)
  2. Créer un dossier data à la racine du projet et créer à l’intérieur de celui-ci un fichier data/raw.csv avec une ligne de données quelconque
  3. Ajouter une première règle au fichier .gitignore qui exclue le dossier data/, et vérifier que la règle fonctionne
  4. Ajouter une seconde règle excluant tous les fichiers de type *.pdf et *.html, et vérifier que la règle fonctionne

❓ Question : que se passe-t-il lorsque l’on ajoute au .gitignore des fichiers qui ont déjà été commit sur le projet Git ?

Des fichiers .gitignore standards

Dans cette application, nous avons généré le fichier .gitignore manuellement. En pratique, il existe des .gitignore standards adaptés pour chaque langage de programmation, qui implémentent déjà de nombreuses règles pertinentes. Le mieux est donc de partir du .gitignore R pour tout nouveau projet R, et de rajouter les règles spécifiques que l’on souhaite appliquer au projet.

Ressources supplémentaires

Partie 2 : bonnes pratiques avec R

Plan de la partie

1️⃣ Qualité du code

2️⃣ Structure des projets

3️⃣ Formats de données

Application 0

Préparation de l’environnement de travail

  1. Créer un dépôt sur Github en incluant un fichier README et un .gitignore (chercher le modèle R dans les suggestions)
  2. Lancer un service RStudio. Dans l’onglet de configuration Git du service, fixer la durée du Cache pour le stockage des identifiants GitHub à une valeur suffisamment élevée (conseil: 36000)
  3. Cloner le dépôt distant sur votre environnement local (ici, le RStudio du Datalab):
    • File → New project → Version Control → Git
  4. Créer un script get_data.R en copiant le contenu de ce fichier, puis l’exécuter
  5. Créer le script script.R dans votre dépôt en copiant le contenu de ce fichier. Ne l’exécutez pas, c’est l’objet de l’exercice suivant.
  6. Ajouter la règle “RPindividus*” au fichier .gitignore. Que signifie-t-elle ?
  7. Commit/push les changements (tous les fichiers, y compris ceux que Git a ajouté)

Préparation de l’environnement de travail

  1. Créer un nouveau dépôt public sur GitLab
  2. Lancer un service RStudio. Dans l’onglet de configuration Git du service, fixer la durée du Cache pour le stockage des identifiants GitLab à une valeur suffisamment élevée
  3. Cloner le dépôt distant sur votre environnement local (ici, le RStudio de LS3):
    • File → New project → Version Control → Git
  4. Créer un script get_data.R en copiant le contenu de ce fichier, puis l’exécuter
  5. Créer le script script.R dans votre dépôt en copiant le contenu de ce fichier
  6. Ajouter la règle “individu_reg.*” au fichier .gitignore. Que signifie-t-elle ?
  7. Commit/push les changements

I- Qualité du code

Enjeux

  • D’une vision utilitariste du code à une vision du code comme outil de communication

  • Favoriser la lisibilité et la maintenabilité

  • Faciliter la réutilisation

  • Assurer la transparence méthodologique

Principes généraux

1️⃣ Adopter les standards communautaires

2️⃣ Eviter la duplication de code

3️⃣ (Auto)-documenter son code

4️⃣ Isoler la configuration du code

1️⃣ Adopter les standards communautaires

“Good coding style is like correct punctuation: you can manage without it, butitsuremakesthingseasiertoread”

Tidyverse Style Guide

  • Respecter les conventions du langage dans lequel il est rédigé

  • Il existe un guide de référence pour bien coder en R : le Tidyverse style guide.

1️⃣ Adopter les standards communautaires

Deux outils pratiques aident à respecter les standards :

  1. linter : programme qui vérifie que le code est formellement conforme à un certain guidestyle
    • signale problèmes formels, sans corriger
  2. formatter : programme qui reformate un code pour le rendre conforme à un certain guidestyle
    • modifie directement le code

Astuce

  • Exemples d’erreurs repérées 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 par un linter :
    • fonctions mal utilisées, arguments mal spécifiés, structure du code incohérente, code insuffisamment documenté…

1️⃣ Adopter les standards communautaires


Dans le cas de :

  • le linter à utiliser est le package lintr
  • le formatter à utiliser est le package styler.
    • Existe également le package formatR.

2️⃣ Utiliser des fonctions

Règle d’or

Il faut utiliser une fonction dès qu’on utilise une même portion de code plus de deux fois (don’t repeat yourself (DRY))

  • Limite les risques d’erreurs liés aux copier/coller
  • Rend le code plus lisible et plus compact
  • Un seul endroit du code à modifier lorsqu’on souhaite modifier le traitement
  • Facilite la réutilisation et la documentation du code !

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.

3️⃣ Documenter son code

  • Grands principes :
    • Documenter le pourquoi plutôt que le comment
    • Privilégier l’auto-documentation

Comment bien documenter un script ?

  • Minimum 🚦 : commentaire au début du script pour décrire ce qu’il fait
  • Bien 👍 : commenter les parties “délicates” du code
  • Idéal 💪 : documenter ses fonctions avec la syntaxe roxygen2.

3️⃣ Documenter son code

L’auto-documentation en pratique

👎 La documentation pallie des mauvais nommages

# Utilise string si x est non manquant et non vide
if (!is.na(x) && nzchar(x)) {
  use_string(x)
}

👍 Les nommages suffisent à comprendre le code

x_is_not_empty_string <- (!is.na(x) && nzchar(x))
if (x_is_not_empty_string) {
  use_string(x)
}

4️⃣ Isoler la configuration du code

  • Rappel : on vise une structure modulaire

  • En pratique : isoler les packages et les secrets

4️⃣ Gestion des packages

  • Externaliser l’installation des packages nécessaires
    • Le code ne doit pas modifier l’environnement
    • Où ? Dans le README ou des fichiers spécialisés (DESCRIPTION ou renv.lock)
  • Expliciter l’appel des packages avec la syntaxe package::fonction()
    • Favorise la lisibilité du code
    • Limite les risques de fonctions “masquées”

Exemple

  • package1 et package2 contiennent chacun une fonction appelée super_fonction.
  • Si package2 est chargé après package1, alors la fonction de package1 est automatiquement masquée et super_fonction désigne par défaut la fonction de package2.
  • Mieux vaut noter package1::superFonction et package2::superFonction

4️⃣ Gestion des secrets

  • Les secrets (mots de passe, tokens, etc.) sont des données sensibles

  • Quelques principes de sécurité essentiels

    • Utiliser des tokens plutôt que des mots de passe
    • Utiliser des comptes de service (quand c’est possible)
    • Jamais de secrets en clair dans le code

  • En pratique, deux recommendations selon l’usage

    • Demander interactivement le secret à l’utilisateur
    • Spécifier des variables d’environnement via le fichier .Renviron (⚠️ à ajouter au .gitignore)

Ressources supplémentaires


Application 1

Partie 1 : vérification du bon fonctionnement du code

Un code reproductible est avant toute chose un code fonctionnel !

  • Repérez les erreurs qui empêchent le script script.R de s’exécuter correctement, et les corriger.
  • Redémarrer votre session avec Session > New Session (ou Ctrl+Maj+F10) et refaire tourner le code de A à Z. Avez-vous une erreur ?

Les pièges que cet exercice vous montre

  • Les fonctions utilisées sans import des packages
  • Les chemins et le working directory
  • L’ordre des imports
  • Les mauvaises pratiques de gestion de l’environnement (les bonnes pratiques arrivent dans les prochains exercices !)

Application 1

Partie 2 : premiers standards de qualité

  1. Installer les packages R lintr et styler1.
  2. Définir le linter à utiliser comme étant de type tidyverse avec lintr::use_lintr(type = "tidyverse")
  3. Diagnostiquer le script script.R avec lintr::lint("script.R").
    • Comprenez-vous la nature des problèmes détectés par le linter?
  4. Appliquer le formatter au script.R avec styler::style_file("script.R").
  5. Refaire tourner le linter. Il reste encore un certain nombre d’erreurs de formattage, car styler est un formatter peu intrusif.
  6. Regarder les problèmes restants repérés par le linter, et en corriger quelques uns (un pour chaque type de problème).

Application 1

Partie 3 : une meilleure gestion des packages utilisés

  1. Limiter les ambiguités sur les packages en utilisant la syntaxe package::fonction pour les packages rarement utilisés dans le script.
  2. L’installation des packages dans un script n’est pas une bonne pratique. Supprimer les instructions correspondantes.
  3. Importer le tidyverse au complet est rarement utile. N’importer à la place que les packages effectivement utilisés dans le script.

A propos du rm(list = ls()) (le supprimer !)

Cette commande est une mauvaise pratique.

On la retrouve encore dans trop de scripts car elle est utilisée pour de mauvaises raisons. Elle ne remets pas à 0 votre environnement: elle supprime juste les données de celui-ci, sans toucher au reste (packages importés, etc.).

Il vaut mieux gérer cela en changeant les options de puis redémarrer la session (CTRL+SHIFT+F10)

Application 1

Partie 4 : (auto-)documentation du code

L’objectif de cet exercice est de remettre de l’ordre dans le script, cela le rendra bien plus lisible.

  1. Déplacer les library pour les mettre tous ensemble au début du script.
  2. Le script n’est pas construit dans un ordre logique. Déplacer les parties pour adopter une structure plus lisible :
    • Gestion de l’environnement -> Définition de fonctions -> Import des données -> Retraitement des données -> Statistiques descriptives -> Graphiques -> Modélisation
  3. Donner des titres aux parties/sous-parties en utilisant les standards de documentation reconnus par RStudio :
    • # TITRE NIVEAU 1 ------------ et ## TITRE NIVEAU 2 ==========

Au passage, vous pouvez changer les noms de certains objets pour les rendre moins cryptiques (df3 n’est pas très clair).

Application 1

Partie 5 : une meilleure gestion des secrets

Dans cette application, on va explorer deux manières possibles de gérer les secrets proprement.

Première possibilité : de manière interactive.

  1. Repérer le jeton d’API dans le code et le retirer, en le stockant temporairement ailleurs.
  2. Utiliser la fonction askForPassword du package rstudioapi, qui permet de demander à l’utilisateur d’entrer le secret à l’aide d’un pop-up interactif.
  3. Vérifier le bon fonctionnement de la solution implémentée.

⚠️ Cette solution nécessite l’exécution du code dans un environnement RStudio, ce qui implique un usage en self.

Deuxième possibilité : via les variables d’environnement.

  1. Supprimer la solution précédente (pop-up interactif) et redémarrer le kernel R
  2. Créer un fichier .Renviron (voir cette fiche UtilitR pour plus d’info sur ce fichier) à la racine du projet et y ajouter une ligne JETON_API=xxx en remplaçant xxx par la valeur du jeton.
  3. Importer la valeur du jeton dans une variable api_token à l’aide de la fonction Sys.getenv.
  4. Vérifier le bon fonctionnement de la solution implémentée.
  5. Vérifier que l’exclusion du .Renviron est bien renseigné dans le .gitignore. Si ce n’est pas le cas, ajouter la règle et vérifier son bon fonctionnement, puis commit/push.

Checkpoint

Checkpoint

Bilan

  • Un code mal structuré
    • Limite la lisibilité du projet
    • Est très coûteux à maintenir (dette technique)
  • Les petits gestes peuvent économiser un temps précieux

 

II- Structure des projets

Enjeux

  1. Favoriser la lisibilité et la maintenabilité

  2. Construire des projets reproductibles

⚠️ A ne pas reproduire chez vous


├── report.Rmd
├── correlation.png
├── data.csv
├── data2.csv
├── fig1.png
├── figure 2 (copy).png
├── report.pdf
├── partial data.csv
├── script.R
└── script_final.R

Source : eliocamp.github.io

Principes généraux

  1. Utiliser les projets RStudio

  2. Organiser son projet en sous-dossiers

  3. Donner des noms pertinents aux fichiers

  4. Documenter son projet

  5. (Faire de son projet un package)

1️⃣ Utiliser les projets RStudio

  • Objectif : favoriser la reproductibilité
    • Tous les fichiers nécessaires au projet dans un même dossier
    • Le dossier contenant le projet RStudio est automatiquement utilisé comme working directory
    • Utilisation de chemins relatifs plutôt qu’absolus.
  • Bonus : en utilisant Git, on s’assure de toujours travailler dans un projet RStudio !

2️⃣ Organiser son projet en sous-dossiers

  • Objectif : adopter une structure arbitraire, mais lisible et cohérente
├── data
│   ├── raw
│   │   ├── data.csv
│   │   └── data2.csv
│   └── derived
│       └── partial data.csv
├── R
|   ├── script.R
│   ├── script_final.R
│   └── report.Rmd
└── output
    ├── fig1.png
    ├── figure 2 (copy).png
    ├── figure10.png
    ├── correlation.png
    └── report.pdf

3️⃣ Donner des noms pertinents aux fichiers

  • Objectif : auto-documenter son projet
├── data
│   ├── raw
│   │   ├── dpe_logement_202103.csv
│   │   └── dpe_logement_202003.csv
│   └── derived
│       └── dpe_logement_merged_preprocessed.csv
├── R
|   ├── preprocessing.R
│   ├── generate_plots.R
│   └── report.Rmd
└── output
    ├── histogram_energy_diagnostic.png
    ├── barplot_consumption_pcs.png
    ├── correlation_matrix.png
    └── report.pdf

4️⃣ Documenter son projet

  • Le fichier README.md, situé à la racine du projet, est à la fois la carte d’identité et la vitrine du projet

  • Idéalement, il contient :

    • Une présentation du contexte et des objectifs
    • Une description de son fonctionnement
    • Un guide de contribution (open-source)

  • Quelques modèles de README.md complets :

5️⃣ Faire de son projet un package

  • Un package est la forme maximale de modularité
    • Contient des fonctions rangées dans des modules
    • Contient également de la documentation, des tests, des (méta-)données…
  • Avantages
    • Idéal pour favoriser la réutilisation du code
    • Des outils de développement : devtools et usethis
  • Inconvénients
    • Coût de maintenance élevé

Ressources supplémentaires


Application 2

Partie 1 : modularisation du projet

  1. Déplacer toutes les fonctions dans un fichier R/functions.R.
  2. Donner à la fonction fonction_de_stat_agregee un nom plus pertinent et des noms d’arguments plus transparents.
    • Documenter la fonction fonction_de_stat_agregee selon le standard roxygen. Vous pouvez vous aider d’une IA assistante comme ChatGPT, Claude ou Copilot, rien n’est sensible dans ce code (d’ailleurs rien de sensible ne doit être dans du code !).
    • Utiliser les exemples d’utilisation de fonction_de_stat_agregee dans cette documentation.
  3. Dans script.R, appeler en début de chaîne ces fonctions avec source("R/functions.R", encoding = "UTF-8").
  4. Tester le bon fonctionnement de script.R.
  5. Si votre chaîne écrit des outputs ou utilise des inputs (par exemple des données), restructurer l’aborescence du projet pour le rendre plus lisible et adaptez votre code en fonction.
  6. Renommer (voire déplacer) les scripts get_data.R et script.R pour rendre plus intelligible la chaîne de production.
  7. Mettre à jour le .gitignore puis commit/push.

Application 2

Partie 2 : création d’un package (FACULTATIF)

  1. Fermer le Rproj en cours (“Close Project” en haut à droite).
  2. Initialiser un package avec la fonction usethis::create_package() (par défaut dans le working directory)
  3. Placer dans le dossier R du package un module stat.R et y copier la fonction de statistique agrégée
  4. Remplir le fichier DESCRIPTION. En particulier, spécifier les dépendances nécessaires (Imports) et facultatives (Suggests)
  5. Construire la documentation du package avec la fonction devtools::document(). Où est-elle stockée et sous quel format ?
  6. Charger le package avec la fonction devtools::load_all() et vérifier que la fonction marche correctement
  7. Vérifier que la documentation de notre fonction est accessible avec ?ma_fonction
  8. (Facultatif) Initialiser un nouveau projet sur GitHub est y mettre le code du package. Vérifier que le package peut être installé en local avec la fonction devtools::install_github().

Checkpoint

Checkpoint

III- Formats de données

Enjeux

  • Le choix d’un format de données répond à un arbitrage entre plusieurs critères :
    • Public cible
    • Finalité (traitement, analyse, diffusion)
    • Volumétrie
    • Interopérabilité

Formats traditionnels

  • Formats de données adhérents à un langage (sas7bdat, RDS, fst, etc.)
    • Non-interopérables -> à éviter !
  • Le format CSV
    • Interopérable et simple d’utilisation
    • Pas de gestion des méta-données
    • Peu adapté aux données volumineuses

Limites du CSV

  • Des performances limitées
    • Stockage : non-compressé -> espace disque élevé
    • Lecture : “orienté-ligne” -> performances faibles

Le format Parquet

  • Stockage :
    • Compression : entre 5 et 20 fois plus léger qu’un CSV

Exemple: Recensement de la Population

  • Ficher détail : 20 millions de lignes, 92 variables
    • CSV: > 4Go
    • Parquet: < 500Mo

Le format Parquet

  • Lecture :
    • Jusqu’à 34x plus rapide qu’un CSV
  • “Orienté colonne”
    • Optimisé pour les traitements analytiques
    • Limite la quantité de données à mettre en mémoire

Le format Parquet

  • Partitionner les données pour optimiser la lecture

L’art de bien partitionner

  • Partitionner par une/des variable(s) d’intérêt

  • Eviter de créer de nombreux petits (< 128Mo) fichiers

Le format Parquet

  • Gestion native des méta-données

    • Définition automatique d’un schéma (noms, types)
    • Mise à disposition plus robuste

  • Interopérable

  • Open-source

Le format Parquet

  • Deux frameworks de référence : Arrow et DuckDB
    • Orientation fichier (Arrow) VS orientation BDD (DuckDB)
    • Très bonne intégration avec le tidyverse
  • Traitement en-mémoire optimisé
    • Orientés-colonne
    • Lazy evaluation

Exemple d’une requête lazy

n_logements_depcom <- achille |> 
  filter(dep %in% c("01", "02", "03")) |>  # Récupère seulement les données nécessaires
  select(idlogement, depcom) |>  # Récupère seulement les colonnes nécessaires
  group_by(depcom) |>
  summarise(n_logements = n()) |>  
  collect()  # Les calculs ne sont effectués qu'à cette étape !

Le format Parquet

  • Parquet gagne sur tous les tableaux

Application 3

Partie 0 : Préparation

  • Remplacer le contenu du script get_data.R en copiant-collant le contenu de ce fichier. Exécuter ce script, il importe les fichiers nécessaires pour cette application.

Partie 0 : Préparation

  • Remplacer le contenu du script get_data.R en copiant-collant le contenu de ce fichier. Exécuter ce script, il importe les fichiers nécessaires pour cette application.

Application 3

Partie 1 : Du CSV au Parquet

Tout au long de cette application, nous allons voir comment utiliser le format Parquet de manière la plus efficiente. Afin de comparer les différents formats et méthodes d’utilisation, nous allons comparer le temps d’exécution et l’usage mémoire d’une requête standard. Commençons par comparer les formats CSV et Parquet.

  • Créer un script benchmark_parquet.R afin de réaliser les différentes comparaisons de performance de l’application
  • Pour effectuer les comparaisons de performance, on va utiliser la fonction bench::mark. Analyser la documentation pour comprendre ce que la fonction attend en entrée.
  • La requête suivante permet de calculer les données pour construire une pyramide des âges sur un département donné, à partir du fichier CSV du recensement. Encapsuler la requête dans une fonction req_csv (sans argument).
res <- readr::read_csv("data/RPindividus_24.csv") |> 
    filter(DEPT == "36") |>
    group_by(AGED, DEPT) |>
    summarise(n_indiv = sum(IPONDI))
  • Sur le même modèle, construire une fonction req_read_parquet basée cette fois sur le fichier data/RPindividus_24.parquet chargé avec la fonction read_parquet d’Arrow
  • Comparer les performances (temps d’exécution et allocation mémoire) de ces deux méthodes grâce à la fonction bench::mark, à laquelle on passera les paramètres iterations = 1 (comparaison à partir d’une seule itération) et check = FALSE (autorise les outputs des deux fonctions à être différents).

❓️ Quelle semble être la limite de la fonction read_parquet ?

Application 3

Partie 2 : Exploiter la lazy evaluation et les optimisations d’Arrow

La partie précédente a montré un gain de temps considérable du passage de CSV à Parquet. Néanmoins, l’utilisation mémoire était encore très élevée alors qu’on utilise de fait qu’une infime partie du fichier. Dans cette partie, on va voir comment utiliser la lazy evaluation et les optimisations du plan d’exécution effectuées par Arrow pour exploiter pleinement la puissance du format Parquet.

  • Utiliser la fonction arrow::open_dataset pour ouvrir le fichier data/RPindividus_24.parquet. Regarder la classe de l’objet obtenu.
  • Afficher les 5 premières lignes de la table avec la fonction head(). Observer l’objet obtenu (sortie en console, classe).
  • Ajouter une étape collect() à la fin de cette chaîne. Comprenez-vous la différence ?
  • Construire une fonction req_open_dataset sur le modèle de celles de la partie précédente, qui importe cette fois les données avec la fonction arrow::open_dataset
  • Comparer les performances (temps d’exécution et allocation mémoire) des trois méthodes (CSV, read_parquet et open_dataset) grâce à la fonction bench::mark

❓️ Quelle méthode retenir pour lire un Parquet avec Arrow ?

Application 3

Partie 3 : Le Parquet partitionné

La lazy evaluation et les optimisations d’Arrow apportent des gain de performance considérables. Mais on peut encore faire mieux ! Lorsqu’on sait qu’on va être amené à filter régulièrement les données selon une variable d’intérêt, on a tout intérêt à partitionner le fichier Parquet selon cette variable.

  • Parcourir la documentation de la fonction arrow::write_dataset pour comprendre comment spécifier la clé de partitionnement d’un fichier Parquet. Plusieurs méthodes sont possibles !
  • Importer la table individus complète du recensement data/RPindividus.parquet avec la fonction arrow::open_dataset et l’exporter en une table data/RPindividus_partitionne.parquet partitionnée par la région (REGION) et le département (DEPT)
  • Observer l’arborescence de fichiers de la table exportée
  • Modifier la fonction req_open_dataset de la partie précédente pour partir de la table complète (non-partitionnée) data/RPindividus.parquet au lieu de l’échantillon
  • Construire une fonction req_open_dataset_partitionne sur le modèle de req_open_dataset, qui importe cette fois les données partitionnées data/RPindividus_partitionne.parquet. Ne pas oublier de spécifier le paramètre hive_style = TRUE.
  • Comparer les performances (temps d’exécution et allocation mémoire) des deux méthodes grâce à la fonction bench::mark

❓️ Dans le cadre d’une mise à disposition de données en Parquet, comment bien choisir la/les clé(s) de partitionnement ? Quelle est la limite à garder en tête ?

Application 3

Partie 4 : mise à jour de la chaîne de production

Convaincus par ce comparatif, nous allons maintenant mettre à jour le format des données utilisées pour notre chaîne de production.

  • Modifier le script script.R pour importer les données d’entrée de votre chaîne à partir de la table Parquet partitionnée data/RPindividus_partitionne.parquet
  • Vérifier que le script complet s’exécute correctement et l’adapter si ce n’est pas le cas

❓️ Cette mise à jour des données utilisées en source de la chaîne de production vous a-t-elle paru compliquée ? Pourquoi ?

Checkpoint

Checkpoint

Ressources supplémentaires

Conclusion

Conclusion

Conclusion

  • Des standards communautaires qui favorisent la reproductibilité et la maintenabilité

  • De multiples outils pour simplifier leur mise en oeuvre

  • Un coût d’autant plus faible que l’on se place en amont

  • Le mouvement de modernisation du self est l’occasion d’une montée en compétence collective

Ressources communautaires