Aventures dans Fabric vol. 2 : Tant de Maisons

Dans notre premier article de blog, Aventures dans Fabric Vol. Un : L’avenir de l’analytique, nous avons exploré pourquoi Microsoft Fabric transforme le paysage de l’analyse de données. Nous avons souligné sa connectivité transparente, ses options de stockage flexibles, sa boîte à outils diversifiée et l’engagement de Microsoft envers l’innovation continue. Nous avons également présenté Fabric Manager, l’accélérateur d’Ateko pour Microsoft Fabric, conçu pour simplifier la mise en œuvre et améliorer la livraison des projets.

Dans cet épisode, Aventures dans Microsoft Fabric Vol. Deux, nous approfondissons les capacités de stockage de Fabric, en examinant les différentes options, leurs avantages uniques et les meilleures pratiques pour optimiser votre stratégie de données.

Lakehouse, Warehouse, Eventhouse : Comprendre le stockage dans Fabric

L’un des principaux avantages de Microsoft Fabric est sa capacité à lire les données dans votre langage de programmation préféré, quel que soit le format de stockage. Contrairement à d’autres plateformes, Fabric ne nécessite pas de moteur de calcul ou de pool dédié – connectez-vous simplement au stockage et commencez à interroger.

Toutes les données dans Fabric sont stockées au format Delta, une norme open-source devenue la référence de l’industrie pour le stockage évolutif et haute performance. Conçu dans un souci d’accessibilité, Fabric prend en charge plusieurs langages, permet des connexions à OneLake et assure la compatibilité avec les formats Unity et Iceberg via des raccourcis ou la mise en miroir.

Choisir la bonne option de stockage

Dans le passé, lorsque les bases de données étaient la solution de stockage principale, les développeurs devaient rarement se soucier de l’emplacement des données – SQL Server s’en chargeait en coulisses. À mesure que les lacs de données gagnaient en popularité, le stockage est passé à une approche basée sur les fichiers, obligeant les développeurs à créer des conventions structurées de noms de dossiers et de fichiers pour maintenir l’organisation.

Microsoft Fabric comble le fossé en offrant des options de stockage flexibles qui combinent les forces des bases de données traditionnelles avec la polyvalence des lacs de données. Mais avec plusieurs choix, comment savoir lequel convient à votre cas d’utilisation ?

Voici une répartition des types de stockage principaux (ou maisons) de Fabric :

Type de stockage	Objectif principal	Approche de développement
Lakehouse	Grandes données, polyvalent, le plus flexible. Fichiers et tables	Notebooks, PySpark ou Spark SQL
Warehouse	Orienté données structurées	Scripts SQL et procédures stockées
Eventhouse	Temps réel, séries chronologiques et géospatiales	Eventstream et KQL Queryset
Modèle sémantique	Couche finale pour l’interactivité métier pour les rapports et ad hoc	Power BI
Base de données SQL	Base de données opérationnelle ou applicative	Scripts SQL et procédures stockées

Alerte nouvelle fonctionnalité : Microsoft a récemment publié un connecteur Spark, permettant l’écriture transparente depuis les notebooks vers un Warehouse. Attendez-vous à une évolution continue des capacités de stockage.

Quelle Maison est faite pour vous ?

Choisir le bon stockage dépend de quatre facteurs clés :

• Type de solution
• Type de données
• Outils préférés et compétences de l’équipe
• Fonctionnalités requises

Cas d’utilisation analytique

Concentrons-nous sur un cas d’utilisation analytique qui se rafraîchit toutes les heures ou tous les jours. Avec ce cas d’utilisation, deux couches de stockage sont nécessaires, et par conséquent, deux décisions de stockage doivent être prises :

• Couche d’ingestion – Parfois appelée couches bronze et argent, cette couche est une zone de staging pour tous les types de données et est similaire au staging dans les entrepôts de données traditionnels.
• Couche Or – C’est la couche finale, prête à la consommation et optimisée pour le reporting et l’analyse ; elle fonctionne comme un Data Mart ou un Data Warehouse.

Couche d’ingestion

