Partager via


Guide opérationnel de preuve de concept Synapse : Exploration du lac de données avec un pool SQL serverless 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 serverless.

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.

Préparer la preuve de concept

Un projet de preuve de concept peut vous aider à prendre une décision métier éclairée sur l’implémentation d’un environnement Big Data et d’analytique avancée sur une plateforme basée sur le cloud qui tire parti du pool SQL serverless dans Azure Synapse. Si vous devez explorer les données du lac de données, obtenir des insights à partir de celles-ci ou optimiser votre pipeline de transformation de données existant, vous pouvez tirer parti de l’utilisation du pool SQL serverless. Il convient aux scénarios suivants :

  • Découverte et exploration de base : comprenez rapidement les données de différents formats (Parquet, CSV, JSON) stockées dans votre lac de données, afin de planifier l’extraction d’insights à partir de celles-ci.
  • Entrepôt de données logique : produisez une abstraction relationnelle pour les données brutes ou disparates, sans déplacer ni transformer ces données, afin de toujours avoir une vue de vos données qui soit actuelle.
  • Transformation des données : Exécutez des requêtes de lac de données simples, évolutives et hautement performantes à l’aide de T-SQL. Vous pouvez alimenter les résultats des requêtes vers des outils décisionnels (BI) ou les charger dans une base de données relationnelle. Les systèmes cibles peuvent inclure des pools SQL dédiés Azure Synapse ou Azure SQL Database.

Différents rôles professionnels peuvent tirer parti du pool SQL serverless :

  • Les ingénieurs des données peuvent explorer le lac, transformer et préparer les données à l’aide de ce pool SQL serverless, et simplifier leurs pipelines de transformation des données.
  • Les scientifiques des données peuvent rapidement raisonner sur le contenu et la structure des données stockées dans le lac de données à l’aide de la fonction T-SQL OPENROWSET et de son inférence automatique de schéma.
  • Les analystes de données peuvent écrire des requêtes T-SQL dans leurs outils de requête préférés, qui peuvent se connecter à un pool SQL serverless. Ils peuvent explorer des données dans des tables externes Spark qui ont été créées par des scientifiques des données ou des ingénieurs de données.
  • Les professionnels du décisionnel peuvent créer rapidement des rapports Power BI qui se connectent à des tables Data Lake ou Spark.

Un projet de preuve de concept de pool SQL serverless identifie vos principaux objectifs et pilotes métier que le pool SQL serverless est conçu pour prendre en charge. Il teste également les fonctionnalités clés et collecte des métriques pour prendre en charge vos décisions d’implémentation. Une preuve de concept n’est pas conçue pour être déployée dans un environnement de production. Il s’agit plutôt d’un projet à court terme qui se concentre sur les questions clés, et son résultat peut être ignoré.

Avant de commencer à planifier votre projet de preuve de concept de pool SQL serverless :

  • Identifiez les restrictions ou recommandations que votre organisation a quant au déplacement de données vers le cloud.
  • Identifiez les commanditaires exécutifs ou commerciaux pour un projet de plateforme d’analytique avancée et de Big Data. Assurez leur soutien envers la migration vers le cloud.
  • Identifiez la disponibilité des experts techniques et des utilisateurs professionnels pour vous aider pendant l’exécution de la preuve de concept.

Avant de commencer à préparer le projet de preuve de concept, nous vous recommandons de lire d’abord la Documentation du pool SQL serverless.

Conseil

Si vous débutez avec les pools SQL serverless, nous vous recommandons de consulter le parcours d’apprentissage Créer des solutions d’analytique des données à l’aide des pools SQL serverless Azure Synapse.

Définir les objectifs

Un projet de preuve de concept réussi nécessite une planification. Commencez par identifier pourquoi vous faites une preuve de concept pour comprendre pleinement les motivations réelles. Les motivations peuvent inclure la modernisation, l’économie de coûts, l’amélioration des performances ou l’expérience intégrée. Veillez à documenter des objectifs clairs pour votre preuve de concept et les critères qui définissent sa réussite. Posez-vous les questions suivantes :

  • Que voulez-vous en tant que résultats de votre preuve de concept ?
  • Qu’allez-vous faire avec ces résultats ?
  • Qui utilisera les résultats ?
  • Qu’est-ce qui définira une preuve de concept réussie ?

Gardez à l’esprit qu’une preuve de concept doit être un effort court et ciblé pour prouver rapidement un ensemble limité de concepts et de fonctionnalités. Ces concepts et fonctionnalités doivent être représentatifs de la charge de travail globale. Si vous avez une longue liste d’éléments à prouver, vous pouvez planifier plusieurs preuves de concept. Dans ce cas, définissez des portes entre les preuves de concept pour déterminer si vous devez continuer avec la suivante. Étant donné les différents rôles professionnels qui peuvent utiliser un pool SQL serverless (et les différents scénarios pris en charge par le pool SQL serverless), vous pouvez choisir d’exécuter plusieurs preuves de concept. Par exemple, une preuve de concept peut se concentrer sur les exigences du rôle scientifique des données, comme la découverte et l’exploration des données dans différents formats. Une autre peut se concentrer sur les exigences du rôle d’ingénierie des données, comme la transformation des données et la création d’un entrepôt de données logique.

