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

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.

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, vos exigences environnementales, vos contraintes, votre calendrier et vos difficultés. Ces informations constituent la base des évaluations et des activités de point de contrôle ultérieures. Cela s’avérera précieux quand il s’agit 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 prendre le temps de recueillir toutes les informations et de veiller à avoir les discussions nécessaires avec les groupes pertinents. Les groupes pertinents peuvent inclure les parties prenantes du projet, les utilisateurs professionnels, les concepteurs de solutions et les experts techniques (SME) 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 porte sur 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écrivez votre charge de travail analytique existante :
  • Quelles sont les charges de travail (entrepôt de données ou Big Data) ?
  • Comment cette charge de travail aide-t-elle l’entreprise ? Quels sont les scénarios de cas d’usage ?
  • Quelle est la motivation professionnelle pour cette plateforme analytique et pour la migration potentielle ?
  • Rassemblez des détails sur l’architecture, la conception et les choix 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, autres fournisseurs cloud ou locaux) ?
• Quelle est la taille totale des jeux de données existants (historiques et incrémentiels) ? Quel est le taux actuel de croissance de vos jeux de données ? Quel est le taux de croissance projeté de vos jeux de données pour les 2 à 5 prochaines années ?
• Disposez-vous d’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 à traiter et analyser ?
• Décrivez la nature du traitement des données (traitement par lot ou en temps réel).
• Avez-vous besoin d’une exploration interactive des données relationnelles, du 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 ?
• Quelles sont les difficultés et 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. Est-ce qu’il s’agit d’un fournisseur de cloud unique ou d’un fournisseur multicloud ?
• Rassemblez vos plans sur l’environnement cloud futur. Est-ce qu’il s’agit d’un fournisseur de cloud unique ou d’un fournisseur multicloud ?
• Quelles sont les exigences de RPO/RTO/HA/SLA dans l’environnement existant ?
• Quelles sont les exigences de RPO/RTO/HA/SLA dans l’environnement planifié ?

Rôles de charge de travail analytique

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

• Décrivez les différents rôles (scientifique des données, ingénieur de données, analyste de données et autres).
• Décrivez l’exigence de contrôle d’accès à la plateforme analytique pour ces rôles.
• Identifiez le propriétaire de la plateforme responsable de l’approvisionnement des ressources de calcul et accordez-lui l’accès.
• Décrivez comment les différents rôles de données collaborent actuellement.
• Plusieurs équipes collaborent-elles 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, la transformation et l’orchestration, évaluez les points suivants.

