NE PAS trouver un inspecteur de données pour les notebooks R Jupyter

Jean-Baptiste-Lasselle commented 8 months ago

Ce que @JeanGarf et @decoderleco utilisaient jusqu'ici pour tester leur données, après chaque transformation

Grâce à une discussion avec @JeanGarf le samedi après midi, j'ai compris comment Pierre et lui-même travaillaient jusque là.

Donc les données en R sont chargées en RAM dans les variables. Je pense que chaque variable est un dataframe

À chaque nouvelle transformation effectuée sur les données, pour vérifier que le résultat de la transformation était ce qui'ls souhaitaient, Pierre et JeanGarf utilisaient un plugin de leur IDE (Rstudio pour @decoderleco et Eclipse StatEt pour JeanGarf, afin de faire la chose suivante:

Et ds eclipse et R Studio ils ont un inspecteur de données qui permet de voir dans une variable:

inspecter les données présentes dans le dataframe: présenté sous forme de table lisibles pour un humain
mais ces tables pouvaient être très, très, très grandes:
- donc, pour bien vérifier que la table (le dataframe en réalité) résultat correspond à ce qu'ils attendent,
- leur plugin leur permettaient de faire des requêtes directement sur les données du dataframe qui est présent en mémoire RAM: en faisant des filtres, tout ce que l'on peut imaginer comme... TESTS
- ce qu'il faut comprendre, qui est fondamental, là, c'st que ce qu'ils faisaient là, ce sont des tests: l'équivalent de tests unitaires en développement classique.

Nous n'allons plus exécuter de tests manuels de cette sorte, à la place, nous allons écrire des tests:

des tests qui permettront de faire des affichages de tables de taille raisonnable, avec des données de petite taille en entrée
ces tests seront des tests unitaires automatisable, avec un véritable expect etc...
de plus pour chaque donnée ingérée, nous allons afficher "les 5 premières lignes de table": les 5 premières "rows" de chaque dataframe, et ce pour pouvoir documenter le modèle d données de la base de données RAW_DATA (base de données des données brutes)

Note importante: rôle des notebooks

