Aller au contenu

Statistiques et monitoring de flux de données


Messages recommandés

Des gens ici ont un background en maîtrise statistique des procédés / statistical process control ?

 

Je me mets pour ce fil dans le cadre des problématiques classiques (ou qui gagneraient à l'être) du monde des ETL, de l'intégration de données et de ce genre de tâches à nettoyer, pardon, à accomplir. J'aimerais surveiller un certain nombre de flux de données entre un système A (la source) et un système B (la cible), les deux étant des bases relationnelles (i.e. on peut classer les flux par entité, et compter le nombre de lignes transférées).

 

Est-il raisonnable de modéliser le volume de chaque flux par une loi log-normale, dont la moyenne est susceptible d'évoluer au cours du temps ? (Par à-coups en cas de mise en production d'une nouvelle entité / changements du mode de chargement entre diff et full ; et sinon doucement, que ce soit de manière linéaire ou exponentielle).

 

Sur quels critères détecter un flux déconnant, au sens de "exécuté sans erreur mais dont le volume est tout à fait inhabituel" ? Le coefficient de variation (écart-type divisé par moyenne) semble une bonne idée, mais faut-il l'appliquer au nombre de lignes ou à son log ? Et quel est le seuil à partir duquel les valeurs de ce CoV devraient mettre la puce à l'oreille ?

Lien vers le commentaire
il y a 42 minutes, Rincevent a dit :

loi log-normale

 

Pourquoi partir vers des trucs continus alors que tu es typiquement dans le domaine des processus de comptage ?

 

J'avais un copain qui avait fait pas mal de truc sur de la longévité et le repérage d'anomalies /changements de tendance à base de processus de Shiraiev Roberts. Ça peut être utile.

 

Lien vers le commentaire
il y a 37 minutes, Bézoukhov a dit :

Pourquoi partir vers des trucs continus alors que tu es typiquement dans le domaine des processus de comptage ?

Bah, est-ce que la différence est si importante pour N dépassant quelques milliers ?

 

il y a 38 minutes, Bézoukhov a dit :

J'avais un copain qui avait fait pas mal de truc sur de la longévité et le repérage d'anomalies /changements de tendance à base de processus de Shiraiev Roberts. Ça peut être utile.

Tu peux développer ?

Lien vers le commentaire
il y a 10 minutes, Rincevent a dit :
il y a 48 minutes, Bézoukhov a dit :

 

Bah, est-ce que la différence est si importante pour N dépassant quelques milliers ?

 

C'est mon côté computer science. Pourquoi aller faire des trucs d'analyse compliqués quand on peut faire simple.

 

Mais surtout, exprimer ton problème en problème de comptage te permet de savoir vers quelle loi théorique tu devrais converger en continu (et je ne sais trop ce qui converge vers une log normale).

 

il y a 11 minutes, Rincevent a dit :

Tu peux développer ?

 

C'est une version améliorée de la problématique résolue par le CUSUM : https://en.m.wikipedia.org/wiki/CUSUM

 

En gros une classe d'outils statistique qui étant donné un flux de données est sensé repérer le moment où les paramètres de la loi sous jacente changent.

Lien vers le commentaire

Ah mais justement je voudrais que mon test soit insensible à une variation douce et régulière de la moyenne de la loi sous-jacente (typiquement, + 1% par jour).

 

 

Il y a 2 heures, Bézoukhov a dit :

Mais surtout, exprimer ton problème en problème de comptage te permet de savoir vers quelle loi théorique tu devrais converger en continu (et je ne sais trop ce qui converge vers une log normale).

The central limit theorem says that the product of a long series of independent and identically distributed positive random variables converges to a log-normal distribution for any positive, finite-variance distribution, me dit-on. Je l'ai explicitement choisie parce que 1- son support est R+ (parce que le volume de données transmises n'est pas négatif, duh), et 2- elle est sans doute celle qui demande le moins de suppositions sur les causes sous-jacentes de la variabilité.

Lien vers le commentaire

J'étais déjà dans les processus en fait. Et comme la loi de poisson qui est le comptage le plus basique, converge vers la normale, je me demandais d'où sortait la lognormale.

 

