Créer un dataset Power BI depuis notre Synapse DataLakeHouse

Notre DataLakeHouse contient physiquement des fichiers de données. Ceux-ci sont organisés, nettoyés, représentent un modèle de donnée défini sur la « dernière » couche et éventuellement de formats différents. Nous pouvons donc lire nos données depuis ces fichiers et travailler dessus pour faire ce que l’on en veut.

Un des principaux cas d’usage est de connecter un outil de reporting pour faire de l’analyse de donnée. Dans un précédent article (Rafraichir un dataset Power BI depuis Azure Synapse Analytics – NiceData) nous avons vu comment rafraichir les données de notre Dataset Power BI directement depuis Synapse.

Nous allons dans cet article nous intéresser à comment créer un dataset Power BI sur les fichiers de notre DataLakeHouse/

Introduction et Prérequis

Dans notre paradigme du DataLakeHouse, nous avons besoin des fichiers de données dans notre Lake. Pour notre cas d’usage, j’utilise des fichiers parquet pour mes tables de faits et des fichiers csv pour mes dimensions. Pourquoi ? Parce que c’est l’avantage d’un DataLakeHouse, on est libre sur la partie « stockage ». L’important est comment on expose ces différents formats à l’extérieur. Nous partons pour notre exemple du postulat que nous avons déjà nos fichiers dans notre Lake.

Mise en place

Création de vues dans le Pool SQL Serverless

La première chose à faire est de créer des vues ou tables externes dans le Pool SQL Serverless afin de pouvoir lire les fichiers présents dans notre lake directement depuis n’importe quel client SQL.

Utilisation de l’interface Azure pour générer les scripts

La méthode la plus simple est d’utiliser directement l’interface de Synapse pour générer automatiquement nos objets SQL. Pour se faire, il faut se rendre dans la page liée à nos Data et naviguer jusqu’à nos fichiers de données.

Ensuite, sur chaque fichier, un clic droit nous offre différentes possibilités de génération de script. Nous allons nous intéresser à la création de tables externe en SQL.

Synapse travail seul dans son coin et nous propose quelques paramètres suivant le type de fichier source sélectionné.

Pour un fichier Parquet, c’est relativement simple, nous ne configurons que la taille maximum des champs de type string.

Pour un fichier CSV,

En ce qui concerne la création de nos objets, la première chose que nous synapse est sur quel serveur nous souhaitons créer nos objets. Dans notre cas nous utilisons le pool Serverless intégré à Synapse qui s’appelle « Built-in »

L’étape suivante consiste à sélectionner dans quelle base de données créée notre objet. Il nous est de plus proposé de créer une nouvelle « Base » directement. Ce que nous allons faire dans notre cas :

Une fois complètement configuré, il suffit d’ouvrir et exécuté le script que synapse a généré pour nous :

Nous n’allons pas analyser ce script qui n’est pas l’objet de cet article, mais simplement l’utiliser tel quel (enfin presque). Une fois sur ce script, il est possible de le renommer et lui donner une description, puis de configurer la connexion SQL à utiliser avant de pouvoir l’exécuter :

Si comme moi vous avez spécifié un schéma spécifique qui n’existe pas encore dans la base de données, il faudra impérativement le créer avant sous peine de rencontrer une erreur d’exécution.

Pour créer un schéma, il n’y a rien de plus simple :

Le script généré par Synapse fait un « Select » de la nouvelle table créer et donc à la fin de l’exécution de celui-ci nous devons voir le résultat de cette instruction dans l’onglet de résultat :

Un refresh de notre espace de travail dans l’espace « Data » nous permet maintenant de voir notre table externe créer dans notre base de données nouvellement crée en tant que « SQL database ».

Nous pouvons maintenant créer l’ensemble de nos tables externe pour créer notre DWH complet. Si vous n’avez pas l’intention de conserver le script de création de la table externe, il est possible de créer la table « Automatiquement » au lieu de générer le Script de création.

Cette fois-ci, le script généré est plus succinct et nous propose simplement de requêter notre table pour vérifier que tout à fonctionné.

Une fois l’ensemble des tables externes généré, nous pouvons décréter notre « Data Warehouse » créé !

Connexion à notre « Data Warehouse »

Nous avons pu voir depuis l’interface Synapse nos tables de données et des scripts SQL, mais le plus intéressant est que celui-ci est accessible comme n’importe quelle base de données SQL Serveur sur Azure.

Les chaines de connexion peuvent se trouver directement dans Synapse studio sur la page management.

Nous retrouvons l’ensemble des propriétés du pool Serverless pour trouver nos chaines de connexion.

Nous pouvons maintenant utiliser notre client SQL favori :

Import des données depuis Power BI

D’un point de vue Power BI nous sommes maintenant dans une situation très classique ou nous pouvons nous connecter à nos données avec une connexion SQL Serveur.

Notre « SQL Pool serverless » doit être considéré comme un serveur SQL classique. On y renseigne la chaine de connexion trouvée dans notre studio synapse.

Dans Power BI, nous ne voyons pas de différence pour la sélection de nos données avec un serveur plus « classique ».

Nous rentrons maintenant dans une configuration classique de travail avec Power BI.

Conclusion

La brique ServerLess SQL est l’atout majeur de notre DataLakehouse dans Synapse pour profiter de la puissance des traitements sur des fichiers cotés datalake tout en apportant la même souplesse d’utilisation qu’un datalake avec des technologies plus classiques.

Il reste maintenant de nombreuses optimisations techniques à mettre en place avec de la mise à jour incrémentale, de l’optimisation sur la structure de nos fichiers comme le partitionnement de fichier vu dans cet article : Générer un dataset partitionné via un data flow Azure Synapse Analytics – NiceData