Que vaut la détection d’anomalies dans Power BI ?

Pour des données établissant une série temporelle (mesure numérique à intervalles de temps régulier), la première étape de mise en qualité des données sera bien souvent de corriger les données dites aberrantes, c’est-à-dire trop éloignées de la réalité.

Rappelons les différents cas pouvant amener à ce type de données :
– erreur de mesure ou de saisie (maintenant plutôt lié à une erreur “informatique”)
– dérive réelle et ponctuelle (souvent non souhaitée, correspondant à un défaut de qualité)
– hasard (événement assez peu probable mais pouvant néanmoins se produire exceptionnellement!)

Avec la version de novembre 2020 de Power BI Desktop, nous découvrons une nouvelle fonctionnalité en préversion (donc à activer depuis le menu Options) qui ajoute une entrée dans le menu Analytique des graphiques en courbe (“line chart“).

Tout d’abord, regardons les limites d’utilisation précisées à cette page. Si 12 points sont le minimum requis (ou 4 patterns saisonniers), il sera beaucoup plus pertinent d’en avoir en plus grand nombre ! Ensuite, de nombreuses fonctionnalités ne sont pas (encore ?) compatibles avec la détection d’anomalies : légende, axe secondaire, prévision (forecast), live connection, drill down

Fonctionnement théorique

Le papier de recherche qui décrit l’algorithme utilisé, nommé unsupervised SR-CNN, est disponible ici. Nous allons essayer de le vulgariser sans trop d’approximations.

Cet algorithme d’apprentissage automatique fait partie de la catégorie des méthodes non-supervisées, c’est-à-dire qu’il n’est pas nécessaire de disposer a priori d’un échantillon de données d’apprentissage où les anomalies seraient déjà identifiées (approche supervisée).

Les deux premières lettres du nom de cette approche correspondent à la méthode dite Spectral Residual, basée sur des transformées de Fourier, qui met en valeur des éléments “saillants” (salient) de la série temporelle.

Issus du domaine du Deep Learning, les réseaux de neurones à convolution (CNN) ont émergé dans le domaine du traitement d’images en deux dimensions. Pour autant, il est tout-à-fait possible de les utiliser dans le cadre d’une série temporelle à une dimension. Au lieu d’analyser des fragments d’images, la série des données transformées va être reformulée comme plusieurs successions de valeurs.

Ainsi, la série {10, 20, 30, 40, 50, 60} pourra donner des séries comme {10, 20, 30}, {20, 30, 40} ou encore {40, 50, 60} (voir ce très bon article pour aller plus loin dans le code).

Le rôle de la couche de convolution est d’extraire les features (caractéristiques) de la série temporelle. Ce sont elles qui permettront ensuite de décider si une valeur est ou non une anomalie.

D’un point de vue de l’architecture du réseau, la couche de convolution à une dimension est suivi d’une couche “fully connected” qui fait le lien entre le résultat de la convolution et le label de sortie (anomalie ou non).

Allons maintenant à la recherche d’un jeu de données pour expérimenter cette fonctionnalité !

Test sur un jeu de données

Il existe des jeux de données de référence pour évaluer la performance de la détection d’anomalies, et plus spécifiquement dans le cadre des séries temporelles. Vous en trouverez par exemple sur cette page.

Nous travaillerons ici avec un jeu de données de trafic réseau.

Ce dataset contient environ 4,5 millions de lignes.

La détection d’anomalies se déclenche dans le menu Analytique du visuel.

Un seul paramètre est disponible pour régler le niveau de détection, entre 0 et 100% : sensitivity.

Plus la valeur est élevée, plus “l’intervalle de confiance” en dehors duquel sera détectée une anomalie est fin. Autrement dit, plus la valeur approche des 100%, plus vous apercevrez de points mis en évidence. Difficile de dire sur quoi joue ce paramètre d’un point de vue mathématique, il n’est pas évoqué dans le papier de recherche cité précédemment.

En cliquant sur un point, s’ouvre un nouveau volet latéral donnant les valeurs de la plage attendue, reprises également dans l’infobulle.