Lorsque vous considérez vos objectifs de preuve de concept, posez-vous les questions suivantes pour vous aider à façonner les objectifs :

  • Effectuez-vous une migration à partir d’une plateforme Big Data et d’analytique avancée existante (locale ou cloud) ?
  • Effectuez-vous la migration, mais souhaitez apporter autant de modifications que possible aux fonctions de traitement des données et d’ingestion existantes ?
  • Vous effectuez une migration, mais souhaitez apporter des améliorations significatives au passage ?
  • Créez-vous une plateforme d’analytique avancée et de Big Data entièrement nouvelle (projet greenfield) ?
  • Quelles sont vos difficultés actuelles ? Par exemple, l’extensibilité, les performances ou la flexibilité.
  • Quelles nouvelles exigences métier devez-vous prendre en charge ?
  • Quels sont les contrats SLA que vous devez respecter ?
  • Quelles seront les charges de travail ? Par exemple, l’exploration des données sur différents formats de données, l’exploration de base, un entrepôt de données logique, la préparation et/ou la transformation des données, l’analyse interactive T-SQL, l’interrogation T-SQL des tables Spark ou la création de rapports sur le lac de données.
  • Quelles sont les compétences des utilisateurs qui seront propriétaires du projet (la preuve de concept doit-elle être implémentée) ?

Voici quelques exemples de définition d’objectif de preuve de concept :

  • Pourquoi faisons-nous une preuve de concept ?
    • Nous devons savoir si nous pouvons explorer tous les formats de fichier brut que nous stockons à l’aide du pool SQL serverless.
    • Nous devons savoir si nos ingénieurs de données peuvent rapidement évaluer de nouveaux flux de données.
    • Nous devons savoir si les performances des requêtes de lac de données à l’aide d’un pool SQL serverless répondent à nos besoins en matière d’exploration de données.
    • Nous devons savoir si le pool SQL serverless est un bon choix pour certaines de nos visualisations et exigences de création de rapports.
    • Nous devons savoir si le pool SQL serverless est un bon choix pour certaines de nos exigences en matière d’ingestion et de traitement des données.
    • Nous devons savoir si notre passage à Azure Synapse respectera notre budget.
  • À la fin de cette preuve de concept :
    • Nous aurons les données pour identifier les transformations de données qui sont bien adaptées au pool SQL serverless.
    • Nous aurons les données pour identifier quand le pool SQL serverless peut être utilisé le mieux pendant la visualisation des données.
    • Nous aurons les données pour connaître la facilité avec laquelle nos ingénieurs de données et scientifiques des données peuvent adopter la nouvelle plateforme.
    • Nous aurons acquis des insights pour mieux estimer l’effort nécessaire pour terminer l’implémentation ou le projet de migration.
    • Nous aurons une liste d’éléments qui peuvent nécessiter plus de tests.
    • Notre preuve de concept réussit si nous avons les données nécessaires et que nous avons terminé les tests identifiés pour déterminer comment le pool SQL serverless prendra en charge notre plateforme de Big Data et d’analytique avancée basée sur le cloud.
    • Nous aurons déterminé si nous pouvons passer à la phase suivante ou si d’autres tests de preuve de concept sont nécessaires pour finaliser notre décision.
    • Nous serons en mesure de prendre une décision professionnelle saine soutenue par des points de données spécifiques.

Planifier le projet

Utilisez vos objectifs pour identifier des tests spécifiques et fournir les résultats que vous avez 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 également les tâches spécifiques d’exploration et d’analyse des données, les transformations spécifiques et le traitement existant spécifique que vous souhaitez tester. Identifiez un jeu de données et un codebase spécifiques que vous pouvez utiliser.

Voici un exemple du niveau de spécificité nécessaire dans la planification :

  • Objectif : Nous devons savoir si les ingénieurs de données peuvent obtenir le traitement équivalent du processus ETL existant nommé « Validation en lot quotidienne de fichiers bruts » dans le contrat SLA requis.
  • Résultat : Nous aurons les données pour déterminer si nous pouvons utiliser des requêtes T-SQL pour exécuter le processus ETL « Validation en lot quotidienne de fichiers bruts » dans le contrat SLA requis.
  • Test : Les requêtes de validation A, B et C sont identifiées par l’ingénierie des données et représentent les besoins globaux en matière de traitement des données. Comparez les performances de ces requêtes avec la référence obtenue à partir du système existant.

Évaluer le jeu de données de la preuve de concept

À l’aide des tests spécifiques que vous avez identifiés, sélectionnez un jeu de données pour prendre en charge les tests. Prenez le temps de passer en revue ce jeu de données. Vous devez vérifier que le jeu de données représentera correctement votre traitement futur en termes de contenu, de complexité et d’échelle. N’utilisez pas un jeu de données trop petit, car il ne fournira pas de performances représentatives. À l’inverse, n’utilisez pas de jeu de données trop volumineux, car la preuve de concept ne doit pas devenir une migration complète des données. Veillez à obtenir les références appropriées des systèmes existants afin de pouvoir les utiliser pour les comparaisons de performances.

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.

