Nous avons fait le choix de créer un compte de stockage (ou plusieurs) séparé de celui propre à Synapse pour notre datalake. Et donc, après avoir créé nos différentes ressources (workspace et stockage), il reste une étape importante qui est la « connexion » du stockage au workspace afin de pouvoir travailler. Dans synapse cela se fait grâce à des « Services liés ».
Dans cet article, nous allons « lier » (faire la connexion) notre/nos comptes de stockage(s) de notre lake à notre workspace synapse.
Création du service lié
Les services liés peuvent être beaucoup de chose (et il y en a de plus en plus) qui peuvent même ne pas être des services Microsoft Azure. La procédure de création d’un service lié démarre de la même façon pour tous et se spécialise suivant le service spécifique que l’on souhaite lier.
Dans Synapse, dans la section « Manage » / « External connection » / « Linked services », nous voyons l’ensemble des services existant et avons la possibilité d’en créer un nouveau.
En cliquant sur « + New / Ajouter », l’interface nous propose la liste de service liable. Il est possible de rechercher un service spécifique et de cliquer sur sa petite image pour rentrer dans son interface de configuration spécifique. Au passage on remarque qu’il est possible de lier de nombreux services différents.
Le type type « Azure Data Lake Storage Gen2 » correspond aux comptes de stockage configuré avec un « hierachical namespace » te que créés précédemment dans notre projet. Par exemple Création des ressources de stockage : Azure Synapse Analytics – Azure Blob Storage – NiceData
Un nouveau panneau s’ouvre pour configurer spécifiquement notre Data Lake Storage. Après lui avoir donné un nom (1), nous avons le choix du type d’authentification. Plusieurs options s’offrent à nous et nous allons dans un premier temps utiliser le « system-assigned managed identity » qui s’apparente à utiliser les droits du user correspondant au Workspace Synapse. Cependant, lors du test de connexion, nous allons rencontrer une erreur de connexion.
Nous n’avons effectivement pas donné les droits à l’utilisateur « Workspace Synapse », mais uniquement à l’utilisateur qui a créé le compte de stockage.
Nous pouvons à ce moment valider la création de notre service et vérifier son fonctionnement plus tard, ouvrir un nouvel onglet pour ajouter les droits puis retenter la validation, ou simplement abandonner et recommencer plus tard.
Autorisations sur le stockage
Direction donc, sur la page de configuration du contrôle d’accès de notre compte de stockage dans Azure pour y ajouter un rôle d’accès.
Dans la liste de rôle présenté, nous pouvons commencer par filtrer les résultats en cherchant « blob » car nous souhaitons autoriser la lecture / écriture de blob dans notre compte de stockage puis cliquer sur « Storage Blob Data Contributor », qui donne les droits en lecture, écriture et suppression aux blobs sur l’ensemble des conteneurs de notre compte de stockage.
L’étape suivante consiste à choisir à quels utilisateurs nous allons attribuer ce rôle. Dans notre cas, nous devons donner ce rôle à l’utilisateur du Workspace. Comme le nom de notre choix d’authentification nous le laissez entrevoir ce « user », est une « identité managée / Managed identity ». Cela veut dire que ce n’est pas un utilisateur Entra/AD, mais une identité particulière qui existe dans Azure.
Pour nous simplifier la vie (et aussi parce que nous ne connaissons pas vraiment le « nom » de ce user, l’interface de sélection nous propose de choisir justement entre utilisateurs « standard » et identité managée. Une fois l’option identité managée sélectionnée, le panneau de sélection s’ouvre et nous propose de sélectionner la souscription qui héberge cette identité (c’est celle qui héberge notre workspace synapse), puis le type de service qui nous intéresse. En choisissant « Synapse workspace », l’interface nous propose la liste de nos workspaces. Nous n’avons plus qu’à sélectionner celui qui nous intéresse. Nous sommes en train de configurer notre environnement de développement donc nous allons sélectionner « Synicedata-dev ».
Si nous ne sommes pas seuls à travailler sur notre projet, il est possible dans le même temps d’ajouter le rôle au compte des autres membres. Il suffit de sélectionner l’option spécifique puis l’ensemble des membres auxquels on veut ajouter ce rôle.
Une fois notre liste complète, il ne nous reste plus qu’à vérifier et assigner notre rôle.
Nous pouvons maintenant reprendre la création de notre service lié et cette fois-ci, le test de connexion réussira !
Conclusion – Utilisation du service lié
Notre service lié est maintenant totalement configuré et prêt à être utilisé.
Après un éventuel rafraichissement de la page, nous pouvons maintenant naviguer dans notre datalake en nous rendant sur la page dédiée –> Data / Linked / sanicedatalakehouse.
Si celui-ci est actuellement vide, il sera possible de lire nos données via Spark ou le serverless SQL par simple navigation et génération automatique de script.