Entreposage de données dans Microsoft Azure

Un entrepôt de données est un référentiel central de données intégrées provenant d’une ou plusieurs sources hétérogènes. Les entrepôts de données stockent des données historiques et actuelles, et permettent de créer des rapports et d’analyser des données.

Téléchargez un fichier Visio de cette architecture.

Les données à déplacer dans un entrepôt de données sont régulièrement extraites de différentes sources qui contiennent d’importantes informations d’entreprise. Durant leur déplacement, les données peuvent être mises en forme, nettoyées, validées, synthétisées et réorganisées. Elles peuvent également être stockées au plus bas niveau de détail, avec des vues agrégées fournies dans l’entrepôt pour la création de rapports. Dans les deux cas, l’entrepôt de données devient un magasin de données permanent pour la création de rapports, l’analyse et l’analyse décisionnelle (BI).

Architectures d’entrepôt de données

Les architectures de référence suivantes illustrent des architectures de l’entrepôt de données de bout en bout sur Azure :

• Décisionnel d’entreprise dans Azure avec Azure Synapse Analytics. Cette architecture de référence implémente un pipeline ELT (extract/extraire), load/charger, transform/transformer) qui déplace des données d’une base de données SQL Server locale vers Azure Synapse.
• Décisionnel d’entreprise automatisé avec Azure Synapse et Azure Data Factory. Cette architecture de référence montre un pipeline ELT avec un chargement incrémentiel, automatisé à l’aide d’Azure Data Factory.

Quand utiliser cette solution ?

Optez pour un entrepôt de données si vous avez besoin de convertir un grand nombre de données de systèmes d’exploitation dans un format facile à comprendre. Les entrepôts de données ne doivent pas forcément suivre la même structure de données sobre que celle que vous pouvez utiliser dans vos bases de données OLTP. Vous pouvez utiliser des noms de colonne pertinents pour les utilisateurs professionnels et les analystes, restructurer le schéma pour simplifier les relations entre les données, et consolider plusieurs tables en une seule. Ces étapes guident les utilisateurs qui ont besoin de créer des rapports et d’analyser les données dans des systèmes de BI, sans l’aide d’un administrateur de base de données (DBA) ou d’un développeur de données.

Vous pouvez utiliser un entrepôt de données si vous avez besoin de conserver vos données d’historique dans un emplacement autre que les systèmes transactionnels sources pour des raisons de performances. Les entrepôts de données facilitent l’accès aux données d’historique à partir de plusieurs emplacements, en fournissant un emplacement centralisé utilisant des formats, des clés et des modèles de données courants.

Étant donné que les entrepôts de données sont optimisés pour l’accès en lecture, la génération de rapports est plus rapide qu’avec le système de transactions source.

Voici d’autres avantages :

• L’entrepôt de données peut stocker les données historiques de plusieurs sources, pour constituer une seule source fidèle.
• Vous pouvez améliorer la qualité des données en les nettoyant au fur et à mesure de leur importation dans l’entrepôt de données.
• Les outils de création de rapports ne sont pas comparables aux systèmes transactionnels pour ce qui est des cycles de traitement des requêtes. Un entrepôt de données permet au système transactionnel de se concentrer sur la gestion des écritures, tandis que l’entrepôt lui-même répond à la plupart des demandes de lecture.
• Un entrepôt de données peut consolider des données provenant de différents logiciels.
• Les outils d’exploration de données peuvent trouver des modèles masqués dans les données à l’aide de méthodologies automatiques.
• Les entrepôts de données facilitent la mise en place d’un accès sécurisé aux utilisateurs autorisés, tout en limitant l’accès aux autres utilisateurs. Les utilisateurs professionnels n’ayant pas besoin d’accéder aux données sources, cela supprimer un vecteur d’attaque potentiel.
• Les entrepôts de données facilitent la création de solutions d’aide à la décision, telles que des cubes OLAP.

Défis

La configuration correcte d’un entrepôt de données en fonction des besoins de votre entreprise peut présenter les difficultés suivantes :

