Création des ressources de stockage : Azure Synapse Analytics – Azure Blob Storage

Pour rappel, nous travaillons à la mise en place d’un datalake/datalakehouse « dans » Azure Synapse Analytics. Ce scénario tourne autour de deux solutions que sont :

• Storage account / Data Lake Storage –> le « datalake »
• Synapse workspace –> L’environnement de développement et d’intégration

Cet article est centré autour de la création du stockage.

Définition du Datalake

En soi, le Datalake n’est rien d’autre qu’un espace de stockage de fichier. Celui-ci a cependant généralement des propriétés technologiques spécifiques permettant une capacité de stockage quasiment infinie, une rapidité de lecture/écriture, des mécanismes de redondance des données et bien d’autres encore.

On parle couramment d’un ou du datalake cependant, un datalake est souvent divisé en plusieurs zones. Le nommage n’est pas important (techniquement parlant), mais la littérature parle souvent de zone Bronze/Silver/Golden et tout dépendra de la nomenclature définie dans notre projet. Cette division peut être « logique » ou « stricte ». Nous ne rentrerons pas de le détail dans cet article qui a vocation à créer ce que nous avons défini dans notre projet.

Division logique

Une division logique signifie d’avoir toutes ces zones dans le même compte de stockage dans des répertoires (ou container) différents.

Le choix d’une division logique rend la gestion des ressources et la configuration de l’ensemble de notre Datalake plus simple, car nous devrons gérer qu’une seule ressource. Cependant nos possibilités de configuration et de sécurités seront réduites.

Cette option reste cependant valide si le datalake n’a pas vocation à être ouvert à une population autre que l’équipe dédiée à sa création (pas de grandes contraintes de sécurités) ou que vous prévoyez de gérer la sauvegarde et la réplication de l’ensemble des zones de la même façon (pas de contrainte de configuration).

Elle est aussi souvent utilisée pour le démarrage du projet ( on ne sait pas encore comment seront découpées nos zones) ainsi que pour des environnements de développement ou de tests.

Division stricte

Une division stricte signifie que chaque zone possède son propre compte de stockage.

Cette option reste la plus utilisée pour un environnement de production et consiste à créer plusieurs comptes de stockage (un par zone) qui pourront ensuite être configurés individuellement.

C’est l’option que nous allons choisir pour notre projet (même si les différences de configuration seront effectuées plus tard).

Information

La procédure définie dans cet article décrit la création d’un seul compte. Il suffit de rejouer la même procédure en changeant les noms de nos ressources pour créer nos différents stockages pour notre séparation stricte. En l’occurrence nous remplacerons : « sanicedatalakedev » par « sanicedatalakebronze », sanicedatalakesilver » et sanicedatalakegolden ».

Création du Datalake

Dans le monde Azure, tout ce qui est stockage tourne autour d’un compte de stockage ou « Storage account ». Ce sera donc notre première étape !

Rendez-vous sur le portail Azure et une des méthodes les plus efficaces reste de faire une recherche de notre « Stora… »

Sinon il est toujours possible d’utiliser le menu et de choisir « All services » pour avoir la liste de ce que propose Azure.

Le Storage account est proposé dans la première partie de cette page :

Nous arrivons donc sur la page de gestions des comptes de stockage ou nous pouvons maintenant en créer un nouveau :

Configuration du projet

La configuration commence très classiquement par les détails de plus haut niveau de notre projet avec la souscription Azure qui sera utilisé et le ressource groupe utilisé. Pour la souscription, la question se pose très rarement à notre niveau et ce sera très certainement la souscription à laquelle vos administrateurs vous ont donné accès ou celle créée pour l’occasion.

Au niveau du ressource group, il y a plusieurs stratégies. Celle que nous utiliserons ici et globalement dans l’ensemble de cette série d’articles est de créer un « rg » (Ressource Group), pour toutes les ressources utilisées dans un environnement pour un projet. La gestion des rg est un sujet à part entière qui n’est pas traité ici, mais il faut comprendre que cela regroupe des ressources différentes et que cela rend la visibilité/gestion de ressources liées plus simple. On peut voir le coût Azure par rg, on peut supprimer en une commande toutes les ressources d’un rg, …

La traduction dans notre cas est la suivante :

• 1 rg pour notre Datalake de DEV
• 1 rg pour notre Datalake de PROD
• 1 rg pour des ressources « cross projets »

Pour notre scénario, si vous avez suivi dans l’ordre, nous utilisons le rg créé à la création du workspace Synapse « nicedatalake-dev ». Sinon, l’idée est de mettre le datalake et le studio dans le même rg.