• Quels outils utilisez-vous aujourd’hui pour l’ingestion des données (ETL ou ELT) ?
• Où existent ces outils 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-lots, horaire, quotidien, hebdomadaire ou mensuel) ?
• Décrivez les exigences de transformation pour chaque couche (Big Data, lac de données, 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 pour automatiser le processus piloté par les données ?
• Où sont les sources de données ETL existantes (Azure, autre fournisseur de cloud ou local) ?
• Quels sont les outils existants de consommation de données (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-santé de 1996 (HIPAA), votre groupe de sécurité a-t-il certifié Azure pour ces données ? Si tel 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 ?
• Des données de test sont-elles disponibles pour le développement et les tests ?
• Décrivez les exigences de sécurité réseau de l’organisation sur le calcul analytique et le stockage (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 Azure et le matériel local (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 des données dynamiques
• Authentification :
  • Connexion SQL
  • Microsoft Entra ID
  • Authentification multifacteur (MFA)
• Sécurité réseau :
  • Réseaux virtuels
  • Pare-feu
  • Azure ExpressRoute
• Protection contre les menaces :
  • Détection de menaces
  • Audit
  • Évaluation des vulnérabilités

Pour plus d’informations, consultez le livre blanc sur la sécurité d’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 la bande passante ?
• Disposez-vous d’une approbation budgétaire pour provisionner les services Azure requis ?
• Comment provisionnez-vous et gérez-vous actuellement les ressources (Azure Resource Manager (ARM) ou Terraform) ?
• Votre équipe clé est-elle familiarisée avec Synapse Analytics ? Une formation est-elle nécessaire ?

Consommation des données

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

• Décrivez la méthode et les outils vous utilisez actuellement pour effectuer des activités comme 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 comme l’ingestion, l’exploration, la préparation et la visualisation des données.
• Quelles applications prévoyez-vous de faire interagir avec la plateforme analytique (Microsoft Power BI, Microsoft Excel, Microsoft SQL Server Reporting Services, Tableau ou 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 porte sur les services dans Azure Synapse. Azure Synapse a les composants suivants pour le déplacement des données et du calcul :

• Synapse SQL : Système de requête distribué pour Transact-SQL (T-SQL) qui permet les scénarios d’entreposage de données et de virtualisation des données. Il étend également T-SQL pour traiter les scénarios de diffusion en continu et de Machine Learning (ML). Synapse SQL propose des modèles de ressources à la fois serverless et dédiés.
• Pool SQL serverless : un système de traitement de données distribué, conçu pour des fonctions de calcul et de données à grande échelle. Il n’existe pas d’infrastructure à configurer ou de clusters à gérer. 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 en cours de provisionnement quand Synapse SQL est utilisé. 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 : offre une intégration profonde et fluide avec Apache Spark, le moteur de Big Data open source le plus répandu dans les domaines de la préparation des données, de l’ingénierie de données, des processus ETL (extraction, transformation et chargement) et du Machine Learning.
• 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 relationnel traditionnel en réservant la puissance de traitement pour les données stockées dans des tables SQL ?
• Vos cas d’usage exigent-ils des performances prévisibles ?
• Voulez-vous créer un entrepôt de données logique sur 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 pools SQL Synapse.

Comparaison	Pool SQL dédié	Pool SQL serverless
Propositions de valeur	Fonctionnalités entièrement gérées d’un entrepôt de données. Performances prévisibles et élevées pour les charges de travail continues. Optimisé pour les données managées (chargées).	Bien démarrer et explorer facilement les données du lac de données. Meilleur coût total de possession (TCO) pour les charges de travail ad hoc et intermittentes. Optimisé pour l’interrogation de données dans un lac de données.
Charges de travail	Idéal pour les charges de travail continues. Le chargement améliore les performances, avec plus de complexité. La facturation par DWU (en cas de dimensionnement adapté) sera rentable.	Idéal pour les charges de travail ad hoc ou intermittentes. Il n’est pas nécessaire de charger des données. Il est donc plus facile de démarrer. La facturation par utilisation sera rentable.
Performances des requêtes	Offre une concurrence élevée et une faible latence. Prend en charge les options de mise en cache enrichies, notamment les vues matérialisées. Il existe la possibilité de choisir des compromis avec la gestion des charges de travail (WLM).	Non adapté aux requêtes de tableau de bord. Des temps de réponse en millisecondes ne sont pas attendus. Ne fonctionne que sur des données externes.

Évaluation du pool SQL dédié

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

• Quelle est la plateforme actuelle d’entrepôt de données (Microsoft SQL Server, Netezza, Teradata, Greenplum ou autre) ?
• Pour une charge de travail de migration, déterminez le fabricant 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 amortie ? Si ce n’est pas le cas, quand l’amortissement sera-t-il terminé? 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, autre fournisseur de cloud ou local) ?
• 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) ?
• Les sources de données comprennent-elles des entrepôts de données ? Si oui, lesquelles ?
• Identifiez tous les scénarios ETL, ELT et de chargement de données (fenêtres de traitement par lots, diffusion en continu, quasi-temps réel). Identifiez les contrats de niveau de service (SLA) 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 en quasi-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) ?
• S’agit-il d’un schéma en étoile, d’un schéma en flocon ou d’une autre conception ?
• Quelles sont les tables les plus volumineuses 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 ?
• Des dimensions à variation lente (SCD) sont-elles utilisées ? Si oui, quels types ?
• Une couche sémantique sera-t-elle implémentée à l’aide de magasins de données relationnels ou d’Analysis Services (tabulaire ou multidimensionnel) ou d’un autre produit ?
• Quelles sont les exigences en matière d’archivage 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 ou de travaux simultanés 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 des 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 ou les mises à jour mensuelles ?
• Quelles sont vos attentes en matière d’exécution de requêtes pour la création de rapports et les requêtes analytiques ?
• 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 (interactif, ad hoc, exportation ou autres) ?
  • Rôles de données et description complète de leurs besoins en données.
  • Nombre maximum de connexions simultanées.
• Modèle SLA des performances des requêtes par :
  • Utilisateurs du tableau de bord.
  • Création de rapports par lots.
  • Utilisateurs de 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 intégrer le scoring de modèle ML à T-SQL ?

Évaluation du pool SQL serverless

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

• Découverte et exploration de base : comprenez rapidement les données de différents formats (Parquet, CSV, JSON) présentes dans votre lac de données, afin de planifier l’extraction d’insights à partir de celles-ci.
• Entrepôt de données logique : fournissez 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 : méthode simple, scalable et performante pour transformer les données d’un lac à l’aide de T-SQL, en vue de les envoyer vers des outils décisionnels ou autre, ou en vue de les charger 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 des données peuvent explorer le lac de données, transformer et préparer les données à l’aide de ce service, et simplifier leurs pipelines de transformation des données.
• Les scientifiques des données peuvent rapidement comprendre le contenu et la structure des données du lac de données, grâce à des fonctionnalités telles que 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 les scientifiques ou les ingénieurs de données en utilisant des instructions T-SQL familières ou leurs outils d’interrogation favoris.
• Les professionnels du décisionnel peuvent rapidement créer des rapports Power BI à partir des données du lac de données et des tables Spark.

Notes

Le langage T-SQL est utilisé à la fois dans le pool SQL dédié et dans le pool SQL serverless, mais il existe des différences dans l’ensemble des fonctionnalités prises en charge. Pour plus d’informations sur les fonctionnalités T-SQL prises en charge dans Synapse SQL (dédié et serverless), consultez Fonctionnalités Transact-SQL prises en charge dans Azure Synapse SQL.

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 des données à partir du lac de données.
• Vos données sont-elles déjà dans Azure Data Lake Storage (ADLS) ou le Stockage Blob Azure ?
• Si vos données se trouvent déjà dans ADLS, avez-vous une bonne stratégie de partitionnement dans le lac de données ?
• Avez-vous des données opérationnelles dans Azure Cosmos DB ? Avez-vous des cas d’usage pour l’analytique en temps réel sur Azure Cosmos DB sans impact sur les transactions ?
• Identifiez les types de fichiers dans le lac de données.
• Identifiez le contrat SLA des performances des requêtes. Votre cas d’usage exige-t-il des performances et des coûts prévisibles ?
• Avez-vous des charges de travail analytiques SQL non planifiées ou en rafale ?
• Identifiez le modèle et les 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 au pool SQL serverless ?
  • Nombre moyen de requêtes actives à tout moment.
  • Quelle est la nature de l’accès aux données (interactif, ad hoc, exportation ou autres) ?
  • Rôles de données et description complète de leurs besoins en données.
  • Nombre maximum 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 et la taille du jeu de résultats de chaque requête.

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.

Évaluation du pool Spark

Les pools Spark dans Azure Synapse permettent 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 leur permettre d’être consommées par d’autres services Azure Synapse. Cela est possible grâce aux différents langages (C#, Scala, PySpark, Spark SQL) et aux bibliothèques fournies pour le traitement et la connectivité.
• Machine Learning : Apache Spark est fourni avec MLlib, bibliothèque de Machine Learning 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 le ML. En outre, Apache Spark sur Synapse fournit des bibliothèques préinstallées pour Microsoft Machine Learning, qui est un framework ML avec tolérance de panne, élastique et RESTful. Tout ceci, combiné à la prise en charge intégrée des notebooks, vous permet de disposer d’un environnement riche pour créer des applications de Machine Learning.

Notes

Pour plus d’informations, consultez Azure Spark dans Azure Synapse Analytics.

De plus, Azure Synapse est compatible avec Linux Foundation Delta Lake. Delta Lake est une couche de stockage open source qui apporte des transactions ACID (atomicité, cohérence, isolation et durabilité) à Apache Spark et aux charges de travail Big Data. Pour plus d’informations, consultez Qu’est-ce que Delta Lake.

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 :
  • Quelle est la plateforme Big Data existante (Cloudera, Hortonworks, services cloud ou autre) ?
  • S’il s’agit d’une migration à partir d’un emplacement local, le matériel est-il amorti ou les licences ont-elles expiré ? Si ce n’est pas le cas, quand se produira l’amortissement ou l’expiration ?
  • Quel est le type de cluster existant ?
  • Quelles sont les bibliothèques et les versions de Spark requises ?
  • Est-ce qu’il s’agit d’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 difficultés et des limitations actuelles ?
• Envisagez-vous d’utiliser Delta Lake ou utilisez-vous déjà Delta Lake ?
• Comment gérez-vous les packages aujourd’hui ?
• Identifiez les types de cluster de calcul requis.
• Déterminez si la personnalisation du cluster est requise.

Conseil

Si vous débutez avec les pools Spark, nous vous recommandons de suivre le parcours d’apprentissage Effectuer l’ingénierie des données avec des pools Apache Spark Azure Synapse.

Étapes suivantes

Dans l’article suivant de la série Réussite d’Azure Synapse par conception, découvrez comment évaluer la conception de l’espace de travail Synapse et vérifier qu’elle répond aux instructions et exigences.