Guide opérationnel de preuve de concept Synapse : Entreposage de données avec un pool SQL dédié dans Azure Synapse Analytics
Cet article présente une méthodologie de haut niveau pour la préparation et l’exécution d’un projet de preuve de concept Azure Synapse Analytics efficace pour un pool SQL dédié.
Notes
Cet article fait partie de la série Guide opérationnel de la preuve de concept Synapse . Pour une vue d’ensemble de la série, consultez Guide opérationnel de la preuve de concept Synapse.
Conseil
Si vous débutez avec les pools SQL dédiés, nous vous recommandons de suivre le parcours d’apprentissage Travailler avec Data Warehouses à l’aide d’Azure Synapse Analytics.
Préparer la preuve de concept
Avant de décider des objectifs de votre preuve de concept Azure Synapse, nous vous recommandons de lire d’abord l’article sur l’architecture Azure Synapse SQL pour vous familiariser avec la façon dont un pool SQL dédié sépare le calcul et le stockage pour fournir des performances de pointe.
Identifier les commanditaires et les points de blocage potentiels
Une fois que vous êtes familiarisé avec Azure Synapse, il est temps de vous assurer que votre preuve de concept dispose du soutien nécessaire et qu’il n’y a aucun obstacle. Vous devriez :
- Identifiez toutes les restrictions ou stratégies de votre organisation quant au déplacement des données et du stockage des données dans le cloud.
- Identifiez le responsable et le commanditaire de l’entreprise pour un projet d’entrepôt de données basé sur le cloud.
- Vérifiez que votre charge de travail est appropriée pour Azure Synapse. Pour plus d’informations, consultez Architecture d’un pool SQL dans Azure Synapse Analytics.
Définir la chronologie
Une preuve de concept est un exercice délimité, sur un temps défini avec des objectifs et des métriques spécifiques, mesurables et qui définissent le succès. Dans l’idéal, elle doit être ancrée dans la réalité de l’entreprise afin que les résultats soient significatifs.
Les preuves de concept ont les meilleurs résultats lorsqu’elles sont limitées dans le temps. La limitation dans le temps alloue une unité fixe et maximale de temps à une activité. D’après notre expérience, deux semaines donnent suffisamment de temps pour terminer le travail sans le fardeau des cas d’usage trop nombreux ou des matrices de test complexes. Dans ce délai fixe, nous vous suggérons de suivre cette chronologie :
- Chargement des données : Trois jours ou moins
- Interrogation : Cinq jours ou moins
- Tests à valeur ajoutée : Deux jours ou moins
Voici quelques conseils :
- Effectuez des estimations réalistes du temps nécessaire pour effectuer les tâches dans votre plan.
- Reconnaissez que le temps d’exécution de votre preuve de concept sera lié à la taille de votre jeu de données, au nombre d’objets de base de données (tables, vues et procédures stockées), à la complexité des objets de base de données et au nombre d’interfaces que vous allez tester.
- Si vous estimez que votre preuve de concept s’exécutera sur plus de quatre semaines, envisagez de réduire l’étendue pour vous concentrer uniquement sur les objectifs les plus importants.
- Obtenez le soutien de toutes les ressources et des commanditaires pour la chronologie avant de commencer le preuve de concept.
Une fois que vous avez déterminé qu’il n’y a pas d’obstacles immédiats et que vous avez défini la chronologie, vous pouvez définir l’étendue d’une architecture de haut niveau.
Créer une architecture de haut niveau avec étendue
Une architecture future de haut niveau contient probablement un grand nombre de sources de données et consommateurs de données, composants Big Data, et éventuellement du Machine Learning et des consommateurs de données IA. Pour que vos objectifs de preuve de concept restent réalisables (et dans les limites de votre chronologie définie), choisissez les composants qui feront partie de la preuve de concept et ceux qui seront exclus.
En outre, si vous utilisez déjà Azure, identifiez les éléments suivants :
- Toutes les ressources Azure existantes que vous pouvez utiliser pendant la preuve de concept. Par exemple, les ressources peuvent inclure l’ID Microsoft Entra ou Azure ExpressRoute.
- Quelles régions Azure votre organisation préfère.
- Un abonnement que vous pouvez utiliser pour le travail de preuve de concept hors production.
- Le débit de votre connexion réseau à Azure.
Important
Veillez à vérifier que votre preuve de concept peut consommer une partie de ce débit sans avoir un effet négatif sur les solutions de production.
Appliquer les options de migration
Si vous migrez d’un système d’entrepôt de données hérité vers Azure Synapse, voici quelques questions à prendre en compte :
- Migrez-vous et souhaitez apporter autant de modifications aux processus d’extraction, de transformation et de chargement (ETL) existants et à la consommation d’entrepôt de données que possible ?
- Vous effectuez une migration, mais souhaitez apporter des améliorations significatives au passage ?
- Créez-vous un environnement d’analytique des données entièrement nouveau (parfois appelé projet greenfield) ?
Ensuite, vous devez prendre en compte vos difficultés.
Identifier les difficultés actuelles
Votre preuve de concept doit contenir des cas d’usage pour prouver que les solutions potentielles résoudront vos difficultés actuelles. Voici quelques questions à considérer :
- Quelles lacunes dans votre implémentation actuelle espérez-vous qu’Azure Synapse remplisse ?
- Quels nouveaux besoins métier devez-vous prendre en charge ?
- Quels contrats de niveau de service (SLA) devez-vous respecter ?
- Quelles seront les charges de travail (par exemple, ETL, requêtes par lots, analyse, requêtes de création de rapports ou requêtes interactives) ?
Ensuite, vous devez définir vos critères de réussite de preuve de concept.
Définir les critères de réussite de preuve de concept
Identifiez pourquoi vous faites une preuve de concept et veillez à définir des objectifs clairs. Il est également important de savoir quels résultats vous attendez de votre preuve de concept et ce que vous envisagez de faire avec.
Gardez à l’esprit qu’une preuve de concept doit être un effort court et ciblé pour prouver ou tester rapidement un ensemble limité de concepts. Si vous avez une longue liste d’éléments à prouver, vous pouvez les répartir entre plusieurs preuves de concept. Les preuves de concept peuvent avoir des portes entre elles afin de pouvoir déterminer s’il faut passer à la preuve de concept suivante.
Voici quelques exemples d’objectifs de preuve de concept :
- Nous devons savoir que les performances des requêtes pour nos requêtes de rapports complexes volumineuses répondront à nos nouveaux contrats SLA.
- Nous devons connaître les performances des requêtes pour nos utilisateurs interactifs.
- Nous devons savoir si nos processus ETL existants sont adaptés et où des améliorations doivent être apportées.
- Nous devons savoir si nous pouvons raccourcir nos runtimes ETL et à quel point.
- Nous devons savoir que Synapse Analytics dispose de fonctionnalités de sécurité suffisantes pour sécuriser correctement nos données.
Ensuite, vous devez créer un plan de test.
Créer un plan de test
À l’aide de vos objectifs, identifiez des tests spécifiques à exécuter pour prendre en charge ces objectifs et fournir vos résultats identifiés. Il est important de s’assurer que vous avez au moins un test pour prendre en charge chaque objectif et le résultat attendu. Identifiez les requêtes, rapports et autres processus spécifiques que vous allez exécuter pour fournir des résultats mesurables.
Affinez vos tests en ajoutant plusieurs scénarios de test pour clarifier toutes les questions de structure de table qui se posent.
Une bonne planification définit généralement une exécution efficace de preuve de concept. Assurez-vous que toutes les parties prenantes acceptent un plan de test écrit qui lie chaque objectif de preuve de concept à un ensemble de cas de test clairement indiqués et à des mesures de réussite.
La plupart des plans de test tournent autour des performances et de l’expérience utilisateur attendue. Voici un exemple de plan de test. Il est important de personnaliser votre plan de test pour répondre à vos besoins métier. Clairement définir ce que vous testez portera ses fruits plus tard dans ce processus.
| Objectif | Test | Résultats attendus |
|---|---|---|
| Nous devons savoir que les performances des requêtes pour nos requêtes de rapports complexes volumineuses répondront à nos nouveaux contrats SLA | - Test séquentiel des requêtes complexes - Test d’accès concurrentiel des requêtes complexes par rapport aux contrats SLA indiqués |
- Requêtes A, B et C terminées en 10, 13 et 21 secondes, respectivement - Avec 10 utilisateurs simultanés, requêtes A, B et C terminées en 11, 15 et 23 secondes, en moyenne |
| Nous devons connaître les performances des requêtes pour nos utilisateurs interactifs | - Test d’accès concurrentiel des requêtes sélectionnées au niveau d’accès concurrentiel attendu de 50 utilisateurs. - Exécutez la requête précédente avec la mise en cache du jeu de résultats |
- À 50 utilisateurs simultanés, le temps d’exécution moyen devrait être inférieur à 10 secondes et sans mise en cache du jeu de résultats - À 50 utilisateurs simultanés, le temps d’exécution moyen devrait être inférieur à cinq secondes avec la mise en cache du jeu de résultats |
| Nous devons savoir si nos processus ETL existants peuvent s’exécuter en respectant le contrat SLA | - Exécutez un ou deux processus ETL pour imiter les charges de production | - Le chargement incrémentiel dans une table de faits de base doit se terminer en moins de 20 minutes (y compris la mise en lots et le nettoyage des données) - Le traitement de dimension doit prendre moins de cinq minutes |
| Nous devons savoir que l’entrepôt de données dispose de fonctionnalités de sécurité suffisantes pour sécuriser nos données | - Passez en revue et activez la sécurité réseau (réseaux virtuels et points de terminaison privés) et le contrôle d’accès (sécurité au niveau des lignes, masquage des données dynamique) | - Prouvez que les données ne quittent jamais notre locataire. - Assurez-vous que le contenu du client est facilement sécurisé |
Ensuite, vous devez identifier et valider le jeu de données de preuve de concept.
Identifier et valider le jeu de données de preuve de concept
À l’aide des tests délimités, vous pouvez maintenant identifier le jeu de données requis pour exécuter ces tests dans Azure Synapse. Passez en revue votre jeu de données en tenant compte des éléments suivants :
- Vérifiez que le jeu de données représente correctement votre jeu de données de production en termes de contenu, de complexité et d’échelle.
- N’utilisez pas de jeu de données trop petit (moins de 1 To), car vous risquez de ne pas obtenir de performances représentatives.
- N’utilisez pas de jeu de données trop volumineux, car la preuve de concept n’est pas destinée à effectuer une migration complète des données.
- Identifiez le modèle de distribution, l’option d’indexation et le partitionnement pour chaque table. S’il existe des questions concernant la distribution, l’indexation ou le partitionnement, ajoutez des tests à votre preuve de concept pour y répondre. N’oubliez pas que vous souhaiterez peut-être tester plusieurs options de distribution ou d’indexation pour certaines tables.
- Vérifiez auprès des propriétaires de l’entreprise tous les points de blocage quant au déplacement du jeu de données de preuve de concept vers le cloud.
- Identifiez les problèmes de sécurité ou de confidentialité.
Important
Veillez à vérifier auprès des propriétaires d’entreprise les blocages avant de déplacer des données vers le cloud. Identifiez les problèmes de sécurité ou de confidentialité ou les besoins d’obfuscation des données avant de déplacer des données vers le cloud.
Ensuite, vous devez assembler l’équipe d’experts.
Assembler l’équipe
Identifiez les membres de l’équipe et leur engagement à soutenir votre preuve de concept. Les membres de l’équipe doivent inclure :
- Un gestionnaire de projet pour exécuter le projet de preuve de concept.
- Représentant de l’entreprise pour superviser les exigences et les résultats.
- Un expert des données d’application pour approvisionner les données du jeu de données de preuve de concept.
- Un spécialiste Azure Synapse.
- Un conseiller expert pour optimiser les tests de preuve de concept.
- Toute personne qui sera requise pour des tâches de projet de preuve de concept spécifiques, mais qui ne sont pas requises pendant toute sa durée. Ces ressources de support peuvent inclure des administrateurs réseau, des administrateurs Azure ou des administrateurs Microsoft Entra.
Conseil
Nous vous recommandons d’engager un conseiller expert pour vous aider avec votre preuve de concept. La communauté de partenaires Microsoft offre une disponibilité mondiale de consultants experts qui peuvent vous aider à évaluer ou implémenter Azure Synapse.
Maintenant que vous êtes entièrement préparé, il est temps de mettre votre preuve de concept en pratique.
Mettre la preuve de concept en pratique
Il est important de garder à l’esprit les points suivants :
- Implémentez votre projet de preuve de concept avec la discipline et la rigueur de tout projet de production.
- Exécutez la preuve de concept conformément au plan.
- Disposez d’un processus de demande de modification en place pour empêcher votre étendue de preuve de concept de croître ou de changer.
Avant de commencer, vous devez configurer l’environnement de test. Cela implique quatre étapes :
- Programme d’installation
- Chargement de données
- Interrogation
- Tests à valeur ajoutée
Paramétrage
Vous pouvez configurer une preuve de concept sur Azure Synapse en procédant comme suit :
- Utilisez ce guide de démarrage rapide pour approvisionner un espace de travail Synapse et configurer le stockage et les autorisations en fonction du plan de test de preuve de concept.
- Utilisez ce guide de démarrage rapide pour ajouter un pool SQL dédié à l’espace de travail Synapse.
- Configurez la mise en réseau et la sécurité en fonction de vos besoins.
- Accordez l’accès approprié aux membres de l’équipe de preuve de concept. Consultez cet article sur l’authentification et l’autorisation pour accéder aux pools SQL dédiés.
Conseil
Nous vous recommandons de développer du code et des tests unitaires à l’aide du niveau de service DW500c (ou ci-dessous). Nous vous recommandons d’exécuter des tests de charge et de performances à l’aide du niveau de service DW1000c (ou supérieur). Vous pouvez suspendre le calcul du pool SQL dédié à tout moment pour cesser la facturation de calcul, ce qui permet d’économiser sur les coûts.
Chargement de données
Une fois que vous avez configuré le pool SQL dédié, vous pouvez suivre ces étapes pour charger des données :
- Chargez les données dans Stockage Blob Azure. Pour une preuve de concept, nous vous recommandons d’utiliser un compte de stockage V2 à usage général avec un stockage localement redondant (LRS). Bien qu’il existe plusieurs outils pour migrer des données vers Stockage Blob Azure, le moyen le plus simple consiste à utiliser l’Explorateur Stockage Azure, qui peut copier des fichiers dans un conteneur de stockage.
- Chargez les données dans le pool SQL dédié. Azure Synapse prend en charge deux méthodes de chargement T-SQL : PolyBase et l’instruction COPY. Vous pouvez utiliser SSMS pour vous connecter au pool SQL dédié pour utiliser l’une ou l’autre méthode.
Lorsque vous chargez des données dans le pool SQL dédié pour la première fois, vous devez prendre en compte le modèle de distribution et l’option d’index à utiliser. Bien qu’un pool SQL dédié prenne en charge une variété des deux, il est recommandé de s’appuyer sur les paramètres par défaut. Les paramètres par défaut utilisent la distribution par tourniquet (round-robin) et un index columnstore en cluster. Si nécessaire, vous pouvez ajuster ces paramètres ultérieurement, comme décrit plus loin dans cet article.
L’exemple suivant montre la méthode de chargement COPY :
--Note when specifying the column list, input field numbers start from 1
COPY INTO
test_1 (Col_1 default 'myStringDefault' 1, Col_2 default 1 3)
FROM
'https://myaccount.blob.core.windows.net/myblobcontainer/folder1/'
WITH (
FILE_TYPE = 'CSV',
CREDENTIAL = (IDENTITY = 'Storage Account Key' SECRET = '<Your_Account_Key>'),
FIELDQUOTE = '"',
FIELDTERMINATOR = ',',
ROWTERMINATOR = '0x0A',
ENCODING = 'UTF8',
FIRSTROW = 2
);
Interrogation
L’objectif principal d’un entrepôt de données est d’effectuer des analyses, ce qui nécessite d’interroger l’entrepôt de données. La plupart des preuves de concept commencent par exécuter un petit nombre de requêtes représentatives sur l’entrepôt de données, d’abord séquentiellement, puis simultanément. Vous devez définir les deux approches dans votre plan de test.
Tests de requêtes séquentielles
Il est facile d’exécuter des tests de requêtes séquentielles dans SSMS. Il est important d’exécuter ces tests à l’aide d’un utilisateur avec une classe de ressource suffisamment grande. Les classes de ressources sont des limites de ressources prédéterminées dans un pool SQL dédié qui régissent les ressources de calcul et la concurrence lors de l’exécution des requêtes. Pour les requêtes simples, nous vous recommandons d’utiliser la classe de ressources staticrc20 prédéfinie. Pour les requêtes plus complexes, nous vous recommandons d’utiliser la classe de ressources staticrc40 prédéfinie.
Notez que la première requête suivante utilise une étiquette de requête pour fournir un mécanisme permettant de suivre la requête. La deuxième requête utilise la vue de gestion dynamique sys.dm_pdw_exec_requests pour rechercher en fonction de l’étiquette.
/* Use the OPTION(LABEL = '') Syntax to add a query label to track the query in DMVs */
SELECT TOP (1000)
*
FROM
[dbo].[Date]
OPTION (LABEL = 'Test1');
/* Use sys.dm_pdw_exec_requests to determine query execution duration (ms) */
SELECT
Total_elapsed_time AS [Elapsed_Time_ms],
[label]
FROM
sys.dm_pdw_exec_requests
WHERE
[label] = 'Test1';
Tests de requête simultanés
Après avoir enregistré les performances des requêtes séquentielles, vous pouvez ensuite exécuter plusieurs requêtes simultanément. De cette façon, vous pouvez simuler une charge de travail décisionnelle s’exécutant sur le pool SQL dédié. Le moyen le plus simple d’exécuter ce test consiste à télécharger un outil de test de contrainte. L’outil le plus populaire est Apache JMeter, qui est un outil open source tiers.
L’outil signale des durées de requête minimales, maximales et médianes pour un niveau d’accès concurrentiel donné. Par exemple, supposons que vous souhaitez simuler une charge de travail décisionnelle qui génère 100 requêtes simultanées. Vous pouvez configurer JMeter pour exécuter ces 100 requêtes simultanées dans une boucle, puis passer en revue l’exécution à l’état stable. Cela peut être effectué avec l’activation et la désactivation de la mise en cache du jeu de résultats pour évaluer la pertinence de cette fonctionnalité.
Veillez à documenter vos résultats. Voici un exemple de résultats :
| Accès concurrentiel | Nombre de requêtes exécutées | DWU | Durée minimale (s) | Durée maximale (s) | Durées médianes |
|---|---|---|---|---|---|
| 100 | 1 000 | 5 000 | 3 | 10 | 5 |
| 50 | 5 000 | 5 000 | 3 | 6 | 4 |
Tests de charge de travail mixtes
Les tests de charge de travail mixtes sont une extension des tests de requêtes simultanées. En ajoutant un processus de chargement de données dans la combinaison de charges de travail, la charge de travail simulera mieux une charge de travail de production réelle.
Optimiser les données
Selon la charge de travail de requête s’exécutant sur Azure Synapse, vous devrez peut-être optimiser les distributions et index de votre entrepôt de données et réexécuter les tests. Pour plus d’informations, consultez Meilleures pratiques pour les pools SQL dédiés dans Azure Synapse Analytics.
Les erreurs les plus courantes observées lors de la configuration sont les suivantes :
- Les requêtes volumineuses s’exécutent avec une classe de ressources trop faible.
- Les DWU de niveau de service de pool SQL dédiés sont trop faibles pour la charge de travail.
- Les tables volumineuses nécessitent une distribution de hachage.
Pour améliorer les performances des requêtes, vous pouvez :
- Créez des vues matérialisées, ce qui peut accélérer les requêtes impliquant des agrégations courantes.
- Répliquez des tables, en particulier pour les petites tables de dimension.
- Distribuez le hachage des tables de faits volumineuses jointes ou agrégées.
Tests à valeur ajoutée
Une fois les tests de performances des requêtes terminés, il est judicieux de tester des fonctionnalités spécifiques pour vérifier qu’elles répondent à vos cas d’usage prévus. Voici quelques fonctionnalités :
- Sécurité au niveau des lignes
- Sécurité au niveau des colonnes
- Masquage des données dynamiques
- Mise à l’échelle intra-cluster via l’isolation de charge de travail
Enfin, vous devez interpréter les résultats de votre preuve de concept.
Interpréter les résultats de la preuve de concept
Une fois que vous avez des résultats de test pour votre entrepôt de données, il est important d’interpréter ces données. Une approche courante consiste à comparer les exécutions en termes de prix/performances. En d’autres termes, les prix/performances suppriment les différences de prix par DWU ou matériel de service et fournissent un chiffre comparable unique pour chaque test de performances.
Voici un exemple :
| Test | Durée du test | DWU | $/hr pour DWU | Coût du test |
|---|---|---|---|---|
| Test 1 | 10 min | 1 000 | 12 $/h | 2 $ |
| Test 2 | 30 min | 500 | 6 $/h | 3 $ |
Cet exemple permet de voir facilement que le test 1 à DWU1000 est plus rentable à 2 $ par série de tests par rapport à 3 $ par série de tests.
Notes
Vous pouvez également utiliser cette méthodologie pour comparer les résultats entre fournisseurs dans une preuve de concept.
En résumé, une fois que vous avez terminé tous les tests de preuve de concept, vous êtes prêt à évaluer les résultats. Commencez par évaluer si les objectifs de la preuve de concept ont été atteints et les résultats souhaités collectés. Notez l’endroit où des tests supplémentaires sont justifiés et les questions supplémentaires qui ont été soulevées.
Étapes suivantes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour