Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Conseil / Astuce
Microsoft Fabric Data Warehouse est un entrepôt relationnel à l’échelle de l’entreprise sur une base de lac de données, avec une architecture future, une IA intégrée et de nouvelles fonctionnalités. Si vous débutez avec l'entreposage de données, commencez par Fabric Data Warehouse. Les charges de travail de pool SQL existantes dédicées peuvent être mises à niveau vers Fabric pour accéder à de nouvelles fonctionnalités dans la science des données, l’analytique en temps réel et la création de rapports.
Cette aide-mémoire fournit des conseils utiles et des bonnes pratiques pour la création de solutions de pool SQL dédiées (anciennement SQL DW).
Le graphique suivant montre le processus de conception d’un entrepôt de données avec un pool SQL dédié (anciennement SQL DW) :
Requêtes et opérations entre tables
Lorsque vous connaissez à l’avance les opérations et requêtes principales à exécuter dans votre entrepôt de données, vous pouvez hiérarchiser votre architecture d’entrepôt de données pour ces opérations. Ces requêtes et opérations peuvent inclure :
- Jointure d’une ou deux tables de faits avec des tables de dimension, filtrage de la table combinée, puis ajout des résultats dans un data mart.
- Faire des mises à jour volumineuses ou petites dans vos données factuelles de vente.
- Ajout de données uniquement à vos tables.
Connaître les types d’opérations à l’avance vous aide à optimiser la conception de vos tables.
Migration de données
Tout d’abord, chargez vos données dans Azure Data Lake Storage ou Stockage Blob Azure. Ensuite, utilisez l’instruction COPY pour charger vos données dans des tables intermédiaires. Utilisez la configuration suivante :
| Mise en page | Recommandation |
|---|---|
| Répartition | Ordonnancement par rotation |
| Indexation | Heap |
| Partitionnement | None |
| Classe de ressources | largerc ou xlargerc |
En savoir plus sur la migration des données, le chargement des données et le processus d’extraction, de chargement et de transformation (ELT).
Tables distribuées ou répliquées
Utilisez les stratégies suivantes, en fonction des propriétés de la table :
| Type | Idéal pour... | Faites attention si... |
|---|---|---|
| Répliqué | * Petites tables de dimension dans un schéma en étoile avec moins de 2 Go de stockage après compression (compression ~5x) | * De nombreuses transactions d’écriture se trouvent sur la table (par exemple, insert, upsert, delete, update) * Vous modifiez fréquemment le provisionnement d’unités d’Data Warehouse (DWU) * Vous utilisez uniquement 2 à 3 colonnes, mais votre table comporte de nombreuses colonnes * Vous indexez une table répliquée |
| Round Robin (valeur par défaut) | * Table temporaire/intermédiaire * Aucune clé de jointure évidente ou bonne colonne candidate |
* Les performances sont lentes en raison du déplacement des données |
| Hachage | * Tables de faits * Grandes tables de dimensions |
* Impossible de mettre à jour la clé de distribution |
Conseils :
- Commencez par une méthode Round Robin, mais aspirez à adopter une stratégie de distribution par hachage pour tirer parti d'une architecture massivement parallèle.
- Assurez-vous que les clés de hachage courantes ont le même format de données.
- N'utilisez pas le varchar pour la distribution.
- Les tables de dimension avec une clé de hachage commune à une table de faits avec des opérations de jointure fréquentes peuvent être distribuées par hachage.
- Utilisez sys.dm_pdw_nodes_db_partition_stats pour analyser toute asymétrie dans les données.
- Utilisez sys.dm_pdw_request_steps pour analyser les mouvements de données derrière les requêtes, surveiller le temps de diffusion et effectuer des opérations de réorganisation. Cela est utile pour passer en revue votre stratégie de distribution.
En savoir plus sur les tables répliquées et les tables distribuées.
Indexer votre table
L’indexation est utile pour lire rapidement les tables. Il existe un ensemble unique de technologies que vous pouvez utiliser en fonction de vos besoins :
| Type | Idéal pour... | Attention si... |
|---|---|---|
| Heap | * Table intermédiaire/temporaire * Petites tables avec de petites recherches |
* Toute requête analyse la table complète |
| Index clusterisé | * Tables avec jusqu’à 100 millions de lignes * Tables volumineuses (plus de 100 millions de lignes) avec seulement 1 à 2 colonnes fortement utilisées |
* Utilisé sur une table répliquée * Vous avez des requêtes complexes impliquant plusieurs opérations de jointure et de GROUP BY * Vous effectuez des mises à jour sur les colonnes indexées : cela consomme de la mémoire |
| Index columnstore clusterisé (CCI) (par défaut) | * Tables volumineuses (plus de 100 millions de lignes) | * Utilisé sur une table répliquée * Vous effectuez des opérations de mise à jour massives sur votre table * Vous surpartitionnez votre table : les groupes de lignes ne s'étendent pas sur différents nœuds de distribution et partitions. |
Conseils :
- Outre un index cluster, vous pouvez ajouter un index non cluster à une colonne fortement utilisée pour le filtrage.
- Veillez à gérer la mémoire sur une table avec CCI. Lorsque vous chargez des données, vous souhaitez que l’utilisateur (ou la requête) tire parti d’une classe de ressources volumineuse. Veillez à éviter le découpage et à créer de nombreux petits groupes de lignes compressés.
- Sur Gen2, les tables CCI sont mises en cache localement sur les nœuds de calcul pour optimiser les performances.
- Pour CCI, les performances lentes peuvent se produire en raison d’une compression médiocre de vos groupes de lignes. Si cela se produit, reconstruisez ou réorganisez votre CCI. Vous souhaitez au moins 100 000 lignes par groupe de lignes compressé. L’idéal est de 1 million de lignes dans un groupe de lignes.
- En fonction de la fréquence et de la taille des chargements incrémentiels, vous souhaitez automatiser le moment où vous réorganisez ou régénérez vos index. Le nettoyage du printemps est toujours utile.
- Soyez stratégique lorsque vous souhaitez découper un groupe de lignes. Quelle est la taille des groupes de lignes ouvertes ? Quelle quantité de données prévoyez-vous de charger dans les jours à venir ?
En savoir plus sur les index.
Partitionnement
Vous pouvez partitionner votre table lorsque vous avez une table de faits volumineuse (supérieure à 1 milliard de lignes). Dans 99 pour cent des cas, la clé de partition doit être basée sur la date.
Avec les tables intermédiaires qui nécessitent ELT, vous pouvez tirer parti du partitionnement. Il facilite la gestion du cycle de vie des données. Veillez à ne pas surpartitionner votre table de faits ou de mise en scène, en particulier sur un index columnstore clusterisé.
En savoir plus sur les partitions.
Charge incrémentielle
Si vous allez charger de manière incrémentielle vos données, commencez par vous assurer que vous allouez des classes de ressources plus grandes pour charger vos données. Cela est particulièrement important lors du chargement dans des tables avec des index columnstore ordonnés. Pour plus d’informations, consultez les classes de ressources .
Nous vous recommandons d’utiliser PolyBase et ADF V2 pour automatiser vos pipelines ELT dans votre entrepôt de données.
Pour un grand lot de mises à jour dans vos données historiques, envisagez d’utiliser un CTAS pour écrire les données que vous souhaitez conserver dans une table plutôt que d’utiliser INSERT, UPDATE et DELETE.
Gérer les statistiques
Il est important de mettre à jour les statistiques à mesure que des modifications significatives se produisent sur vos données. Consultez les statistiques de mise à jour pour déterminer si des modifications importantes ont eu lieu. Les statistiques mises à jour optimisent vos plans de requête. Si vous constatez qu’il faut trop de temps pour conserver toutes vos statistiques, soyez plus sélectif sur les colonnes qui ont des statistiques.
Vous pouvez également définir la fréquence des mises à jour. Par exemple, vous pouvez mettre à jour les colonnes de date, où de nouvelles valeurs peuvent être ajoutées quotidiennement. Vous bénéficiez du plus grand avantage en ayant des statistiques sur les colonnes impliquées dans les jointures, les colonnes utilisées dans la clause WHERE et les colonnes trouvées dans GROUP BY.
En savoir plus sur les statistiques.
Classe de ressources
Les groupes de ressources sont utilisés comme moyen d’allouer de la mémoire aux requêtes. Si vous avez besoin de plus de mémoire pour améliorer la vitesse de requête ou de chargement, vous devez allouer des classes de ressources supérieures. De l’autre côté, l’utilisation de classes de ressources plus volumineuses a un impact sur la concurrence. Vous souhaitez prendre cela en compte avant de déplacer tous vos utilisateurs vers une classe de ressources volumineuse.
Si vous remarquez que les requêtes prennent trop de temps, vérifiez que vos utilisateurs ne s’exécutent pas dans de grandes classes de ressources. Les classes de ressources volumineuses consomment de nombreux emplacements d’accès concurrentiel. Ils peuvent entraîner la mise en file d’attente d’autres requêtes.
Enfin, à l’aide de Gen2 du pool SQL dédié (anciennement SQL DW), chaque classe de ressource obtient 2,5 fois plus de mémoire que Gen1.
Apprenez-en davantage sur l’utilisation des classes de ressources et de la concurrence.
Réduire votre coût
Une fonctionnalité clé de Azure Synapse est la possibilité de ressources de calcul managées. Vous pouvez suspendre votre pool SQL dédié (anciennement SQL DW) lorsque vous ne l’utilisez pas, ce qui arrête la facturation des ressources de calcul. Vous pouvez adapter les ressources pour répondre à vos besoins en matière de performance. Pour suspendre, utilisez le portail Azure ou PowerShell. Pour effectuer une mise à l’échelle, utilisez le portail Azure, PowerShell, T-SQL ou une API REST.
Mise à l’échelle automatique maintenant au moment souhaité avec Azure Functions :
Optimiser votre architecture pour les performances
Nous vous recommandons de prendre en compte SQL Database et Azure Analysis Services dans une architecture hub-and-spoke. Cette solution peut fournir une isolation de charge de travail entre différents groupes d’utilisateurs tout en utilisant des fonctionnalités de sécurité avancées de SQL Database et de Azure Analysis Services. Il s’agit également d’un moyen de fournir une concurrence illimitée à vos utilisateurs.
En savoir plus sur les architectures typicales qui tirent parti du pool SQL dédié (anciennement SQL DW) dans Azure Synapse Analytics.
Déployez vos spokes dans des bases de données SQL à partir d’un pool SQL dédié (anciennement SQL DW) :