L’émergence des bases de données HANA met le reporting en temps réel sur le devant de la scène.
Il y a peu, la question de l’actualisation des données arrivait dans les premières questions en phase de cadrage. Lorsque le reporting en J+1 était envisageable on ne revenait plus dessus. L’architecture mise en place, ainsi que la réponse fonctionnelle aux besoins découlaient de cette hypothèse.
Aujourd’hui les utilisateurs commencent par mentionner qu’il leur faut des données en temps réel avant même de dessiner une maquette de leur rapport.
Lors des premières versions de Power BI, le mode « direct query » était relativement faible, et présentait de nombreuses contraintes (connexion à une seule table ou modèle autorisée, impossibilité de créer des colonnes supplémentaires dans le desktop, …).
Les versions successives de Power BI permettent aujourd’hui d’accéder aux données en temps réel, via rafraichissement ou de façon composite. Néanmoins ce choix est beaucoup plus structurant qu’il n’y paraît. Attention donc à ne pas foncer dans la facilité du reporting en temps réel uniquement pour la raison « qui peut le plus peut le moins ».
Note :
- La mise à jour de février 2020 ajoute une fonction de rechargement incrémental pour le mode import (https://docs.microsoft.com/fr-fr/power-bi/service-premium-incremental-refresh).
- La mise à jour d’octobre 2019 permet de rafraîchir automatiquement le cache pour les rapports connectés en mode direct query.
Ces deux fonctionnalités supplémentaires ne sont pas traitées dans cet article, pour une raison de simplification. Elles permettent néanmoins d’optimiser en run ce qui intervient après le choix du mode de connexion.
Power BI permet un mode import et/ou un mode direct query
Mode import
Le mode import est le mode de fonctionnement historique de Power BI. Dans ce cas de figure, les jeux de données Power BI sont rafraîchis de manière planifiée et discrète.
Lors d’un rafraîchissement, toutes les étapes de création du modèle sont exécutées séquentiellement :
- Connexion aux sources de données,
- Chargement des données brutes (rafraîchies),
- Transformation,
- Création du modèle (lien entres données).
Le jeu de données ainsi obtenu est mis en cache afin de proposer une interactivité optimale pour l’utilisateur qui va se connecter.
Si vous avez déjà vu des démonstrations Power BI avec des visuels interactifs et des filtrages croisés, il s’agissait très certainement de ce mode de fonctionnement.
Mode « direct query »
Le mode « direct query » permet de laisser les données au sein de la base source. Des requêtes SQL peuvent alors être envoyées systématiquement :
- Durant la création du rapport (le desktop envoie une requête à chaque action afin de mettre à jour le visuel).
- A chaque étape de navigation par un utilisateur (c’est alors Power BI service qui prend le relai et envoie les requêtes).
Dans ce mode de fonctionnement l’aspect temps-réel est atteint puisque les données remontent de la base à chaque interaction.
Mode composite
Le mode composite permet au sein d’un même jeu de données d’avoir :
- Des sources de données rafraichies par import,
- D’autres sources de données connectées en direct.
Dans ce cas de figure, la mémoire cache de Power BI contient les données des sources connectées en import. Puis, lors de l’interaction d’un utilisateur, le service Power BI crée les requêtes SQL (en fonction du contexte), les transmet à la bonne base de données, afin de mettre à jour les éléments de la page en temps réel.
Le choix du mode d’acquisition est (quasiment) définitif dans Power BI
Le mode d’acquisition est déterminé dès la connexion à la source de données, il s’agit de la première étape lors de la création d’un rapport.
La définition du paramétrage du rapport est définitive et ne peut pas être modifiée ultérieurement.
Une exception existe toutefois. Il sera possible à un utilisateur de basculer une source de données paramétrée en « connexion directe » vers le mode « Importer », et ce à n’importe quel moment.
Une fois en mode « Importer », aucun retour arrière n’est réalisable et l’utilisateur ne pourra pas rebasculer en « connexion directe ».
Quelles sont les grandes lignes à suivre avant de choisir un mode ou l’autre dans Power BI ?
Avant de faire un choix, les critères suivants doivent être étudiés.
1 – Privilégier le mode Import lorsque c’est possible
Les recommandations de l’éditeur sont de privilégier l’import afin de profiter au maximum de la rapidité de calcul de power BI pour une expérience utilisateur fluide.
Les points à vérifier sont les suivants :
- Limitation du jeu de données ?
- En fonction de vos licences, une taille maximale de modèle existe (1GB pour un utilisateur pro ou en fonction du type de capacité pour les utilisateurs premiums).
- Le temps réel est-il nécessaire à tout prix ?
- Rappelons que Power BI Premium permet de rafraîchir jusqu’à 48 fois par jour un jeu de données.
2 – Evaluer les limitations de DirectQuery avant de passer à l’action
Les questions à se poser :
- Quelle sera la charge sur le système source ?
- La base de données sera souvent sollicitée, avec un risque de goulot d’étranglement induit par le reporting dans un système transactionnel.
- Quel est le temps de réaction d’une requête ?
- L’éditeur donne la limite de 5 secondes à ne pas dépasser. Au-delà l’expérience utilisateur ne sera pas bonne.
- Existe-t-il des limitations propres à ma source de données ?
- Chaque source de données ne donne pas accès aux mêmes fonctionnalités dans Power BI en mode connexion directe.
- Par exemple, SAP HANA n’est pas compatible aujourd’hui avec un modèle composite.
La connexion à SAP BW est un bon exemple pour illustrer que le choix du mode de connexion est lié avant tout au contexte :
- On peut trouver au sein du Magic Quadrant 2020 de Gartner une justification pour le mode import.
« Connectivity to SAP BW and HANA direct queries is problematic — a known issue that Microsoft is working on. Customers generally choose to load data into Power BI instead, which is more performant.”
- La recommandation de Microsoft est de passer par le mode direct query lors d’une connexion à une source OLAP (afin d’éviter les effets d’agrégations de mesures non additives) :
“ Pour faciliter l’obtention des données agrégées appropriées (en fonction des besoins du visuel) directement à partir de la source, il faudrait envoyer des requêtes par visuel comme c’est le cas dans DirectQuery. »
Pour creuser le sujet, le document suivant de l’éditeur ouvre la discussion sur les limitations en fonction des différents scénarios (lien : https://docs.microsoft.com/fr-fr/power-bi/desktop-directquery-about)
3 – Anticiper les pièges du temps réel et former les utilisateurs.
En mode composite, on peut retrouver le problème d’une source de données non rafraîchies comparée à une source de données en temps réel.
- Cela peut engendrer des incidents aux yeux de l’utilisateur non conscient de cette limitation.
L’interaction entre les visuels envoient tous une requête en base de données.
- Dans un contexte avec de nombreux utilisateurs et de nombreux visuels, le nombre de requêtes envoyées en base peut devenir un risque.
Lors de la conception d’un rapport, chaque action envoie une requête en base de données.
- De bonnes pratiques existent mais doivent être transmises, notamment dans un contexte de self-service.
Conclusion
L’expérience utilisateur est aujourd’hui le point fort de Power BI. Toute personne découvrant une maquette Power BI se rappellera la navigation fluide et intuitive.
Cette navigation fluide repose sur les modèles acquis en mode import, précalculés et conservés en mémoire cache.
Le reporting temps réel est certes réalisable avec Power BI, néanmoins cela sera au détriment des arguments précédents.
Le risque de détériorer l’expérience utilisateur au profit du reporting temps réel existe bel et bien au vu des nombreuses limitations existantes via les connexions DirectQuery.
Il s’agit donc de bien comprendre les conséquences de ce choix, les expliquer aux décideurs, pour éviter de perdre l’une des forces de cet outil au profit de 30 minutes de délai entre la nouvelle donnée et son apparition dans le reporting.
Emilien Gaignette