En plaçant d’autres champs de la table dans la case “explain by“, on peut espérer mettre une évidence un facteur explicatif de cette anomalie.

Attention, il n’est pas envisageable de “zoomer” sur un portion du graphique contenant une anomalie car cela modifiera la plage de données servant à évaluer l’algorithme et fera donc apparaître ou disparaître des points identifiés comme aberrants !

Zoom sur une journée contenant initialement une détection d’anomalies

On pourra plutôt profiter de l’affichage du visuel en tant que table de données qui dispose d’une colonne “anomaly” valant 0 ou 1. On s’aperçoit ici que plusieurs points consécutifs sont identifiés comme des anomalies, ce qui était difficilement identifiable sur le graphique.

En conclusion

Malheureusement, les informations obtenues au travers de ce visuel ne peuvent pas réellement être exploitées : pas d’indicateur créé dans la table, pas d’export au delà de 30000 points (soit un peu plus de 8h pour des données à la seconde), un modèle perpétuellement recalculé et ne pouvant être arrêté sur une période. Alors, que faire lorsque des anomalies apparaissent ? Rien hormis prévenir le propriétaire des données…

Comme pour les autres services touchant (de loin) à l’IA sous Power BI, je suis sceptique quant au moment où cette fonctionnalité est mise en œuvre. La détection d’anomalies est une étape de préparation de la donnée et hormis à effectuer un reporting sur ces anomalies elles-mêmes, nous sommes en droit d’attendre qu’elles soient déjà retirées des données avant exposition. Il serait donc beaucoup plus opportun d’utiliser le service cognitif Azure dans un dataflow (Premium ou maintenant en licence Premium Per User) afin de mettre la donnée en qualité lors de la constitution de donnée. Pour une détection sur un flux de streaming, on se tournera avec intérêt vers les possibilités offertes par Azure Databricks, comme exposé dans ce tutoriel.

A l’inverse, les algorithmes prédictifs qui ne peuvent être utilisés que dans les dataflows seraient beaucoup plus à leur place dans un visuel qui permettrait de tester différents scénarios et d’observer les prévisions associées.

En résumé, les ingrédients de la recette sont les bons, encore faut-il les ajouter dans l’ordre pour obtenir un plat satisfaisant !

L’algorithme choisi (SR-CNN) ne doit pour autant pas être remis en cause car il semble aujourd’hui représenter l’état de l’art de la détection d’anomalies;

Vos remarques sur cet outil peuvent être déposées sur cette page communautaire.

Data Analytics, back to basics ! (*) [1/3]

(*) Revenir à l’essentiel : l’analyse des données !

Intelligence Artificielle, Machine Learning, RGPD… la donnée ne quitte plus le devant de la scène médiatique, qui attribue bien souvent à la data des pouvoirs thaumaturges. Le monde du recrutement s’emballe autour des profils « Data Scientists » tout en présentant des listes de compétences impossibles à maîtriser pour une seule et même personne, allant de l’architecture Big Data à la programmation de réseaux de neurones convolutifs (le fameux Deep Learning). A l’exception des entreprises dont la data constitue le cœur de métier comme Booking, AirBNB ou Uber, quelles sont celles qui ont réellement modifié et amélioré leur activité par une approche « data driven », c’est-à-dire pilotée par la donnée ? Ce phénomène de « hype » autour de la donnée peut poser question et générer une certaine méfiance.

Pourtant, une réaction inverse qui reviendrait à rejeter tout apport de la donnée serait aussi improductive. Et tant qu’à stocker la data, autant en tirer profit ! Dans une série de trois articles, nous nous arrêterons successivement sur l’intérêt, pour les entreprises, de l’analyse de données exploratoire, l’analyse prédictive grâce au Machine Learning et les promesses du Deep Learning sur les données non structurées.

Une même finalité, de nouveaux outils