Créer une architecture de haut niveau

En fonction de l’architecture de haut niveau de votre architecture d’état futur proposée, identifiez les composants qui feront partie de votre preuve de concept. Votre architecture d’état futur de haut niveau contient probablement de nombreuses sources de données, de nombreux consommateurs de données, des composants Big Data, et éventuellement des consommateurs de données de Machine Learning et d’intelligence artificielle (IA). Votre architecture de preuve de concept doit identifier spécifiquement les composants qui feront partie de la preuve de concept. Elle doit surtout identifier tous les composants qui ne feront pas partie du test de preuve de concept.

Si vous utilisez déjà Azure, identifiez les ressources que vous avez déjà en place (Microsoft Entra ID, ExpressRoute et autres) que vous pouvez utiliser pendant la preuve de concept. Identifiez également les régions Azure que votre organisation utilise. Il est maintenant très utile d’identifier le débit de votre connexion ExpressRoute et de vérifier auprès d’autres utilisateurs professionnels que votre preuve de concept peut consommer une partie de ce débit sans impact négatif sur les systèmes de production.

Identifier les ressources de preuve de concept

Identifiez spécifiquement les ressources techniques et les engagements en temps nécessaires pour prendre en charge votre preuve de concept. Votre preuve de concept aura besoin de ce qui suit :

  • Représentant de l’entreprise pour superviser les exigences et les résultats.
  • Un expert en données d’application, pour approvisionner les données de la preuve de concept et fournir des connaissances sur les processus et la logique existants.
  • Un expert en pools SQL serverless.
  • Un conseiller expert, pour optimiser les tests de preuve de concept.
  • Les ressources qui seront requises pour des composants spécifiques de votre projet de preuve de concept, mais pas nécessairement requises pour la durée de la preuve de concept. Ces ressources peuvent inclure des administrateurs réseau, des administrateurs Azure, des administrateurs Active Directory, des administrateurs du portail Azure et d’autres.
  • Vérifiez que toutes les ressources des services Azure requis sont approvisionnées et que le niveau d’accès requis est accordé, y compris l’accès aux comptes de stockage.
  • Vérifiez que vous disposez d’un compte disposant des autorisations d’accès aux données nécessaires pour récupérer des données de toutes les sources de données dans l’étendue de la preuve de concept.

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.

Définir la chronologie

Passez en revue vos détails de planification et vos besoins métier pour identifier un délai d’exécution pour votre preuve de concept. Faites des estimations réalistes du temps nécessaire pour atteindre les objectifs de la preuve de concept. Le temps d’exécution de votre preuve de concept sera influencé par la taille de votre jeu de données de preuve de concept, le nombre et la complexité des tests, ainsi que le nombre d’interfaces à tester. Si vous estimez que votre preuve de concept s’exécutera sur plus de quatre semaines, envisagez de réduire l’étendue de la preuve de concept pour vous concentrer sur les objectifs prioritaires. Veillez à obtenir l’approbation et l’engagement de toutes les ressources et de tous les commanditaires principaux avant de continuer.

Mettre la preuve de concept en pratique

Nous vous recommandons d’exécuter votre projet de preuve de concept avec la discipline et la rigueur de tout projet de production. Exécutez le projet conformément au plan et gérez un processus de demande de modification pour empêcher la croissance non contrôlée de l’étendue de la preuve de concept.

Voici quelques exemples de tâches de haut niveau :

  1. Créer un espace de travail Synapse, des comptes de stockage et les ressources Azure identifiées dans le plan de preuve de concept.
  2. Configurez la mise en réseau et la sécurité en fonction de vos besoins.
  3. Accordez l’accès approprié aux membres de l’équipe de preuve de concept. Consultez cet article sur les autorisations d’accès aux fichiers directement à partir du Stockage Azure.
  4. Chargez le jeu de données de la preuve de concept.
  5. Implémentez et configurez les tests et/ou migrez le code existant vers des scripts et vues de pool SQL serverless.
  6. Exécutez les tests :
    • De nombreux tests peuvent être exécutés en parallèle.
    • Enregistrez vos résultats dans un format consommable et facilement compréhensible.
  7. Surveillez la résolution des problèmes et les performances.
  8. Évaluez vos résultats et présentez-les.
  9. Collaborez avec les parties prenantes techniques et l’entreprise pour planifier l’étape suivante du projet. L’étape suivante peut être une preuve de concept de suivi ou une implémentation de production.

Interpréter les résultats de la preuve de concept

Lorsque vous avez terminé tous les tests de preuve de concept, vous évaluez les résultats. Commencez par évaluer si les objectifs de la preuve de concept ont été atteints et si les résultats souhaités ont été collectés. Déterminez si des tests supplémentaires sont nécessaires ou si des questions doivent être posées.

Étapes suivantes