Architecture de solution BI dans le Centre d’excellence

Cet article cible les professionnels de l’informatique et les responsables informatiques. Vous découvrirez l’architecture de solution BI dans le CENTRE d’excellence et les différentes technologies utilisées. Les technologies incluent Azure, Power BI et Excel. Ensemble, elles peuvent être exploitées pour fournir une plateforme cloud BI évolutive et orientée par les données.

La conception d’une plateforme BI robuste est un peu comme la création d’un pont ; pont qui connecte les données sources transformées et enrichies aux consommateurs de données. La conception d’une telle structure complexe nécessite un état d’esprit d’ingénierie, bien qu’il puisse s’agir de l’une des architectures informatiques les plus créatives et enrichissantes que vous pourriez concevoir. Dans une grande organisation, une architecture de solution BI peut se composer des éléments suivants :

• Sources de données
• Ingestion des données
• Big Data / Préparation des données
• Entrepôt de données
• Modèles sémantiques BI
• Rapports

La plateforme doit prendre en charge des demandes spécifiques. Plus précisément, il doit s'adapter et performer pour répondre aux attentes des services professionnels et des consommateurs de données. En même temps, il doit être sécurisé dès le départ. Et il doit être suffisamment résilient pour s’adapter au changement, car il est certain que, dans le temps, de nouvelles données et domaines d’objet doivent être mis en ligne.

Frameworks

Chez Microsoft, dès le départ, nous avons adopté une approche semblable aux systèmes en investissant dans le développement de framework. Les infrastructures techniques et de processus métier augmentent la réutilisation de la conception et de la logique et fournissent un résultat cohérent. Ils offrent également une flexibilité en matière d’architecture tirant parti de nombreuses technologies, et simplifient et réduisent la surcharge d’ingénierie par le biais de processus reproductibles.

Nous avons appris que les infrastructures bien conçues augmentent la visibilité de la traçabilité des données, de l’analyse d’impact, de la maintenance de la logique métier, de la gestion de la taxonomie et de la rationalisation de la gouvernance. En outre, le développement est devenu plus rapide et la collaboration entre les grandes équipes est devenue plus réactive et efficace.

Nous allons décrire plusieurs de nos frameworks dans cet article.

Modèles de données

Les modèles de données vous permettent de contrôler la structure et l’accès aux données. Pour les services métier et les consommateurs de données, les modèles de données sont leur interface avec la plateforme BI.

Une plateforme BI peut fournir trois types de modèles différents :

• Modèles d’entreprise
• Modèles sémantiques BI
• Modèles Machine Learning (ML)

Modèles d’entreprise

Les modèles d’entreprise sont construits et gérés par les architectes informatiques. Elles sont parfois appelées modèles dimensionnels ou magasins de données. En règle générale, les données sont stockées dans un format relationnel sous forme de tables de dimension et de faits. Ces tables stockent les données nettoyées et enrichies consolidées à partir de nombreux systèmes et représentent une source faisant autorité pour la création de rapports et l’analytique.

Les modèles d’entreprise fournissent une source de données cohérente et unique pour la création de rapports et la bi. Ils sont créés une fois et partagés en tant que standard d’entreprise. Les stratégies de gouvernance garantissent que les données sont sécurisées, de sorte que l’accès à des jeux de données sensibles, tels que les informations client ou les finances, est limité en fonction des besoins. Ils adoptent des conventions d’affectation de noms garantissant ainsi la cohérence, ce qui renforce la crédibilité des données et de la qualité.

Dans une plateforme cloud BI, les modèles d’entreprise peuvent être déployés sur un pool SQL Synapse dans Azure Synapse. Le pool Synapse SQL devient ensuite la version unique de la vérité sur laquelle l’organisation peut compter pour obtenir des insights rapides et robustes.

Modèles sémantiques BI