La configuration générale du Storage Account

Sur la même page, juste en dessous, nous trouvons la configuration des « détails de l’instance » qui est la première étape de notre création.

Après la configuration de notre compte de stockage et sa localisation (que nous choisirons la plus proche de nous), nous allons aborder le premier sujet important des comptes de stockage.

Voici ce qui est proposé par défaut (que l’on a tendance à garder lorsque l’on est novice) :

• Côté « Performance », pour un datalake, le Standard est probablement plus que suffisant. Lorsque l’on travaille sur des batchs de gros fichiers, la latence n’est généralement pas le souci majeur.
• Côté « Redundancy » (redondance), il faut bien réfléchir à notre cas d’usage et l’implication de chaque sélection sur les coûts..

La sélection par défaut nous propose du « GRS ». Ceci implique que pour des raisons de « sauvegarde et reprises d’activité », vos données sont répliquées dans une zone géographique différente. Ceci est évidemment très intéressant, car nous protège de la perte ou de l’indisponibilité du datacenter qui nous héberge. cependant, cela implique deux coûts supplémentaires :

• Le stockage étant « dupliqué », celui-ci est aussi facturé. Nous serons donc facturés à la fois pour notre stockage « primaire » et pour le secondaire.
• La bande passante utilisée pour la Géoréplication des données.

Lorsque l’on fait des tests, un peu de veille et que l’on ne travaille pas sur de gros volume de données, ces coûts peuvent être très faibles et passés inaperçus. Cependant, lorsque l’on travaille avec du « BigData », et que nos traitements utilisent beaucoup de stockage « temporaire », alors, ces coûts peuvent devenir conséquents. Il est alors important de s’assure que cette redondance est bien nécessaire et qu’elle ne peut se faire « autrement. »

De plus, la case à coche en dessous permet d’avoir des accès point sur la zone de stockage secondaire. Ceci permet de rester accessible en cas d’indisponibilité de la zone principale, car nous serons en mesure de directement lire nos données sur la 2nd zone sans avoir à « restaurer » nos données en premier. Mais cette résilience a aussi un coût.

Pour en savoir plus, la Doc officielle est disponible ici.

Ma proposition pour notre datalake de développement est donc d’utiliser du Standard / LRS :

Configuration avancée

On continue la configuration avec là encore un besoin de modification d’un paramètre par défaut.

Si plusieurs paramètres sont importants, notamment la partie sécurité ou « Blob storage » les configurations par défaut sont acceptables pour de nombreux cas d’usage, il nous est nécessaire d’activer la fonctionnalité « Enable hierarchical namespace » dans la section « Data Lake Storage Gen2 ». C’est principalement ce paramètre qui « transforme » note espace de stockage en datalake en permettant de créer une structure de dossiers pour « organiser » notre datalake.

Configuration réseau

A ce moment, nous allons pouvoir configurer la connectivité de notre compte de stockage. Il faut à ce moment comprendre ce que représente les deux notions que sont :

• Public access : globalement c’est « internet », l’idée principale c’est que cet accès n’est pas « privé » et donc n’utilise pas d’accès spécifique comme un VPN par exemple. (Attention, il n’est pas ici question d’accéder à notre stockage sans authentification ou mot de passe, mais de pouvoir renseigner nos identifications depuis n’importe quel réseau même non protégé ou identifié)
• Private access : à l’inverse, dans ce type de communication, il n’est pas possible d’accès au compte de stockage sans être préalablement dans un réseau privé type VPN.

Il existe cependant un choix intermédiaire qui propose un bon compromis. Il s’agit d’autoriser les connexions publiques depuis un réseau ou une IP spécifique. Très facile à configurer, l’interface nous demande de renseigner un réseau virtuel Azure existant (ou d’en créer un pour l’occasion), soit de créer une règle Firewall sur notre compte de stockage. En entreprise, il sera souvent nécessaire de définir la plage d’IP utilisé et pour les connexions personnelles, notre IP publique sera nécessaire. (L’interface nous propose d’ailleurs d’ajouter simplement l’adresse par laquelle nous sommes actuellement connectés). Lorsque nous créons une règle de restriction, il est cependant crucial de garder cochée l’exception qui permet aux ressources Azures de communiquer avec notre compte de stockage pour éviter de complexifier nos connectivités futures.

Le choix de la connectivité sera fortement guidé par les administrateurs réseau et « l’équipe » sécurité qui auront déjà défini comment l’on doit se connecter sur Azure lors du choix du provider cloud.

Ce qu’il faut retenir c’est que c’est à notre équipe réseau / sécurité de nous dire comment configurer cette partie.

