Guide

Les données sont organisées dans une disposition tabulaire fixe avec un schéma prédéfini (lignes et colonnes), comme un catalogue de produits ou des registres financiers.

→Représenter comme des données structurées.

Pourquoi: Les données structurées sont conformes à un schéma rigide, idéal pour les bases de données relationnelles (OLTP). À l'inverse des données semi-structurées (JSON/XML) et non structurées (images/audio).

Les données ont une certaine structure organisationnelle (balises, clés) mais n'ont pas de schéma rigide. Chaque enregistrement peut avoir des champs différents, comme les documents JSON de capteurs IoT.

→Représenter comme des données semi-structurées (par exemple, JSON, XML).

Pourquoi: JSON et XML sont auto-descriptifs, offrant une flexibilité par rapport aux schémas fixes des données structurées. Idéal pour les bases de données NoSQL et les lacs de données.

Stocker des fichiers volumineux sans schéma prédéfini ni structure organisationnelle, comme des IRM, des vidéos ou des enregistrements audio.

→Représenter comme des données non structurées.

Pourquoi: Ce type de données ne peut pas être stocké dans des bases de données traditionnelles ligne/colonne. Nécessite un stockage d'objets comme Azure Blob Storage.

Différencier les charges de travail pour les opérations quotidiennes de l'analyse historique.

→Utiliser OLTP (Online Transaction Processing) pour les transactions à volume élevé et faible latence (par exemple, commandes de commerce électronique). Utiliser OLAP (Online Analytical Processing) pour les requêtes complexes sur de grands ensembles de données historiques (par exemple, analyse des tendances de vente).

Pourquoi: Les systèmes OLTP sont normalisés et optimisés pour les écritures rapides. Les systèmes OLAP sont dénormalisés (schéma en étoile) et optimisés pour les lectures et les agrégations rapides.

Choisir un modèle d'intégration de données pour un entrepôt de données.

→Utiliser ETL (Extract, Transform, Load) lorsque la logique de transformation est complexe et effectuée sur un serveur de staging avant le chargement. Utiliser ELT (Extract, Load, Transform) pour charger les données brutes dans un système cible puissant (par exemple, Synapse Analytics) et exploiter sa puissance de calcul pour les transformations.

Pourquoi: ELT est le modèle cloud moderne, exploitant la puissance de calcul évolutive dans le magasin de données cible (entrepôt de données/lakehouse) et simplifiant l'ingestion.

Attribuer la responsabilité des tâches de la plateforme de données.

→Ingénieur de données : Construit et maintient les pipelines ETL/ELT. Administrateur de base de données : Gère la sécurité, les performances et la disponibilité des bases de données. Analyste de données : Crée des rapports et des visualisations (par exemple, Power BI) pour les analyses métier.

Pourquoi: Des rôles clairement définis sont essentiels. La distinction clé est construire (Ingénieur), gérer (DBA) et analyser (Analyste).

Traitement de grands volumes de données avec différentes exigences de latence.

→Utiliser le traitement par lots (Batch Processing) pour les données au repos, traitées à intervalles réguliers (par exemple, rapports nocturnes). Utiliser le traitement de flux (Stream Processing) pour les données en mouvement, traitées en continu dès leur arrivée (par exemple, détection de fraude en temps réel).

Pourquoi: Le compromis clé est la latence par rapport au coût/débit. Le traitement de flux offre une faible latence mais nécessite des ressources toujours actives. Le traitement par lots a une latence élevée mais est rentable pour de grands volumes.

Concevoir un schéma pour un entrepôt de données afin de prendre en charge les requêtes analytiques.

→Utiliser un schéma en étoile (Star Schema) composé d'une table de faits centrale (contenant des mesures numériques) connectée à plusieurs tables de dimensions (contenant des attributs descriptifs).

Pourquoi: Cette structure dénormalisée minimise les jointures pour les requêtes analytiques, améliorant les performances par rapport à un schéma normalisé (OLTP). Il est plus simple et plus rapide pour la plupart des outils de BI qu'un schéma en flocon.

Choisir un référentiel central pour l'analyse.