les notebooks nous serviront à 2 choses :
- nous permettre de servir de "laboratoire de données": analyser de nouvelles données brutes que l'on envisage d'ingérer, concevoir de nouvelles transformations de données etc...
- apporter de premiers éléments de preuve de reproductibilité au grand public :
- publier des Notebooks que le commun des mortels pourra exécuter le plus facilement possible, "jsute en appuyant sur le bouton play"
- ces notebooks permettront:
  - D'expliquer, et documenter le moindre détail de chaque transformation de données effectuée par la plateforme
  - De montrer les tests automatisés sur les données, pour montrer les lacunes ou incohérences présentes dans une source de données extérieure: en plus, en comparant les données ingérées à deux dates différentes, pour une même soruce de données, ces tests permettront de montrer, si cela est avéré, "ce qui a été modifié / corrigé / truqué" dans la sources de données. Exemple:
  - à une date D1, le nombre de cas déclarés de la tranche d'âge 30/35 ans pour telle affection, pendant l'année 1997, contient 12.07% d'enregistrements avec une valeur undefined ou null, ou positif
  - et 6 mois plus tard, le même chiffre pour l'année 1997, a changé il n'est plus que de 6.03%
  - de concevoir les data pipelines:
  - l'ingestion: quelle requête fait(on pour aller chercher la donnée, et quelle requête fait-on pour insérer la donnée brute dans la base de données brutes RAW_DATA
  - les transformations: un graphe acyclique orienté, de transformations,
  - les tests: et chaque transformation DOIT avoir des tests automatisés:
    - tests unitaire, et pour chaque tests, on doit avoir:
    - de tout petits échantillons de données utilisées pour l'entrée des tests
    - de tout petits échantillons de donnés utilisés comme expect des tests
    - on doit donc pouvoir créer / mocker de toutes petites bases de données extrêmement rapidement et les teardown (lakefs sera problablement extrêmement utile en la matière
    - des tests de data quality (il existe beaucoup de frameworks qui permettent de faire de tels tests): ces tests sont typiquement joués toutes les nuits sur la branche develop, ou sur des braches d'acceptance testing (sur lesquelles les Data Scientists font leur tests d'acceptance avec des notebooks

les notebooks servent donc :

à développer des transformations et leurs tests unitaires
à développer des tests unitaires
à développer des tests d'acceptance

Le pourquoi du comment

D'abord, faire des tests manuels, c'est bien entendu exclut et le méthodes d'ingénierie issues du développement logiciel classique, exigeant l'automatisation des tests permettent de le comprendre très facilement: les tests manuels rendent absolument impossible à maintenir un quelqconue logiciel, et encore moins une plateforme de data engineering
au volume de code où est arrivé le code R existant: la complexité du code, et la complexité des données s'ajoutent, et on est déjà arrivé à la limite où l'one st obligé de passer à une conceptin différent,e pour pouvoir gérer ces complexité. L'incident qui est survenu juste avant L'interview Italienne, en est la parfaite illustration. Nous reparlerons dans un debrief dédié, de cet incident que nous appellerons "Incident de L'interview Italienne"

Mon analyse dans le notebook ./notebooks/RefonteArchitecture_IngestionEurostatData.ipynb, a permis:

de discuter avec JeanGarf, pour comprendre ce que j'ai dit au dessus: que les tests sur les données se font en utilisant un "inspecteur de données dataframe en RAM"
que l'on est déjà à un point de complexité tel, que certaines transformations de données, (notamment une certaine jointure à gauche), font exploser le kernel Jupyter , sans aucun doute parce que la quantité de données accumulées dans la RAM uniquement, est trop grande:
- c'est un problème absolument typique de data engineering, et le framework polars adresse exactement ce problème très connu, présent aussi dans un framework python comme pandas
- ensuite, même avec des frameworks qui ont le pouvoir de dépasser la capacité de la RAM (comme polars):
- il est hors de question de faire des traitements massifs de données avec une seule machine, si grosse soit elle, si efficace soit le framework : ne serait-ce que pour des questions de résilience du système
- cela est une des raisons pour laquelle des frameworks comme Spark ont émergé il y a longtemps:
  - parce que se limiter à la RAM d'uns seule machine, même très grosse, est une limitation qui aurait empêché tous ce qui existe aujourd'hui pour le traitement de grandes quantités de données: cela limite la quantité de données traitées par seconde, et plus le temps de traitement est long, plsu la probabilité d'une panne de la machine augmente
  - la machine devient un single point of failure
  - voilà pourquoi on a eu très tôt de la recherche pour faire ces traitements avec des systèmes distribués, capables de résilience, comme Hadoop et Spark: ils ne sont pas seulement distribués, ils permettent une résilience des traitement de données, avec le concept bien connu de RDD , Resilient Distributed Dataset

Pour toutes ces raisons, mon analyse montre:

Que nous sommes exactement au moment où décoder l'éco doit passer aux méthodes d'ingénierie modernes du Data Engineering
que les notebooks n'auront jamais le rôle d'effectuer les traitement de données,
que les notebooks à la place auront le rôle capital de permettre la conception, et la documentation de tout les data pipelines:
- ce qui sera un élément de transparence et de rigueur scientifique fondamental pour prouver le sérieux et la jutesse de toutes les analyses statistiques
- ce qui sera un élément nécessaire, et non suffisant à la capacité de reproductibilité totale de la plateforme décoder l'éco
Qu'il n'est pas question d'essayer de mettre en oeuvre un "inspecteur de données chargées dans la RAM" comme (Rstudio pour @decoderleco et Eclipse StatEt:
- À la place il va falloir faire usage d'un framework comme polars, qui permet de manipuler des quantité de données de tailles largement supérieure à la RAM
- Le format Application web est bien le bon format pour donner au citoyen curieux, des détails des traitement de données effectués par décoder l'éco (à terme en réalité la documentation complète des data pipelines) , en partant d'extrait de données de sources de données externes:
- même si on exigeait du citoyen d'installer "des choses" sur son PC pour y faire tourner R et exécuter "notre code",
- il n'est pas question d'exiger de lui que la RAM de sa machine ait une taille suffisante pour charger d'énorme quantité de données brutes: avec les notebooks la RAM utilisée est côté serveur, pas dans le navigateur, aussi seul celui
- et le mode applicaton web "rien à installler", les notebooks, sont la bonne solution, pour rendre disponible et transparente la documentation détaillée de tout nos traitement de données: les notebooks sont un standard chez les data engineer
- les notebooks ne doivent pas faire exploser les machines pc standards que le citoyen moyen utilisera à la maison, pour faire jouer les notebooks Jupyter decoder léco, en faisant tourner le côté server des jupyter notebook sur sa propre machine (docker compose)
- Il n'est pas question d'attendre du citoyen moyen, même ingénieur de l'IT, qu'il utilise un IDE comme R Studio ou Eclipse et l'inspection manuelle des données en RAM, pour vérifier que nos transformations de données sont correctes: en l'état, il ne saurait même pas quels tests exécuter, après chaque transformation faite par le code R, il faudrait qu'il le trouve tout seul. Quoi, faire des screenshots de nos Eclipse IDE pour montrer quelle requête faire dans son eclipse ? Non, ce n'est pas raisonnable.

De L'"Incident de L'interview Italienne"

Il est très important de débriefer avec @decoderleco ce qui s'y est produit dans la prochaine réunion, ce qui permettra de dégager une première roadmap ou de vraies tâches très concrètes à réaliser vont se dégager.

Ce qui s'est produit:

le code ne marche plus
erreur no1 trouvée : les données de la source de données ont changées, une colonne de table a changé de nom
erreur no2 trouvée : la fonction unnest produit désormais des doublons...

On a typiquement là deux types d'erreurs qui sont 'léessence de l'émergence des méthodes dites de "data engineering":

des méthodes qui permettent de séparer la gestion de la complexité du code, de la gestiond el a complexité de la data.

Voilà ce qu'est l'essence du data engineering, une approche scientifique vieille comme le monde: lorsque l'on a un problème de complexe à résoudre, on le casse (on le décompose) en de plus petits problèmes, dont la complexité est inférieure, pour les résoudre séparément.

Jean-Baptiste-Lasselle commented 8 months ago

le plugin eclispe c'est celui-là : https://projects.eclipse.org/projects/science.statet

Jean-Baptiste-Lasselle commented 8 months ago

https://medium.com/@heshanottawa/variable-inspector-in-jupyter-notebook-or-jupyterlab-mac-os-5639f12bbfb

Jean-Baptiste-Lasselle commented 8 months ago

https://blog.jupyter.org/a-visual-debugger-for-jupyter-914e61716559

Jean-Baptiste-Lasselle commented 8 months ago

Je vais réfléchir à cette histoire d'inspecteur de variables R d'objets R, il y a une autre chose très importante à rediscuter derrière en fait je suis en train de le comprendre, pdt que je suis avec ma femme au tel

Oui il y a une vraie question, très, très importante, et entre autres, qui répondra à la question: dans la plateforme à quoi va servir un notebook?

Début de réponse: ce ne sont pas les notebooks qui vont faire tout le traitement de données de masse. Et ce ne sera même pas du R qui fera le traitement de données de masse.

Jean-Baptiste-Lasselle commented 8 months ago

Cette tâche est conservée pour archives, la tâche a été annulée, l'explication est largement donnée dans la description

JeanGarf commented 8 months ago

Bonsoir @Jean-Baptiste-Lasselle ,

Je suis globalement d'accord avec ce que tu indiques, même si je t'avoue que le style employé me donne un peu mal au ventre tant il me donne l'impression que Pierre et moi avons fait n'importe quoi.

J'apprécierais à l'avenir que notre travail soit vu comme une première version réalisée dans l'urgence et que l'on se propose d'améliorer à présent pour le rendre plus accessible, mais sans pour autant dénigrer ce qui a été fait.

Ceci étant dit, la notion d'inspection n'est à mon sens pas la même que celle de test, car ces notions interviennent dans des phases de développement distinctes :

L'inspection, au même titre qu'un debugger, est utile lors de la phase de mise au point ou de l'investigation. Par exemple, lorsque l'on doit découvrir les siouxeries présentes dans un fichier de données téléchargées ou lorsque l'on fait du reverse engineering sur du code.

Les Test Unitaires (TU) permettent d'assurer la Non Régression d'un traitement, voire de spécifier un traitement dans le cas du Test Driven Dev.

Il me semble donc qu'un outil d'inspection "user friendly" qui permet de filtrer, trier et sélectionner des colonnes, sans avoir besoin de saisir des commandes textuelles complexe est important, tout comme l'est un débugger, car cela permet de gagner du temps lors de la phase de mise au point. Mais je suis d'accord avec toi que cela ne doit pas remplacer les TU.

Concernant les erreurs rencontrées lors de "L'Incident de L'interview Italienne" : erreur no1 trouvée : les données de la source de données ont changées, une colonne de table a changé de nom erreur no2 trouvée : la fonction unnest produit désormais des doublons...

Il me semble que la première erreur qui provient d'un changement externe arrivera également sur notre plateforme lors d'une mise à jour des données. Simplement, sa correction sera centralisée au niveau de l'extraction et du coup sans impact sur les transformations, ce qui est un avantage.

Concernant la seconde erreur, nous ne l'aurons pas tant que l'on restera dans un conteneur figé (et en supposant que R/Libs fasse partie du conteneur, ce qui n'est pas le cas aujourd'hui je crois). Mais dès que l'on upgradera R et/ou que l'on ré-installera des packages, on aura les mêmes difficultés, sauf si on trouve comment figer les versions (style Maven).

A+

decoder-leco / poc-data-visualization