Les modèles sémantiques BI représentent une couche sémantique sur les modèles d’entreprise. Ils sont créés et gérés par les développeurs décisionnels et les utilisateurs professionnels. Les développeurs décisionnels créent des modèles sémantiques BI de base qui proviennent de données provenant de modèles d’entreprise. Les utilisateurs professionnels peuvent créer des modèles indépendants à plus petite échelle, ou étendre des modèles sémantiques BI de base avec des sources départementales ou externes. Les modèles sémantiques BI se concentrent généralement sur une seule zone d’objet et sont souvent largement partagés.

Les fonctionnalités métier ne sont pas activées uniquement par les données, mais par des modèles sémantiques BI qui décrivent les concepts, les relations, les règles et les normes. De cette façon, ils représentent des structures intuitives et faciles à comprendre qui définissent des relations de données et encapsulent des règles métier en tant que calculs. Ils peuvent également appliquer des autorisations de données affinées, ce qui garantit que les bonnes personnes ont accès aux données appropriées. Il est important de noter qu’ils accélèrent les performances des requêtes, ce qui offre des analyses interactives extrêmement réactives, même sur des téraoctets de données. Comme les modèles d’entreprise, les modèles sémantiques BI adoptent des conventions d’affectation de noms garantissant la cohérence.

Dans une plateforme cloud BI, les développeurs décisionnels peuvent déployer des modèles sémantiques BI sur Azure Analysis Services, les capacités Power BI Premium ou les capacités de Microsoft Fabric.

Important

Cet article fait référence à Power BI Premium ou à ses abonnements de capacité (SKU P). Actuellement, Microsoft consolide les options d’achat et met hors service les références SKU Power BI Premium par capacité. Les clients nouveaux et existants devraient envisager d’acheter des abonnements de capacité Fabric (SKU F) à la place.

Pour plus d’informations, consultez Importante mise à jour à venir des licences Power BI Premium et FAQ sur Power BI Premium.

Il est recommandé de déployer sur Power BI lorsqu'il est utilisé comme couche de reporting et d'analyse. Ces produits prennent en charge différents modes de stockage, ce qui permet aux tables de modèles de données de mettre en cache leurs données ou d’utiliser DirectQuery, qui est une technologie qui transmet des requêtes à la source de données sous-jacente. DirectQuery est un mode de stockage idéal lorsque les tables de modèle représentent de grands volumes de données ou qu’il est nécessaire de fournir des résultats en quasi-temps réel. Les deux modes de stockage peuvent être combinés : les modèles composites combinent des tables qui utilisent différents modes de stockage dans un modèle unique.

Pour les modèles soumis à de nombreuses requêtes, Azure Load Balancer peut être utilisé pour distribuer uniformément la charge de requête entre les réplicas de modèle. Il vous permet également de mettre à l’échelle vos applications et de créer des modèles sémantiques BI hautement disponibles.

Modèles Machine Learning

Les modèles Machine Learning (ML) sont créés et gérés par les scientifiques des données. Ils sont principalement développés à partir de sources brutes dans le lac de données.

Les modèles ML entraînés peuvent révéler des modèles au sein de vos données. Dans de nombreuses circonstances, ces modèles peuvent être utilisés pour effectuer des prédictions qui peuvent être utilisées pour enrichir les données. Par exemple, le comportement d’achat peut être utilisé pour prédire l’évolution du client ou segmenter les clients. Les résultats de prédiction peuvent être ajoutés aux modèles d’entreprise pour permettre l’analyse par segment client.

Dans une plateforme cloud BI, vous pouvez utiliser Azure Machine Learning pour entraîner, déployer, automatiser, gérer et suivre des modèles ML.

Entrepôt de données

Assis au cœur d’une plateforme BI est l’entrepôt de données, qui héberge vos modèles d’entreprise. Il s'agit d'une source de données autorisées, en tant que système d'enregistrement et hub, au service des modèles d'entreprise pour le reporting, la BI et la science des données.

De nombreux services métier, y compris les applications métier, peuvent s’appuyer sur l’entrepôt de données comme source de connaissances d’entreprise faisant autorité et régie.

Chez Microsoft, notre entrepôt de données est hébergé sur Azure Data Lake Storage Gen2 (ADLS Gen2) et Azure Synapse Analytics.

