Architecture

Les tendances des architectures analytiques

Les architectures de données sont en continuelle évolution, il existe aujourd’hui énormément de modèles d’architectures sur le marché embrassant un nombre d’outils et standards toujours plus importants.

Plusieurs patterns sont très connus, nous pouvons citer les suivants :

Lambda : l’architecture Lambda est un modèle de traitement de données qui sépare les flux de données en deux chemins distincts, un pour le traitement en temps réel et un autre pour le traitement par lots, permettant ainsi une analyse des données à la fois rapide et complète.
Kappa : l’architecture Kappa est une alternative à l’architecture Lambda, proposée par Jay Kreps, où toutes les données transitent par un seul chemin en utilisant un système de traitement de flux, ce qui simplifie la gestion et évite la duplication de la logique de calcul.
Warehouse : l’architecture de type Warehouse fait référence à un modèle de traitement et de stockage de données qui permet une analyse efficace et à grande échelle, souvent centralisée dans une technologie de base de données.
Delta : l’architecture Delta est un modèle de traitement de données qui combine les avantages...

Le concept d’architecture autour de Microsoft Fabric

Le déploiement d’une plateforme Fabric nécessite la compréhension de quatre concepts : le tenant, la capacité, le groupe de travail et les items (artefacts). Au niveau le plus haut vous trouvez le tenant, souvent lié à l’annuaire d’entreprise Microsoft Entra (anciennement appelé Azure Active Directory), plus communément présenté comme un annuaire de sécurité contenant les utilisateurs et groupes d’entreprises ainsi qu’un ensemble de fonctionnalité de sécurité. Un tenant peut être lié à une ou plusieurs capacités Fabric, chacune des capacités peut être liée à un ou plusieurs groupes de travail et chacun des groupes de travail peut héberger plusieurs items de tous types (Notebooks, Warehouse, rapports Power BI, flux temps réel, etc.).

La structure de l’entreprise amène souvent plusieurs réflexions sur l’architecture de la plateforme Fabric, celle-ci dépend souvent de l’orientation donnée à la plateforme, des contraintes de sécurité, d’une approche spécifique de sa scalabilité, de sa gouvernance, du cycle de vie des applications et bien plus. Nous avons donc autant de façons de configurer la plateforme que d’approches stratégiques d’entreprise. Il existe donc plusieurs modèles (patterns) de déploiement, très flexibles, pour mapper au mieux l’architecture de la plateforme Fabric aux réflexions de l’entreprise. Par exemple, une organisation peut utiliser la notion de domaine pour groupe les groupes de travail, donc avoir une orientation très décentralisée des projets. Une autre approche peut associer chacun des groupes de travail à une géolocalisation, donc en utilisant plusieurs capacités par plaques géographiques, pour par exemple respecter des notions de gouvernance par zone géographique.

Nous allons maintenant parcourir les différents modèles (patterns) d’architecture possibles pour la plateforme.

1. Les différents modèles d’architectures

a. Monolithique

Ce type de modèle convient pour les organisations qui souhaitent...

Fabric et le Data Mesh

1. Qu’est-ce que le concept d’architecture de Data Mesh ?

Le concept de Data Mesh est une méthodologie qui vise à faire évoluer les architectures, d’un point de vue logique, d’une approche très monolithique centrée sur le Datalake vers une approche distribuée orientée Mesh. Cette méthodologie a été introduite par Zhamak Dehghani (Nextdata) en 2019 dont les principes ont été détaillés en décembre 2020. En résumé, une architecture data mesh doit résoudre trois grands types de problèmes. Le premier porte sur les entités responsables des données, la façon de redonner l’appartenance des données aux métiers, le second est une réflexion sur la qualité des données échangées, souvent en lien avec la propriété de la donnée et enfin le dernier sur la mise à l’échelle d’une telle approche, comment l’entreprise peut industrialiser globalement cette stratégie de responsables de données.

Le Data Mesh repose sur quatre piliers : le produit, le domaine, la plateforme de données et la gouvernance fédérée.

a. Les produits (Data Products)

L’idée est de considérer la donnée comme un produit dans l’entreprise, au même titre que le produit historique de l’entreprise, la donnée devient maintenant un véritable asset d’entreprise...

Fabric et l’approche verticalisée par métier

1. Well architected framework for Industry

Le framework Well-Architected for Industry est un ensemble de principes directeurs conçus pour aider les clients à construire des déploiements Microsoft Cloud pour l’industrie qui adhèrent aux principes d’une solution cloud bien conçue. Il offre une orientation complète pour améliorer la qualité de vos développements dans le cloud industriel.

Il comprend des listes de contrôle ou des outils d’auto-évaluation pour évaluer la conception, le déploiement et l’exploitation des solutions dans le cloud industriel, ainsi que des références de documentation technique et des prérequis techniques à réutiliser dans la mise en œuvre.

Les piliers principaux du framework Well-Architected for Industry sont les suivants :

excellence opérationnelle : assurer une gestion et une automatisation efficaces des opérations pour maintenir la qualité des services ;
sécurité : protéger les données, les systèmes et les actifs tout en permettant l’agilité et l’innovation des entreprises ;
fiabilité : concevoir des systèmes capables de se remettre des défaillances et de répondre aux besoins des utilisateurs ;
efficacité de la performance : fournir les niveaux de performance requis de manière efficace et...

Architectures et comportement en charge de la plateforme

Microsoft Fabric est une plateforme SaaS qui vous permet de réaliser tout type de projet et de créer tout type d’architectures projets. Bien que cette plateforme soit de type SaaS il est nécessaire de bien comprendre comme elle réagit et s’adapte d’un point de vue performance quand elle est soumise à une ou plusieurs charges projets répartis sur une ou plusieurs capacités Fabric.

1. Les questions avant la mise en production

Un utilisateur Fabric va pouvoir manipuler tous les artefacts sur une approche purement SaaS, sans se soucier à aucun moment du moteur sous-jacent faisant tourner la charge projet qu’il est en train de développer et déployer. Cependant, d’un point de vue architecture globale de la plateforme, il est nécessaire de comprendre comment va interagir cette charge de travail avec les autres éléments du ou des groupes de travail qui sont associés à la même capacité Fabric.

Nous avons donc deux grandes compréhensions de la plateforme : l’une en termes d’usage en mode SaaS et l’autre en termes de comportement en mode SaaS mais avec des notions comportementales liées à une approche PaaS.

Fabric est une plateforme globale d’entreprise et le passage d’un mode expérimentation à un mode industrialisation nécessite de comprendre comment v évoluer le comportement de la plateforme quand plusieurs charges de travail vont venir s’exécuter sur les capacités déployées. Il va donc être nécessaire d’avoir une approche assez standardisée qui permettra de recueillir certaines métriques d’entreprises, comme le volume de données, le nombre d’enregistrements manipulés, le nombre de jobs Spark concurrents, etc. afin d’architecturer la plateforme en termes de nombre de capacités à déployer et en termes d’organisation de ces capacités.

Disposer de moteurs de calculs en mode SaaS n’affranchit pas les administrateurs ou personnes de l’IT gouvernant la plateforme de comprendre comment se comporte celle-ci et de fait dérouler un certain nombre de tests en amont pour donner les bonnes hypothèses de dimensionnement des capacités...