Méthodologie de réussite de l’implémentation de Synapse : Évaluer la conception de pool SQL serverless

Notes

Cet article fait partie de la série Réussite de l’implémentation d’Azure Synapse par conception. Pour obtenir une vue d’ensemble de la série, consultez Réussite de l’implémentation d’Azure Synapse par conception.

Vous devez évaluer la conception de votre pool SQL serverless pour identifier les problèmes et vérifier qu’il répond aux instructions et exigences. En évaluant la conception avant le début du développement de la solution, vous pouvez éviter les blocages et les modifications de conception inattendues. De cette façon, vous assurez le calendrier et le budget du projet.

La séparation architecturale du stockage et du calcul pour les données modernes, les plateformes analytiques et les services est une tendance et il s’agit d’un modèle fréquemment utilisé. Elle offre des économies et une plus grande flexibilité permettant une mise à l’échelle indépendante à la demande de votre stockage et de votre calcul. Synapse SQL serverless étend ce modèle en ajoutant la possibilité d’interroger directement vos données de lac de données. Il n’est pas nécessaire de vous soucier de la gestion du calcul lors de l’utilisation de types de charges de travail en libre-service.

Ajuster l’analyse des écarts

Lorsque vous envisagez d’implémenter des pools SQL serverless dans Azure Synapse, vous devez d’abord vous assurer que les pools serverless sont adaptés à vos charges de travail. Vous devez envisager l’excellence opérationnelle, l’efficacité des performances, la fiabilité et la sécurité.

Excellence opérationnelle

Pour une excellence opérationnelle, évaluez les points suivants.

• Environnement de développement de solutions : Dans cette méthodologie, il existe une évaluation de l’environnement de développement de solution. Identifiez la façon dont les environnements (développement, test et production) sont conçus pour prendre en charge le développement de solutions. En règle générale, vous trouverez un environnement de production et un environnement hors production (pour le développement et le test). Vous devez trouver des espaces de travail Synapse dans tous les environnements. Dans la plupart des cas, vous devrez séparer vos utilisateurs et charges de travail de production et de développement/test.
• Conception de l’espace de travail Synapse : Dans cette méthodologie, il existe une évaluation de la conception de l’espace de travail Synapse. Identifiez la façon dont les espaces de travail ont été conçus pour votre solution. Familiarisez-vous avec la conception et déterminez si la solution utilisera un seul espace de travail ou si plusieurs espaces de travail font partie de la solution. Sachez pourquoi une conception d’espace de travail unique ou multiple a été choisie. Une conception multi-espace de travail est souvent choisie pour appliquer des limites de sécurité strictes.
• Déploiement : SQL serverless est disponible à la demande avec chaque espace de travail Synapse, ce qui ne nécessite aucune action de déploiement particulière. Vérifiez la proximité régionale du service et celle du compte Azure Data Lake Storage Gen2 (ADLS Gen2) auquel il est connecté.
• Surveillance : Vérifiez si la surveillance intégrée est suffisante et si des services externes doivent être mis en place pour stocker les données de journal historiques. Les données de journal permettent d’analyser les changements de performances et de définir des actions d’alerte ou déclenchées pour des circonstances spécifiques.

Efficacité des performances

Contrairement aux moteurs de base de données traditionnels, SQL serverless ne s’appuie pas sur sa propre couche de stockage optimisée. Pour cette raison, ses performances dépendent fortement de la façon dont les données sont organisées dans ADLS Gen2. Pour améliorer l’efficacité des performances, évaluez les points suivants.

• Ingestion des données : Passez en revue la façon dont les données sont stockées dans le lac de données. Les tailles de fichier, le nombre de fichiers et la structure de dossiers ont tous un impact sur les performances. Gardez à l’esprit que même si certaines tailles de fichier peuvent fonctionner pour SQL serverless, elles peuvent poser des problèmes d’efficacité pour le traitement ou la consommation par d’autres moteurs ou applications. Vous devez évaluer la conception du stockage de données et la valider par rapport à tous les consommateurs de données, y compris SQL serverless et tous les autres outils de données qui font partie de votre solution.
• Placement des données : Déterminez si votre conception a des modèles communs unifiés et définis pour le placement des données. Assurez-vous que l’embranchement d’annuaire peut prendre en charge vos exigences de sécurité. Il existe quelques modèles courants qui peuvent vous aider à organiser vos données de série chronologique. Quel que soit votre choix, assurez-vous qu’il fonctionne également avec d’autres moteurs et charges de travail. Vérifiez également s’il peut vous aider à partitionner la découverte automatique pour les applications Spark et les tables externes.
• Formats de données : Dans la plupart des cas, SQL serverless offre les meilleures performances et la meilleure compatibilité en utilisant un format Parquet. Vérifiez vos exigences en matière de performances et de compatibilité, car bien que Parquet améliore les performances, grâce à une meilleure compression et à une réduction des E/S (en lisant uniquement les colonnes requises pour l’analyse), il nécessite davantage de ressources de calcul. En outre, étant donné que certains systèmes sources ne prennent pas en charge Parquet en tant que format d’exportation, cela peut entraîner des étapes de transformation supplémentaires dans vos pipelines et/ou dépendances dans votre architecture globale.
• Exploration : Chaque secteur est différent. Toutefois, dans de nombreux cas, il existe des modèles d’accès aux données courants trouvés dans les requêtes les plus fréquentes. Les modèles impliquent généralement un filtrage et des agrégations par dates, catégories ou régions géographiques. Identifiez vos critères de filtrage les plus courants et associez-les à la quantité de données lues/ignorées par les requêtes les plus fréquentes. Vérifiez si les informations sur le lac de données sont organisées pour favoriser vos exigences et attentes en matière d’exploration. Pour les requêtes identifiées dans votre conception et dans votre évaluation, vérifiez si vous pouvez éliminer les partitions inutiles dans votre paramètre de chemin OPENROWSET, ou (s’il existe des tables externes) si la création d’index supplémentaires peut vous aider.