• ADLS Gen2 fait du Stockage Azure la base de la création de lacs de données d’entreprise sur Azure. Il est conçu pour traiter plusieurs pétaoctets d’informations tout en maintenant des centaines de gigabits de débit. Il offre également une capacité de stockage et des transactions à faible coût. De plus, il prend en charge l’accès compatible Hadoop, ce qui vous permet de gérer et d’accéder aux données comme vous le feriez avec un système de fichiers distribué Hadoop (HDFS). En fait, Azure HDInsight, Azure Databricks et Azure Synapse Analytics peuvent accéder à toutes les données stockées dans ADLS Gen2. Par conséquent, dans une plateforme BI, il est judicieux de stocker des données sources brutes, des données semi-traitées ou intermédiaires et des données prêtes pour la production. Nous l’utilisons pour stocker toutes nos données métier.
• Azure Synapse Analytics est un service d’analytique qui regroupe l’entreposage de données d’entreprise et l’analytique Big Data. Il vous donne la liberté d’interroger des données selon vos besoins, en utilisant soit des ressources à la demande sans serveur, soit des ressources approvisionnées, à grande échelle. Synapse SQL, un composant d’Azure Synapse Analytics, prend en charge l’analytique complète basée sur T-SQL. Il est donc idéal pour héberger des modèles d’entreprise comprenant vos tables de dimension et de faits. Les tables peuvent être chargées efficacement à partir d’ADLS Gen2 à l’aide de requêtes T-SQL Polybase simples. Vous disposez ensuite de la puissance de MPP pour exécuter des analyses hautes performances.

Infrastructure du moteur de règles d’entreprise

Nous avons développé une infrastructure BRE ( Business Rules Engine ) pour cataloguer n’importe quelle logique métier qui peut être implémentée dans la couche entrepôt de données. Un BRE peut signifier beaucoup de choses, mais dans le contexte d’un entrepôt de données, il est utile de créer des colonnes calculées dans des tables relationnelles. Ces colonnes calculées sont généralement représentées sous forme de calculs mathématiques ou d’expressions à l’aide d’instructions conditionnelles.

L'intention est de séparer la logique métier du code principal d'informatique décisionnelle. Traditionnellement, les règles métier sont codées en dur dans des procédures stockées SQL, ce qui entraîne souvent beaucoup d’efforts pour les maintenir lorsque les besoins de l’entreprise changent. Dans un bre, les règles d’entreprise sont définies une fois et utilisées plusieurs fois lorsqu’elles sont appliquées à différentes entités d’entrepôt de données. Si la logique de calcul doit changer, elle ne doit être mise à jour qu’à un seul endroit et pas dans de nombreuses procédures stockées. Il existe également un avantage latéral : un framework BRE favorise la transparence et la visibilité de la logique métier implémentée, qui peut être exposée via un ensemble de rapports qui créent une documentation auto-mise à jour.

Sources de données

Un entrepôt de données peut consolider des données à partir de n’importe quelle source de données. Il est principalement construit sur des sources de données métier, qui sont généralement des bases de données relationnelles stockant des données spécifiques à l’objet pour les ventes, le marketing, la finance, etc. Ces bases de données peuvent être hébergées dans le cloud ou elles peuvent résider localement. D’autres sources de données peuvent être basées sur des fichiers, en particulier des journaux web ou des données IOT provenant d’appareils. De plus, les données peuvent être sources à partir de fournisseurs SaaS (Software-as-a-Service).

Chez Microsoft, certains de nos systèmes internes génèrent des données opérationnelles directes vers ADLS Gen2 à l’aide de formats de fichiers bruts. En plus de notre lac de données, d’autres systèmes sources comprennent des applications métier relationnelles, des classeurs Excel, d’autres sources basées sur des fichiers et la gestion des données de référence (GPM) et des référentiels de données personnalisés. Les référentiels MDM nous permettent de gérer nos données de référence pour garantir des versions faisant autorité, standardisées et validées des données.

Ingestion des données