Bien avant l’explosion de l’engouement pour la Data Science, certaines personnes dans l’entreprise pratiquaient déjà l’analyse de données sous des intitulés de poste tels que « chargé.e d’études statistiques », « statisticien.ne », « actuaire », « data miner », etc. Souvent éloignées du département IT et des architectures de production, ces personnes en charge de forer la donnée réalisent des extractions puis travaillent ces échantillons dans un classeur Excel ou un logiciel spécialisé. Une fois les conclusions obtenues, celles-ci figurent dans une présentation au format Word ou PowerPoint, c’est-à-dire sans possibilité simple de mise à jour ni d’extension à d’autres données. Nous allons voir ici que c’est aujourd’hui, non pas un bouleversement méthodologique, mais bien une simplification et une meilleure performance des outils qui changent ces métiers.

Notre approche méthodologique visera à répondre aux quatre temps de l’analyse de données.

Les quatre temps de l’analyse de données

Prenons un exemple concret : l’analyse des accidents corporels de la circulation pour laquelle les données sont disponibles en open data sur le portail data.gouv.fr.

Pour une première approche du jeu de données, nous travaillerons dans l’outil Microsoft Power BI Desktop qui, même s’il n’est pas un logiciel statistique à proprement parler, permet de nettoyer et visualiser les données très rapidement. Nous verrons même qu’il cache plusieurs fonctionnalités analytiques particulièrement intéressantes. Enfin, lorsque l’étude exploratoire sera terminée, il ne sera plus nécessaire de quitter l’outil pour présenter les résultats dans un logiciel bureautique figé. L’interface proposera une visualisation dynamique et adaptée à la restitution.

L’indispensable nettoyage des données

Observons tout d’abord le schéma des données collectées, dont la description précise des champs est disponible dans ce document. Nous travaillerons ici avec les notions de :

  • Caractéristiques de l’accident
  • Lieu de l’accident
  • Véhicules impliqués
  • Usagers des véhicules impliqués
Modélisation des données dans Power BI Desktop

La qualité des données en entrée déterminera la qualité des résultats qui seront obtenus (ou tout du moins, garbage in, garbage out !). Un travail d’inspection de chaque champ est nécessaire et celui-ci se fait rapidement grâce au profil de la colonne, comme par exemple ci-dessous, sur l’année de naissance de l’usager.

La lecture des indicateurs de synthèse (moyenne, médiane, écart-type, etc.) nous permet de débusquer des valeurs aberrantes (un conducteur né en 1924, cela reste plausible) et de comptabiliser des valeurs manquantes qui nécessiterait un traitement spécifique (ici, toutes les lignes sont renseignées.)

L’interaction pour une meilleure exploration des données

L’une des grandes forces de Power BI réside dans son haut niveau d’interaction avec la donnée, au moyen de filtres visuels ou en sélectionnant un élément graphique pour obtenir instantanément la mise à jour des autres visuels.

L’analyse descriptive est ainsi rapidement obtenue. A vous de jouer, ce rapport est totalement interactif !

Bien sûr, il ne faudra pas tomber dans le travers de chercher à filtrer sur toutes les dimensions possibles ! L’être humain n’est pas en capacité d’appréhender un trop grand nombre d’informations mais les méthodes d’analyse avancée sont là pour nous aider.

Des fonctionnalités pour l’analyse explicative

Observons l’évolution du nombre d’accidents dans le temps, au niveau annuel. On constate une hausse en 2016 avec un recul des accidents sur les années précédentes.

Expliquer (automatiquement) la hausse

Power BI va rechercher les facteurs explicatifs de la hausse de l’indicateur en testant tous les champs du modèle et nous fera plusieurs propositions. Nous retenons ici celle du département de l’accident qui met en évidence une hausse significative sur les départements d’Ile-de-France 75 et 93, contre une baisse dans les Alpes-Maritimes. Cette piste nous mettrait sur la voie de données décrivant ces départements (population, infrastructures routières, etc.).

Visuels générés automatiquement par Power BI : l’utilisateur choisit le plus parlant.

L’analyse faite jusqu’ici nous permet de comprendre les données dans leur ensemble mais il est fondamental de répondre à une problématique levée par le sujet, ici l’accidentologie, et nous allons donc rechercher des explications à la mortalité routière.

Nous disposons pour cela d’une information sur la gravité de l’accident qui permet de déterminer si l’usager est décédé.

Influenceurs clés : une régression logistique visuelle !