Cette configuration pourra se changer plus tard et il est plutôt recommandé de ne pas utiliser l’option d’autorisation depuis « tout » les réseaux publics (dans le cadre de notre POC, pour être certains de pas rencontrer de problèmes de connectivités qui doivent être réglés avec une équipe réseau, nous allons malgré tout pouvoir utiliser cette option qui sera donc à modifier plus tard pour rentre notre plateforme plus sécurisée).

Nous pouvons maintenant passer à l’étape suivante qui reste dans le thème de la sécurité.

La sécurité des données

Après la sécurité de niveau réseau, Azure nous nous propose de nous intéresser à la protection de données.

A ce niveau ce qui nous intéresse concerne la suppression de fichier ou leur modification. Que ce soit manuellement ou via des scripts, nous allons nécessairement agir sur nos fichiers. Nous ne sommes donc pas à l’abri de faire une mauvaise manipulation de supprimer ou modifier le mauvais fichier. Beaucoup d’autres cas pourraient entrer en jeux comme de la corruption de fichier, mais là n’est pas la question. Pour « sécuriser nos données », Azure nous propose le « Soft delete ».

Le soft delete peux être vue comme une corbeille intelligente qui fonctionne aussi avec la modification.

Le processus est simple, lorsque l’on supprime un fichier, celui-ci est juste « marqué » comme supprimé et « caché » par défaut. Sur le même principe lors de la modification d’un fichier, notre corbeille intelligente va en faite créer un nouveau fichier avec les modifications et marquer l’ancien fichier comme supprimé et le cacher.

Couplée à ce principe, afin de ne pas faire gonfler notre stockage à vie, une période de rétention est attachée après laquelle notre fichier masqué sera définitivement supprimé.

Ce principe de soft delete peux s’applique au niveau blobs (fichier), container ou file shares et les valeurs de rétentions par défaut sont la limite basse de 7 jours :

Dans le cadre de notre datalake, nous allons :

• Etre amené à énormément modifier certains de nos fichiers des couches hautes : à chaque alimentation nous allons modifier les fichiers de notre « datawarehouse »;
• Créer des fichiers de travail temporaire pour nos traitements;
• Mais globalement nous n’avons pas d’utilisateurs risquant de modifier ou supprimé nos données critiques (les raw data) car uniquement accessibles depuis via des scripts et non exposé au « public ».

Pour nos deux premiers points, nous allons multiplier les fichiers « caché ». Si techniquement, cela n’a que très peu d’impact, ce sont nos finances qui vont en pâtir, car un fichier même caché est un fichier facturé !

Association Soft delete et GRS

L’association des fonctionnalités de Soft delete et la géoredondance apporte une sécurité accrue permettant de traiter à la fois les questions de sauvegarde et de résilience. Cependant il faut noter que si les fichiers cachés sont facturés, ils seront aussi répliqués et les coûts peuvent commencer à s’envoler.

C’est le prix de la sécurité, mais il est primordial de prendre cela en considération lors de la création de notre datalake.

Dans le cas de notre plateforme de développement, nous allons réduire les coûts au maximum et ne pas activer les options de sécurité de la donnée :

Encryption et Tags

Pour la partie encryption, c’est encore une fois l’équipe sécurité qui devra nous répondre sinon les options par défaut feront l’affaire.

Concernant les tags, c’est un moyen de donner du sens à nos ressources. Ces tags n’ont aucune utilité technique, mais nous permette simplement d’identifier les usages d’une ressource. Dans certaines entreprises des tags peuvent être mis par équipe pour identifier quelle équipe est propriétaire de la ressource.

Dans notre cas, nous allons simplement identifier « l’application » et l’environnement de nos ressources :

Revue et création

Nous arrivons à la fin de notre configuration. Et nous pouvons voir le résumé de celle-ci avant de lancer sa création :

Si nous sommes ok, nous avons la possibilité de télécharger le template pour l’automatisation ou de créer notre ressource. L’objet de notre article n’étant pas l’automatisation, nous allons maintenant créer notre ressource !

Dans le cloud rien n’est instantané (même si c’est plus rapide que si l’on devait tout faire On-Premises) et donc nous sommes avertis que l’exécution de notre déploiement a démarré :

Le lien nous permettra de suivre l’exécution de celui-ci :

Pour normalement arriver à la situation finale suivante :

Notre datalake est maintenant créée et il devient accessible pour commencer à ajouter des données :

Point de situation

Suivant le choix fait pour la création du datalake avec une séparation logique ou stricte, nous devons avoir la configuration suivante.

Pour une séparation stricte :

Pour une séparation logique :