Méthodologie de réussite de l’implémentation synapse : Évaluer l’environnement

La première étape lors de l’implémentation d’Azure Synapse Analytics consiste à effectuer une évaluation de votre environnement. Une évaluation vous offre la possibilité de recueillir toutes les informations disponibles sur votre environnement existant, les exigences environnementales, les exigences relatives aux projets, les contraintes, les chronologies et les points de douleur. Ces informations constituent la base des évaluations et des activités de point de contrôle ultérieures. Il s’avère inestimable quand il est temps de valider et de comparer la solution de projet à mesure qu’elle est planifiée, conçue et développée. Nous vous recommandons de consacrer un bon temps pour recueillir toutes les informations et être sûr d’avoir des discussions nécessaires avec des groupes pertinents. Les groupes pertinents peuvent inclure les parties prenantes du projet, les utilisateurs professionnels, les concepteurs de solutions et les experts en matière (PME) de la solution et de l’environnement existants.

L’évaluation deviendra un guide pour vous aider à évaluer la conception de la solution et à formuler des recommandations technologiques éclairées pour implémenter Azure Synapse.

Évaluation de la charge de travail

L’évaluation de la charge de travail concerne l’environnement, les rôles de charge de travail analytiques, ETL/ELT, la mise en réseau et la sécurité, l’environnement Azure et la consommation de données.

Environnement

Pour l’environnement, évaluez les points suivants.

• Décrire votre charge de travail analytique existante :
  • Quelles sont les charges de travail (telles que l’entrepôt de données ou le Big Data) ?
  • Comment cette charge de travail aide-t-elle l’entreprise ? Quels sont les scénarios de cas d’usage ?
  • Quel est le moteur métier pour cette plateforme analytique et pour la migration potentielle ?
  • Rassemblez des détails sur les choix d’architecture, de conception et d’implémentation existants.
  • Rassemblez des détails sur tous les composants et consommateurs dépendants en amont et en aval existants.