Fiabilité

Pour une meilleure fiabilité, évaluez les points suivants.

• Disponibilité : Validez les exigences de disponibilité identifiées pendant la phase d’évaluation. Bien qu’il n’y ait aucun contrat SLA spécifique pour SQL serverless, il existe un délai d’expiration de 30 minutes pour l’exécution des requêtes. Identifiez les requêtes les plus longues à partir de votre évaluation et validez-les par rapport à votre conception SQL serverless. Un délai d’expiration de 30 minutes peut nuire aux attentes de votre charge de travail et apparaître en tant que problème de service.
• Cohérence : SQL serverless est conçu principalement pour les charges de travail de lecture. Vérifiez donc si toutes les vérifications de cohérence ont été effectuées pendant le processus d’approvisionnement et de formation du lac de données. Tenez compte des nouvelles fonctionnalités, par exemple la couche de stockage open source Delta Lake qui assure la prise en charge des garanties ACID (atomicité, cohérence, isolation et durabilité) pour les transactions. Cette fonctionnalité vous permet d’implémenter des architectures lambda ou kappa efficaces pour prendre en charge les cas d’usage de diffusion en continu et de traitement par lots. Veillez à évaluer votre conception pour les opportunités d’appliquer de nouvelles fonctionnalités, mais pas au détriment du calendrier ou du coût de votre projet.
• Sauvegarde : Passez en revue les exigences de récupération d’urgence identifiées lors de l’évaluation. Validez-les par rapport à votre conception SQL serverless pour la récupération. SQL serverless lui-même n’a pas sa propre couche de stockage, ce qui nécessiterait la gestion des captures instantanées et des copies de sauvegarde de vos données. Le magasin de données accessible par SQL serverless est externe (ADLS Gen2). Passez en revue la conception de récupération dans votre projet pour ces jeux de données.

Sécurité

L’organisation de vos données est importante pour créer des bases de sécurité flexibles. Dans la plupart des cas, différents processus et utilisateurs nécessitent différentes autorisations et accès à des sous-zones spécifiques de votre lac de données ou de votre entrepôt de données logique.

Pour la sécurité, évaluez les points suivants.

• Stockage de données : À l’aide des informations collectées au cours de la phase d’évaluation, identifiez si les zones de lac de données brutes, intermédiaires et organisées classiques doivent être placées sur le même compte de stockage plutôt que des comptes de stockage indépendants. Cette dernière option peut offrir une plus grande flexibilité en termes de rôles et d’autorisations. Elle peut également ajouter d’autres opérations d’entrée/sortie par seconde (IOPS) qui peuvent être nécessaires si votre architecture doit prendre en charge des charges de travail de lecture/écriture lourdes et simultanées (comme les scénarios en temps réel ou IoT). Vérifiez si vous devez séparer davantage en conservant vos zones de données bac à sable et de référence sur des comptes de stockage distincts. La plupart des utilisateurs n’auront pas besoin de mettre à jour ou de supprimer des données. Ils n’ont donc pas besoin d’autorisations d’écriture sur le lac de données, à l’exception des zones de bac à sable et privées.
• À partir de vos informations d’évaluation, identifiez si des exigences s’appuient sur des fonctionnalités de sécurité comme Always Encrypted, le masquage dynamique des données ou la sécurité au niveau des lignes. Validez la disponibilité de ces fonctionnalités dans des scénarios spécifiques, comme lorsqu’elles sont utilisées avec la fonction OPENROWSET. Anticipez les solutions de contournement potentielles qui peuvent être requises.
• À partir de vos informations d’évaluation, identifiez les meilleures méthodes d’authentification. Considérez les principaux de service Microsoft Entra, la signature d’accès partagé (SAP) ainsi que quand et comment l’authentification directe peut être utilisée et intégrée dans l’outil d’exploration choisi par le client. Évaluez la conception et validez la meilleure méthode d’authentification dans le cadre de la conception.

Autres considérations

Passez en revue votre conception et vérifiez si vous avez mis en place les meilleures pratiques et recommandations. Accordez une attention particulière à l’optimisation et au classement des filtres pour vous assurer que la poussée de prédicats fonctionne correctement.

Étapes suivantes

Dans l’article suivant de la série Réussite d’Azure Synapse par conception, découvrez comment évaluer la conception de votre pool Spark pour identifier les problèmes et valider qu’elle répond aux instructions et exigences.