Monitoring des flux ADF sur Power BI

Par Samy ABTOUT, Data Engineer

Table des matières

  • Problématique
  • Solution
    • Présentation
  • Paramétrage
    • Data visualisation
  • Aller plus loin : Création d’alerte

Problématique

La gestion des données est aujourd’hui un enjeu majeur pour les entreprises. Nombreuses sont celles qui ont fait le choix de se doter d’un Data Lake afin de stocker leurs données de manière centralisée. En résulte alors une augmentation des flux d’alimentation accompagnés de leur solution de supervision.

Azure Data Factory (ADF) est l’outil principal d’extraction, d’ingestion et de transformation des données dans l’écosystème Microsoft Azure. Il propose également une interface de surveillance depuis l’onglet « Monitoring ». Cependant, celle-ci s’avère confuse et peu adaptée à de la supervision quotidienne, se limitant à lister chronologiquement l’ensemble des traitements exécutés.

Il est donc préférable de tirer parti d’outils de DataViz tel que Power BI, afin de restituer ces données au travers d’interfaces adaptées aux tâches de suivi et d’analyse.

Solution

Présentation

Les flux de traitements de données se décomposent généralement de la façon suivante :

  • Un pipeline Azure Data Factory en charge de l’orchestration globale des traitements
  • Plusieurs pipelines Azure Data Factory en charge de l’exécution d’activités de traitement

Des logs associés à l’exécution des pipelines et activités de traitements sont automatiquement générés à la volée dans ADF. Comme expliqué dans l’introduction, ces logs, visibles dans l’outil d’orchestration, sont utiles pour les développeurs lors du débogage pendant des phases de tests, mais ne sont pas adaptés pour de la supervision quotidienne.

Les informations exploitables depuis les logs, dans le cadre d’un suivi des traitements, sont multiples :

  • Nom des sources de données
  • Nom d’objets
  • Statut de l’exécution des pipelines et activités
  • Durée de traitement
  • Messages d’erreurs liés à des activités de traitement
  • Nom des fichiers rejetés, le cas échéant

Il est alors nécessaire d’exporter ces logs afin d’en faciliter l’utilisation.

Log Analytics est une solution Azure offrant la possibilité de collecter, d’analyser et de restituer les logs. Elle permet la centralisation des logs générés par des plateformes d’exécution telles qu’Azure Data Factory, et la mise à disposition de ceux-ci à destination d’outils de reporting pour de l’exploitation de données.

Paramétrage

Une configuration est nécessaire dans Azure Data Factory pour exporter les logs générés vers Log Analytics. Elle permet la connexion entre les deux outils et le filtrage des types de logs souhaités.

Pour cela, il faut se rendre dans le portail Azure :

  • Aller dans la ressource Azure Data Factory
  • Cliquer sur l’onglet Diagnostic settings (Paramètres de diagnostic)

  • Cliquer sur Ajouter un paramètre de diagnostic

  • La page des paramètres de diagnostic s’affiche :

  • Nommer le paramètre de diagnostic
  • Sélectionner les catégories de logs désirées
  • Définir une destination pour le stockage des logs. Voici les quatre choix possibles :
    • Envoyer les logs dans un magasin Azure Monitor Logs: Ceux-ci seront convertis au format journal.
      • Définir la souscription et le Workspace Log Analytics
      • Définir le type de table de destination :
        • Azure diagnostics: tous les logs sont écrits dans une unique table nommée AzureDiagnostics
        • Resource specific: chaque catégorie de logs possède une table de stockage distincte (logs de pipeline, d’activité, de déclenchement, etc…). Nous choisirons cette option qui facilite le requêtage des données.

    • Archiver les logs dans un fichier sur un compte de stockage : Cette approche est intéressante à des fins d’audit, d’analyse statique ou de sauvegarde. Ce mode de stockage est moins onéreux que le stockage Log Analytics.
      • Définir le compte de stockage de destination
        • Les fichiers seront stockés dans un conteneur nommé en fonction de la catégorie de logs généré, préfixé de « insights-logs » (Ex : insights-logs-sandboxpipelineruns). Voici l’arborescence de stockage :

      • Définir le temps de rétention des informations stockées dans le compte de stockage
    • Envoyer les logs vers un Event Hub
      • Définir l’EventHub de destination
    • Envoyer les logs vers des solutions partenaires de Microsoft: Une trentaine d’outils d’observabilité partenaires sont disponibles, voici la description de trois d’entre eux :
      • DataDog: Plateforme de supervision et d’analytique pour les applications à grande échelle.
      • Elastic: Plateforme qui permet de créer des expériences de recherche modernes et d’optimiser la visibilité sur l’intégrité, les performances et la sécurité de votre infrastructure, des applications et des données.
      • Grafana: Application Open Source qui permet de visualiser les données de métriques de façon chronologique

En ce qui concerne notre besoin de superviser les flux de traitements de données depuis Power BI, les redirections des logs vers Log Analytics ou un compte de stockage sont les solutions les plus adaptées à mettre en place.

La solution Log Analytics est la plus appropriée car elle permet le requêtage des logs via le langage Kusto. C’est un langage performant et facile à prendre en main car il possède une syntaxe proche du SQL, adapté à du requêtage de logs.

Enfin, il sera possible de mettre en place un système d’alertes depuis Log Analytics.

Data visualisation

Les informations liées à l’exécution des pipelines et des activités dans l’outil d’orchestration Azure Data Factory sont désormais redirigées vers Log Analytics et prêtes à être exploitées par Power BI.

Pour accéder aux logs générés, aller sur la ressource émettrice des logs (dans notre cas Azure Data Factory), et cliquer sur l’onglet Logs :

Depuis cette interface, il est possible de requêter le puit de logs via le langage Kusto. Voici un exemple de requête :

Après le développement des jeux de données en Kusto, il est possible d’exporter les requêtes en le langage M vers un fichier texte :

 

Il nous faut maintenant copier la requête exportée dans Power BI. Pour cela :

  1. Ouvrir Power BI Desktop et cliquer sur Transformer les données afin d’ouvrir Power Query :                   
  2. Ouvrir une requête vide :
  3. Aller dans l’éditeur avancé :
  4. Coller le contenu du fichier texte exporté

 

Le jeu de données est maintenant disponible dans Power Query.

Répéter les étapes 2, 3 et 4 pour chaque jeu de données à importer. Voici un exemple de hiérarchie entre jeux de données qui peut être effectuée :

  • Dataset lié aux pipelines d’orchestration
    • Dataset lié aux pipelines d’exécution
      • Dataset lié aux activités

Fermer et appliquer les changements sur Power Query. Afin de finaliser la création du modèle de données, il est nécessaire d’établir les liens entre les jeux de données :

Le modèle créé, il ne reste plus qu’à développer les visuels permettant de surveiller de manière efficiente les flux de traitements de données.

 

Aller plus loin : Création d’alerte

Nous venons de voir comment monitorer les flux de traitements de données. Il est également recommandé de mettre en place une stratégie d’alertes afin d’être immédiatement averti en cas de disfonctionnement dans la chaîne d’alimentation.

En fonction du degré de précision attendu par ces alertes, il est possible de distinguer deux types de notifications :

  • Les alertes statiques, qui sont créées depuis la section Alerte de la ressource Azure Log Analytics
  • Les alertes personnalisables, qui peuvent être configurées en HTML depuis Azure Data Factory et envoyées à une LogicApp via la restAPI qui se chargera du formatage et de l’envoi de mail

Dans un prochain article, nous explorerons plus précisément la création, la configuration et l’exploitation des notifications avec les systèmes d’alertes mentionnés précédemment afin d’optimiser la surveillance des flux de traitements de données.

Comment optimiser les performances d’un rapport Power BI ?

Par Khaoula BENYAHYA, Data Analyst

En tant que Data Analyst Power BI, nous sommes souvent confrontés à des problèmes de performances. Il est alors recommandé de prendre en considération cette composante lors des développement et maintenance de nos rapports.

