Mettre à l’échelle l’analyse à l’échelle du cloud dans Azure
Une plateforme de données évolutive est essentielle pour faire face à la croissance rapide des données. De grandes quantités de données sont générées chaque seconde partout dans le monde. La quantité de données disponibles va vraisemblablement croître de façon exponentielle au cours des prochaines années. À mesure que le taux de génération de données augmente, la vitesse du déplacement des données augmente également.
Quelle que soit la quantité de données dont vous disposez, vos utilisateurs exigent des réponses rapides aux requêtes. Ils s’attendent à patienter quelques minutes, et non plusieurs heures, pour obtenir des résultats. Cet article explique comment mettre à l’échelle votre solution d’analytique à l’échelle du cloud Azure et continuer à répondre aux demandes des utilisateurs en matière de rapidité.
Introduction
De nombreuses entreprises ont des monolithes de plateforme de données volumineux. Ces monolithes sont construits autour d’un seul compte Azure Data Lake Gen2 et parfois d’un seul conteneur de stockage. Un seul abonnement Azure est souvent utilisé pour toutes les tâches liées à la plateforme de données. La mise à l’échelle du niveau de l’abonnement est absente de la plupart des plateformes architecturales, ce qui peut entraver l’adoption continue d’Azure si les utilisateurs rencontrent des limitations au niveau du service ou de l’abonnement Azure. Même si certaines des contraintes représentent des limites souples, les atteindre peut toujours avoir un effet négatif significatif sur votre plateforme de données.
Lorsque vous structurez votre plateforme de données, tenez compte de la structure de votre organisation. Notez la propriété des données et les responsabilités fonctionnelles de vos équipes. Si votre organisation offre aux équipes un grand degré d’autonomie et de propriété distribuée, une architecture de maillage de données est votre meilleure option.
Évitez les situations où différentes équipes sont responsables des différentes tâches d’une solution, telles que l’ingestion, le nettoyage, l’agrégation et le service. Une dépendance vis-à-vis de plusieurs équipes peut entraîner une perte de vélocité importante. Par exemple, si vos consommateurs de données sur la couche de service doivent intégrer de nouvelles ressources de données ou implémenter des modifications fonctionnelles pour une ressource de données particulière, ils doivent passer par un processus en plusieurs étapes. Pour cet exemple, les étapes sont les suivantes :
- Le consommateur de données envoie un ticket à chaque équipe responsable d’une phase de pipeline de données.
- Les équipes doivent travailler ensemble de manière synchronisée, car les couches sont interconnectées. Les nouveaux services nécessitent des modifications de la couche de nettoyage des données, conduisant à des modifications dans la couche d’agrégation de données, qui entraînent des modifications dans la couche de service. Les modifications peuvent affecter chaque phase du pipeline.
- Il est difficile pour les équipes de voir les effets potentiels du traitement des modifications, car elles n’ont pas de vue d’ensemble de l’ensemble du cycle de vie de bout en bout. Elles doivent collaborer afin de concevoir un plan de mise en production bien défini qui minimise les effets sur les pipelines et les consommateurs existants. Cette gestion des dépendances augmente la surcharge de gestion.
- En règle générale, les membres des équipes ne sont pas des experts techniques en ce qui concerne la ressource de données demandée par le consommateur de données. Pour comprendre les nouvelles fonctionnalités du jeu de données ou valeurs de paramètres, ce dernier doit consulter un expert.
- Une fois toutes les modifications implémentées, le consommateur de données est averti que la nouvelle ressource de données est prête à être utilisée.
Chaque grande organisation comprend des milliers de consommateurs de données. Un processus complexe comme celui décrit ici diminue gravement la vitesse dans les grandes architectures, car les équipes centralisées deviennent un goulot d’étranglement pour les unités commerciales. Il en résulte moins d’innovation et une efficacité limitée. Potentiellement, les unités commerciales peuvent décider de quitter le service et de créer leur propre plateforme de données à la place.
Méthodes de mise à l’échelle
L’analytique à l’échelle du cloud aborde les défis de mise à l’échelle grâce à deux concepts clés :
- Utilisation de zones d’atterrissage de données pour la mise à l’échelle
- Utilisation de produits de données ou d’intégrations de données pour la mise à l’échelle, afin de rendre possible la propriété distribuée et décentralisée des données
Vous pouvez déployer une ou plusieurs zones d’atterrissage de données. Les zones d’atterrissage de données vous permettent de découvrir et de gérer les données en vous connectant à une zone d’atterrissage de gestion des données. Chaque zone d’atterrissage de gestion des données se trouve dans un seul abonnement Azure.
Les abonnements sont les unités de gestion, de facturation et de mise à l’échelle d’Azure. Ils jouent un rôle essentiel dans votre plan d’adoption Azure à grande échelle.
Mise à l’échelle avec des zones d’atterrissage de données
Les concepts centraux de l’analyse à l’échelle du cloud sont la zone d’atterrissage de gestion des données et la zone d’atterrissage des données. Vous devez placer chacune dans son propre abonnement Azure. Les séparer vous permet de séparer clairement les tâches, de suivre le principe du privilège minimum et de résoudre partiellement le problème de mise à l’échelle de l’abonnement mentionné plus haut. Une configuration d’analyse à l’échelle du cloud minimale comprend une zone d’atterrissage de données unique et une zone d’atterrissage de gestion des données unique.
Toutefois, une configuration minimale n’est pas suffisante pour les déploiements de plateforme de données à grande échelle. Les entreprises créent des plateformes à grande échelle et investissent de manière cohérente et efficace pour mettre à l’échelle leurs efforts en matière de données et d’analytique au fil du temps. Pour surmonter les limitations au niveau de l’abonnement, l’analytique à l’échelle du cloud utilise les abonnements en tant qu’unité de mise à l’échelle, comme indiqué dans Zones d’atterrissage Azure. Cette technique permet d’augmenter l’encombrement de la plateforme de données en ajoutant d’autres zones d’atterrissage de données à l’architecture. L’adoption de cette technique résout également le problème lorsqu’une seule instance Azure Data Lake Gen2 est utilisée pour toute une organisation, car chaque zone d’atterrissage de données comprend trois lacs de données. Les projets et les activités de plusieurs domaines peuvent être distribués sur plusieurs abonnements Azure, ce qui autorise une plus grande scalabilité.
Déterminez le nombre de zones d’atterrissage de données dont votre organisation a besoin avant d’implémenter une architecture d’analytique à l’échelle du cloud. Prendre la bonne décision pose les bases d’une plateforme de données efficace et performante.
Le nombre de zones d’atterrissage de données requises dépend de nombreux facteurs, en particulier :
- L’alignement organisationnel, par exemple combien d’unités commerciales ont besoin de leur propre zone d’atterrissage de données
- Les considérations opérationnelles, telles que la façon dont votre organisation aligne les ressources opérationnelles et les ressources propres à une unité commerciale
L’utilisation du modèle de zone d’atterrissage de données approprié permet de minimiser les futurs efforts de déplacement des produits de données et des ressources de données d’une zone d’atterrissage vers une autre. Cela vous permettra également d’effectuer une mise à l’échelle efficace et cohérente des efforts de Big Data et d’analytique à venir.
Tenez compte des facteurs suivants lors du choix du nombre de zones d’atterrissage de données à déployer.
| Factor | Description |
|---|---|
| Structure organisationnelle et propriété des données | Réfléchissez à la structure de votre organisation et à la propriété des données dans votre organisation. |
| Région et localisation | Si vous déployez dans plusieurs régions, choisissez la ou les régions qui doivent héberger les zones de données. Veillez à respecter toutes les exigences de résidence des données. |
| Quotas | Les quotas d’abonnement ne constituent pas des garanties de capacité et sont appliqués par région. |
| Souveraineté des données | En raison des réglementations de souveraineté des données, les données doivent être stockées dans une région spécifique et suivre des stratégies propres à la région. |
| Stratégies Azure | Les zones d’atterrissage des données doivent respecter les exigences de diverses stratégies Azure. |
| Limite de gestion | Les abonnements fournissent une délimitation de la gestion pour la gouvernance et l’isolation, qui sépare clairement les problèmes. |
| Mise en réseau | Chaque zone d’atterrissage a un réseau virtuel. Étant donné qu’un réseau virtuel réside dans une seule région, chaque nouvelle région nécessite une nouvelle zone d’atterrissage. Les réseaux virtuels doivent être des réseaux virtuels appairés, afin de permettre la communication inter-domaines. |
| Limites | Un abonnement a des limites. En ayant plusieurs abonnements, vous pouvez atténuer les risques liés à l’atteinte de ces limites. |
| Affectation des coûts | Déterminez si les services partagés tels que les comptes de stockage payés de manière centralisée doivent être fractionnés par unité commerciale ou par domaine. L’utilisation d’un abonnement distinct crée une limite pour l’allocation des coûts. Vous pouvez obtenir la même fonctionnalité à l’aide de balises. |
| Classifications des données et données hautement confidentielles | Les mécanismes de sécurité peuvent affecter le développement des produits de données et la facilité d’utilisation d’une plateforme de données. Pensez aux classifications de données et déterminez si les jeux de données hautement confidentiels nécessitent un traitement spécial, comme l’accès juste-à-temps, les clés gérées par le client (CMK), les contrôles réseau affinés, ou plus de chiffrement. |
| Autres implications légales ou relatives à la sécurité | Déterminez s’il existe d’autres exigences légales ou de sécurité qui nécessitent la séparation logique ou physique des données. |
Si vous implémentez une architecture de maillage de données, prenez en compte les facteurs suivants lorsque vous décidez comment distribuer vos zones d’atterrissage de données et vos domaines de données.
| Factor | Description |
|---|---|
| Domaines de données | Tenez compte des domaines de données utilisés par votre organisation, et déterminez ceux qui se trouveront sur votre plateforme de données. Tenez compte de la taille de vos domaines de données individuels. Pour plus d’informations, consultez Domaines de données. |
| Latence | Les domaines qui collaborent sur de grandes quantités de données peuvent transférer une grande quantité de données entre les zones d’atterrissage. Vous pouvez allouer vos domaines dans la même zone d’atterrissage ou la même région. Le fait de les séparer augmente la latence et peut augmenter les coûts dans les domaines inter-régions. |
| Sécurité | Certains déploiements ou configurations de service nécessitent des privilèges élevés dans un abonnement. Accorder ces privilèges à un utilisateur dans un domaine donne implicitement à cet utilisateur les mêmes privilèges dans d’autres domaines au sein du même abonnement. |
Vous trouverez d’autres considérations sur les abonnements dans le guide du framework d’adoption du cloud.
De nombreuses organisations souhaitent une mise à l’échelle efficace de leur plateforme de données d’entreprise. Les unités commerciales doivent être en mesure de créer leurs propres solutions et applications de données pour répondre à leurs besoins uniques. Fournir cette capacité peut représenter un défi, car de nombreuses plateformes de données existantes ne sont pas construites autour de concepts de scalabilité et de propriété décentralisée. Ce défaut se constate clairement dans l’architecture, la structure d’équipe et le modèle d’opérations de ces plateformes de données.
Les zones d’atterrissage des données ne créent pas de silos de données au sein de votre organisation. La configuration réseau recommandée pour l’analyse à l’échelle du cloud permet un partage de données sécurisé et sur place entre les zones d’atterrissage, ce qui facilite à son tour l’innovation entre les domaines de données et les unités commerciales. Pour plus d’informations, consultez Considérations relatives à l’architecture réseau.
Il en va de même pour la couche d’identité. Lorsque vous utilisez un seul locataire Microsoft Entra, vous pouvez accorder aux identités l’accès aux ressources de données dans plusieurs zones d’atterrissage de données. Pour en savoir plus sur le processus d’autorisation d’utilisateur et d’identité, consultez Gestion de l’accès aux données.
Notes
Si vous disposez de plusieurs zones d’atterrissage de données, les zones peuvent se connecter aux données hébergées dans d’autres zones. Cela permet aux groupes de collaborer au sein de votre entreprise.
L’analyse à l’échelle du cloud utilise une architecture commune pour promouvoir une gouvernance cohérente. Votre architecture définit les stratégies et les fonctionnalités de base. Toutes les zones d’atterrissage de données adhèrent aux mêmes contrôles et audits. Vos équipes peuvent créer des pipelines de données, ingérer des sources et créer des produits de données, tels que des rapports et des tableaux de bord. Les équipes peuvent également effectuer une analyse Spark/SQL en fonction des besoins. Vous pouvez augmenter les fonctionnalités des zones d’atterrissage de données en ajoutant des services à la fonctionnalité de la stratégie. Par exemple, une équipe peut ajouter un moteur graphique tiers pour répondre à une exigence métier.
L’analytique à l’échelle du cloud met essentiellement l’accent sur la classification et le catalogage centraux pour protéger les données et permettre à différents groupes de découvrir des produits de données.
Attention
Nous vous déconseillons d’interroger des données entre les régions. Au lieu de cela, assurez-vous que les données sont proches des ressources de calcul qui les utilisent, tout en respectant les limites régionales.
L’architecture d’analytique à l’échelle du cloud et le concept de zones d’atterrissage de données permettent à votre organisation d’augmenter facilement la taille de votre plateforme de données au fil du temps. Vous pouvez ajouter d’autres zones d’atterrissage de données par le biais d’une approche progressive. Vos clients n’ont pas besoin d’avoir plusieurs zones d’atterrissage dès le début. Lorsque vous adoptez cette architecture, classez par ordre de priorité quelques zones d’atterrissage de données et les produits de données qu’elles contiennent. Une hiérarchisation appropriée aide à garantir la réussite de votre déploiement d’analytique à l’échelle du cloud.
Mise à l’échelle avec des produits de données ou des intégrations de données
Dans chaque zone d’atterrissage, votre organisation peut effectuer une mise à l’échelle à l’aide d’applications de données. Les applications de données sont des unités ou des composants de votre architecture de données qui encapsulent les fonctionnalités qui permettent de rendre les produits de données optimisés en lecture utilisables par d’autres applications de données. Dans Azure, les applications de données sont des environnements sous la forme de groupes de ressources qui permettent aux équipes interfonctionnelles d’implémenter des solutions de données et des charges de travail. Une équipe associée s’occupe du cycle de vie de bout en bout de la solution de données, qui comprend les tâches d’ingestion, de nettoyage, d’agrégation et de service.
L’analytique à l’échelle du cloud aborde les problèmes d’intégration et de responsabilité des données dont nous avons discuté plus haut. Au lieu des responsabilités fonctionnelles monolithiques pour l’ingestion de table et l’intégration du système source, la conception de référence fournit une architecture distribuée basée sur des domaines de données. Les équipes interfonctionnelles assument la responsabilité fonctionnelle de bout en bout et la propriété de l’étendue des données.
Au lieu de disposer d’une pile technique centralisée et d’une équipe responsable de toutes les tâches de votre workflow de traitement des données, vous pouvez répartir la responsabilité de bout en bout entre plusieurs équipes d’intégration de données interfonctionnelles autonomes. Chaque équipe est propriétaire d’une fonctionnalité de domaine ou de sous-domaine, et est encouragée à servir des jeux de données en fonction des besoins des consommateurs de données.
Ces différences architecturales ont comme conséquence une vélocité accrue sur votre plateforme de données. Vos consommateurs de données n’ont plus besoin de s’appuyer sur un ensemble d’équipes centralisées ou de se battre pour la hiérarchisation de leurs modifications demandées. À mesure que les petites équipes prennent possession de votre flux de travail d’intégration de bout en bout, la boucle de rétroaction entre le fournisseur de données et le consommateur de données est beaucoup plus courte. Cette approche entraîne une hiérarchisation plus rapide, des cycles de développement plus rapides et un processus de développement plus agile. Vos équipes n’ont plus besoin de synchroniser les processus et les plans de mise en production entre elles, car l’équipe d’intégration de données interfonctionnelle est pleinement au fait de la pile technique de bout en bout et des implications des changements. Elle peut utiliser des pratiques de génie logiciel pour exécuter des tests unitaires et d’intégration en vue de réduire l’effet global sur les consommateurs.
Dans l’idéal, l’équipe propriétaire des systèmes d’intégration de données est également propriétaire des systèmes sources. Cette équipe doit être composée d’ingénieurs de données qui travaillent sur les systèmes sources, d’experts techniques (SME) pour les jeux de données, d’ingénieurs cloud et de propriétaires de produits de données. La création de ce type d’équipe interfonctionnelle réduit la quantité de communications nécessaires avec les équipes externes, et est essentielle lors du développement de la pile complète, de l’infrastructure jusqu’aux pipelines de données.
La base de votre plateforme de données est constituée de jeux de données intégrés à partir de systèmes sources. Ces jeux de données permettent à vos équipes de produits de données d’innover sur les tables de faits métier, et d’améliorer la prise de décision et les processus métier. Vos équipes d’intégration de données et vos équipes de produits de données doivent offrir des contrats de niveau de service (SLA) aux consommateurs, et s’assurer que tous les contrats sont respectés. Les contrats SLA proposés peuvent être liés à la qualité des données, à la chronologie, aux taux d’erreur, à la durée de bon fonctionnement et à d’autres tâches.
Résumé
En utilisant les mécanismes de mise à l’échelle de votre architecture d’analytique à l’échelle du cloud, votre organisation développe votre patrimoine de données dans Azure au fil du temps tout en évitant les limitations techniques connues. Les deux méthodes de mise à l’échelle décrites dans cet article vous aident à surmonter différentes complexités techniques, et peuvent être utilisées de manière simple et efficace.