Sur une base périodique, et selon les rythmes de l’entreprise, les données sont ingérées à partir de systèmes sources et chargées dans l’entrepôt de données. Il peut s’agir d’une fois par jour ou à intervalles plus fréquents. L’ingestion des données concerne l’extraction, la transformation et le chargement des données. Ou, peut-être l’autre façon : extraction, chargement, puis transformation de données. La différence réside dans l'endroit où la transformation a lieu. Les transformations sont appliquées au nettoyage, à la conformité, à l’intégration et à la normalisation des données. Pour plus d’informations, consultez Extraire, transformer et charger (ETL).

En fin de compte, l’objectif est de charger les données appropriées dans votre modèle d’entreprise aussi rapidement et efficacement que possible.

Chez Microsoft, nous utilisons Azure Data Factory (ADF). Les services sont utilisés pour planifier et orchestrer des validations de données, des transformations et des charges en bloc à partir de systèmes sources externes dans notre lac de données. Il est géré par des frameworks personnalisés pour traiter les données en parallèle et à grande échelle. En outre, la journalisation complète est entreprise pour prendre en charge la résolution des problèmes, la surveillance des performances et pour déclencher des notifications d’alerte lorsque des conditions spécifiques sont remplies.

Entre-temps, Azure Databricks , une plateforme d’analytique basée sur Apache Spark optimisée pour la plateforme de services cloud Azure, effectue des transformations spécifiquement pour la science des données. Il génère et exécute également des modèles ML à l’aide de notebooks Python. Les scores de ces modèles ML sont chargés dans l’entrepôt de données pour intégrer des prédictions à des applications d’entreprise et des rapports. Étant donné qu’Azure Databricks accède directement aux fichiers data lake, il élimine ou réduit la nécessité de copier ou d’acquérir des données.

Cadre d’ingestion

Nous avons développé une infrastructure d’ingestion en tant qu’ensemble de tables et procédures de configuration. Il prend en charge une approche pilotée par les données pour acquérir de grands volumes de données à grande vitesse et avec un code minimal. En bref, cette infrastructure simplifie le processus d’acquisition de données pour charger l’entrepôt de données.

L’infrastructure dépend des tables de configuration qui stockent des informations relatives à la source de données et à la destination des données, telles que le type de source, le serveur, la base de données, le schéma et les détails liés aux tables. Cette approche de conception signifie que nous n’avons pas besoin de développer des pipelines ADF spécifiques ou des packages SQL Server Integration Services (SSIS). Au lieu de cela, les procédures sont écrites dans le langage de notre choix pour créer des pipelines ADF générés dynamiquement et exécutés au moment de l’exécution. Ainsi, l’acquisition de données devient un exercice de configuration facilement opérationnel. Traditionnellement, il nécessite des ressources de développement étendues pour créer des packages ADF ou SSIS codés en dur.

L’infrastructure d’ingestion a également été conçue pour simplifier le processus de gestion des modifications de schéma source en amont. Il est facile de mettre à jour les données de configuration , manuellement ou automatiquement, lorsque des modifications de schéma sont détectées pour acquérir des attributs nouvellement ajoutés dans le système source.

Infrastructure d’orchestration

Nous avons développé un framework d’orchestration pour opérationnaliser et orchestrer nos pipelines de données. L’infrastructure d’orchestration utilise une conception pilotée par les données qui dépend d’un ensemble de tables de configuration. Ces tables stockent les métadonnées décrivant les dépendances de pipeline et comment mapper les données sources aux structures de données cibles. L’investissement dans le développement de ce cadre adaptatif a depuis payé pour lui-même ; il n’est plus nécessaire de coder en dur chaque déplacement de données.

Stockage de données

Un lac de données peut stocker de grands volumes de données brutes pour une utilisation ultérieure, ainsi que des transformations de données intermédiaires.

Chez Microsoft, nous utilisons ADLS Gen2 comme source unique de vérité. Il stocke les données brutes en même temps que les données intermédiaires et les données prêtes pour la production. Il fournit une solution de lac de données hautement évolutive et économique pour l’analytique big data. En combinant la puissance d’un système de fichiers hautes performances avec une capacité d'extension massive, il est optimisé pour les charges de travail d’analyse des données, accélérant le temps d'obtention des résultats.