Pour notre couche d’ingestion, nous avons besoin de la flexibilité de stocker tout type de données. Le Lakehouse est le choix évident car il prend en charge tous les formats de données – structurées (tables), semi-structurées (JSON) et non structurées (images). Si une partie des données n’est pas au format table, le Lakehouse offre un endroit pour les stocker sous forme de fichiers.

Vous pourriez penser : « Mais attendez ! Toutes mes sources sont des bases de données, alors pourquoi aurais-je besoin d’un Lakehouse ? » Bien que cela puisse être vrai aujourd’hui, de plus en plus de sources sont semi-structurées, et l’utilisation d’un seul Warehouse pourrait limiter votre capacité à gérer ces types de données à l’avenir. Choisir un Lakehouse pérennise également votre solution en vous donnant une couche de stockage capable de prendre en charge les structures de données basées sur un schéma et celles sans schéma.

Couche Or

Pour la couche Or, il y a plus à considérer, notamment en ce qui concerne les ensembles d’outils et les langages préférés.

Les outils d’écriture diffèrent selon les types de stockage :

Bien que les données puissent être lues avec n’importe quel outil, l’écriture se fait généralement avec un seul : les Notebooks pour Lakehouse et les Scripts SQL pour Warehouse.

L’expertise de l’équipe compte :

Si l’équipe est à l’aise avec SQL et les procédures stockées, le Warehouse peut être le meilleur choix. Si l’équipe travaille principalement avec Spark, alors le Lakehouse est la voie à suivre. Les Notebooks peuvent écrire en Spark SQL vers un Lakehouse. Bien que la syntaxe soit légèrement différente, elle est très transférable.

Considérations de sécurité :

Le Lakehouse et le Warehouse offrent tous deux une sécurité au niveau objet/colonne/ligne. Cependant, le Lakehouse applique un modèle de sécurité tout ou rien lorsqu’il est accédé via un Notebook. La sécurité granulaire n’est disponible que via le Point de terminaison SQL (SQL Endpoint).

Fonctionnalités et limitations :

Il est préférable de consulter la documentation officielle pour l’ensemble des fonctionnalités le plus récent. Par exemple, au moment du développement, le Warehouse ne prenait pas en charge la fonction merge, ce qui nous a conduits à utiliser le Lakehouse. De plus, le Warehouse prenait en charge le masquage dynamique. Si cela avait été une exigence, le Warehouse aurait été le choix privilégié.

Qu’en est-il des autres stockages ?

L’Eventhouse est conçu pour les données en temps réel et les séries chronologiques, offrant une solution de stockage très performante pour les messages basés sur les événements. Il peut fonctionner comme une solution autonome non analytique ou servir de couche de stockage supplémentaire pour gérer les messages en temps réel pendant que la solution analytique principale effectue les transformations lourdes.

La base de données SQL (SQL Database) dans Fabric est une option de stockage récemment publiée, toujours en préversion, principalement destinée aux cas d’utilisation opérationnels et applicatifs. Cependant, nous y voyons un potentiel pour être utilisée comme DataMart dans certains scénarios. Actuellement, la base de données SQL a une limite de 4 To. Nous sommes particulièrement intéressés par l’évolution future du stockage Warehouse et SQL Database et par la manière dont ils pourraient se compléter.

Raccourcis : Éliminer la redondance

Il y a quelques années, partager des fichiers signifiait les envoyer par e-mail, ce qui entraînait plusieurs copies enregistrées, différentes versions et une confusion quant à la version correcte. Maintenant, au lieu de dupliquer des fichiers, nous partageons un lien vers une source unique – ce même principe s’applique aux raccourcis de données dans Fabric. Les raccourcis sont des liens pour les données.

Fabric a été conçu dans l’idée que les données ne devraient exister qu’en une seule copie, dans le format dont vous avez besoin. Cependant, dans les grands lacs de données, nous constatons souvent plusieurs copies des mêmes données dispersées sur différents projets. Par exemple, sur un projet de machine learning, les data scientists copient les données dans leur sandbox. Un développeur citoyen souhaite ajouter des données supplémentaires, créant ainsi une autre copie.