→Utiliser un lac de données (Data Lake) (par exemple, Azure Data Lake Storage) pour stocker de grandes quantités de données brutes dans leur format natif (schéma-à-la-lecture). Utiliser un entrepôt de données (Data Warehouse) (par exemple, Synapse Dedicated SQL Pool) pour stocker des données structurées et traitées pour la BI et les rapports (schéma-à-l'écriture).

Pourquoi: Les lacs de données offrent de la flexibilité pour la science des données et l'exploration des données brutes. Les entrepôts de données offrent des performances élevées et une structure pour l'intelligence économique.

Besoin d'une base de données relationnelle entièrement gérée pour une nouvelle application cloud-native sans gérer l'infrastructure sous-jacente.

→Utiliser Azure SQL Database.

Pourquoi: C'est une offre PaaS avec des correctifs automatiques, des sauvegardes et une haute disponibilité. Idéal pour les charges de travail SQL standard où l'accès au niveau du système d'exploitation n'est pas nécessaire.

Référence↗

Migration "lift-and-shift" d'une charge de travail SQL Server sur site qui utilise des fonctionnalités au niveau de l'instance comme SQL Server Agent, les requêtes inter-bases de données ou Service Broker.

→Utiliser Azure SQL Managed Instance.

Pourquoi: SQL MI offre une compatibilité quasi-totale avec le moteur SQL Server sur site, minimisant les changements de migration. Azure SQL Database ne prend pas en charge ces fonctionnalités au niveau de l'instance.

Référence↗

Migration d'une base de données SQL Server vers Azure nécessitant un contrôle total sur le système d'exploitation, des versions spécifiques de SQL Server ou des fonctionnalités avec un support PaaS limité (par exemple, certains assemblys CLR).

→Utiliser SQL Server sur les machines virtuelles Azure.

Pourquoi: Cette option IaaS offre une compatibilité et un contrôle maximum, mais oblige l'utilisateur à gérer le système d'exploitation, les correctifs et les sauvegardes, contrairement aux offres PaaS.

Une application a des modèles d'utilisation intermittents et imprévisibles avec de longues périodes d'inactivité. Besoin de minimiser les coûts pendant l'inactivité.

→Utiliser le niveau de calcul Serverless pour Azure SQL Database.

Pourquoi: Serverless met automatiquement à l'échelle le calcul en fonction de la demande et peut mettre la base de données en pause automatique, facturant uniquement le stockage pendant les périodes d'inactivité. Idéal pour les charges de travail variables.

Référence↗

Héberger plusieurs petites bases de données pour différents locataires (SaaS) avec des charges de travail variables. Besoin de partager les ressources pour réduire les coûts.

→Utiliser les pools élastiques Azure SQL Database.

Pourquoi: Les pools élastiques permettent à plusieurs bases de données de partager un ensemble de ressources pré-allouées (DTU ou vCores), offrant une solution rentable pour les applications multi-locataires.

Une base de données est censée dépasser 4 To (jusqu'à 100 To) et nécessite une mise à l'échelle rapide ainsi que des sauvegardes et restaurations quasi instantanées, quelle que soit sa taille.

→Utiliser le niveau de service Hyperscale pour Azure SQL Database.

Pourquoi: Hyperscale utilise une architecture distribuée unique pour les très grandes bases de données (VLDB), dépassant les limites de taille des autres niveaux et offrant des opérations de base de données à temps constant.

Déploiement d'une base de données PostgreSQL gérée pour une application de microservices, nécessitant une haute disponibilité redondante interzone et une mise à l'échelle indépendante du calcul et du stockage.

→Utiliser Azure Database pour PostgreSQL - Flexible Server.

Pourquoi: Flexible Server est l'offre recommandée, offrant une haute disponibilité redondante interzone, des fenêtres de maintenance personnalisées et une meilleure optimisation des coûts par rapport à l'ancien modèle Single Server.

Protéger les données sensibles (par exemple, numéros de carte de crédit) afin qu'elles restent chiffrées au repos, en transit ET pendant leur utilisation (en mémoire) sur le serveur. Même les DBA ne devraient pas voir les données en clair.

→Utiliser Always Encrypted.

Pourquoi: Always Encrypted est une technologie de chiffrement côté client où les clés sont détenues par le client, garantissant que les données ne sont jamais déchiffrées sur le serveur. TDE ne protège les données qu'au repos.

Besoin de masquer des données sensibles aux utilisateurs non privilégiés dans les résultats de requête (par exemple, n'afficher que les quatre derniers chiffres d'un numéro de sécurité sociale) sans modifier les données stockées.

→Utiliser le masquage dynamique des données (Dynamic Data Masking).

Pourquoi: DDM applique des règles de masquage au moment de la requête en fonction des autorisations de l'utilisateur. C'est une fonctionnalité de sécurité pour limiter l'exposition des données, pas une fonctionnalité de chiffrement.

Assurer la continuité des activités pour un groupe de bases de données Azure SQL en activant le basculement automatique vers une région secondaire en cas de panne régionale.

→Configurer un groupe de basculement automatique.

Pourquoi: Les groupes de basculement automatique fournissent un point de terminaison d'écoute unifié qui redirige automatiquement le trafic après le basculement, simplifiant la conception de l'application pour la reprise après sinistre. Il offre un RPO/RTO inférieur à la restauration à partir de sauvegardes géo-redondantes.

Besoin de stocker d'énormes quantités de données non structurées, telles que des fichiers vidéo, des images, des sauvegardes et des journaux, de manière rentable.

→Utiliser Azure Blob Storage.

Pourquoi: Blob Storage est un service de stockage d'objets optimisé pour le stockage de pétaoctets de données non structurées. Il ne convient pas aux charges de travail de requêtes structurées.

Référence↗

Optimiser les coûts de stockage pour les données avec des modèles d'accès variables.

→Utiliser les niveaux d'accès d'Azure Blob Storage : Chaud (accès fréquent), Froid (accès peu fréquent, >30 jours), Archive (accès rare, >180 jours).

Pourquoi: Les niveaux offrent un compromis de coûts : Chaud a le coût de stockage le plus élevé mais le coût d'accès le plus bas. Archive a le coût de stockage le plus bas mais le coût d'accès et la latence de récupération les plus élevés (heures).

Déplacer automatiquement les objets blob entre les niveaux Chaud, Froid et Archive en fonction de leur âge ou de leur dernière heure d'accès pour optimiser les coûts.

→Configurer une politique de gestion du cycle de vie sur le compte de stockage.

Pourquoi: Cela automatise le processus de hiérarchisation, garantissant que les données sont toujours sur le niveau le plus rentable sans intervention manuelle.

Migrer une application sur site qui utilise des partages de fichiers SMB. Plusieurs VM doivent monter et accéder au même dossier partagé.

→Utiliser Azure File Storage.

Pourquoi: Azure Files fournit des partages de fichiers entièrement gérés dans le cloud accessibles via les protocoles SMB et NFS, ce qui en fait un remplacement direct des serveurs de fichiers sur site.

Construire un lac de données pour l'analyse de big data qui nécessite des opérations efficaces au niveau du répertoire et un contrôle d'accès granulaire de type POSIX.

→Utiliser Azure Data Lake Storage Gen2.

Pourquoi: ADLS Gen2 s'appuie sur Blob Storage en ajoutant un espace de noms hiérarchique (pour les opérations de répertoire atomiques) et la prise en charge des ACL conformes à POSIX, qui sont essentielles pour les performances et la sécurité dans les frameworks de big data comme Spark.

Une application globale nécessite une latence de lecture/écriture de quelques millisecondes, une réplication multirégionale automatique et une mise à l'échelle horizontale pour une base de données NoSQL.

→Utiliser Azure Cosmos DB.

Pourquoi: Cosmos DB est conçu pour les applications critiques distribuées mondialement, offrant une distribution globale clé en main, des SLA de faible latence garantis et plusieurs modèles de cohérence.

Référence↗

Choisir un modèle de données et une API pour une nouvelle application Cosmos DB.

→Utiliser l'API pour NoSQL (document), l'API MongoDB (document), l'API Apache Gremlin (graphique), l'API Table (clé-valeur) ou l'API Apache Cassandra (colonne large).

Pourquoi: Sélectionnez l'API qui correspond le mieux à votre modèle de données et à votre pile d'applications existante. Utilisez NoSQL pour les nouvelles applications basées sur JSON, Gremlin pour les données riches en relations, et d'autres pour la migration de charges de travail existantes (MongoDB, Cassandra, Table Storage).

Équilibrer la cohérence en lecture, la disponibilité et les performances pour une application Cosmos DB.

→Choisir parmi cinq niveaux de cohérence : Strong (Forte), Bounded Staleness (Obsolescence Limitée), Session (par défaut), Consistent Prefix (Préfixe Cohérent), Eventual (Éventuelle).

Pourquoi: Strong offre la plus haute cohérence mais la latence la plus élevée. Eventual offre la latence la plus faible mais la cohérence la plus faible. Session est le plus courant, garantissant qu'un utilisateur lit ses propres écritures au sein de sa session.

Un service en aval doit réagir en quasi temps réel à toute donnée créée ou mise à jour dans un conteneur Cosmos DB (par exemple, pour mettre à jour un index de recherche).

→Utiliser le flux de changements de Cosmos DB.

Pourquoi: Le flux de changements fournit un journal persistant et ordonné des modifications. Il est couramment consommé par une fonction Azure pour construire des architectures événementielles sans interroger la base de données.

Besoin d'exécuter des requêtes analytiques complexes sur des données opérationnelles Cosmos DB sans impacter les performances de la charge de travail transactionnelle (HTAP).

→Activer le magasin analytique Azure Cosmos DB et utiliser Azure Synapse Link.

Pourquoi: Le magasin analytique est une représentation colonnaire entièrement isolée et synchronisée automatiquement de vos données transactionnelles. Il permet des requêtes analytiques via Synapse sans consommer d'unités de requête (RU) transactionnelles.

Stocker de grandes quantités de données non relationnelles simples et structurées (par exemple, télémétrie d'appareils) pour des recherches rapides basées sur des clés à très faible coût.

→Utiliser Azure Table Storage.

Pourquoi: Table Storage est un magasin de valeurs-clés NoSQL optimisé pour les recherches simples et à volume élevé avec une PartitionKey et une RowKey. Il est nettement moins cher que Cosmos DB lorsque des SLA de faible latence et une distribution globale ne sont pas requis.

Besoin d'un système de messagerie simple et fiable pour découpler les composants d'application, où les messages sont traités de manière asynchrone.

→Utiliser Azure Queue Storage.

Pourquoi: Queue Storage fournit une file d'attente de messages simple, rentable et fiable pour les modèles de communication asynchrone de base.

Besoin de construire, planifier et surveiller des workflows complexes d'intégration de données qui déplacent et transforment des données provenant de diverses sources sur site et dans le cloud.

→Utiliser Azure Data Factory (ADF).

Pourquoi: ADF est un service d'orchestration cloud géré pour la construction et la gestion de pipelines ETL/ELT à grande échelle, avec des capacités de connectivité et de surveillance étendues.

Référence↗

Un pipeline Azure Data Factory doit accéder à une source de données située sur site derrière un pare-feu d'entreprise.

→Installer un Integration Runtime (IR) auto-hébergé sur une machine au sein du réseau sur site.

Pourquoi: L'IR auto-hébergé agit comme une passerelle sécurisée, permettant à ADF dans le cloud de se connecter et de déplacer des données depuis des sources sur site sans les exposer à l'internet public.

Besoin d'une plateforme unique et intégrée pour l'entreposage de données (SQL), l'analyse de big data (Spark), l'exploration de données (SQL serverless) et l'intégration de données.

→Utiliser Azure Synapse Analytics.

Pourquoi: Synapse fournit un espace de travail unifié (Synapse Studio) qui rassemble ces différents moteurs analytiques, réduisant la complexité et les frais généraux d'intégration.

Choisir un moteur de requête SQL au sein de Synapse Analytics.

→Utiliser le pool SQL Serverless pour les requêtes ad hoc et exploratoires sur les données du lac de données avec un modèle de paiement à la requête. Utiliser le pool SQL dédié pour les charges de travail d'entreposage de données performantes et prévisibles avec des ressources provisionnées.

Pourquoi: Serverless est pour l'exploration et la découverte imprévisibles. Dedicated est pour la BI et les rapports de production avec des SLA de performance.

Besoin de traiter et d'analyser des données de streaming à grand volume en temps réel provenant de sources comme IoT Hub ou Event Hubs pour alimenter des tableaux de bord en direct ou déclencher des alertes.

→Utiliser Azure Stream Analytics.

Pourquoi: Stream Analytics est un moteur de traitement d'événements en temps réel qui utilise un langage de requête simple, de type SQL, pour analyser les données en mouvement avec une faible latence.

Une équipe de science des données a besoin d'un environnement collaboratif basé sur des notebooks pour l'ingénierie des données à grande échelle et l'apprentissage automatique utilisant Apache Spark.

→Utiliser Azure Databricks.

Pourquoi: Databricks fournit un runtime Spark optimisé, des notebooks collaboratifs et des capacités ML intégrées (MLflow), ce qui en fait la plateforme principale pour l'analyse avancée et le ML sur Azure.

Besoin d'ingérer des millions d'événements par seconde provenant de sources telles que les applications mobiles, la télémétrie web ou les appareils IoT pour un traitement en temps réel.

→Utiliser Azure Event Hubs.

Pourquoi: Event Hubs est une plateforme de streaming de big data conçue pour l'ingestion d'événements à haut débit. Il agit comme la "porte d'entrée" pour les données de streaming, découplant les producteurs des consommateurs.

Une organisation souhaite une plateforme d'analyse SaaS unique et unifiée combinant l'ingénierie des données, la science des données, l'entreposage de données et la BI avec une gestion minimale de l'infrastructure.

→Utiliser Microsoft Fabric.

Pourquoi: Fabric offre une expérience d'analyse de bout en bout basée sur SaaS, construite sur un lac de données unique (OneLake). Cela simplifie l'architecture et réduit les frais généraux d'intégration par rapport à la construction avec des services PaaS séparés.

Référence↗

Au sein de Microsoft Fabric, besoin d'un artefact unique pour stocker des données au format Delta Lake ouvert, accessible à la fois par les moteurs Spark (pour l'ingénierie des données) et les moteurs SQL (pour la BI).

→Utiliser un Microsoft Fabric Lakehouse.

Pourquoi: Le Lakehouse est le modèle architectural principal dans Fabric. Il combine l'évolutivité et la flexibilité d'un lac de données avec les garanties transactionnelles et les capacités de requête SQL d'un entrepôt de données.

Un rapport Power BI dans Microsoft Fabric doit interroger de grands volumes de données directement depuis OneLake avec les performances du mode d'importation mais la fraîcheur des données de DirectQuery.

→Utiliser le mode Direct Lake dans Power BI.

Pourquoi: Direct Lake est une fonctionnalité unique de Fabric qui charge les fichiers Parquet/Delta directement dans la mémoire du moteur Power BI à la demande, évitant la duplication des données et la latence des requêtes tout en offrant un accès aux données quasi en temps réel.

Les utilisateurs métier doivent se connecter à diverses sources de données, créer des tableaux de bord et des rapports interactifs, et partager des informations au sein de l'organisation.

→Utiliser Power BI.

Pourquoi: Power BI est le service d'analyse commerciale de Microsoft pour la création de visualisations de données interactives. Utilisez Power BI Desktop pour la création et Power BI Service pour le partage et la collaboration.

Différencier une analyse interactive multi-pages d'une vue d'ensemble de haut niveau sur une seule page dans Power BI.

→Un rapport (Report) est une collection multi-pages de visuels détaillés et interactifs construits à partir d'un seul jeu de données. Un tableau de bord (Dashboard) est une toile unique de vignettes épinglées à partir d'un ou plusieurs rapports, offrant une vue d'ensemble rapide.

Pourquoi: Les rapports sont destinés à une analyse approfondie. Les tableaux de bord sont destinés au suivi des métriques clés.

Un seul rapport Power BI doit être partagé avec plusieurs utilisateurs, mais chaque utilisateur ne doit voir que les données qui le concernent (par exemple, un directeur des ventes ne voit que les données de sa région).

→Implémenter la sécurité au niveau des lignes (RLS).

Pourquoi: RLS définit des règles de filtrage basées sur les rôles des utilisateurs, appliquant la sécurité des données au niveau du modèle de données afin que les utilisateurs accédant au même rapport voient des sous-ensembles de données différents.

Besoin de générer des rapports très formatés, au pixel près (comme des factures ou des états financiers) optimisés pour l'impression ou l'exportation PDF.

→Utiliser les rapports paginés Power BI.

Pourquoi: Les rapports paginés sont conçus pour des mises en page prêtes à l'impression avec un contrôle précis sur les en-têtes, les pieds de page et les sauts de page, contrairement aux rapports Power BI interactifs standard qui sont destinés à l'exploration à l'écran.

Un jeu de données Power BI contenant des milliards de lignes prend trop de temps à se rafraîchir. Seuls les derniers jours de données changent fréquemment.

→Configurer l'actualisation incrémentielle sur le jeu de données.

Pourquoi: L'actualisation incrémentielle partitionne les données (généralement par date) et n'actualise que les partitions les plus récentes, réduisant considérablement le temps d'actualisation et l'utilisation des ressources pour les grands jeux de données.

Un seul rapport Power BI doit combiner des données préchargées et performantes (mode Import) avec des données en temps réel provenant d'une source opérationnelle (mode DirectQuery).

→Utiliser les modèles composites Power BI.

Pourquoi: Les modèles composites permettent à un seul jeu de données de mélanger des tables avec différents modes de stockage, offrant la flexibilité d'équilibrer les performances et la fraîcheur des données.

Une organisation a besoin de découvrir, classifier et cataloguer tous les actifs de données à travers son patrimoine de données hybride pour permettre la gouvernance et la découverte des données.

→Utiliser Microsoft Purview.

Pourquoi: Purview est un service unifié de gouvernance des données qui fournit une analyse automatique des données, un glossaire métier, une classification des données et une visualisation de la lignée des données de bout en bout.