• Consacrer le temps nécessaire à la définition correcte des concepts de votre entreprise : Les entrepôts de données sont pilotés par les informations. Vous devez normaliser les termes professionnels et les formats courants, tels que les devises et les dates. Vous devez également restructurer le schéma de façon à ce qu’il soit logique pour des utilisateurs professionnels, tout en garantissant l’exactitude des agrégats de données et des relations entre les données.

• Planifier et configurer l’orchestration de vos données. Prenez en compte la façon dont les données doivent être copiées à partir du système transactionnel source vers l’entrepôt de données, et du moment auquel les données historiques doivent être déplacées de vos magasins de données opérationnels vers l’entrepôt.

• Préserver ou améliorer la qualité des données en les nettoyant au cours de leur importation dans l’entrepôt.

Entreposage de données dans Azure

Vous pouvez avoir une ou plusieurs sources de données, qu’il s’agisse de transactions client ou d’applications professionnelles. Ces données sont généralement stockées dans une ou plusieurs bases de données OLTP. Les données peuvent être persistantes dans d’autres supports de stockage tels que des partages réseau, des objets blob de stockage Azure ou un Data Lake. Elles peuvent également être stockées dans l’entrepôt de données lui-même ou dans une base de données relationnelle comme Azure SQL Database. L’objectif de la couche du magasin de données analytique est de satisfaire les requêtes émises par les outils d’analyse et de création de rapports au niveau de l’entrepôt de données. Dans Azure, cette fonctionnalité de magasin analytique est disponible avec Azure Synapse, ou avec HDInsight Azure en utilisant une requête Hive ou interactive. Vous avez également besoin d’un certain niveau d’orchestration pour déplacer ou copier des données du stockage de données vers l’entrepôt de données, ce qui peut être effectué à l’aide d’Azure Data Factory ou d’Oozie sur Azure HDInsight.

Il existe plusieurs façons d’implémenter un entrepôt de données dans Azure, en fonction des besoins. Les listes suivantes sont divisées en deux catégories, multitraitement symétrique (SMP) et traitement massivement parallèle (MPP).

SMP :

• Azure SQL Database
• SQL Server dans une machine virtuelle

MPP :

• Azure Synapse Analytics (anciennement Azure Data Warehouse)
• Apache Hive sur HDInsight
• Interactive Query (Hive LLAP) sur HDInsight

