Architecture de référence d’Azure Data Factory sur les zones d’atterrissage Azure
Cet article explique comment implémenter un modèle de conception de médaillon lakehouse pour un cas d’utilisation axé sur la solution. La solution utilise une topologie de réseau hub-and-spoke avec des zones d’atterrissage qui suivent les bonnes pratiques du Cloud Adoption Framework pour Azure.
Important
Ces conseils sont illustrés par un exemple d’implémentation qui présente une configuration Azure Data Factory de référence sur Azure. Vous pouvez utiliser cette implémentation comme base pour le développement ultérieur de la solution lors de votre première étape vers la production.
Choix de conception clés
Ce modèle porte sur l’entreprise de taille intermédiaire Contoso qui s’apprête à migrer vers le cloud Azure en s’appuyant sur l’automatisation. Contoso dispose d’une fondation cloud Azure établie avec une zone d’atterrissage d’entreprise. Les dirigeants se préparent à transférer leurs premières charges de travail de données dans le cloud, en s’appuyant sur Azure Well-Architected Framework.
Ce cas d’usage initial inclut les scénarios suivants :
- Les données proviennent d’un système d’opérations financières local.
- Elles sont copiées dans le cloud pour les cas d’usage analytiques.
- Contoso établit une fonctionnalité de science des données d’entreprise.
Conditions clés
Le département financier et d’autres divisions de l’entreprise utilisent principalement la solution comme système analytique et de création de rapports.
Le système source local possède les propriétés suivantes :
Une taille d’un téraoctet (TB) avec une croissance annuelle prévue de 5 %.
Un processus de mise à jour par lots qui s’exécute chaque nuit et se termine généralement avant 3 heures, sauf pendant les mises à jour financières de fin d’année.
La solution doit réduire son impact sur le système source.
Les utilisateurs financiers doivent disposer de la possibilité d’afficher l’état des données à un moment donné.
Le cas d’usage initial vise les rapports analytiques et de gestion avec des capacités en libre-service. Cette conception devrait également servir de base à la mise en place d’une fonctionnalité de science des données au sein de l’entreprise.
Les données étant classées confidentielles, la solution doit intégrer des contrôles de sécurité efficaces et une surveillance des composants et des données auxquelles on accède ou que l’on utilise. Sécurisez toutes les données avec un chiffrement robuste des données au repos et des données en transit.
Le modèle de données d’entreprise de Contoso inclut un sous-ensemble spécifique pour les données financières. Les éléments de données clés doivent être nettoyés, modélisés et adaptés aux différentes hiérarchies de rapports avant d’être utilisés pour ces derniers.
Les données sources ingérées qui ne sont pas actuellement mappées au modèle d’entreprise doivent être conservées et rendues disponibles pour des analyses et des cas d’utilisation futurs.
La solution doit être mise à jour quotidiennement en fonction de la disponibilité des sources et disposer d’une option de calcul élastique permettant d’obtenir une mise à jour de la solution de bout en bout en moins de 90 minutes.
La solution doit prendre en charge les contrats de niveau de service (SLA) cibles suivants :
99,5 % de temps de fonctionnement, soit environ 1 jour et 20 heures de temps d’arrêt en un an.
Objectif de point de récupération de trois jours.
Objectif de temps de récupération d’un jour.
La solution doit être conçue dans une optique d’avenir, de façon à pouvoir s’adapter à la croissance future et à l’extension des capacités sans devoir procéder à une refonte en profondeur.
La solution doit prendre en charge l’utilisation attendue suivante :
200 gestionnaires, contrôleurs financiers et analystes connectés au département financier, avec une croissance estimée inférieure à 5 % par an.
100 analystes connectés à d’autres services de l’entreprise, avec une croissance estimée inférieure à 5 % par an.
Seuls les employés de Contoso ont accès à la solution. Ce contrôle exclut explicitement tout accès direct par des tiers ne faisant pas partie de Contoso ou externes.
La solution doit disposer des fonctions suivantes :
Contrôle de bout en bout et pistes d’audit.
Alertes activées concernant la fiabilité, les performances et les mesures du coût.
La solution doit privilégier :
Les compétences et les capacités existantes au lieu d’en développer de nouvelles. Cette stratégie réduit la complexité, le risque et le coût.
Des niveaux de service cloud modernes. Par exemple, elle doit utiliser des solutions PaaS (Platform as a Service) chaque fois que cela est possible, afin de réduire la charge de gestion et les risques, et de contribuer à la maîtrise des coûts.
Des composants matures sur le marché et faciles à trouver. Contoso prévoit de renforcer les compétences des ingénieurs tout au long du cycle de vie du développement logiciel (SDLC).
La solution doit être optimisée pour les exigences non fonctionnelles (NFR) dans l’ordre suivant :
Le coût de la création et de l’exécution de la solution.
Les performances de la solution.
La facilité d’entretien de la solution.
Choix de conception clés
L’architecture d’analytique moderne avec Azure Databricks constitue la base de la conception de la solution. Cette conception est une extension naturelle de l’architecture d’entreprise de la zone d’atterrissage Azure. Elle réutilise de nombreux composants fondamentaux de l’architecture d’entreprise de la zone d’atterrissage Azure, comme Microsoft Entra ID et Azure Monitor. Seules les mises à jour de la configuration spécifique à la solution sont requises.
Cette conception s’adapte facilement aux exigences de volume et de traitement prévues, y compris celle liées à la mise à l’échelle automatique.
Delta Lake prend en charge les exigences relative au point dans le temps, ainsi que le contrôle de version des données amélioré, l’application des schémas et les voyages dans le temps. Delta Lake offre également des garanties d’atomicité, de consistance, d’isolation et de durabilité (ACID).
Offre mature sur le marché, niveaux élevés de disponibilité des compétences, et possibilité d’améliorer les compétences et la formation.
Permet de satisfaire le désir stratégique d’une capacité de science des données d’entreprise en utilisant l’accès aux lacs bruts ou validés dans Azure Databricks.
Azure Data Lake Storage et Azure Databricks fournissent un stockage et un traitement de données de taille moyenne efficaces.
Prend en charge les exigences en matière de performances, de fiabilité et de résilience des services.
La sélection des services PaaS décharge Microsoft d’une grande partie de la charge opérationnelle en échange d’un contrôle moindre.
S’agissant de la version initiale de la solution, nous vous recommandons d’utiliser la licence Pro Power BI comme option. Ce choix est un compromis explicite entre les dépenses d’exploitation et les performances de Power Bi Premium.
Les principales modifications de cette solution sont les suivantes :
Azure SQL est utilisé pour la capacité de modélisation des données en raison des volumes de données attendus, de la réduction des nouveaux composants introduits et de la réutilisation des compétences existantes.
Étant donné que la solution est basée sur des lots, Data Factory est utilisée en fonction de la correspondance fonctionnelle, du coût et de la simplicité.
La conception est extensible pour prendre en charge l’ingestion en streaming.
Un runtime d’intégration auto-hébergé (SHIR) Data Factory est requis pour l’ingestion locale, ce qui signifie qu’Azure Site Recovery est requis pour la résilience du service.
Microsoft Purview Data Governance fait partie de la couche de base, qui fournit une transparence, un catalogue de données et des fonctionnalités de gouvernance.
Architecture
Flux de données
Cette solution utilise Data Factory avec un SHIR pour ingérer des données depuis le système source local vers Data Lake Storage. Data Factory orchestre également les notebooks Azure Databricks pour transformer et charger les données dans des tables Delta Lake hébergées sur Data Lake Storage.
Delta Lake est associé à Power BI, lequel est utilisé pour créer des tableaux de bord et des analyses pour l’équipe de direction à partir des tableaux de Delta Lake. Azure Databricks fournit également un accès au lac brut ou validé pour les charges de travail de science des données et de machine learning.
Le flux de données suivant correspond au diagramme précédent :
Les données sont ingérées à partir d’un système source local vers Data Lake Storage à l’aide de Data Factory avec un SHIR. Data Factory fournit également une orchestration de processus pour les notebooks Azure Databricks afin de transformer et de charger les données dans des tables Delta Lake stockées sur Data Lake Storage, ainsi que des processus d’extraction, de transformation et de chargement de SQL Server.
Delta Lake fournit une couche de format ouvert qui prend en charge le contrôle des versions des données, applique le schéma, permet le voyage dans le temps et garantit la conformité ACID. Les données sont organisées selon les couches suivantes :
La couche Bronze contient toutes les données brutes.
La couche Argent contient des données nettoyées et filtrées.
La couche Or stocke les données agrégées qui sont utiles pour l’analytique métier.
Data Lake Storage sous-tend Delta Lake en raison de sa capacité à stocker efficacement tous les types de données. Cette flexibilité permet de prendre en charge des flux de travail plus ou moins rapides et de maintenir un bon rapport coût-efficacité.
SQL Server est utilisé pour prendre en charge les exigences en matière de modélisation des données d’entreprise, y compris la conformité hiérarchique.
Power BI permet de créer des tableaux de bord d’informations de gestion à partir du modèle d’entreprise. Ce service fournit une vue cohérente, standardisée et performante des données. Power BI peut également activer le travail d’analyse directement à partir de Delta Lake à l’aide d’Azure Databricks.
La solution enrichit les services Azure fondamentaux de deux composants supplémentaires, qui assurent la collaboration, la gouvernance, la fiabilité et la sécurité :
Microsoft Purview fournit des services de découverte de données, un catalogue unifié et des insights de gouvernance sur l’ensemble de la plateforme.
Site Recovery prend en charge la sauvegarde et la récupération des machines virtuelles, qui fournissent le calcul au SHIR de Data Factory, lequel est requis pour ingérer des données à partir d’un emplacement local.
Les services de base suivants nécessitent une extension pour prendre en charge cette solution :
Azure DevOps offre une intégration continue et une livraison continu (CI/CD) et d’autres fonctionnalités de gestion de versions intégrées.
Azure Key Vault gère les secrets, les clés et les certificats de manière sécurisée.
Microsoft Entra ID fournit l’authentification unique (SSO) sur la pile, y compris les utilisateurs Azure Databricks et Power BI.
Azure Monitor collecte et analyse la télémétrie des ressources Azure, qui fournit des audits et des alertes. Ce service optimise les performances et la fiabilité, en identifiant les problèmes de manière proactive.
Microsoft Cost Management fournit des services de gouvernance financière pour les charges de travail Azure.
Conception du réseau
Téléchargez un fichier Visio de cette architecture.
Vous pouvez utiliser des pare-feu Azure pour sécuriser la connectivité réseau entre votre infrastructure locale et votre réseau virtuel Azure.
Vous pouvez déployer un SHIR sur une machine virtuelle dans votre environnement local ou dans Azure, cette dernière solution étant recommandée. Vous pouvez utiliser un SHIR pour vous connecter en toute sécurité à des sources de données locales et effectuer des tâches d’intégration de données dans Data Factory.
Une liaison privée et des points de terminaison privés sont implémentés, et vous pouvez les utiliser pour placer le service dans votre réseau virtuel.
Pour tirer parti de l’étiquetage des données assisté par le machine learning, vous devez créer un nouveau compte de stockage différent de celui par défaut que vous avez créé pour l’espace de travail Azure Machine Learning. Vous pouvez lier le nouveau compte de stockage non défini par default au même réseau virtuel que l’espace de travail. Si vous préférez garder le compte de stockage séparé, vous pouvez le placer dans un sous-réseau différent au sein de ce réseau virtuel.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.
En utilisant Azure Databricks Delta Lake, vous ne pouvez pas utiliser les comptes Azure Storage du niveau Archive, car ce niveau est un stockage hors ligne effectif. Ce choix de conception est un compromis entre les fonctionnalités et les coûts.
Lorsque vous créez un espace de travail Azure Databricks, la redondance par défaut du compte de stockage managé (système de fichiers Azure Databricks ou racine du système de fichiers Databricks) est définie comme stockage géoredondant (GRS). Vous pouvez modifier la redondance en stockage localement redondant (LRS) si la géoredondance n’est pas nécessaire.
En règle générale, les entrepôts de données d’une taille inférieure à 1 To fonctionnent mieux sur Azure SQL Database que sur Synapse. Synapse commence à afficher les gains de performances lorsque l’entrepôt de données est d’une taille supérieure à 1 à 5 To. Cette différence de performances est le principal facteur de choix d’Azure SQL plutôt que Synapse.
Autres solutions
Microsoft Fabric dispose de Data Factory, d’Azure Databricks et de Power BI intégrés en tant que solution unique. Étant donné que Fabric est un service relativement nouveau, certaines fonctionnalités présentes dans les services utilisées dans ce scénario pourraient ne pas être disponibles. Les opérateurs pourraient également devoir suivre une courbe d’apprentissage.
Azure Synapse Analytics est une solution de rechange pour la couche de traitement du stockage. Ce service n’est pas adapté au scénario décrit dans cet article, car Azure Databricks est un service mature et fonctionnel qui dispose de compétences disponibles sur le marché.
Les services suivants sont des solutions de rechange pour la couche de modélisation de stockage :
Azure Synapse Analytics : ce service n’est pas adapté au scénario décrit dans cet article, en raison des volumes de données et du chevauchement fonctionnel avec Azure Databricks.
Azure SQL Managed Instance : ce service n’est pas adapté au scénario décrit dans cet article en raison du manque d’exigences de migration et des dépenses d’exploitation plus élevées.
Azure Database pour PostgreSQL : ce service n’est pas une bonne correspondance pour le scénario décrit dans cet article en raison de l’ensemble de compétences et de la préférence existants de Contoso pour minimiser l’introduction de nouvelles technologies, ce qui réduit les coûts et la complexité.
Fiabilité
La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.
S’aligner sur les objectifs de fiabilité d’un système d’analytique et de production de rapport décisionnels :
Les SLA Azure par défaut de la solution répondent aux exigences, de sorte qu’il n’est pas nécessaire de mettre en place une haute disponibilité ou une extension multirégionale.
L’architecture utilise une stratégie de récupération d’urgence Attendre Microsoft en raison de la faible criticité du service de la solution et de l’utilisation des services PaaS.
Les fonctionnalités natives suivantes traitent les sauvegardes de données :
Historique d’une table Delta Lake dans Azure Databricks.
Sauvegardes par défaut SQL Server.
Couche bronze Delta Lake qui stocke toutes les données sources ingérées dans un format en ajout seul. Cette fonctionnalité permet une relecture complète de la solution sans réingestion à partir du système source.
Important
Pour atteindre vos objectifs de résilience, déployez plusieurs instances SHIR dans différentes zones de disponibilité ou régions, le cas échéant.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.
Cette architecture aborde la sécurité par le biais de la configuration de l’infrastructure choisie et des contrôles du plan de contrôle et de données mis en œuvre. Ces choix de conception sont basés sur le modèle Confiance Zéro et les principes d’accès avec un privilège minimum. Les composants natifs utilisent les contrôles de sécurité suivants :
Les composants de solution utilisent des identités managées pour l’authentification et l’autorisation, ce qui permet un contrôle d’accès cohérent en fonction du rôle.
Key Vault stocke en toute sécurité tous les secrets et certificats de l’application.
Les rôles intégrés spécifiques aux composants permettent un contrôle granulaire pour l’autorisation au niveau du plan de contrôle.
En raison de l’étendue, ces rôles spécifiques sont préférés aux rôles généraux.
Les rôles personnalisés sont explicitement exclus en raison des exigences de gestion de cycle de vie en cours.
Un ensemble de groupes Microsoft Entra spécifiques à un domaine contrôle l’accès aux données dans l’ensemble de la solution, ce qui reflète l’infrastructure de classification des données de Contoso. Les composants individuels de la solution utilisent ces groupes pour appliquer des contrôles au niveau des données. Par exemple, le masquage des données dynamique SQL Server et la sécurité au niveau des lignes Power BI prennent tous deux en charge cette conception.
Cette conception permet d’accorder l’accès à un composant, tout en interdisant la visualisation des données qu’il contient. Pour accéder aux données, l’utilisateur doit également disposer d’un accès aux composants.
Cette solution crée les groupes, comme le financement, au niveau du domaine pour permettre la réutilisation. L’infrastructure de classification des données limite la prolifération des groupes spécifiques à une solution.
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.
Pour optimiser les coûts, cette architecture :
Lie fortement la sélection de la référence SKU des composants aux exigences, ce qui permet d’éviter l’anti-modèle l’offre crée la demande. Cette solution planifie des révisions régulières des métriques pour permettre le bon dimensionnement et l’utilisation de Microsoft Copilot dans Azure.
Met en œuvre des mesures pratiques de réduction des dépenses d’exploitation dans le cadre d’opérations financières plus larges, telles que :
Réservations Azure pour les charges de travail stables et plans d’économies pour les charges de travail dynamiques, pour une durée maximale sur l’ensemble de la solution.
Capacité de réserve Data Factory pour les flux de données.
Niveau d’engagement Log Analytics.
Dispose de configurations de composants qui permettent de trouver un compromis entre les économies et la réponse instantanée :
Calcul serverless Azure Databricks.
Niveaux d’accès des comptes de stockage automatisés par le biais de la configuration des stratégies de gestion du cycle de vie. Vous ne pouvez pas utiliser le niveau archive dans Delta Lake.
Espaces de travail Log Analytics pour la rétention et l’archivage des données et Azure Monitor.
Utilise Azure Hybrid Benefit pour réduire les coûts liés aux licences SQL Server.
Implémente les alertes de coût et de budget via Cost Management et les garde-fous en matière de dépenses.
Excellence opérationnelle
L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.
L’excellence opérationnelle est rendue possible par l’automatisation, la surveillance et l’audit tout au long du SDLC. Cette solution inclut :
Espaces de travail Azure Monitor et Log Analytics en tant que composants de surveillance principaux.
Une stratégie d’étiquetage qui permet la transparence entre les composants de la solution.
Les composants suivants pour le développement :
Tous les déploiements de production utilisent Azure DevOps via la configuration en tant que code, qui est stocké dans un référentiel de contrôle de code source, tel qu’Azure Repos ou GitHub. Cette configuration fournit une piste d’audit complète du déploiement et permet des méthodologies modernes de déploiement, de restauration et de récupération.
Les infrastructures de tests comme PSRule garantissent que les déploiements s’alignent sur les instructions de Well-Architected Framework.
Azure Policy applique les normes organisationnelles et évalue la conformité à grande échelle. Le visualiseur de gouvernance Azure fournit des insights configurables et précis sur l’implémentation technique.
Surveillance
Le monitoring est une partie critique de toute solution au niveau de la production. Prenez en charge les solutions Azure avec une stratégie de surveillance dans le cadre de la stratégie d’observabilité de bout en bout.
Azure Databricks offre des fonctionnalités solides permettant de superviser des métriques d’application personnalisées, des événements de requête de streaming et des messages de journaux d’application. Azure Databricks peut envoyer ces données de surveillance à différents services de journalisation. Vous pouvez utiliser Azure Monitor pour surveiller les pipelines Data Factory et écrire des journaux de diagnostic. Azure Monitor fournit des métriques et des journaux d’activité de niveau de base d’infrastructure pour la plupart des services Azure. Pour plus d'informations, consultez Supervision d'Azure Databricks.
La base de référence d’alerte recommandée inclut ce qui suit :
Alerte sur les coûts et le budget pour le cluster de calcul Azure Databricks, les SHIR Data Factory et SQL Server.
Processus de longue durée dans la solution.
Refus de connexion SQL Server.
Utilisation de Power BI et, le cas échéant, limitation de capacité Power BI Premium.
Espaces de travail Log Analytics pour les cas où la collecte de données est importante.
Important
Créez des groupes d’actions d’alerte en tant que ressources globales pour garantir la continuité en cas de problèmes de service régional.
Efficacité des performances
L’efficacité des performances est la capacité de votre charge de travail à répondre aux demandes qu’elle impose aux utilisateurs de manière efficace. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances
Pour améliorer l’efficacité des performances, cette architecture comprend :
Les niveaux de service standard de différentes versions de composants en fonction des exigences. Vous pouvez effectuer un scale-up de ces ressources à la demande sans interruption dans les niveaux de service. Vous devez tester rigoureusement la mise à l’échelle automatique avant la mise en production.
Une base de référence des options de calcul qui utilisent des fonctionnalités natives cloud pour prendre en charge la demande, par exemple :
Mise à l’échelle automatique Azure Databricks.
Mise à l’échelle et montée en puissance SQL Server.
Configurations de tâches Data Factory pour les performances et l’extensibilité.
Appliquez des conseils disponibles dans les guides d’optimisation suivants dans la solution, par exemple :
Flux de données Data Factory et un SHIR.
Il faut savoir que les performances des solutions de données se dégradent généralement avec le temps. Établissez la capacité d’optimisation continue des performances et effectuez des révisions techniques proactives pour vous assurer que la solution reste adaptée à l’objectif.
Antimodèles
L’état d’esprit local : les services cloud répondent aux contraintes traditionnelles telles que les délais d’approvisionnement, les fonctionnalités et les capacités. Ces services introduisent également la nécessité cruciale de la gestion des coûts tout au long du SDLC. Si vous négligez ce facteur pour les personnes, les processus et la technologie, il en résulte souvent des coûts inattendus et des frictions entre les parties prenantes.
Les contrôles des limites sont la solution : les services cloud, en particulier PaaS, ont l’identité comme contrôle principal qui doit être mis en œuvre et bien gouverné. Si les contrôles de mise en réseau et des limites sont importants, ils ne sont qu’une partie de la solution et non la solution complète.
Définir et oublier : les solutions cloud nécessitent des révisions régulières pour évaluer l’utilisation et les performances actuelles. Ces révisions doivent prendre en compte toutes les modifications fonctionnelles et tarifaires dans Azure. Sans ces révisions, la valeur et l’efficacité des solutions peuvent diminuer au fil du temps.
Déployer ce scénario
Pour déployer cette architecture, suivez les instructions pas à pas dans l’exemple GitHub.
Pour déployer un SHIR sur une machine virtuelle Azure, utilisez le modèle de démarrage rapide.
Étapes suivantes
- Zones d'atterrissage Azure
- Framework d’adoption du cloud
- Choisir entre un plan d’économies et une réservation