Avoir plusieurs copies des mêmes données augmente non seulement la complexité et les coûts de stockage, mais aussi le risque d’aperçus incohérents entre les différentes équipes. Les raccourcis résolvent ce problème en permettant un accès direct aux données existantes sans duplication, garantissant que tout le monde travaille à partir d’une source unique et fiable.

Les raccourcis sont disponibles sur tous les types de stockage Fabric et s’étendent pour prendre en charge davantage de solutions de stockage externes. Les organisations peuvent ingérer les données une seule fois, puis les partager de manière transparente avec les créateurs et les consommateurs de données. De plus, les raccourcis s’intègrent aux principaux magasins de données externes, tels qu’Azure Data Lake Storage (ADLS), ce qui signifie qu’il n’est pas nécessaire de copier les données dans Fabric – il suffit de les lier et de commencer l’analyse.

Mise en miroir : Synchronisation des données en temps réel

Une autre façon de récupérer et de stocker des données dans Fabric est la mise en miroir. La mise en miroir offre une réplication à faible latence utilisant la Capture de Données Modifiées (CDC), copiant toutes les données et transactions dans des tables Delta dans OneLake. Contrairement aux raccourcis, la mise en miroir permet une réplication complète de la base de données source au sein de Fabric. La liste des systèmes sources pris en charge continue de s’étendre, ce qui en fait une option précieuse pour maintenir un jeu de données à jour. Généralement, nous traitons les données mises en miroir comme nous le ferions pour un système source, en les intégrant dans le processus ETL pour une transformation et une analyse plus poussées.

Bien que la mise en miroir aide à intégrer les données dans Fabric efficacement, l’étape suivante consiste à décider où stocker et traiter ces données. Les différentes options de stockage servent des objectifs différents, et choisir la bonne est essentiel pour la scalabilité, la performance et la facilité d’utilisation.

Quelle Maison pour le Fabric Manager d’Ateko ?

Fabric Manager est l’accélérateur d’Ateko conçu pour rationaliser la mise en œuvre et améliorer la livraison de projets au sein de Microsoft Fabric. Il fournit un cadre structuré pour gérer l’ingestion, la transformation et la gouvernance des données tout en maintenant la flexibilité pour différents besoins analytiques et de reporting. Notre objectif chez Ateko était de construire une solution capable de s’intégrer de manière transparente avec diverses sources de données, cas d’utilisation métier et capacités évolutives de Fabric.

Pour y parvenir, nous avons dû prendre une décision stratégique concernant le stockage basée sur trois facteurs clés :

• Les données utilisées dans l’analytique
• Les paramètres pilotés par les données utilisés pour ingérer et exécuter la plateforme
• Enregistrement des mouvements de données

Les données utilisées dans l’analytique

L’une des premières et des plus importantes décisions que nous avons prises lors de la création de Fabric Manager a été de savoir où stocker les données analytiques elles-mêmes. Comme nous voulions un accélérateur capable de prendre en charge plusieurs cas d’utilisation, nous avons choisi le Lakehouse comme fondation. Pourquoi ?

• Nous travaillons souvent avec des données d’API au format JSON, qui ne s’intègrent pas bien dans un entrepôt de données traditionnel.
• Nous sommes investis dans les opportunités pilotées par l’IA, et avoir nos données structurées pour les futures intégrations IA était une priorité.
• Le Lakehouse offre de la flexibilité, prenant en charge les données structurées et semi-structurées tout en maintenant de hautes performances.

Pour organiser nos données efficacement, nous avons suivi une Architecture Medallion, une approche par couches qui garantit que les données sont structurées, propres et optimisées pour l’utilisation métier :

• Couche Bronze – Données brutes, non modifiées, stockées dans des fichiers, aussi près que possible de la source.
• Couche Argent – Une version dédupliquée des données, avec des schémas appliqués et les changements historiques suivis.
• Couche Or – Un modèle dimensionnel affiné, transformant les données dans un format convivial pour les entreprises.
• Modèle sémantique – La version finale, optimisée pour le reporting et l’analyse dans Power BI, permettant des interactions faciles par glisser-déposer.