L’analyseur d’influenceurs clés (key influencers, basé sur une approche de modélisation par régression logistique) identifie la non utilisation d’un équipement de sécurité (ceinture, casque, etc) comme le facteur le plus fort dans un décès lié à un accident : la probabilité est presque multipliée par 6. L’âge est également un facteur très important. Si celle-ci est inférieure à 1932, le risque de décès est ici multiplié par 4.

Nous obtenons ici, grâce à l’analyse, des leviers d’actions concrets pour la sécurité routière, ce qui constitue une première forme d’analyse prescriptive

… et une première analyse prédictive !

Reprenons l’évolution du nombre d’accidents dans le temps mais cette fois-ci, au niveau mensuel. La courbe traduit clairement une notion de saisonnalité : il y a beaucoup (trop) d’accidents lors des périodes de vacances scolaires par exemple. Si l’on ajoute une droite de tendance, on voit que celle-ci est légèrement à la hausse. Prolonger cette droite ne donnerait pas une bonne prévision au détail mensuel puisqu’il faut tenir compte de cette saisonnalité.

Nous utilisons ici la fonctionnalité de « forecast » de Power BI basée sur la méthode statistique du lissage exponentiel. N’allons pas trop loin, il est conseillé de ne pas dépasser une prévision au tiers de l’historique disponible. Cette prévision est encadrée par un intervalle de prévision, donnant les bornes entre lesquelles on espère voir apparaître la « vraie » valeur, avec un niveau de confiance de 95%.

Paramètres de la prévision

On obtient alors la prévision sur le graphique et l’infobulle donne les valeurs chiffrées.

Une présentation dynamique sans changer d’outil

Résumons maintenant toutes les informations découvertes au travers de cette première analyse. Pour communiquer ces résultats, nous pourrions utiliser un support externe comme PowerPoint ou un fichier PDF mais nous perdrions toute interaction. Les bookmarks (ou signets) de Power BI sont ici un outil extrêmement pratique pour garder en mémoire une sélection personnalisée de filtres et enchainer la lecture de plusieurs pages de rapport comme l’on enchainerait des diapositives.

Signets dans Power BI : un outil de story telling

Quel langage pour la préparation de données sur Azure Databricks ?

Azure Databricks se positionne comme une plateforme unifiée pour le traitement de la donnée et en effet, le service de clusters managés permet d’aborder des problématiques comme le traitement batch, mais aussi le streaming, voire l’exposition de données à un outil de visualisation comme Power BI.

La capacité de mise à l’échelle (scalabilité ici horizontale) d’Azure Databricks  est également un argument de poids pour établir cette solution dans un contexte de forte volumétrie. Par forte volumétrie, nous entendons ici le fait qu’un tableau de données, ou les opérations qui permettraient d’y parvenir,  dépasse la mémoire disponible sur une seule machine. La solution sera donc de distribuer la donnée ou les traitements. Mais attention, il va falloir bien choisir ses armes avant de se lancer dans un premier notebook !

Le choix des armes

A la création d’un notebook sur Azure Databricks, quatre langages sont disponibles.

Sauf à ne vouloir faire que du SQL, je vous déconseille de prendre ce type de notebook puisqu’il sera très simple d’exécuter une commande SQL dans une cellule à l’aide la commande magique %sql.

Si vous venez de la Data Science « traditionnelle » (rien de péjoratif, c’est d’ailleurs mon parcours, comprendre ici l’approche statistique antérieure à l’ère de la Big Data), vous serez attirés par le langage R. Mais vous savez sûrement que R est un langage, de naissance, single-threaded et peu apte à paralléliser les traitements. Microsoft a pourtant racheté la solution RevoScaleR de Revolution Analytics et l’a intégrée en particulier à SQL Server. Dans un contexte Spark, on peut s’orienter vers l’API SparkR mais celle-ci ne semble pas soulever un très gros engouement (contredisez-moi dans les commentaires) dans la communauté.

Python remporte aujourd’hui une plus forte adhésion, en particulier auprès des profils venant du monde du développement. Attention, coder un traitement de données en Python ne vous apportera aucune garantie d’amélioration par rapport au même code R ! Ici, plusieurs choix se présentent à nouveau.