• Migrez-vous un entrepôt de données existant (comme Microsoft SQL Server, Microsoft Analytics Platform System (APS), Netezza, Snowflake ou Teradata ?
• Migrez-vous une plateforme Big Data (comme Cloudera ou Hortonworks) ?
• Rassemblez les diagrammes d’architecture et de flux de données pour l’environnement analytique actuel.
• Où se trouvent les sources de données de vos charges de travail analytiques planifiées (Azure, d’autres fournisseurs de cloud ou locaux) ?
• Quelle est la taille totale des jeux de données existants (historique et incrémentiel) ? Quel est le taux actuel de croissance de vos jeux de données ? Quel est le taux de croissance prévu de vos jeux de données pour les 2 à 5 prochaines années ?
• Avez-vous un lac de données existant ? Rassemblez autant de détails que possible sur les types de fichiers (comme Parquet ou CSV), les tailles de fichier et la configuration de sécurité.
• Avez-vous des données semi-structurées ou non structurées pour traiter et analyser ?
• Décrire la nature du traitement des données (traitement par lots ou en temps réel).
• Avez-vous besoin d’une exploration interactive des données à partir de données relationnelles, de lac de données ou d’autres sources ?
• Avez-vous besoin d’une analyse et d’une exploration de données en temps réel à partir de sources de données opérationnelles ?
• Quels sont les points de douleur et les limitations dans l’environnement actuel ?
• Quels sont les outils de contrôle de code source et DevOps que vous utilisez aujourd’hui ?
• Avez-vous un cas d’usage pour créer une solution analytique hybride (cloud et locale), cloud uniquement ou multicloud ?
• Rassemblez des informations sur l’environnement cloud existant. S’agit-il d’un fournisseur à cloud unique ou d’un fournisseur multicloud ?
• Rassemblez des plans sur l’environnement cloud futur. Est-ce qu’il s’agit d’un fournisseur à cloud unique ou d’un fournisseur multicloud ?
• Quelles sont les exigences RPO/RTO/HA/SLA dans l’environnement existant ?
• Quelles sont les exigences RPO/RTO/HA/SLA dans l’environnement planifié ?

Rôles liés à la charge de travail analytique

Pour les rôles de charge de travail analytique, évaluez les points suivants.

• Décrire les différents rôles (scientifique des données, ingénieur données, analyste de données et autres).
• Décrivez l’exigence de contrôle d’accès de la plateforme analytique pour ces rôles.
• Identifiez le propriétaire de la plateforme responsable de l’approvisionnement des ressources de calcul et accordez l’accès.
• Décrivez comment les différents rôles de données collaborent actuellement.
• Existe-t-il plusieurs équipes qui collaborent sur la même plateforme analytique ? Si c’est le cas, quelles sont les exigences de contrôle d’accès et d’isolation pour chacune de ces équipes ?
• Quels sont les outils clients que les utilisateurs finaux utilisent pour interagir avec la plateforme analytique ?

ETL/ELT, transformation et orchestration

Pour ETL/ELT, transformation et orchestration, évaluez les points suivants.

• Quels outils utilisez-vous aujourd’hui pour l’ingestion de données (ETL ou ELT) ?
• Où ces outils existent-ils dans l’environnement existant (local ou cloud) ?
• Quelles sont vos exigences actuelles en matière de chargement et de mise à jour des données (temps réel, micro batch, horaire, quotidien, hebdomadaire ou mensuel) ?
• Décrivez les exigences de transformation pour chaque couche (Big Data, Data Lake, entrepôt de données).
• Quelle est l’approche de programmation actuelle pour transformer les données (sans code, faible code, programmation comme SQL, Python, Scala, C# ou autre) ?
• Quelle est l’approche de programmation planifiée préférée pour transformer les données (sans code, faible code, programmation comme SQL, Python, Scala, C# ou autre) ?
• Quels outils sont actuellement utilisés pour l’orchestration des données afin d’automatiser le processus piloté par les données ?
• Où se trouvent les sources de données pour votre ETL existant (Azure, d’autres fournisseurs de cloud ou locaux) ?
• Quels sont les outils de consommation de données existants (rapports, outils décisionnels, outils open source) qui nécessitent une intégration à la plateforme analytique ?
• Quels sont les outils de consommation de données planifiés (rapports, outils décisionnels, outils open source) qui nécessitent une intégration à la plateforme analytique ?

Le réseau et la sécurité

Pour la mise en réseau et la sécurité, évaluez les points suivants.

• Quelles exigences réglementaires avez-vous pour vos données ?
• Si vos données contiennent du contenu client, de l’industrie des cartes de paiement (PCI) ou de la Loi sur la portabilité et la responsabilité d’assurance maladie de 1996 (HIPAA), votre groupe de sécurité a-t-il certifié Azure pour ces données ? Si c’est le cas, pour quels services Azure ?
• Décrivez vos exigences d’autorisation et d’authentification utilisateur.
• Existe-t-il des problèmes de sécurité qui peuvent limiter l’accès aux données pendant l’implémentation ?
• Existe-t-il des données de test disponibles pour l’utilisation pendant le développement et le test ?
• Décrivez les exigences de sécurité réseau de l’organisation sur le calcul et le stockage analytiques (réseau privé, réseau public ou restrictions de pare-feu).
• Décrivez les exigences de sécurité réseau pour les outils clients pour l’accès au calcul analytique et au stockage (réseau homologue, point de terminaison privé ou autre).
• Décrivez la configuration réseau actuelle entre local et Azure (Azure ExpressRoute, site à site ou autre).

Utilisez les listes de contrôle suivantes des exigences possibles pour guider votre évaluation.

• Protection des données :
  • Chiffrement en transit
  • Chiffrement au repos (clés par défaut ou clés gérées par le client)
  • Découverte et classification des données
• Contrôle d’accès :
  • Sécurité au niveau des objets
  • Sécurité au niveau des lignes
  • Sécurité au niveau des colonnes
  • Masquage dynamique des données
• Authentication:
  • Connexion SQL
  • Microsoft Entra ID (système d'identification de Microsoft)
  • Authentification multifacteur (MFA)
• Sécurité réseau :
  • Réseaux virtuels
  • Firewall
  • Azure ExpressRoute
• Protection contre les menaces :
  • Détection de menaces
  • Auditing
  • Évaluation des vulnérabilités

Pour plus d’informations, consultez le livre blanc de sécurité Azure Synapse Analytics.

Environnement Azure

Pour l’environnement Azure, évaluez les points suivants.

• Utilisez-vous actuellement Azure ? Est-il utilisé pour les charges de travail de production ?
• Si vous utilisez Azure, quels services utilisez-vous ? Quelles régions utilisez-vous ?
• Utilisez-vous Azure ExpressRoute ? Quelle est sa bande passante ?
• Disposez-vous d’une approbation budgétaire pour approvisionner les services Azure requis ?
• Comment provisionnez-vous et gérez-vous actuellement des ressources (Azure Resource Manager (ARM) ou Terraform ?
• Votre équipe clé est-elle familiarisée avec Synapse Analytics ? Une formation est-elle requise ?

Consommation de données

Pour la consommation de données, évaluez les points suivants.

• Décrivez comment et quels outils vous utilisez actuellement pour effectuer des activités telles que l’ingestion, l’exploration, la préparation et la visualisation des données.
• Identifiez les outils que vous envisagez d’utiliser pour effectuer des activités telles que l’ingestion, l’exploration, la préparation et la visualisation des données.
• Quelles applications sont planifiées pour interagir avec la plateforme analytique (Microsoft Power BI, Microsoft Excel, Microsoft SQL Server Reporting Services, Tableau ou d’autres) ?
• Identifiez tous les consommateurs de données.
• Identifiez les exigences en matière d’exportation et de partage de données.

Évaluation des services Azure Synapse

L’évaluation des services Azure Synapse concerne les services dans Azure Synapse. Azure Synapse a les composants suivants pour le calcul et le déplacement des données :

• Synapse SQL : Système de requête distribué pour Transact-SQL (T-SQL) qui permet l’entreposage de données et les scénarios de virtualisation des données. Il étend également T-SQL pour traiter les scénarios de streaming et de Machine Learning (ML). Synapse SQL offre des modèles de ressources serverless et dédiés .
• Pool SQL sans serveur : Un système de traitement des données distribué, conçu pour les fonctions de données et de calcul à grande échelle. Il n'existe aucune infrastructure à configurer ni clusters à maintenir. Ce service est adapté aux charges de travail non planifiées ou en rafale. Les scénarios recommandés incluent l’exploration rapide des données sur les fichiers directement sur le lac de données, l’entrepôt de données logique et la transformation des données brutes.
• Pool SQL dédié : Représente une collection de ressources analytiques approvisionnées lors de l’utilisation de Synapse SQL. La taille d’un pool SQL dédié (anciennement SQL DW) est déterminée par les unités d’entreposage de données (DWU). Ce service est adapté à un entrepôt de données avec des charges de travail continues prévisibles et hautes performances sur les données stockées dans des tables SQL. 
• Pool Apache Spark : Intègre profondément et en toute transparence Apache Spark, qui est le moteur Big Data open source le plus populaire utilisé pour la préparation des données, l’ingénierie des données, ETL et ML.
• Pipelines d’intégration de données : Azure Synapse contient le même moteur d’intégration de données et les mêmes expériences qu’Azure Data Factory (ADF). Ils vous permettent de créer des pipelines ETL à grande échelle sans quitter Azure Synapse.

Pour déterminer le meilleur type de pool SQL (dédié ou serverless), évaluez les points suivants.

• Voulez-vous créer un entrepôt de données relationnelle traditionnel en réservant la puissance de traitement des données stockées dans des tables SQL ?
• Vos cas d’usage demandent-ils des performances prévisibles ?
• Voulez-vous créer un entrepôt de données logique au-dessus d’un lac de données ?
• Voulez-vous interroger des données directement à partir d’un lac de données ?
• Voulez-vous explorer les données d’un lac de données ?

Le tableau suivant compare les deux types de pool SQL Synapse.

Évaluation du pool SQL dédié

Pour l’évaluation du pool SQL dédié, évaluez les points de plateforme suivants.

• Qu’est-ce que la plateforme d’entrepôt de données actuelle (Microsoft SQL Server, Netezza, Teradata, Greenplum ou autre) ?
• Pour une charge de travail de migration, déterminez la marque et le modèle de votre appliance pour chaque environnement. Incluez les détails des PROCESSEURs, des GPU et de la mémoire.
• Pour une migration d’appliance, quand le matériel a-t-il été acheté ? L’appliance a-t-elle été entièrement dépréciée ? Si ce n’est pas le cas, quand l’amortissement se terminera-t-il ? Et combien de dépenses d’investissement reste-t-il ?
• Existe-t-il des diagrammes d’architecture matérielle et réseau ?
• Où se trouvent les sources de données de votre entrepôt de données planifié (Azure, d’autres fournisseurs de cloud ou locaux) ?
• Quelles sont les plateformes d’hébergement de données des sources de données de votre entrepôt de données (Microsoft SQL Server, Azure SQL Database, DB2, Oracle, Stockage Blob Azure, AWS, Hadoop ou autre) ?
• Certains des sources de données sont-elles des entrepôts de données ? Si c’est le cas, quelles sont celles-ci ?
• Identifiez tous les scénarios de chargement d’ETL, ELT et de données (fenêtres de traitement par lots, diffusion en continu, quasiment en temps réel). Identifiez les contrats de niveau de service existants pour chaque scénario et documentez les contrats SLA attendus dans le nouvel environnement.
• Quelle est la taille actuelle de l’entrepôt de données ?
• Quel est le taux de croissance du jeu de données ciblé pour le pool SQL dédié ?
• Décrivez les environnements que vous utilisez aujourd’hui (développement, test ou production).
• Quels outils sont actuellement en place pour le déplacement des données (ADF, Microsoft SQL Server Integration Services (SSIS), robocopy, Informatica, SFTP ou autres) ?
• Envisagez-vous de charger des données en temps réel ou quasiment en temps réel ?

Évaluez les points de base de données suivants.

• Quel est le nombre d’objets dans chaque entrepôt de données (schémas, tables, vues, procédures stockées, fonctions) ?
• Est-ce qu’il s’agit d’un schéma en étoile, d’un schéma flocon ou d’une autre conception ?
• Quelles sont les tables les plus importantes en termes de taille et de nombre d’enregistrements ?
• Quelles sont les tables les plus larges en termes de nombre de colonnes ?
• Existe-t-il déjà un modèle de données conçu pour votre entrepôt de données ? S’agit-il d’une conception de schéma Kimball, Inmon ou en étoile ?
• Les dimensions à variation lente (SCD) sont-elles utilisées ? Si c’est le cas, quels types ?
• Une couche sémantique sera-t-elle implémentée à l’aide de marts de données relationnelles ou d’Analysis Services (tabulaire ou multidimensionnel) ou d’un autre produit ?
• Quelles sont les exigences en matière de Haute Disponibilité/RPO/RTO/archivage de données ?
• Quelles sont les exigences en matière de réplication de région ?

Évaluez les caractéristiques de charge de travail suivantes.

• Quel est le nombre estimé d’utilisateurs simultanés ou de travaux accédant à l’entrepôt de données pendant les heures de pointe ?
• Quel est le nombre estimé d’utilisateurs ou de travaux simultanés accédant à l’entrepôt de données pendant les heures creuses ?
• Y a-t-il une période où il n’y aura pas d’utilisateurs ou de travaux ?
• Quelles sont vos attentes en matière de performances d’exécution de requête pour les requêtes interactives ?
• Quelles sont vos attentes en matière de performances de charge de données pour les charges de données quotidiennes/hebdomadaires/mensuelles ou les mises à jour ?
• Quelles sont vos attentes d’exécution de requête pour les requêtes de création de rapports et d’analyse ?
• Quelle est la complexité des requêtes les plus couramment exécutées ?
• Quel pourcentage de la taille totale de votre jeu de données est votre jeu de données actif ?
• Approximativement quel pourcentage de la charge de travail est prévu pour le chargement ou la mise à jour, le traitement par lots ou la création de rapports, les requêtes interactives et le traitement analytique ?
• Identifiez les modèles et plateformes consommant des données :
  • Méthode et outils de création de rapports actuels et planifiés.
  • Quelles applications ou outils analytiques accéderont à l’entrepôt de données ?
  • Nombre de requêtes simultanées ?
  • Nombre moyen de requêtes actives à un moment donné ?
  • Quelle est la nature de l’accès aux données (interactive, ad hoc, export ou autres) ?
  • Rôles de données et description complète de leurs exigences en matière de données.
  • Nombre maximal de connexions simultanées.
• Modèle de SLA pour la performance des requêtes par :
  • Utilisateurs du tableau de bord.
  • Production de rapports par lots.
  • Utilisateurs ML.
  • Processus ETL.
• Quelles sont les exigences de sécurité pour l’environnement existant et pour le nouvel environnement (sécurité au niveau des lignes, sécurité au niveau des colonnes, contrôle d’accès, chiffrement et autres) ?
• Avez-vous des exigences pour l'intégration du scoring des modèles d'apprentissage automatique avec T-SQL ?

Évaluation du pool serverless SQL

Le pool SQL Serverless Synapse prend en charge trois cas d’usage majeurs.

• Découverte et exploration de base : Analyse rapide des données dans différents formats (Parquet, CSV, JSON) dans votre lac de données, afin d'en extraire des perspectives.
• Entrepôt de données logique : Fournissez une abstraction relationnelle en plus des données brutes ou disparates sans déplacer et transformer des données, ce qui permet une vue toujours actuelle de vos données.
• Transformation des données : Moyen simple, évolutif et performant de transformer des données dans le lac à l’aide de T-SQL, afin qu’elles puissent être alimentées à BI et à d’autres outils ou chargées dans un magasin de données relationnelles (bases de données Synapse SQL, Azure SQL Database ou autres).

Différents rôles de données peuvent tirer parti du pool SQL serverless :

• Les ingénieurs données peuvent explorer le lac de données, transformer et préparer des données à l’aide de ce service et simplifier leurs pipelines de transformation de données.
• Les scientifiques des données peuvent rapidement raisonner sur le contenu et la structure des données dans le lac de données, grâce à des fonctionnalités telles qu’OPENROWSET et l’inférence de schéma automatique.
• Les analystes de données peuvent explorer les données et les tables externes Spark créées par des scientifiques des données ou des ingénieurs données à l’aide d’instructions T-SQL familières ou de leurs outils de requête préférés.
• Les professionnels de la bi peuvent rapidement créer des rapports Power BI sur des données dans les tables Data Lake et Spark.

Pour l’évaluation du pool SQL serverless, évaluez les points suivants.

• Avez-vous des cas d’usage pour découvrir et explorer des données à partir d’un lac de données à l’aide de requêtes relationnelles (T-SQL) ?
• Avez-vous des cas d’usage pour créer un entrepôt de données logique au-dessus d’un lac de données ?
• Identifiez s’il existe des cas d’usage pour transformer des données dans le lac de données sans d’abord déplacer de données à partir du lac de données.
• Vos données se trouvent-elles déjà dans Azure Data Lake Storage (ADLS) ou Stockage Blob Azure ?
• Si vos données se trouvent déjà dans ADLS, avez-vous une bonne stratégie de partition dans le lac de données ?
• Avez-vous des données opérationnelles dans Azure Cosmos DB ? Avez-vous des cas d’utilisation pour l’analytique en temps réel sur Azure Cosmos DB sans avoir d’impact sur les transactions ?
• Identifiez les types de fichiers dans le lac de données.
• Identifiez le SLA de performance de requête. Votre cas d’utilisation demande-t-il des performances et des coûts prévisibles ?
• Avez-vous des charges de travail analytiques SQL non planifiées ou irrégulières et soudaines ?
• Identifiez le modèle et les plateformes consommant des données :
  • Méthode et outils de création de rapports actuels et planifiés.
  • Quelle application ou outils analytiques accéderont au pool SQL serverless ?
  • Nombre moyen de requêtes actives à tout moment.
  • Quelle est la nature de l’accès aux données (interactive, ad hoc, export ou autres) ?
  • Rôles de données et description complète de leurs exigences en matière de données.
  • Nombre maximal de connexions simultanées.
  • Complexité des requêtes ?
• Quelles sont les exigences de sécurité (contrôle d’accès, chiffrement et autres) ?
• Quelle est la fonctionnalité T-SQL requise (procédures stockées ou fonctions) ?
• Identifiez le nombre de requêtes qui seront envoyées au pool SQL serverless, ainsi que la taille du jeu de résultats de chaque requête.

Évaluation du pool Spark

Les pools Spark dans Azure Synapse activent les scénarios clés suivants.

• Ingénierie des données/préparation des données : Apache Spark inclut de nombreuses fonctionnalités de langage pour prendre en charge la préparation et le traitement de grands volumes de données. La préparation et le traitement peuvent rendre les données plus précieuses et les permettre d’être consommées par d’autres services Azure Synapse. Il est activé via plusieurs langages (C#, Scala, PySpark, Spark SQL) et à l’aide de bibliothèques fournies pour le traitement et la connectivité.
• Machine Learning : Apache Spark est fourni avec MLlib, qui est une bibliothèque ML basée sur Spark que vous pouvez utiliser à partir d’un pool Spark. Les pools Spark incluent également Anaconda, qui est une distribution Python qui comprend différents packages pour la science des données, y compris ML. En outre, Apache Spark sur Synapse fournit des bibliothèques préinstallées pour Microsoft Machine Learning, qui est une infrastructure ML à tolérance de panne, élastique et RESTful ML. Lorsqu'il est combiné avec le support intégré des notebooks, vous disposez d’un environnement riche pour la création d’applications ML.

Pour l’évaluation du pool Spark, évaluez les points suivants.

• Identifiez les charges de travail qui nécessitent l’ingénierie des données ou la préparation des données.
• Définissez clairement les types de transformations.
• Identifiez si vous avez des données non structurées à traiter.
• Lorsque vous effectuez une migration à partir d’une charge de travail Spark/Hadoop existante :
  • Qu’est-ce que la plateforme Big Data existante (Cloudera, Hortonworks, services cloud ou autres) ?
  • S’il s’agit d’une migration à partir d’un site local, le matériel est-il déprécié ou les licences ont-ils expiré ? Si ce n’est pas le cas, quand l’amortissement ou l’expiration arriveront-ils ?
  • Qu’est-ce que le type de cluster existant ?
  • Quelles sont les bibliothèques requises et les versions spark ?
  • Est-ce une migration Hadoop vers Spark ?
  • Quels sont les langages de programmation actuels ou préférés ?
  • Quel est le type de charge de travail (Big Data, ML ou autre) ?
  • Quels sont les outils clients existants et planifiés et les plateformes de création de rapports ?
  • Quelles sont les exigences de sécurité ?
  • Existe-t-il des points de douleur et des limitations actuels ?
• Prévoyez-vous d’utiliser ou utilisez-vous actuellement Delta Lake ?
• Comment gérer les packages aujourd’hui ?
• Identifiez les types de cluster de calcul requis.
• Identifiez si la personnalisation du cluster est requise.

Étapes suivantes

Dans l'article suivant de la série Azure Synapse : succès par conception, découvrez comment évaluer la conception de l’espace de travail Synapse et valider qu’elle répond aux directives et exigences.