Introduction
Lors de mes différents parcours d’apprentissage sur internet et dans les livres, j’ai trouvé différentes catégories d’articles ou tutoriaux :
- Les bases pour comprendre une nouvelle technologie;
- Approfondissement d’un point spécifique;
- Optimisation extrême d’un composant;
- Définition d’un concept;
- Le fameux « Getting started »;
Ayant personnellement suivi de très nombreux « Getting started » je me suis très souvent confronté à un mur à la sortie. J’ai trouvé deux cas de figure différents :
- Les articles qui proposent comment mettre en place une technologie en mode « Etat de l’art » et qui peut s’avérer complexe à comprendre et rend le démarrage long;
- Le strict minimum du type « Hello World » où on a une plateforme qui marche, mais avec laquelle on ne peut/sais rien faire;
Ce qui m’a souvent manqué ce sont des articles qui présentent comment mettre en place un concept avec une technologie. Une sorte d’entre les deux qui va un peux plus loin que le simple « Hello World », mais sans rentrer dans des solutions d’expert. On cherche « juste » à mettre en place la plateforme, le 1er cas d’usage et le minimum vital de suivit de production.
Notre projet est de créer un Data Lakehouse … avec Azure Synapse.
Cet article est le point de départ du projet global qui sera créé le long de plusieurs articles à venir. L’objectif est de créer un Data Lakehouse autour de la solution intégrée de Microsoft : Azure Synapse Analytiques et d’autres solutions Microsoft / Azures s’imbriquant dans notre besoin.
Pour suivre ce projet, rendez-vous sur la page qui centralise les différents articles de celui-ci : Création d’un Datalake avec Azure Synapse Analytique – NiceData
Un Data Lakehouse ?
Notre projet consiste à créer un Data Lakehouse, mais qu’est-ce que c’est ? La définition la plus simple est :
Un Datalake et un Datawarehouse unifié sur une plateforme
Pour rentrer un peu plus dans le détail, je vous propose d’aller faire un tour sur le site de databricks qu’on pourrait considérer comme les « fondateur » de ce principe : Data Lakehouse Platform by Databricks.
La différence entre Datalake et Datawarehouse repose principalement en deux points :
- Dans la dernière zone (Gold) du datalake, il faut mettre à disposition des données structurées comme nous le ferions dans un DWH;
- Un composant technique doit permettre le requêtage des fichiers du datalake en utilisant des outils dédiés à l’analytique (globalement il faut un moyen d’interroger les données en SQL comme si nous avions une BDD relationnelle).
Le projet
Nous allons découvrir grâce à une série d’articles comment mettre en place chaque brique de notre solution complète avec la philosophie suivante:
Avoir rapidement une solution exploitable que l’on améliorera petit à petit
Les différentes étapes de mise en place seront donc les suivantes :
- Création et configuration de la plateforme;
- Développement des premiers cas d’usages;
- Monitoring de notre plateforme;
C’est uniquement ensuite que nous chercherons à ajouter des fonctionnalités et à rendre plus robustes notre plateforme et Datalake.
Voici le schéma global que nous allons mettre en place dans notre projet :
Les briques d’architectures
Notre projet est centré sur la création d’un Datalake qui se positionne donc au cœur de notre architecture et nous nous intéresserons donc aux éléments l’entourant directement.
Les sources
Pour qu’un data Lakehouse prenne forme, il est nécessaire d’avoir des sources de données. Celles-ci peuvent (et c’est généralement le cas) provenir de plusieurs endroits. Il y a deux grandes catégories de provenance des données.
Les données cloud
Dans ce cas, il est souvent nécessaire d’utiliser des connecteurs spécifiques à chaque service ou applications intégrées dans les solutions d’intégration. Dans d’autres cas, il est nécessaire d’utiliser d’interroger des API en direct.
Les données locales (On Prem)
Les données locales sont souvent les premières données que l’on veut intégrer dans notre Lake car ce sont « nos » données qui sont souvent bien connues et la source des repportings existants. Les sources sont souvent de multiples formats entre bases de données relationnelles et divers formats de fichiers (CSV ou Excel principalement).
La « passerelle » vers notre lake
Pour notre projet, nous allons travailler principalement avec des bases de données SQL Serveur et des fichiers « locaux » qu’il va nous falloir déplacer vers le cloud. Nous utiliserons un composant qui ferra cette « passerelle ».
En tant que sources de données, nous utiliserons principalement les samples que Microsoft fournit généreusement via GitHub sur un serveur SQL local.
Le datalake
Intéressons-nous au cœur de notre projet qu’est le Datalake. En soi, le datalake est uniquement une zone de stockage de données (de n’importe quel type). Cependant nous élargissons souvent cette définition pour inclure les technologies qui nous permettent d’interagir avec lui pour intégrer et traiter la donnée du datalake. Les nouvelles technologies BigData puis Cloud ont permis de décorréler le stockage du processing. Aujourd’hui, afin de facilité l »intégration de toutes ces solutions, nous trouvons de plus en plus de solutions « d’analytique intégré » qui permette de facilité l’intégration des outils d’ingestion, transformation, stockage pour des cas d’usages très différents comme les besoins d’un lake ou d’un Datawarehouse traditionnel.
Synapse est la proposition de Microsoft pour travailler sur de « l’analytique illimité » que nous utiliserons dans notre projet.
Si la solution est « intégré », elle est malgré tout composé de plusieurs composants que l’on peut découper à minima en deux :
Le processing
Le processing dans Synapse analytique peux se faire via plusieurs moteurs dont du SQL « classique », Spark ou Data explorer. Ces moteurs de processing s’appuient sur la deuxième couche de notre solution qu’est le stockage.
Le stockage
Le stockage est un des composants centraux d’Azure et dans le cas de notre datalake, nous utiliserons un compte de stockage « classique » avec des options et configurations spécifiques pour en faire un datalake.
La restitution
La restitution est la partie visible de « l’Iceberg » des données de l’entreprise. C’est ce que verront la grande majorité des utilisateurs et est donc une composante cruciale de notre système.
Si la restitution n’est pas propre au datalake, et souvent gérée par des équipes différentes, il reste nécessaire de connecter le datalake aux différents systèmes de restitution de l’entreprise. Cette communication doit se faire à la fois au niveau « modèle de donnée » pour la rendre la donnée exploitable, mais aussi techniquement compatible pour que les connexions se trouvent facilitées pour les utilisateurs.
Dans le monde Microsoft (et pas que), Power BI est la solution privilégiée pour toute restitution de donnée. Nous aurons pour mission de connecter Power BI à notre datalake pour rendre notre solution pleinement exploitable.
Une réponse à “Un Data Lakehouse fonctionnel avec Azure Synapse Analytics”
I want to to thank you for this good read!! I absolutely enjoyed every little bit of it.
I’ve got you saved as a favorite to look at new stuff you post…