Une première piste sera d’exploiter la librairie Dask qui permet de distribuer les traitements.

Une deuxième possibilité est de remplacer les instructions de la librairie pandas par la librairie développée par Databricks : koalas. Je détaillerai sûrement l’intérêt de cette librairie dans un prochain article.

Le troisième choix possible sera à mon sens le meilleur : l’API pyspark. Cette API va vous permettre :

  • de créer des objets Spark DataFrames
  • d’enregistrer ces DataFrames sous formes de tables (locales ou globales dans Databricks)
  • d’exécuter des requêtes SQL sur ces tables
  • de lire des fichiers au format parquet

Les API Spark permettent d’écrire dans un langage de plus haut niveau et plus accessible pour les développeurs (data scientists ou data engineers) qui sera ensuite traduit pour son exécution dans le langage natif du cluster.

Les différents codes possibles

Je vous propose ci-dessous un comparatif des approches pandas et pyspark pour un même traitement de données. Le scénario est de charger les données de la base open data des accidents corporels, soit deux dossiers de fichiers csv : les usagers et les caractéristiques des accidents. Une fois les fichiers chargés, une jointure sera réalisée entre les deux sources sur la base d’une clé commune.

L’objectif est ici d’établir un parallèle entre les syntaxes et non d’évaluer les performances. La librairie pandas n’est d’ailleurs pas la plus optimale pour charger des fichiers csv et on mettra à profit les méthodes plus classiques de lecture de fichiers.

A l’import, création d’un dataframe

# pandas
df = pd.read_csv(filename)

# pyspark
df = spark.read.format("csv") \
.option("header", "true").option("inferSchema", "true").load("filename")  

Avec pandas, il pourra être nécessaire de caster certaines colonnes dates suite à l’import.

La lecture en Spark autorise l’emploi de caractères génériques ( ? ou *) pour lire et concaténer automatiquement plusieurs fichiers. Les archives .zip contenant par exemple un fichier .csv peuvent être chargées sans décompression préalable, ce qui ne sera pas le cas avec pandas.

Fusion de deux dataframes

# pandas
df = pd.merge(df1, df2, on='key', how='inner')

# pyspark
df = df1.join( df2, 'key', how='inner') 

L’avantage de Databricks sera de pouvoir persister certains dataframes sous forme de vues (« tables locales ») ou de tables (« tables globales).  En particulier, le format delta pourra être mis à profit. Dès lors, il devient très simple de travailler en Spark SQL pur, toujours en débutant la cellule par la commande magique %sql.

Vérification du dataframe

# pandas
df.shape
df.info

# pyspark
df.count()
len(df.columns)
df.printSchema

Pandas se montre ici à son avantage avec des résultats plus simples à obtenir pour connaître les dimensions du dataframe (shape) ou des informations sur le schéma et les valeurs manquantes.

En conclusion

Lorsqu’on pose à certains érudits musicaux la sempiternelle question « Stones ou Beatles », il n’est rare d’entendre la réponse suivante : « ni l’un, ni l’autre, mais les Kinks ! »

A la question non moins sempiternelle « R ou Python », je répondrai donc… Scala ! C’est en effet le langage natif de Spark et donc le plus proche du moteur d’exécution.

Malgré tout, le choix se fera aussi en fonction de critères plus pragmatiques comme la puissance nécessaire au traitement, le coût de travailler sur l’exhaustivité des données (pourquoi par un échantillon représentatif ?) ou la maîtrise des différents langages par les personnes en charge des développements.

Que propose Microsoft pour la Data Science ?

En mars 2019, je publiais sur un blog ami cet état des lieux de l’offre Microsoft pour la Data Science : https://www.stat4decision.com/fr/microsoft-pour-la-data-science/

Depuis, la version Gen2 d’Azure Data Lake Storage est sortie (le logo a évolué). Azure Machine Learning Service est devenu un portail à part entière : ml.azure.com et depuis

Voici un aperçu des fonctionnalités en vidéo de ce qui s’appelle pour l’instant Azure Machine Learning Web Experience.