Il y a 2 heures, Rincevent a dit :

Ah mais justement je voudrais que mon test soit insensible à une variation douce et régulière de la moyenne de la loi sous-jacente (typiquement, + 1% par jour).

 

Si les souvenirs sont bons, ça devrait marcher avec les tests de cette famille.

Lien vers le commentaire
il y a 4 minutes, Bézoukhov a dit :

J'étais déjà dans les processus en fait. Et comme la loi de poisson qui est le comptage le plus basique, converge vers la normale, je me demandais d'où sortait la lognormale.

De ce que je compte le nombre de lignes transférées chaque jour (ou semaine, ou heure, on verra). Tout bêtement. Le service où je bosse n'est même pas encore assez mature pour mailer une "alerte au flux déconnant" si un flux ne se lance pas ou est lancé par erreur douze fois au lieu d'une ; alors tu penses bien, j'essaie de faire simple et crédible pour attirer l'attention des gens sur le problème (trouver une log-normale pour estimer la volumétrie "naturelle" des flux, i.e. moyenne et écart-type, afin d'avoir un critère pour savoir quand on est en dehors des clous).

Lien vers le commentaire

Une carte de contrôle avec un 6 sigma tout con ça ne suffirait pas à ton besoin ?

 

En tout cas si tu es désoeuvré il y a une littérature abondante sur "qu'est ce qu'un outlyer" et pas mal de packages dispo dans différents langages.

Lien vers le commentaire
il y a 43 minutes, Mathieu_D a dit :

Une carte de contrôle avec un 6 sigma tout con ça ne suffirait pas à ton besoin ?

Hé, pour ça il faudrait qu'on aie une idée de la moyenne et de l'écart-type attendus. :lol:

(J'ai bossé plusieurs mois il y a 15 ans sur des questions de MSP et de Six Sigma, tu penses bien que j'y ai songé tout de suite).

Lien vers le commentaire
Il y a 2 heures, Rincevent a dit :

j'essaie de faire simple et crédible pour attirer l'attention des gens sur le problème

 

Si ils sont à ce niveau, je pense qu'un graphique bien pensé sera plus à même de déclencher un truc que des stats.

Lien vers le commentaire
il y a 21 minutes, Bézoukhov a dit :

Si ils sont à ce niveau, je pense qu'un graphique bien pensé sera plus à même de déclencher un truc que des stats.

J'ai déjà un graphique à la con sur Excel : log du nombre de lignes intégrées par jour, moyenne mobile exponentielle du précédent avec param 1/7 (j'ai pris 1/7 parce que 7 jours par semaine, mais je suis ouvert à d'autres propositions), rapport entre écart-type (sur 7 jours encore une fois) et la valeur moyennée (je ne sais pas si je devrais prendre mon écart-type sur le moyenné ou sur le log originel, ni si je devrais diviser par l'un ou l'autre) histoire d'avoir un coefficient de variation sans unité.

 

J'essaie surtout de trouver un système pour que 1- ça marque les esprits, et 2- ce soit facile à actualiser* afin que ça reste dans la liste de priorités de mon N+1 voire de mon N+2 assez longtemps pour que ça ait de l'effet sur mon service.

 

*Relativement facile, hein. Je ne peux pas brancher directement une feuille Excel sur une base de prod sans demander une bardée d'autorisations.

Lien vers le commentaire

Oui sors déjà la courbe du réel en daily sur une année et regarde avec le métier si les gros pics ou les gros creux sont cohérents.

 

Est-ce que tu as une saisonnalité à part hebdomadaire ? Est-ce qu'il y a des pics après des campagnes marketings ou des trucs du genre ?

 

Est-ce que si tu fais un arima basique ou un Prophet avec en apprentissage les années n-3, n-2, n-1 tu es à l'Ouest sur ton année n ou pas ?

Lien vers le commentaire
il y a une heure, Mathieu_D a dit :

Est-ce qu'il y a des pics après des campagnes marketings ou des trucs du genre ?

C'est des master data. Oui, l'endroit où je travaille est incapable de savoir si ses master data présentes et si son référentiel historique est alimenté.

Lien vers le commentaire
×
×
  • Créer...