En règle générale, les entrepôts SMP sont idéaux pour les jeux de données de taille petite ou moyenne (jusqu'à 4-100 To), tandis que les entrepôts MPP sont souvent utilisés pour le Big Data. La frontière entre le Big Data et les volumes petits/moyens de données est en partie liée à la définition et à l’infrastructure sous-jacente de votre organisation. (Voir Choisir un magasin de données OLTP.)

Au-delà de la taille des données, le type de modèle de charge de travail a toutes les chances d’être un facteur plus déterminant. Par exemple, les requêtes complexes risquent d’être trop lentes pour une solution SMP et d’exiger plutôt une solution MPP. Les systèmes MPP imposent généralement une pénalité de performances aux données de petite taille, en raison de la façon dont les tâches sont distribuées et consolidées sur les différents nœuds. Si vos données dépassent déjà 1 To et qu’elles seront amenées à croître en permanence, envisagez une solution MPP. Toutefois, si elles sont de plus petite taille, mais que vos charges de travail dépassent les ressources disponibles de votre solution SMP, le meilleur choix reste peut-être là aussi un système MPP.

Les données lues et stockées par l’entrepôt de données peuvent provenir de différentes sources de données, y compris un lac de données tel que Azure Data Lake Storage. Vous trouverez une session vidéo comparant les différents avantages offerts par les services MPP qui peuvent utiliser Azure Data Lake sur la page Azure Data Lake et Azure Data Warehouse : appliquer des pratiques modernes à une application.

Les systèmes SMP sont caractérisés par une seule instance d’un système de gestion de base de données relationnelle, partageant toutes les ressources (UC / mémoire / disque). Un système SMP peut monter en puissance. Si SQL Server est exécuté sur une machine virtuelle, vous pouvez augmenter la taille de cette dernière. Dans le cas d’Azure SQL Database, le scale-up passe par le choix d’un autre niveau de service.

Pour faire monter en puissance parallèle des systèmes MPP, il faut ajouter des nœuds de calcul (qui ont leurs propres sous-systèmes d’UC, de mémoire et d’E/S). La montée en puissance d’un serveur est soumise à des limites physiques, au-delà desquelles la montée en charge est plus judicieuse, en fonction de la charge de travail. Toutefois, les différences entre l’interrogation, la modélisation et le partitionnement des données signifient que les solutions MPP requièrent des compétences distinctes.

Pour choisir quelle solution SMP utiliser, consultez Étude détaillée d’Azure SQL Database et de SQL Server sur des machines virtuelles Azure.

Azure Synapse (anciennement Azure SQL Data Warehouse) est également utilisable pour des jeux de données de taille petite ou moyenne, dont la charge de travail nécessite d’importantes ressources de calcul et de mémoire. Apprenez-en davantage sur les modèles Azure Synapse et les scénarios courants :

• Modèles de charge de travail Azure SQL Data Warehouse et anti-modèles

• Modèles et stratégies de chargement Azure SQL Data Warehouse

• Migrating data to Azure SQL Data Warehouse in practice

• Modèles d’application courants des ISV avec Azure SQL Data Warehouse

Critères de sélection principaux

Pour restreindre les choix, commencez par répondre aux questions suivantes :

• Préférez-vous opter pour un service géré plutôt que de gérer vos propres serveurs ?

• Travaillez-vous avec des jeux de données extrêmement volumineux, ou des requêtes longues et très complexes ? Si oui, envisagez un système MPP.

• Dans le cas d’un jeu de données volumineux, la source de données est-elle structurée ou non structurée ? Le traitement des données non structurées doit parfois s’effectuer dans un environnement Big Data comme Spark sur HDInsight, Azure Databricks, Hive LLAP sur HDInsight ou Azure Data Lake Analytics. Tous ces outils peuvent servir de moteurs ELT (extraction, chargement, transformation) et ETL (extraction, transformation, chargement). À partir des données traitées, ils peuvent produire des données structurées, plus faciles à charger dans Azure Synapse ou les autres solutions. Pour des données structurées, Azure Synapse inclut un niveau de performances nommé Optimisé pour le calcul, adapté aux charges de travail nécessitant de nombreuses ressources de calcul et des performances extrêmement élevées.

• Souhaitez-vous séparer vos données historiques de vos données opérationnelles actuelles ? Si oui, sélectionnez l’une des solutions pour lesquelles l’orchestration est requise. Ces sont des entrepôts autonomes optimisés pour un accès en lecture intensif et idéaux comme magasins de données historiques distincts.

• Avez-vous besoin d’intégrer des données provenant de plusieurs sources, au-delà de votre magasin de données OLTP ? Si oui, choisissez des solutions qui intègrent facilement plusieurs sources de données.

• Avez-vous un besoin de mutualisation ? Dans ce cas, Azure Synapse n’est pas idéal. Pour plus d’informations, consultez Modèles Azure Synapse et anti-modèles.

• Préférez-vous un magasin de données relationnel ? Si oui, choisissez une option avec un magasin de données relationnel, mais sachez que vous pouvez utiliser un outil comme PolyBase pour interroger des magasins de données non relationnels si nécessaire. Si vous décidez d’utiliser PolyBase, toutefois, exécutez des tests de performances sur vos jeux de données non structurées pour votre charge de travail.

• Avez-vous des exigences de création de rapports en temps réel ? Si vous avez besoin de faibles temps de réponse aux requêtes sur des volumes élevés d’insertions de singletons, choisissez une option prenant en charge les rapports en temps réel.

• Devez-vous prendre en charge un grand nombre de connexions et d’utilisateurs simultanés ? La capacité à prendre en charge de nombreux utilisateurs/connexions simultanés dépend de plusieurs facteurs.

  • Pour Azure SQL Database, référez-vous aux limites de ressources documentées selon votre niveau de service.

  • SQL Server autorise un maximum de 32 767 connexions utilisateurs. En cas d’exécution sur une machine virtuelle, les performances dépendront de la taille de cette machine virtuelle et d’autres facteurs.

  • Azure Synapse est soumis à des limites sur les requêtes et les connexions simultanées. Pour plus d’informations, consultez la page Gestion de la concurrence et des charges de travail dans Azure Synapse. Vous pouvez utiliser des services complémentaires, par exemple, Azure Analysis Services, pour surmonter les limites d’Azure Synapse.

• De quel type est votre charge de travail ? En général, les solutions d’entrepôts MPP sont idéales pour les charges de travail analytiques par lots. Si les vôtres sont de nature transactionnelle, avec beaucoup de petites opérations de lecture/écriture ou d’opérations ligne par ligne, regardez du côté des solutions SMP. Il existe une exception à cette recommandation : si vous utilisez le traitement des flux de données sur un cluster HDInsight, par exemple, Spark Streaming, et que vous stockez les données dans une table Hive.

Matrice des fonctionnalités

Les tableaux suivants résument les principales différences entre les fonctionnalités.

Fonctionnalités générales

[1] Mise à l’échelle et configuration manuelles.

[2] Les clusters HDInsight peuvent être supprimés s’ils ne sont pas nécessaires, puis recréés. Attachez un magasin de données externe à votre cluster afin de conserver vos données si vous supprimez votre cluster. Vous pouvez utiliser Azure Data Factory pour automatiser le cycle de vie de votre cluster en créant un cluster HDInsight à la demande pour traiter votre charge de travail, puis en le supprimant une fois le traitement terminé.

[3] Azure Synapse vous permet de restaurer une base de données à un point de restauration disponible des sept derniers jours. Les captures instantanées démarrent toutes les quatre à huit heures et sont disponibles pendant sept jours. Quand une capture instantanée a une ancienneté supérieure à sept jours, elle expire et son point de restauration n’est plus disponible.

[4] Envisagez d’utiliser un metastore Hive externe qui peut être sauvegardé et restauré en fonction des besoins. Il est possible d’utiliser les options de sauvegarde et de restauration standard qui s’appliquent au Stockage Blob ou à Data Lake Storage pour les données, ou bien des solutions de sauvegarde et de restauration HDInsight tierces, comme Imanis Data, pour plus de flexibilité et de facilité d’utilisation.

Fonctionnalités d’évolutivité

[1] Azure Synapse permet de monter ou descendre en puissance en ajustant le nombre d’unités DWU (Data Warehouse Unit). Consultez Gérer la puissance de calcul dans Azure Synapse.

Fonctionnalités de sécurité

[1] Suppose d’utiliser un cluster HDInsight joint à un domaine.

[2] Suppose d’utiliser le chiffrement TDE (Transparent Data Encryption) pour chiffrer et déchiffrer les données au repos.

[3] Pris en charge si utilisé au sein d’un Réseau virtuel Azure.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• Zoiner Tejada | CEO et architecte

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Pour plus d’informations sur la sécurisation de l’entrepôt de données :

• Sécurisation de votre base de données SQL
• Sécuriser une base de données dans Azure Synapse
• Étendre HDInsight à l’aide d’un Réseau virtuel Azure
• Sécurité Hadoop au niveau de l’entreprise avec des clusters HDInsight joints à un domaine

Ressources associées

• Décisionnel d’entreprise dans Azure avec Azure Synapse Analytics
• Décisionnel d'entreprise automatisé avec Azure Synapse et Azure Data Factory
• Entrepôt de données logique avec des pools SQL serverless Azure Synapse
• Entrepôt de données d’entreprise