ADLS Gen2 offre le meilleur de deux mondes : il s’agit du stockage BLOB et d’un espace de noms de système de fichiers hautes performances, que nous configurons avec des autorisations d’accès affinées.

Les données affinées sont ensuite stockées dans une base de données relationnelle pour fournir un magasin de données hautes performances et hautement évolutif pour les modèles d’entreprise, avec sécurité, gouvernance et facilité de gestion. Les marts de données spécifiques à l'objet sont stockés dans Azure Synapse Analytics et chargés par Azure Databricks ou des requêtes T-SQL de Polybase.

Consommation de données

Au niveau de la couche de création de rapports, les services métier consomment des données d’entreprise provenant de l’entrepôt de données. Ils accèdent également aux données directement dans le lac de données pour les tâches ad hoc d’analyse ou de science des données.

Les autorisations affinées sont appliquées à toutes les couches : dans le lac de données, les modèles d’entreprise et les modèles sémantiques BI. Les autorisations garantissent que les consommateurs de données ne peuvent voir que les données auxquelles ils ont accès.

Chez Microsoft, nous utilisons des rapports et des tableaux de bord Power BI et des rapports paginés Power BI. Certaines analyses de rapports et ad hoc sont effectuées dans Excel, en particulier pour les rapports financiers.

Nous publions des dictionnaires de données, qui fournissent des informations de référence sur nos modèles de données. Ils sont mis à la disposition de nos utilisateurs afin qu’ils puissent découvrir des informations sur notre plateforme de Business Intelligence. Les dictionnaires documentent les conceptions de modèles, fournissant des descriptions sur les entités, les formats, la structure, la traçabilité des données, les relations et les calculs. Nous utilisons Azure Data Catalog pour rendre nos sources de données facilement détectables et compréhensibles.

En règle générale, les modèles de consommation de données diffèrent en fonction du rôle :

• Les analystes de données se connectent directement aux modèles sémantiques décisionnels principaux. Lorsque les modèles sémantiques bi principaux contiennent toutes les données et la logique dont ils ont besoin, ils utilisent des connexions actives pour créer des rapports et des tableaux de bord Power BI. Lorsqu’ils doivent étendre les modèles avec des données de service, ils créent des modèles composites Power BI. S’il est nécessaire de créer des rapports de style feuille de calcul, ils utilisent Excel pour produire des rapports basés sur des modèles sémantiques décisionnels centraux ou des modèles sémantiques décisionnels de département.
• Les développeurs décisionnels et les auteurs de rapports opérationnels se connectent directement aux modèles d’entreprise. Ils utilisent Power BI Desktop pour créer des rapports analytiques de connexion dynamique. Ils peuvent également créer des rapports décisionnels de type opérationnel sous forme de rapports paginés Power BI, en écrivant des requêtes SQL natives pour accéder aux données à partir des modèles d'entreprise d'Azure Synapse Analytics à l’aide de T-SQL, ou des modèles sémantiques Power BI à l’aide de DAX ou de MDX.
• Les scientifiques des données se connectent directement aux données dans le lac de données. Ils utilisent des notebooks Azure Databricks et Python pour développer des modèles ML, souvent expérimentaux et nécessitant des compétences spécialisées pour une utilisation en production.

Contenu connexe

Pour plus d’informations sur cet article, consultez les ressources suivantes :

• Feuille de route d’adoption du tissu : Centre d’excellence
• Enterprise BI dans Azure avec Azure Synapse Analytics
• Vous avez des questions ? Essayez de poser votre question à la communauté Fabric
• Vous avez des suggestions ? Apporter des idées pour améliorer Fabric

Services professionnels

Les partenaires Power BI certifiés sont disponibles pour aider votre organisation à réussir lors de la configuration d’un centre d’excellence. Ils peuvent vous fournir une formation économique ou un audit de vos données. Pour trouver un partenaire Power BI, visitez le portail partenaires Microsoft Power BI.

Vous pouvez également collaborer avec des partenaires de conseil expérimentés. Ils peuvent vous aider à évaluer, évaluer ou implémenter Power BI.