Les paramètres pilotés par les données utilisés pour ingérer et exécuter la plateforme

Chez Ateko, nous nous appuyons souvent sur des bases de données structurées pour gérer les configurations pilotées par les données qui contrôlent l’ingestion et l’exécution de la plateforme. Nous avons estimé qu’un Warehouse était le mieux adapté à cette tâche car il est de nature tabulaire, et nous mettons souvent à jour les valeurs. Au moment du développement, la base de données SQL dans Fabric n’était pas encore disponible, mais compte tenu de son orientation opérationnelle, c’est quelque chose vers quoi nous pourrions migrer à l’avenir à mesure que la plateforme évolue.

Enregistrement des mouvements de données

La surveillance et le dépannage des pipelines de données sont essentiels pour assurer le bon fonctionnement. Nous avions besoin d’une solution centralisée pour capturer l’activité du pipeline en temps réel et stocker les journaux historiques pour l’analyse des tendances. Pour y parvenir, nous avons construit un système de journalisation centralisé en utilisant un Eventhouse central.

• Suivi des données en direct – Fournit des aperçus en temps réel de ce qui est actuellement en cours d’exécution.
• Analyse des données historiques – Nous permet de détecter des schémas et de dépanner les échecs plus efficacement.

En consolidant tous les journaux et messages d’erreur en un seul endroit, nous avons créé un système de surveillance fiable et évolutif qui garantit la transparence et l’efficacité de nos flux de données.

Leçons apprises pour le Fabric Manager d’Ateko

Nos choix de stockage se sont bien alignés avec l’objectif visé, mais l’adaptation à la nouvelle architecture de Fabric a présenté quelques obstacles inattendus. Comme notre équipe était familière avec d’autres solutions de stockage, nous avons rencontré plusieurs défis et limitations en cours de route :

• Limitations d’écriture entre les types de stockage : Une frustration courante a été de réaliser que chaque type de stockage dispose d’un outil d’écriture désigné. Les développeurs s’attendaient souvent à plus de flexibilité mais ont dû s’adapter. Bien que cela ait du sens d’un point de vue technique, il a fallu du temps pour s’adapter.
• Fonctionnalités clés manquantes dans Warehouse : Il y a certaines choses sur lesquelles on finit par compter. Dans Warehouse, le manque de colonnes d’identité (Identity Columns) et d’instructions MERGE nous a beaucoup dérangés.
• Délai de rafraîchissement du Point de terminaison SQL : Lors de la lecture d’un Lakehouse, les données sont accessibles via le Point de terminaison SQL, qui est parfois mis en cache et désynchronisé avec les dernières mises à jour. Ce décalage était particulièrement frustrant car il était intermittent et imprévisible. Bien qu’il existe une solution de contournement utilisant un exemple de code pour déclencher manuellement un rafraîchissement, on a l’impression que cela devrait se produire automatiquement.
• Support limité du schéma pour Lakehouse : Le support des schémas dans Lakehouse est encore en préversion, et ses limitations – en particulier concernant le partage et la restriction d’accès via le Point de terminaison SQL – étaient suffisamment importantes pour que nous choisissions de ne pas l’utiliser pour l’instant.

Et ensuite ? Fonctionnalités que nous sommes impatients d’explorer

L’orientation innovation d’Ateko s’est déplacée vers l’IA générative, et la sortie de la base de données SQL (SQL Database) dans Fabric est particulièrement excitante. Les types de données vectorielles sont désormais disponibles directement dans SQL, ce qui est précisément le type de données nécessaire pour la plupart des personnalisations d’IA. Avoir un stockage vectoriel intégré directement dans SQL signifie que nous pouvons stocker et traiter des données liées à l’IA sans avoir besoin de les déplacer vers une base de données spécialisée.

Ateko fournit des services gérés qui permettent aux clients d’adopter les solutions Fabric de Microsoft en plus d’autres services Azure natifs.

Alors que Fabric continue d’évoluer, nous sommes impatients d’explorer les nouvelles améliorations. Restez à l’écoute pour notre prochaine aventure Fabric !