Cet article détaille, dans un premier temps, une liste d’outils permettant d’identifier la cause de la latence. Puis, il décrit les bonnes pratiques à adopter lors des phases de développement et d’optimisation d’un rapport.

  • Pourquoi un rapport est lent ?

Le diagramme suivant aide à orienter le développeur lors de l’évaluation des causes de la latence constatée :

Source : https://docs.microsoft.com/fr-fr/power-bi/guidance/report-performance-troubleshoot

Dans le cas où l’arbre de décision nous redirige vers la mesure 5 (optimisation du rapport), nous devons réaliser une étude de l’existant afin d’identifier les axes d’amélioration possibles. Pour ce faire, nous disposons de différents outils, détaillés ci-dessous.

  • Outils pour mesurer la performance des rapports Power BI :

Les outils suivants constituent une liste non exhaustive des solutions permettant l’analyse des performances de rapports Power BI :

  • Analyseur de performance – Power BI Desktop : mesure le temps d’exécution (en millisecondes) associé aux différentes actions effectuées sur le rapport. Il sert donc à mesurer quels sont les traitements les plus couteux en temps d’exécution afin de connaître les visuels et traitements à optimiser en priorité.

  • Diagnostic de requêtes Power Query :

Pour comprendre le type de requêtes émises et les ralentissements qui peuvent avoir lieu lors de l’actualisation du modèle, ainsi que le type d’évènements qui se produisent en arrière-plan :

  • Dax Studio :

Pour mesurer la performance d’une requête DAX :

Pour mesurer la taille des tables et quelle colonne occupe le plus d’espace en mémoire :

Lorsque les rapports sont hébergés sur une capacité Premium, il est également possible d’identifier les rapports lents en surveillant l’application Power BI Premium Metrics.

  • Bonnes pratiques pour améliorer la performance des rapports :

Voici les bonnes pratiques à mettre en place pour améliorer la performance des rapports Power BI. La performance peut être améliorée sur 5 niveaux :

  • Connectivité et choix du mode de stockage ;
  • Passerelle ;
  • Modèle de données ;
  • Requêtes DAX ;
  • Design

 

1- Connectivité et mode de stockage :

Le choix du mode de connectivité dépend de plusieurs facteurs :

En résumé, le mode Import offre de meilleures performances mais requiert davantage de mémoire dans le service Power BI ainsi qu’une gestion spécifique de l’actualisation des données.

A contrario, le mode DirectQuery n’est pas soumis à ces contraintes par son mécanisme d’interrogation en temps réel de la source de données connexe. Cependant, cela entraine une augmentation de la latence puisque toutes les requêtes s’exécutent à la volée.

Le mode Mixte permet de trouver un équilibre entre les performances des rapports, les données en temps réel, la taille et le temps d’actualisation du dataset.

2. Passerelle :

La passerelle est mise en place quand on interroge une source de données locale. Elle agit comme un pont entre la source de données et le service Power BI. Voici des bonnes pratiques à appliquer lors du déploiement de passerelles :

  • Placer le serveur de passerelle aussi proche que possible des sources de données pour minimiser la latence du réseau. Si le serveur de passerelle est loin de la source, les informations devront passer par plusieurs ordinateurs et composants d’infrastructure. Chaque étape ajoute une petite quantité de délai de traitement, qui peut augmenter lorsque les réseaux sont encombrés.
  • Supprimer la limitation du réseau : certains pare-feu ou proxy réseau peuvent être configurés pour limiter les connexions afin d’optimiser la connectivité Internet. Cela peut ralentir les transferts via la passerelle.
  • Éviter d’exécuter d’autres applications ou services sur la passerelle, surtout sur les environnements de production. Cela garantit que les charges provenant d’autres applications ne peuvent pas avoir d’impact imprévisible sur les requêtes.
  • Séparer les passerelles des sources de données DirectQuery des sources de données en import (qui demandent une actualisation planifiée) autant que possible. Cela permet d’éviter la mise en file d’attente de milliers de requêtes DirectQuery dans la passerelle au moment de l’actualisation planifiée d’un modèle de données volumineux.
  • Utiliser un stockage local suffisant et rapide : le serveur de passerelle met en Buffer (mémoire tampon) les données avant de les envoyer dans le cloud. En cas d’actualisation de plusieurs datasets volumineux en parallèle, il faut s’assurer d’avoir assez d’espace en mémoire pour pouvoir les stocker temporairement en local. Il est donc recommandé d’utiliser des options de stockage à haut débit et faible latence (par exemple les disques SSD) pour éviter que le stockage ne devienne un goulot d’étranglement.
  • Favoriser la passerelle de données locale (on-premise) au lieu de la passerelle personnelle (Personal Gateway). La Personal Gateway importe des données dans Power BI. La passerelle on-premise (également appelée Enterprise Gateway) n’importe rien, ce qui est plus efficace en cas de grands volumes de données.

3. Modèle de données :

Pour améliorer la performance au niveau du modèle de données :

  • Favoriser le modèle en étoile au lieu d’un modèle en flocon.
  • Favoriser la création de nouveaux champs (colonnes) directement sur la source de données plutôt que de créer des colonnes calculées. Une colonne est recalculée à chaque actualisation du rapport ce qui fait perdre la performance.
  • Privilégier la création de mesures des colonnes. Une colonne est physiquement stockée dans le fichier, elle augmente donc la taille du dataset et le temps d’actualisation. Contrairement à une mesure qui permettra de réduire le temps d’actualisation ainsi que la taille du fichier .pbix.
  • Supprimer les tables ou les colonnes non utiles pour diminuer la taille du dataset et avoir un modèle simple. Cela améliorera aussi l’expérience utilisateur.
  • Renommer les champs directement sur la source de données si possible, pour éviter les étapes de « rename» dans le modèle de données. Ce sont des étapes de transformation supplémentaires que le modèle n’aura pas à exécuter.
  • Favoriser le filtrage simple (à sens unique) et ne pas activer les relations du filtrage croisé bidirectionnel sauf dans un contexte d’utilisation et intérêt bien définis. L’activation de cette option peut entraîner des ambiguïtés, un suréchantillonnage, des résultats inattendus et une détérioration potentielle des performances. L’ambiguïté associée à ce type de filtrage est amplifiée dans une relation plusieurs-à-plusieurs en raison de la multitude de chemins entre les différentes tables.
  • Activer la sécurité au niveau des lignes (RLS : Row Level Security) pour restreindre l’accès des utilisateurs à certaines lignes d’une base de données en fonction du rôle exécutant une requête. Avec la RLS, Power BI importe uniquement les données que l’utilisateur est autorisé à afficher.
  • Éviter d’utiliser des types de données à virgule flottante (Float) car ils peuvent entraîner des erreurs d’arrondi imprévisibles et réduire les performances des rapports.
  • Appliquer le « Query Folding» : cela signifie que le moteur Power Query peut traduire les étapes de transformations en une seule requête qui est envoyée à la source de données dans son langage de requête natif :

Pour cela, sur l’éditeur de requêtes Power Query, vérifier que la « barre de formule » est activée sur l’onglet « Affichage » :

4. Requêtes DAX :

Pour améliorer la performance des mesures et des requêtes DAX créées :

  • Se méfier des fonctions qui nécessitent d’évaluer chaque ligne d’une table (par exemple SUMX). Ce type de fonctions parcourt l’ensemble de la table, ligne par ligne :  calcule une expression pour chaque ligne d’une table spécifiée, stocke temporairement le résultat de chaque ligne, additionne tous ces résultats puis libère la mémoire temporaire et renvoie le résultat final. Il faut donc les utiliser uniquement si nécessaire car elles consomment plus.
  • Utiliser des variables au lieu de répéter les définitions de mesures pour ne pas dupliquer les mêmes calculs dans une seule mesure. Par exemple, la mesure basique pour calculer un taux d’évolution des ventes par rapport à N-1 est la suivante :

