Différences

Ci-dessous, les différences entre deux révisions de la page.

--- boardz:journal22052019 [2019/05/27 08:33] – créée florence
+++ boardz:journal22052019 [2026/01/13 08:03] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
 |
-===== JOURNAL DE BORD au 12 Mai 2019 =====
+| {{ :avignon-universite.jpg?nolink|}} | {{ :blocks:logo-apl.png?nolink&220|}} |
+===== JOURNAL DE BORD au 22 Mai 2019 =====
 ===== BoardZ Version 2 =====
@@ Ligne 18: / Ligne 19: @@
 ====Confirmation du fonctionnement des HtmlPanel====
-Le HtmlPanel assemble des Widgets et des Panels en une structure de panneaux imbriqués pour assembler les différentes vues d'indicateurs ensemble
+Le HtmlPanel assemble des Widgets et des Panels en une structure de panneaux imbriqués pour assembler les différentes vues d'indicateurs ensemble.
+====Structure d'enregistrement des indicateurs====
+L'objectif du projet étant de sortir un enregistreur d'indicateurs massif et robuste, s'est rapidement posé le choix de sa structure : En général deux stratégies sont plausibles :
+   *  1/ Un grand datawarehouse unique : les mesures (données individuelles) sont stockées dans une immense table avec plein d'index dessus. Les extractions d'indicateurs doivent effectuer des SELECTs dans cette table avec une combinaison de règles qui focalisent les données intéressantes.
+Contrainte : si les indicateurs font appel à des "agrégats" ou des fonctions statistiques, la performance sur des centaines de millions d'échantillons peut être catastrophique, en tout cas avec des technologies open-source courantes.
+   * 2/ Des stockages localisés ultra spécialisés par donnée et par indicateur (ce que ferait naturellement un développement "pratique" dans architecture préalable) à partir d'objets simples.
+Contrainte : la multiplication de centaines de milliers d'indicateurs simples génère une consommation et un gaspillage mémoire tous important, et il faut administrer une très grande quantité de paramètres pour obtenir un tableau de bord utilisable au niveau métier.
+Ces deux approches théoriques sont donc fausses toutes les deux dans la réalité opérationnelle.
+===Choix d'un "in beteween"===
+Nous partirons donc sur une approche médiane, un "en même temps"  qui permet d'objectiver des indicateurs simples, d'utiliser cette objectivation tant que la demande fonctionnelle est générique et peu précisée, mais capable aussi de porter des objets plus "dédiés" à une structure particulière qu'elle pourra "optimiser en interne" (quitte à dé-normaliser l'approche architecturale générale).
+Plus concrètement :
+Un indicateur global par exemple, suivre le nombre instantané de connectés sur une plate forme est un indicateur simple. Il peut être monté dans une chaîne d'objets génériques de type "indicateur scalaire".
+Suivre simultanément quelques variantes de cet indicateur (par exemple, les connectés depuis 2 heures) peut être pensé en montant un panneau avec les deux widgets simples sur les deux valeurs.
+Maintenant, prenons un indicateur plus complexe qui admet des modalités de paramétrage : je veux savoir le positionnement de chaque utilisateur par rapport aux participants, et ce dans chacun de ses cours. L'indicateur est de type simple, un "ratio", donc un entier. Mais son arité n'est plus simple (scalaire).
+Le résultat :
+  * Est paramétrique : l'utilisateur que l'on veut observer
+  * Produit une série de données (tableau) indexé sur les cours (mettons 30 UE de cours que suit l'étudiant)
+Il apparaît dans ce cas très maladroit de monter cet indicateur avec une composition graphique de 30 widgets d'indicateur simples, ne serait ce que par l'occupation graphique des ces 30 boites et le gaspillage d'espace visuel. De plus, le paramétrage de la visualisation affectera les 30 valeurs à la fois (le changement d'utilisateur).
+Donc un widget capable de supporter un indicateur complexe qui intègre toute la logique de ce cas de figure devient pertinent.