YoY% = DIVIDE (
SUM ( [Total Sales] )
CALCULATE ( SUM ( [Total Sales] ), DATEADD ( ‘Calendrier'[Date], –1, YEAR ) ),
CALCULATE ( SUM ( [Total Sales] ), DATEADD ( ‘Calendrier'[Date], –1, YEAR ) ) )

La valeur des ventes N-1 est référencée deux fois et peut être stockée dans une variable.

Une façon plus optimisée de calculer ce taux est donc la suivante :

YoY%_VAR =
VAR __PREV_YEAR = CALCULATE ( SUM ( [Total Sales] ), DATEADD ( ‘Calendrier'[Date], –1, YEAR ) )
RETURN
DIVIDE ( ( SUM ( [Total Sales] ) – __PREV_YEAR ), __PREV_YEAR )

 

  • Éviter d’utiliser FILTER dans les fonctions qui acceptent les conditions de filtre : les fonctions telles que CALCULATE et CALCULATETABLE acceptent un paramètre de filtre utilisé pour ajuster le contexte du calcul. La fonction FILTER renvoie une table, ce qui n’est pas efficace lorsqu’elle est utilisée comme condition de filtre dans d’autres fonctions.

La mesure suivante permet de calculer les ventes effectuées sur la catégorie « Accessories » :

Sales = CALCULATE ( [Sales], FILTER ( ‘Product’, ‘Product'[Category] == « Accessories » ) )

Il est préférable de remplacer l’expression de table par une expression booléenne, comme suit :

Sales = CALCULATE ( [Sales], ‘Product'[Category] == « Accessories » )

 

  • Utiliser SUMMARIZE uniquement pour les colonnes de texte : Bien que cette fonction autorise n’importe quel type de colonne, il est conseillé de ne pas utiliser de colonnes numériques pour des raisons de performances. Il faut utiliser plutôt SUMMARIZECOLUMNS, qui est plus récent et plus optimisé. La raison en est que SUMMARIZECOLUMNS fonctionne dans un contexte de ligne, alors que la même expression dans un SUMMARIZE est exécutée dans un contexte de filtre correspondant aux valeurs des colonnes groupées.
  • Utiliser ISBLANK au lieu de = BLANK pour vérifier les valeurs vides : ils obtiennent le même résultat, mais ISBLANK est plus rapide.
  • Utiliser IFERROR et ISERROR de manière appropriée : Ils peuvent être enroulés autour d’une mesure pour fournir des alternatives en cas d’erreurs de calcul. Cependant, ils doivent être utilisés avec précaution car ils augmentent le nombre d’analyses requises au niveau du moteur de stockage et peuvent forcer les opérations ligne par ligne dans le moteur. Il est recommandé de traiter les erreurs de données à la source ou dans les étapes ETL pour éviter d’effectuer une vérification des erreurs en DAX.
  • Utiliser la fonction DIVIDE au lieu de l’opérateur de division : En divisant des nombres, il faut gérer les valeurs vides ou nulles dans le dénominateur pour éviter les erreurs. L’intérêt de la fonction DIVIDE est qu’elle gère automatiquement ces cas au niveau du moteur de stockage ce qui est plus rapide. De plus, elle a un troisième paramètre facultatif qui permet de spécifier une valeur alternative à utiliser si le dénominateur est nul ou vide.

 

La mesure suivante permet de calculer le profit :

Profit = IF ( OR ( ISBLANK ( [Sales] ), [Sales] == 0 ), BLANK (), [Profit] / [Sales] )

Une version améliorée utiliserait la fonction DIVIDE, comme suit :

Profit = DIVIDE ( [Profit], [Sales] )

  • Utiliser COUNTROWS plutôt que COUNT : la fonction COUNT compte les valeurs de colonne et COUNTROWS compte les lignes de la table. Les deux fonctions renvoient le même résultat, dans la mesure où la colonne comptée (avec COUNT) ne contient pas de valeurs BLANK. Pour éviter tout type d’erreur, il est meilleur d’utiliser COUNTROWS car elle est plus efficace et donc plus performante. De plus, elle ne tient pas compte des valeurs BLANK contenues dans les colonnes de la table.

 

5. Design :

L’amélioration des performances d’un rapport passe également par la conception et l’agencement des différents visuels :

  • Limiter le nombre de visuels par page. Chaque page doit contenir de 5 à 7 visuels au maximum.
  • Limiter l’interaction entre les visuels si elle n’est pas nécessaire. Cela réduira le nombre de requêtes exécutées car une sélection dans un visuel n’affecte plus tous les autres.
  • Utiliser des arrière-plans de rapport pour les images statiques plutôt que plusieurs visuels.
  • Utiliser des signets, des pages d’accès au détail et des info-bulles. Ceux-ci permettent de réduire le volume et la complexité des requêtes exécutées et donc de réduire le temps de chargement de la page.
  • Tester les performances des visuels personnalisés car ceux-ci peuvent mal fonctionner lors de la gestion de grands ensembles de données ou d’agrégations complexes. Les visuels personnalisés non certifiés ne sont généralement pas testés par l’équipe Power BI et sont donc déconseillés.
  • Réduire le nombre de requêtes envoyées par Power BI à l’aide des paramètres de réduction des requêtes. Pour les slicers, sélectionner l’option « Ajouter un bouton Appliquer à chaque slicer pour appliquer les changements quand vous êtes prêt ».

Pour les filtres, sélectionner « Ajouter un seul bouton Appliquer au volet de filtres pour appliquer les changements à la fois « .

  • Combiner des cartes individuelles dans des cartes à plusieurs lignes ou des tableaux : Une pratique de rapport courante consiste à utiliser de nombreux visuels de cartes individuelles pour afficher des métriques récapitulatives dans une ligne. Or, chacun de ces visuels émettra une requête.

Lorsque les mesures proviennent du même visuel, les moteurs de stockage de données peuvent souvent récupérer des données et calculer plusieurs mesures en un seul lot. Par conséquent, en utilisant une seule carte multi-lignes ou un visuel de tableau, une seule requête sera émise.

 

En conclusion, il est possible d’améliorer les performances d’un rapport à chaque étape de son développement, de la collecte des données sources à la conception des visuels. A travers cet article, nous avons détaillé les bonnes pratiques à adopter et appliquer afin d’obtenir un rapport Power BI performant. Celles-ci se basent au préalable sur une bonne compréhension des causes potentielles de latence obtenue à l’aide des outils décrits en introduction.

Pourquoi et comment intégrer Python dans Power BI – partie 2 ?

Par Khaoula BENYAHYA, Data Analyst

 

Cas d’illustration :

Dans cette partie, nous allons illustrer l’intérêt d’utiliser Python dans Power BI en réalisant des visuels qui n’existent pas dans l’outil. Nous nous sommes basés sur un jeu de données qui contient le détail des commandes avec des données sur les produits achetés ou vendus ainsi que les données relatives aux clients et aux vendeurs. Nous avons 3 catégories de produits : Accessories, Bikes et Clothing.

Pour les graphiques réalisés, nous avons utilisé la librairie matplotlib. C’est une librairie très riche qui permet de customizer presque tous les paramètres d’un graphique Python.

  • 1er exemple

Dans un premier temps, nous voulons afficher la répartition mensuelle des quantités commandées de chaque catégorie, ainsi que le total de ces quantités. Nous allons illustrer cela sous forme d’histogrammes.

Ce qui donne :

Le graphique est dynamique si nous filtrons sur les catégories. Nous affichons la répartition de chaque catégorie sélectionnée ainsi qu’un histogramme global qui illustre la somme des catégories choisies. C’est la boucle for qui permet cette dynamique. Par exemple :

Le code qui permet de réaliser cela est :

   # import libraries
    import matplotlib.pyplot as plt
    # color pallet
    colors = ['#12239E','#118DFF','#E66C37','#751E73']
    # get number of categories
    nb_cat = len(dataset['Category'].unique())+1
    # declare constraints
    const = 1
    cpt = 1
    color_choice = 0
    # for loop to plot histograms for each category chosen
    for category in dataset['Category'].unique():
    # get number of the subplot
    subplot=int(str(nb_cat)+str(const)+str(cpt))
    # choose the subplot where to plot the histogram
    plt.subplot(subplot)
    # get data of the category to plot
    cat=dataset[dataset.Category==category].drop('Category',axis=1)
    # plot the graph
    plt.bar(cat['Mois'],cat['OrderQty'],color=colors[color_choice],width=0.5)
    # set x axis to invisible
    plt.gca().get_xaxis().set_visible(False)
    plt.title(category)
    cpt=cpt+1
    color_choice=color_choice+1
    # calculate and plot the sum of order quantities by month
    total_simple =
    dataset.groupby('Mois').agg('sum').reset_index().sort_values(by='Month
    Num')
    subplot_total=int(str(nb_cat)+str(const)+str(cpt))
    plt.subplot(subplot_total)
    plt.bar(total_simple['Mois'],total_simple['OrderQty'],color='#6B007B',width=0.5)
    plt.title('Total')
    plt.xlabel('Période') # label of axis x
    plt.xticks(rotation=35) # rotate axis x labels
    # visualizing the plot
    plt.show()

Grâce à la bibliothèque Matplotlib, une seule ligne de code est nécessaire pour spécifier les colonnes sur lesquelles vous souhaitez faire rapport pour créer ce graphique. Le reste du code permet de customizer celui-ci et le rendre plus dynamique. Cela montre à quel point Python est simple pour créer des graphiques, ce qui permet donc de créer des rapports Power BI plus avancés.

  • 2e exemple

Dans l’exemple suivant, nous souhaitons afficher l’évolution des quantités commandés ainsi que les montants commandés des sous-catégories.

Les courbes réagissent bien avec le filtre « SubCategory » en n’affichant que les sous-catégories sélectionnées sur l’axe x.

Ce graphique à 2 axes y permet d’analyser la relation entre la quantité commandée et le montant commandé. Cependant, si vous n'avez besoin que de simples graphiques linéaires ou à barres, je vous suggère d'utiliser plutôt les graphiques intégrés de Power BI, faciles à configurer et à modifier, sans nécessité de code. De plus, le chargement des visuels Python prend plus de temps que les graphiques intégrés, il est donc plus logique d'allouer le temps de chargement plus long à des graphiques plus complexes que nous ne pouvons pas réaliser avec Power BI.

Le code qui permet de réaliser ce graphique est le suivant :

    import matplotlib.pyplot as plt
    # create figure and axis objects with subplots() and defining the figure
    size
    fig,ax = plt.subplots(figsize=(10,6))
    # make a plot
    ax.plot(dataset.SubCategory,dataset.OrderQty,color="#12239E")
    ax.set_ylabel("Quantité de commandes",color="#12239E",fontsize=14)
    # get rid of the frame
    for spine in plt.gca().spines.values():
    spine.set_visible(False)
    # twin object for two different y-axis on the sample plot
    ax2=ax.twinx()
    # make a plot with different y-axis using second axis object
    ax2.plot(dataset.SubCategory,dataset.LineTotal,color="#D64550")
    ax2.set_ylabel("Montant commandé",color="#D64550",fontsize=14)
    fig.autofmt_xdate(rotation=45)
    # get rid of the frame of the twin object
    for spine in plt.gca().spines.values():
    spine.set_visible(False)
    ax.grid('on')
    plt.rcParams["figure.dpi"] = 100
    plt.show()

 

  • 3e exemple

Dans l’exemple suivant, nous souhaitons réaliser des ventilations petits multiples par mesure et non par axe uniquement, en changeant le type de graphique par mesure.

Un histogramme pour la mesure Order Quantity, une courbe linéaire pour Line Total, et un nuage de points pour Unit Price. Les 3 graphiques ont un axe x commun qui représente les mois.

Le code :

  import matplotlib.pyplot as plt
    # set the size of the figure
    figure = plt.figure(figsize=(10,6))
    # subplot the figure into 3 plots and configure the 1st plot
    plt.subplot(311)
    plt.bar(dataset.Mois,dataset.OrderQty,color='r',width=0.5)
    # set axis x to invisible
    for spine in plt.gca().spines.values():
    spine.set_visible(False)
    plt.grid('on')
    ax=plt.gca()
    ax.get_xaxis().set_visible(False)
    # set label for axis y
    plt.ylabel('Order quantity')
    # configure the 2nd plot
    plt.subplot(312)
    plt.plot(dataset['Mois'],dataset.LineTotal,color='b')
    # set axis x to invisible
    for spine in plt.gca().spines.values():
    spine.set_visible(False)
    plt.grid('on')
    # set grid of axis x to invisible
    ax=plt.gca()
    ax.get_xaxis().set_visible(False)
    plt.ylabel('Line Total')
    # configure the 3rd plot
    plt.subplot(313)
    # set axis x to invisible
    for spine in plt.gca().spines.values():
    spine.set_visible(False)
    plt.grid('on')
    #unit=dataset.groupby(['Mois']).UnitPrice.mean()
    plt.scatter(dataset['Mois'],dataset['UnitPrice'],color='g') # plot scatter
    for Unit Price by months
    plt.ylabel('Unit Price')
    plt.xlabel('Période',fontsize=14)
    figure.autofmt_xdate(rotation=35) # rotate axis x labels
    plt.show() # visualizing the plot

 

  • 4e exemple

Dans ce dernier exemple, nous voulons afficher la performance en pourcentage d’un individu, sous forme d’une jauge, avec la possibilité d’afficher la valeur de l’objectif à atteindre pour l’année N ainsi que la performance de l’année N-1. Pour cet exemple, nous avons utilisé un 2 e jeu de données qui contient les données de performance d’un individu selon les années.

L’axe x présente la performance en %
Nous obtenons le résultat suivant pour l’année 2020 :

Pour 2016 :

Le code utilisé est le suivant :

 import pandas as pd
    import matplotlib.pyplot as plt
    import numpy as np
    label='Performance' # bar label
    # positions of horizontal lines
    positions = [dataset["Objectif"],dataset["Réalisé N-1"]]
    line_colors = ['#E66C37','#744EC2'] # color palet
    line_styles = ['solid','dashed'] # style of lines
    # define the size of the figure
    fig, ax = plt.subplots(figsize=(8, 2.5))
    # define the limits of x axis
    plt.xlim(0, 100)
    # change the scale of x axis
    plt.xticks(np.arange(0, 110, 10))
    # plot the horizontal bar
    plt.barh(label,width=dataset["Réalisé"],height=0.8,color='#118DFF',linestyle='solid',hatch='/',linewidth=5)
    # get rid of the frame
    for spine in plt.gca().spines.values():
    spine.set_visible(False)
    # plot the horizontal lines
    for i in range(2):
    plt.vlines(x=positions[i], ymin=-1.5, ymax=1.5, color=line_colors[i],
    linestyle=line_styles[i])
    # plot the legend
    ax.legend(['Objectif','Réalisé n-1','Réalisé'],ncol=3, bbox_to_anchor=(0,
    1), loc='lower left')
    # visualizing the plot
    plt.show()

NB :
la librairie NumPy est la bibliothèque Python la plus populaire de calcul numérique.

Conclusion :

Dans cet article, nous avons vu ce que Python peut faire dans Power BI à l'aide de quelques exemples simples. Python libère un grand potentiel en termes d'obtention de données et de création de graphiques personnalisés plus compliqués. Cependant, il existe certaines limitations des visuels Python. Comme nous l'avons mentionné précédemment, Python peut ralentir les performances et ne peut récupérer que 150 000 enregistrements. Je peux imaginer que cela soit problématique pour les grands projets de business intelligence.

Mais cela n'est que le début de l’exploration des faisabilités de Python dans Power BI. J'aurai peut-être d'autres idées à partager à l'avenir !

Pourquoi et comment intégrer Python dans Power BI ?

Par Khaoula BENYAHYA, Data Analyst

 

La visualisation des données nous aide à identifier des modèles, des tendances et des corrélations qui pourraient ne pas être détectés autrement. En plaçant les données dans un contexte visuel, nous améliorons notre compréhension des données. Power BI est un outil parmi d’autres pour la visualisation des données.

Qu’est-ce que Power BI ?

Power BI est un outil de business intelligence (BI) qui sert à la gestion, l’analyse, la visualisation et le partage de données au sein d’une organisation.

Le principe de Power BI, c’est le self-service BI. Cela veut dire que l’utilisateur final n’a pas besoin d’avoir des connaissances informatiques poussées pour être en mesure de produire son propre
rapport.

See the source image

Pourquoi utiliser Power BI ?

Power BI présente de nombreux avantages :

1. Mémoire et vitesse : de gros volumes de données peuvent être rapidement collectées et analysées.

2. Sécurité des données : Power BI permet de publier des rapports en toute sécurité et de contrôler librement l’accessibilité des données.

3. Savoir-faire technique avancé non requis : pour rendre ainsi accessible au plus grand nombre d’usagers.

4. Interaction entre les diverses solutions Microsoft : Les solutions Microsoft s’intègrent facilement avec Power BI. De plus, de nombreuses fonctionnalités sont partagées entre les différentes applications de Microsoft. Par exemple, Power BI repose sur le langage DAX et le langage DAX, repose en partie sur la bibliothèque de fonctions Excel. Il y a donc un gain important au niveau de l’apprentissage des usagers.

5. Coût relativement faible : l’application Desktop est gratuite et pour tirer avantage de toutes les fonctionnalités de sécurité, partage, gouvernance, etc., il faut adhérer à une licence.

6. Fonctionnalités pertinentes offertes aux créateurs : en voici quelques-unes :

  • Large choix de connexion aux sources de données
  • Options de personnalisation riches et puissantes pour la création des tableaux de bord.
  • Accès à de nombreux visuels et modèles de tiers de la communauté Power BI
  • Création de visuels basés sur des fonctionnalités d’IA.
  • Bénéficier de compléments comme R et Python pour l’analyse avancée.

Intérêt de faire du Python dans Power BI :

Python est devenu l’un des langages de données à la croissance la plus rapide et de plus en plus utile. Profitant de cette tendance, Power BI a introduit la prise en charge de Python en août 2018.

Cette intégration ouvre un large éventail de possibilités en termes d’extraction et de nettoyage des données ainsi que de création de visuels attrayants et entièrement personnalisés.

Python est indiscutablement l’un des langages préférés des statisticiens, des data scientists et des data analysts. Par conséquent, pour les data analysts ou data scientists qui développent déjà en Python, mais qui ne sont pas chargés d’utiliser Power BI pour une raison quelconque, ils peuvent facilement intégrer leur corpus de travail existant dans cet outil.

En tant que professionnels de la BI, si on souhaite effectuer certaines tâches de data science, on doit nous appuyer sur une équipe de data scientists. D’un autre côté, un développeur Python doit s’appuyer sur l’équipe BI pour présenter son analyse dans un format présentable. A l’inverse, et c’est tout l’intérêt, Power BI supprime cette co-dépendance car il est possible désormais d’exécuter Python dans un environnement intégré.

Qu’est-ce que Python ?

C’est un langage de programmation open source qui présente de nombreuses caractéristiques intéressantes. Il est :

  • Multiplateforme : C’est-à-dire qu’il fonctionne sur de nombreux systèmes d’exploitation : Windows, Mac OS X, Linux, Android, iOS, depuis les mini-ordinateurs Raspberry Pi jusqu’aux supercalculateurs.
  • Gratuit : Vous pouvez l’installer sur autant d’ordinateurs que vous voulez (même sur votre téléphone !).
  • De haut niveau : Il demande relativement peu de connaissance sur le fonctionnement d’un ordinateur pour être utilisé.
  • Langage interprété : Un script Python n’a pas besoin d’être compilé pour être exécuté, contrairement à des langages comme le C ou le C++.
  • Orienté objet : C’est-à-dire qu’il est possible de concevoir en Python des entités qui miment celles du monde réel avec un certain nombre de règles de fonctionnement et d’interactions.
  • Relativement simple à prendre en main (notion très relative !).
  • Très utilisé en bio-informatique et plus généralement en analyse et science de données.


Exemples de fonctionnalités de Python dans Power BI

L’utilisation de Python dans Power BI offre plusieurs fonctionnalités : 1. Importer des données en utilisant un script Python. Sur le ruban d’accueil, cliquez sur Obtenir les données > Plus… puis choisissez Script Python, puis au code !

Une image contenant texte Description générée automatiquement
Figure 1 : Importation de donnée avec un script Python

2. Intégrer Python dans l’éditeur Power Query de Power BI Desktop. Cela permet d’effectuer un nettoyage des données à l’aide de Python et d’effectuer une mise en forme et une analyse avancée de données dans les datasets, y compris le traitement des données manquantes, les prédictions et le clustering, pour n’en nommer que quelques-uns. Pour ce faire, il faut :

  • Ouvrir Power Query
  • Sur l’onglet « Transformer », cliquer sur « Exécuter le script Python »
  • Sur la fenêtre qui s’ouvre, écrire le code pour le traitement souhaité. Par exemple pour un cas simple de traitement de valeurs manquantes :

Une image contenant texte Description générée automatiquementFigure 2 : Exécution du script Python

 

3. Incorporer des fonctionnalités du Machine Learning en tant qu’étape du workflow.

4. Automatiser et optimiser les processus.

5. Créer des visuels personnalisés : on va détailler cela dans la partie suivante.

Comment ajouter des visuels personnalisés en Python dans Power BI ?

 

1- Installation de Python : avant d’exécuter des scripts Python dans Power BI Desktop, vous devez installer Python sur votre ordinateur local. En effet, Power BI Desktop n’inclut, ne déploie, ni n’installe le moteur Python. Une fois Python installé, il faut vérifier que les scripts Pythons sont activés sur Power BI Desktop.

Pour cela, sélectionnez : Fichier > Options et paramètres > Options > Création de scripts Python. Au niveau de la page Options de scripts Python, vérifiez que le chemin local d’installation de Python est détecté, ou si nécessaire l’indiquer dans Répertoires de base Python détectés le chemin d’accès.

Graphical user interface, text, application Description automatically generated
Figure 3 : Options de script Python

 

2- Installation des packages requis : les packages pandas (bibliothèque pour la manipulation et l’analyse des données) et matplotlib (bibliothèque de traçage 2D de Python qui produit des figures de qualité) sont nécessaires pour que Python visual fonctionne, il est donc requis de les installer grâce à la commande pip install sur une console ou un interpréteur de commandes.

3- Création de visualisations avec Python dans Power BI Desktop :

a. Cliquer sur le visuel Python dans le panneau de visualisation :

A screenshot of a computer Description automatically generated with low confidenceFigure 4 : Les visuels Python

 

b. Un espace réservé au visuel Python apparaît dans le canevas de Power BI. En cliquant dessus, on voit apparaître un « éditeur de script Python » en bas de la page.

Graphical user interface Description automatically generated with low confidenceFigure 5 : Editeur de script Python

c. Après avoir chargé un jeu de données dans Power BI, glisser et déposer les attributs/champs à visualiser dans la section Valeurs :

Graphical user interface, application Description automatically generated

Figure 6 : Section Valeurs

 

d. Désormais, les données peuvent être utilisées pour créer des tracés à l’aide du script Python. Un code Python est généré pour les champs sélectionnés.

Text Description automatically generated

Figure 7 : Éditeur de Script Python

e. Le code Python peut être exécuté en cliquant sur le bouton  » play« .


Contraintes et limitations de Python dans Power BI :

Python est une excellente fonctionnalité à utiliser avec Power BI, mais il présente quelques limitations :

  • Taille des données : les données utilisées par le visuel Python pour le traçage sont limitées à 150 000 lignes. Si plus de 150 000 lignes sont sélectionnées, seules les 150 000 premières lignes sont utilisées et un message s’affiche sur l’image. En outre, les données d’entrée ont une limite de 250 Mo.
  • Résolution : tous les visuels Python sont affichés dans une résolution de 72 ppp.
  • Temps de calcul : si le calcul d’un visuel Python prend plus de cinq minutes, le délai d’exécution est dépassé, ce qui provoque une erreur.
  • Relations : Comme avec d’autres visuels Power BI Desktop, si des champs de données provenant de différentes tables, sans aucune relation définie entre elles, sont sélectionnés, une erreur se produit.

· Si le jeu de données d’entrée d’un visuel Python a une colonne qui contient une valeur de chaîne de plus de 32766 caractères, cette valeur est tronquée.

· Les visuels Python sont actualisés lors de la mise à jour, du filtrage et de la sélection des données. Toutefois, l’image elle-même n’est pas interactive et ne peut pas être la source du filtrage croisé.

· Les visuels Python répondent à la sélection d’autres visuels, mais vous ne pouvez pas cliquer sur des éléments dans le visuel Python pour appliquer un filtre croisé à d’autres éléments.

· Seuls les tracés représentés sur l’écran Python par défaut s’affichent correctement sur le canevas. Évitez d’utiliser explicitement un autre écran Python.

· Les visuels Python ne prennent pas en charge le renommage des colonnes d’entrée. Les colonnes sont référencées par leur nom d’origine durant l’exécution du script.

· Uniquement les packages Python suivants sont actuellement pris en charge : Numpy, Pandas, Matplotlib, Seaborn,Scipy, Scikit-learn, Statsmodels, Xgboost.

· Sur l’éditeur de script Python sur Power BI, on ne retrouve pas les fonctionnalités d’un IDE (Integrated Development Environment) indépendant, telle que IntelliSense : un assistant de complétion de code, qui reste une des fonctionnalités les plus importantes pour un développeur. Cela ne sera pas très contraignant puisqu’en général, on ne sera pas amené à écrire des centaines lignes de code sur Power BI. Cette limite peut être contournée par la possibilité de développer sur votre éditeur externe préféré, puis directement importer le code sur Power BI Desktop.

Automatiser le déploiement de rapports Power BI à l’aide d’Azure DevOps

Power BI est une solution d’analyse de données conçue par Microsoft. Pensée dans une logique de self-service BI, elle vise à rendre autonome les utilisateurs métier sur les phases de conception et développement de rapports interactifs.

Les rapports développés sont partagés au travers d’un portail web : https://app.powerbi.com.

Cette publication peut se faire manuellement depuis le client lourds Power BI Desktop, ou via le portail web directement. La gestion des déploiements, des versions de rapports ou encore des environnements cibles peut rapidement s’avérer fastidieuse.

Afin de sécuriser la chaine de développement et simplifier la réalisation et le suivi des publications, il est pertinent de mettre en place un pipeline de déploiement automatisé.

Au travers de cet article, nous allons voir comment mettre en place une chaine CI/CD pour Power BI avec Azure DevOps. Nous verrons comment :

  • Enregistrer et paramétrer une application dans Azure Active Directory
  • Configurer les tenant et Workspace Power BI
  • Enregistrer des développements Power BI dans un Repo DevOps
  • Configurer et créer un pipeline de build/release


Configuration des environnements

Enregistrement d’une nouvelle application

Pour accéder au contenu et aux API du service Power BI, vous devez inscrire une application qui s’authentifiera auprès de votre Azure Active Directory.

Pour ce faire, suivez ces instructions :

  •  Se connecter à l’Azure Portal
  •  Sélectionner Azure Active directory, puis App Registration
  • Cliquer sur New Registration
  • Donner un nom et une description à l’application, puis sélectionner le type de compte coché (cf. Figure 1) avant de l’enregistrer

Une image contenant texte Description générée automatiquement

Figure 1 : Créer une application

Une fois l’application créée, nous pouvons accéder à sa vue d’ensemble :

Figure 2 : Overview de l’application Power Bi créée

Depuis l’application, sélectionner Certificats & Secrets et générer un nouveau secret client :

Une image contenant texte Description générée automatiquement

Figure 3 : Création d’un secret client pour l’application

La dernière étape consiste à paramétrer les permissions de l’application afin de lui donner la possibilité d’accéder en lecture et écriture au Service Power BI.

Pour ce faire :

  • Cliquer sur API permissions, puis Add a permission
  • Rechercher Power BI Service
  • Sélectionner Application permissions
  • Cocher Tenant.ReadAll et Tenant.ReadWriteAll
  • Valider les permissions

Figure 4 : Paramétrage des permissions de l’application

NB : les autorisations ajoutées peuvent nécessiter la validation par un administrateur. Si cela est le cas :

  • Se rendre dans l’Azure Active Directory, puis sélectionner Entreprise Application
  • Rechercher et cliquer sur l’application PowerBI
  • Dans le panneau latéral, cliquer sur Permissions situé dans l’onglet Security
  • Cliquer enfin sur Grant admin consent for <VotreSouscription>

 

Configuration du tenant Power BI

L’application enregistrée précédemment au niveau de l’Azure Active Directory communique avec les APIs Power BI via un Service Principal qui lui est assigné.

Cette communication doit être préalablement autorisée au niveau du tenant Power BI pour être pleinement fonctionnelle.

Pour ce faire :

  • Se connecter au portail Power BI
  • Cliquer sur l’icône des paramètres en haut à droite et sélectionner Admin portal
  • Cliquer sur Tenant settings et autoriser l’option Allow service principals to use Power BI APIs présente dans la partie Developer settings

Une image contenant texte Description générée automatiquement

Figure 5 : Autorisation du Service Principal à accéder aux APIs Power BI

Configuration d’un Workspace Power BI

La seconde étape consiste à autoriser l’application à interagir avec un Workspace donné, afin de lui permettre par la suite de publier des rapports dans le cadre du pipeline de déploiement automatisé.

L’attribution des droits est similaire à un utilisateur classique, à savoir :

  • Sélectionner le Workspace cible
  • Cliquer sur les 3 points verticaux en haut à droite
  • Cliquer sur Workspace access

Figure 7 : Accès à la fenêtre de paramétrage des accès du Workspace

  • Rechercher l’application dans Azure AD et ajouter les droits Administrateur ou Collaborateur à minima

Figure 8 : Attribution du rôle Contributor à l’app PowerBI


Synchronisation depuis Azure DevOps


Enregistrement des rapports Power BI dans un repo Azure DevOps

Azure Repos
est un système de contrôle de version basé sur git et faisant partie de la solution Azure DevOps. Coupler les sources de développement à ce service permet leur sauvegarde et suivi dans
le temps, tout en facilitant le travail collaboratif.

De plus, il offre la possibilité de mettre en place des chaines CI/CD pour le déploiement des sources vers différents environnements.

NB : l’utilisation d’Azure Repos comme contrôleur de source n’est pas obligatoire, et peut être substitué par BitBucket, TFCV, GitHub, …

Dans le cadre de cet article, nous n’allons pas détailler les actions de création, synchronisation et utilisation d’un repo, mais simplement rappeler les étapes entrant dans la sauvegarde d’un rapport Power BI dans un repo Azure DevOps :

  • Créer un nouveau repo Power BI dans lequel seront gérées les différentes versions des rapports

Figure 9 : Initialisation d’un repo Power BI dans Azure DevOps

  • Cloner le Repo Power BI sur le serveur local en cliquant sur Clone in VS Code avant de choisir un répertoire local :

Figure 10 : Clonage du repo Power BI dans un répertoire local

Une image contenant texte Description générée automatiquement

Figure 11 : Accès au contenu du répertoire Power BI depuis Visual Studio Code

  • Créer un rapport Power BI dans le répertoire en question. Dans cet exemple, nous ajoutons le rapport suivant :
    – Libellé : AdventureWorks_InternetSales.pbix
    – Source : Base de données Azure Analysis Services

Une image contenant texte Description générée automatiquement

Figure 12 : Ajout du rapport AdventureWorks_InternetSales.pbix

  • Réaliser un commit puis un push des modifications réalisées dans le répertoire vers le repo Azure :

Une image contenant texte Description générée automatiquement

Figure 13 : Enregistrement des modifications dans Azure Repo

  • Vérifier que le rapport est bien présent dans le repo depuis l’interface web Azure DevOps :

Une image contenant texte Description générée automatiquement

Figure 14 : Rapport Power BI sauvegardé dans DevOps


Création de pipelines de déploiement Azure DevOps

Extension d’automatisation

Grâce aux API REST Power BI, il est possible d’interagir avec le Service Power BI afin de réaliser de nombreuses tâches telles que :

  • Import / export de rapport Power BI Desktop (.pbix)
  • Rafraichissement d’un dataset
  • Création / suppression de Workspace
  • Gestion des accès à un Workspace (Utilisateur, Groupe, Service Principal)

Dans le cadre de l’implémentation de pipelines CI/CD, nous sommes amenés à utiliser ces API afin de configurer l’automatisation des déploiements.
Afin de simplifier ce processus, Il existe des extensions DevOps dédiées.
Microsoft a mis à disposition depuis décembre 2021 l’extension Power BI automation tools.

Une image contenant texte Description générée automatiquement

  • Figure 15 : Power BI Automation tools

Cette extension propose un ensemble d’opérations d’API pour les pipelines de déploiement :

  •  Créer/supprimer un pipeline
  • Attribuer/retirer un Workspace au pipeline
  • Ajouter un utilisateur à un pipeline et/ou Workspace
  • Déployer des Dataflows, Datasets, Reports et Dashboard dans un Workspace

Cependant, elle présente pour l’heure certaines limitations qui peuvent s’avérer bloquantes :

  • Ne prend pas en charge la mise à jour des chaines de connexion des sources du rapport
  • Fonctionne uniquement sur des Workspace Premium
  • Est toujours en version Preview

Une autre extension, développée et mise à disposition par Maik VAN DER GAAG, permet également de réaliser facilement des chaines CI/CD. Nommée Power BI Actions, celle-ci offre la possibilité d’automatiser un grand nombre de tâches telles que :

  • Chargement / import de rapports Power BI
  • Création / suppression de Workspace Power BI
  • Ajout d’utilisateurs, Group ou Service Principal à un Workspace Power BI
  • Mise à jour des chaines de connexion d’un rapport et rafraichissement automatisé
  • Etc…

Répondant à l’ensemble de nos besoins et ne nécessitant pas d’abonnement Premium, c’est la solution pour laquelle nous allons opter pour la suite de cet article.

Ainsi, la première étape de la création de pipelines de déploiement automatisé consiste à installer cette extension dans notre organisation DevOps. Pour ce faire :

  • Depuis Organization Settings, cliquer sur Extensions présent dans l’onglet General.
    Cliquer ensuite le bouton Browse marketplace



Figure 16 : Recherche de l’extension depuis la marketplace

  • Rechercher Power BI Actions, la sélectionner puis cliquer sur Get it free

Une image contenant texte Description générée automatiquement

Figure 17 : Ajout de l’extension

  • Sélectionner l’organisation DevOps à laquelle ajouter l’extension puis lancer son installation

Figure 18 : Installation de l’extension pour l’organisation sélectionnée

Connexion au Service Power BI

Avant de créer le pipeline de déploiement, nous devons configurer la connexion entre DevOps et leService Power BI. Celle-ci, nomméeService connection, est à paramétrer depuis DevOps :

  • Depuis l’écran Project Settings du projet Power BI, cliquer sur Service connections présent dans l’ongletPipelines avant de sélectionner Create service connection
  • Rechercher Power BI Service connection et passer à l’étape suivante

Figure 19 : Création d’une connexion à Power BI

  • Depuis l’écran de configuration, choisir Service Principal comme méthode d’authentification, ainsi que l’environnement Public, puis préciser les informations suivantes :
    Tenant ID : Directory (tenant) ID de l’app Power BI créée en début d’article
    Client ID : Application (client) ID de l’app Power BI
    Client Secret : Value du secret de l’app Power BI

Figure 20 : Configuration du service connection

Création du pipeline de build (CI)

Ce pipeline a pour objectif de capturer l’ensemble des sources du repo (ici le rapport .pbix) afin de les publier sous forme d’artefacts de déploiement. Ce sont ensuite ces artefacts qui seront déployés sur les différents environnements via le pipeline de release.

La création de ce pipeline se fait par le biais des étapes suivantes :

  • Depuis le projet DevOps, sélectionnerPipelines puis cliquer sur Create Pipeline
  • Choisir Azure Repos Git, puis le repo PowerBI et enfin Starter pipeline

Figure 21 : Configuration du pipeline de build

Dans l’écran de Review du pipeline YAML, ajouter le code suivant :

trigger:
- main

pool:
  vmImage: 'windows-latest'

steps:
- task: CopyFiles@2
  displayName: "---=== Power BI Reports ===---"
  inputs:
    SourceFolder: '$(Build.SourcesDirectory)'
    Contents: '**.pbix'
    TargetFolder: '$(Build.ArtifactStagingDirectory)'
    Overwrite: true
- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'PowerBIReport'
    publishLocation: 'Container'

 

NB : Ce script se charge de copier les fichiers .pbix présents dans le repository pour les publier en tant qu’artefacts dans le répertoire PowerBIReport.

  • Cliquer enfin sur Save and run. Le pipeline s’exécutera alors avec succès

Création du pipeline de release (CD)

Ce pipeline définit l’ensemble des étapes à suivre pour déployer les datasets et rapports Power BI (.pbix) vers les environnements cibles.

L’utilisation de l’extension Power BI Actions précédemment installée permet de faciliter son implémentation, en proposant une interface graphique de configuration des différentes tâches du pipeline.

Pour cet exemple, nous souhaitons :

  • Déployer un rapport Power BI Desktop (.pbix) sur un Workspace de production
  • Modifier la chaine de connexion au cube Azure Anaysis Services afin de pointer vers la base de données de production.

La création d’un tel pipeline suit les étapes suivantes :

  • Depuis le projet DevOps, sélectionnerRelease dans l’onglet Pipelines, cliquer sur New pipeline puis Empty job

Figure 22 : Création d’un pipeline de release vide

  • Cliquer sur Add an artifact.
  • Depuis la fenêtre de paramétrage, choisir Build comme Source type afin de récupérer le rapport publié par le pipeline de build créé à l’étape précédente.
  • Compléter les informations Project etSource, choisir Latest pour Default version afin de déployer automatiquement la dernière version du rapport, puis valider.

Figure 23 : Configuration des artefacts à déployer

  • Une fois l’artefact paramétré, cliquer sur 1 job, 0 task du Stage 1 afin de configurer les tâches de déploiement.
  • Au niveau de l’Agent job, cliquer le +, puis rechercher Power BI Actions avant de cliquer sur Add :

Figure 24 : Ajout d’une tâche Power BI Actions

  • La première tâche consiste à publier le rapport sur le Workspace de production. Renseigner les informations suivantes :
    Power BI service connection : Service connection configuré précédemment
    Action : Upload Power BI report
    Workspace name : Libellé du Workspace de destination
    – Source file : chemin complet vers le rapport à déployer.

Celui-ci est facilement accessible depuis le menu « » car l’artefact a été paramétré plus tôt

Figure 25 : Configuration de la tâche de publication du rapport

  • Ajouter une nouvelle tâche Power BI Actions.
  • Cette seconde tâche consiste à mettre à jour la chaine de connexion à la base de données Azure Analysais Services (AAS). Les informations suivantes sont attendues :
    Power BI service connection : Service connection configuré précédemment
    Action : Update datasource connection
    Workspace name : Libellé du Workspace de destination
    Dataset name : Libellé du rapport Power BI
    Datasource type : Type de la source de données (ici Analysis Services)
    Old Server : Chaine de connexion au server préconfiguré dans le rapport
    New server : Chaine de connexion vers le server AAS de destination
    Old dataset : Libellé de la base de données sur le server source
    New dataset : Libellé de la base de données sur le server de destination

Une image contenant texte Description générée automatiquement

Figure 26 : Configuration de la tâche de mise à jour de la chaine de connexion de la source AAS

  • Sauvegarder le pipeline de release.

Une image contenant texte Description générée automatiquement

Figure 27 : Sauvegarde du pipeline de release

  • Afin de tester notre pipeline, nous devons créer une release avant de la déployer. Pour ce faire, cliquer sur Create release à côté du bouton Save.
  • Dans la nouvelle fenêtre, sélectionner l’étape tout juste créée (renommée ici Publish Power BI Report) puis cliquer sur Create.

Figure 28 : Création d’une release

  • La release Release-1 a été créée.
  • Sélectionner l’étape non déployée, avant de cliquer sur Deploy.

Figure 29 : Déploiement du pipeline de release

  • Une fois le déploiement achevé, un résumé des actions est disponible, ainsi que les logs associées.

Figure 30 : Déploiement du rapport et modification de la chaine de connexion réalisés avec succès

  • Enfin, nous retrouvons bien les rapports et datasets publiés dans notre espace de travail.

Une image contenant texte Description générée automatiquement

Figure 31 : Rapport Power BI accessible depuis le Workspace de production

Variabilisation des paramètres du pipeline

Lors de la création du pipeline de release, nous avons paramétré un certain nombre d’informations, telles que les serveurs et base de données AAS, ou encore le Workspace de destination Power BI.

Ces informations, codées « en dur », ne facilitent pas la maintenance et l’évolutivité de la chaine.

Ainsi, il est recommandé de les variabiliser à l’aide des variables de pipelines.

Depuis l’écran Pipeline variables de l’onglet Variables du pipeline de release, il est possible de paramétrer les variables qui seront par la suite appelées depuis les tâches.

Celles-ci sont constituées de :

  • Name : Libellé de la variable
  • Value : Valeur de la variable
  • Lock : Masquer ou non la valeur de la variable
  • Scope : Périmètre sur lequel la variable est disponible

Afin d’illustrer leur utilisation, nous faisons évoluer le pipeline précédent en ajoutant une nouvelle étape de publication du rapport sur l’environnement de développement.

Puis, nous créons les 7 variables suivantes :

Figure 32 : Variables du pipeline de release

Les 5 premières variables, communes aux deux étapes, sont rattachées au périmètre Release.

A l’inverse, les libellés des Workspace de DEV et PROD sont associés uniquement à leur étape respective.

Enfin, nous modifions les tâches précédemment développées en remplaçant les valeurs inscrites « en dur » par leur équivalent sous forme de variables.
Tout d’abord pour la tâche de publication du rapport :

Figure 33 : Variabilisation des informations de paramétrage de la publication du rapport

Puis pour la tâche de modification de la chaine de connexion :

Une image contenant texte Description générée automatiquement

Figure 34 : Variabilisation des informations de paramétrage de la modification de la chaine de connexion

Une fois les modifications sauvegardées, la release recréée puis déployée, nous obtenons une chaine CI/CD complète de publication et paramétrage en DEV et PROD d’un rapport Power BI Desktop « commité » dans un repo Azure :

Figure 35 : Déploiement du rapport et modification de la chaine de connexion sur deux environnements


Conclusion

Au travers de ce cas d’usage, nous avons vu comment réaliser de bout en bout une chaine CI/CD de déploiement de rapport Power BI Desktop (.pbix).

Par le biais d’un pipeline de build / release, il est possible d’automatiser les tâches de publication des rapports. Cette solution, au-delà du côté pratique, présente de nombreux avantages :

  • Fiabilisation du processus de publication
  • Versioning des rapports
  • Choix de la version du rapport à publier, permettant un rollback à tout moment
  • Gouvernance du service Power BI simplifiée

Quelles sont les étapes clés d’un projet décisionnel ?

Créer une base de données dédiée, le DatawareHouse pour

Accueillir de manière centralisée et transversale les données détaillés des applications sources et construire un référentiel commun
Conserver les données sources supprimées ou purgées pour les analyser si besoin
Garantir flexibilité et évolutivité, pour s’adapter rapidement aux stratégies de l’entreprise
Dater les changements, par exemple, si un produit change de rayon, cet évènement sera daté. On pourra ainsi mesurer l’impact de ce changement sur un résultat des ventes.

Le DatawareHouse peut aussi être décomposé en datamart(s), sous-ensemble(s) offrant une vision centrée autour d’un métier, un processus de l’entreprise.

Charger les données

A l’aide d’un outil nommé ETL (Extract Transform, Load), le datawarehouse est alimenté à une fréquence régulière. L’ETL va permettre de charger rapidement une forte volumétrie d’informations, homogénéiser et transformer les données avant de les déposer dans le DatawareHouse.

Permettre l'analyse des données

...grâce à l'utilisation de l'OLAP(OnLine Analytical Processing). Cette étape consiste à réorganiser les données sous une forme multidimensionnelle. Elles sont dès lors stockées sous forme d’axes d’analyse de l’entreprise, appelés aussi dimensions, (exemple : dimension temps, dimension produit, dimension géographie…) Aux croisements de ces dimensions, on définit des mesures pour constater un résultat, un fait.
Exemple, au croisement de l’axe du temps 2009, produit ordinateur et magasin Paris, j’obtiens la mesure 1 000 K€ de CA réalisé. Le principal avantage d’une solution OLAP, est de pré-agréger les données de les restituer sans pénaliser les temps de réponse… Plus besoin d’attendre 15 min pour afficher un reporting !
Les dimensions étant généralement organisées par hiérarchies, il est possible d’explorer dynamiquement les données, en allant du niveau le plus agrégé vers le plus détaillé (exemple : explorer le CA pour 2009, puis du premier semestre 2009, puis consulter le résultat pour chaque mois du semestre…)

Restituer l’information

sous deux formes : les états pré-formatés tels que les tableaux de bords s ynthétiques, les listes de résultats, les états à sélection multicritères et les états construits dynamiquement par les utilisateurs métiers. Ces outils, simples d’utilisation rendent autonomes les utilisateurs qui n’ont pas besoin de solliciter le service informatique. Ils peuvent aussi créer directement les états à partir de leurs outils bureautiques tels qu’Excel.
Afin de privilégier le travail collaboratif, les états sont regroupés sur un portail, et peuvent être distribués de manière automatique par email. L’utilisateur reçoit uniquement les états à jour correspondant à ces besoins. L’envoi peut aussi être déclenché par une alerte comme la détection d’un incident, un objectif non atteint, un niveau de stock insuffisant…

Au-delà de la business intelligence, le datamining

Grâce à des algorithmes puissants, cette technique va analyser les données stockées dans le DatawareHouse et effectuer des regroupements d’informations, rechercher des associations, exemple : quand un client achète un produit, quel autre produit achète-t-il généralement ? Toujours à partir des données existantes, le datamining permet de mener des analyses prédictives.
On pourra de cette manière définir des tendances, prévoir des ventes à partir de critères comme une saisonnalité, une zone géographique… Et bien plus encore.