Questions fréquentes (FAQ) sur Azure Synapse Analytics

Azure Synapse présente un certain nombre de rôles et d’étendues à affecter, qui simplifieront la sécurisation de votre espace de travail.

Rôles RBAC Synapse :

• Administrateur Synapse
• Administrateur Synapse SQL
• Administrateur Synapse Spark
• Contributeur Synapse
• Éditeur d'artefact Synapse
• Utilisateur d'artefact Synapse
• Opérateur de capacité de calcul Synapse
• Utilisateur d’informations d’identification Synapse
• Gestionnaire des données liées Synapse
• Utilisateur Synapse

Pour sécuriser votre espace de travail Synapse, attribuez les rôles RBAC à ces étendues RBAC :

• Workspaces
• Spark pools
• Runtimes d’intégration
• Services liés
• Informations d'identification

De plus, avec les pools SQL dédiés, vous disposez des mêmes fonctionnalités de sécurité que celles que vous connaissez et aimez.

Azure Synapse travaille avec l’analyse des coûts et les alertes de coût intégrées qui sont disponibles au niveau de l’abonnement Azure, ce qui constitue une base de départ.

• Pools SQL dédiés : vous bénéficiez d’une visibilité directe sur le coût et la maîtrise du coût, car vous créez et indiquez les tailles des pools SQL dédiés. Vous pouvez mieux contrôler quels utilisateurs peuvent créer ou mettre à l’échelle les pools SQL dédiés avec les rôles RBAC Azure.

• Pools SQL serverless : vous disposez de contrôles de supervision et de gestion des coûts qui vous permettent de limiter les dépenses aux niveaux quotidien, hebdomadaire et mensuel. Pour plus d’informations, consultez Gestion des coûts du pool SQL serverless.

• Pools Spark serverless : vous pouvez limiter les personnes autorisées à créer des pools Spark avec des rôles RBAC Synapse.

Les espaces de travail Synapse prennent en charge les dossiers définis par l’utilisateur.

Oui, à compter du 10 juin 2021, Synapse Studio vous permet désormais d’ajouter plusieurs espaces de travail Power BI à un espace de travail Azure Synapse.

Azure Synapse Analytics prend actuellement en charge Azure Synapse Link à partir d’Azure Cosmos DB vers Synapse Apache Spark et un pool SQL serverless. Azure Synapse Link pour Apache Spark est en disponibilité générale. Synapse Link pour le pool SQL serverless est en préversion. Pour plus d’informations, consultez Azure Synapse Link pour Azure Cosmos DB.

Azure Synapse Link pour SQL est en disponibilité générale pour SQL Server 2022 et Azure SQL Database. Pour plus d’informations, consultez Qu’est-ce qu’Azure Synapse Link pour SQL ?.

Oui ! Tous les artefacts de pipeline, les notebooks, scripts SQL et définitions de travaux Spark résideront dans Git. Toutes les définitions de pool seront stockées dans Git comme modèles Azure Resource Manager (ARM). Les objets de pool SQL dédiés (schémas, tables, vues, etc.) sont gérés avec des projets de base de données incluant la prise en charge des pratiques CI/CD. Pour plus d’informations, consultez ce guide des pratiques CI/CD.

Les fonctionnalités et les besoins sont différents entre les deux types de pool. Les différences incluent les objets de base de données, les fonctionnalités du langage de requête, la sécurité, les outils, l’accès aux données et le format des données. Pour une comparaison détaillée des pools SQL et des pools serverless, consultez Comparaison des pools. Pour connaître les bonnes pratiques relatives à l’utilisation de l’un ou l’autre des types de pool, consultez Bonnes pratiques pour les pools SQL dédiés et Bonnes pratiques pour les pools SQL Serverless.

Une architecture Lakehouse est basée sur des formats de données ouverts à accès direct, par exemple Apache Parquet. Elle offre une prise en charge de premier plan pour le machine learning et la science des données. Une table Delta est une vue des données contenues dans un lac Delta, qui prend en charge la plupart des options fournies par les API de lecture et d’écriture de DataFrame Apache Spark. Les architectures Lakehouse peuvent vous aider à surmonter les problèmes majeurs liés aux entrepôts de données, par exemple l’obsolescence, la fiabilité, le coût total de possession et le verrouillage des données. Dans les tables Delta, les optimisations telles que le compactage automatique et les plans de requête adaptatifs sont disponibles. Pour obtenir un guide détaillé sur le format de données Delta Lake, consultez le Guide Delta Lake.

Le compactage automatique est l’une des deux fonctionnalités complémentaires de l’optimisation automatique pour les tables Delta. Une fois l’écriture dans une table réussie, le compactage automatique peut compacter davantage les fichiers des partitions qui contiennent le plus grand nombre de petits fichiers. Il est recommandé d’opter pour le compactage automatique pour les cas d’usage de streaming où l’ajout de minutes de latence est acceptable, et où vous n’avez pas d’appels OPTIMIZE réguliers sur votre table. Pour plus d’informations sur l’optimisation automatique et le compactage automatique, consultez ce guide de l’optimisation automatique.

Chaque activité d’un pipeline Synapse est exécutée avec des informations d’identification spécifiées à l’intérieur du service lié.

Pas pour l'instant.

La prise en charge des paramètres globaux, le monitoring des travaux Spark pour Data Flow et le partage d’Integration Runtime sont des exemples de différences. Pour plus d’informations, consultez ce document : Intégration de données dans Azure Synapse Analytics par rapport à Azure Data Factory.

À ce stade, vous devez recréer manuellement vos pipelines Azure Data Factory, et les artefacts associés, en exportant le fichier JSON depuis le pipeline d’origine et en l’important dans votre espace de travail Synapse.

Consultez ce Guide de démarrage rapide.

Il existe deux options pour ce cas d’usage. La première option consiste à conserver les pipelines dans ADF. Vous devrez ensuite wrapper une activité web. Pour plus d’informations sur cette option, consultez ce guide de l’activité web. L’autre option consiste à migrer les pipelines vers Synapse. Pour plus d’informations sur la deuxième option, consultez cet exemple de code de migration.

Apache Spark pour Synapse n’est autre qu’Apache Spark doté d’une prise en charge supplémentaire pour les intégrations à d’autres services (Microsoft Entra ID, AzureML, etc.), avec des bibliothèques supplémentaires (mssparktuils, Hummingbird) et des configurations de performances prédéfinies.

Toute charge de travail en cours d’exécution sur Apache Spark s’exécutera sur Apache Spark pour Azure Synapse sans modification.

Depuis septembre 2023, Azure Synapse Apache Spark prend entièrement en charge Spark 3.3. Pour obtenir la liste complète des composants de base et des versions prises en charge, consultez Prise en charge des versions d’Apache Spark.

Oui, Azure Synapse Apache Spark fournit la bibliothèque mssparkutils. Pour obtenir une documentation complète de l’utilitaire, consultez Présentation des utilitaires Microsoft Spark.

Pour définir des paramètres de session, utilisez %%configure magic disponible. Un redémarrage de session est nécessaire pour que les paramètres soient pris en compte.

Pour définir des paramètres au niveau du cluster, vous pouvez fournir un fichier spark.conf destiné au pool Spark. Ce pool respectera ensuite les paramètres passés dans le fichier de configuration.

Azure Synapse fournit des moteurs spécialement conçus pour des cas d’usage spécifiques. Apache Spark pour Synapse est conçu comme un service de travaux, et non comme un modèle de cluster. Il existe deux scénarios dans lesquels un modèle de cluster multiutilisateur est demandé.

Scénario 1 : Accès de nombreux utilisateurs à un cluster pour traiter des données à des fins décisionnelles.

Le moyen le plus simple d’accomplir cette tâche consiste à préparer les données avec Spark, puis à tirer parti des fonctionnalités de service de Synapse SQL, afin qu’elles puissent connecter Power BI à ces jeux de données.

Scénario 2 : Présence de plusieurs développeurs sur un seul cluster pour faire des économies.

Pour développer ce scénario, vous devez donner à chaque développeur un pool Spark serverless configuré pour utiliser un petit nombre de ressources Spark. Comme les pools Spark serverless ne coûtent rien tant qu’ils ne sont pas utilisés activement, vous réduisez les coûts lorsqu’il y a plusieurs développeurs. Du fait que les pools partagent des métadonnées (tables Spark), ils peuvent facilement travailler ensemble.

Vous pouvez installer des packages externes par le biais d’un fichier requirements.txt lors de la création du pool Spark, à partir de l’espace de travail Synapse ou du portail Azure. Consultez Gérer des bibliothèques pour Apache Spark dans Azure Synapse Analytics.

MSSparkUtils sur Synapse Spark offre un large éventail d’utilitaires permettant d’améliorer votre expérience utilisateur, et de faciliter l’intégration à d’autres outils et services. Utilisez des systèmes de fichiers, obtenez des variables d’environnement, enchaînez des notebooks, et utilisez des secrets en un minimum d’étapes manuelles. Pour obtenir une documentation complète, accédez à Utilitaires Microsoft Spark.

Les pools SQL dédiés (anciennement SQL DW) sont une plateforme d’entreposage de données d’entreprise PaaS (Platform-as-a-Service) Azure. Vous pouvez interroger des pools SQL dédiés existants (anciennement SQL DW) et créer également de nouveaux pools SQL dédiés dans votre espace de travail Azure Synapse. Toutes les fonctionnalités du pool SQL dédié dans les espaces de travail Azure Synapse ne s’appliquent pas au pool SQL dédié autonome (anciennement SQL DW), et inversement. Pour plus d’informations, consultez Quelle est la différence entre les pools SQL dédiés Azure Synapse (anciennement SQL DW) et les pools SQL dédiés dans un espace de travail Azure Synapse Analytics ?. Pour activer les fonctionnalités de l’espace de travail Azure Synapse pour un pool SQL dédié (anciennement SQL DW) existant, consultez Activer les fonctionnalités de l’espace de travail Synapse pour un pool SQL dédié (anciennement SQL DW).

Vous trouverez la liste complète des différences dans Différences entre les fonctionnalités T-SQL dans Synapse SQL.

Aucun déplacement ni aucune migration n’est nécessaire. Vous pouvez choisir d’activer les nouvelles fonctionnalités de l’espace de travail sur vos pools existants. Dans ce cas, il n’y aura aucun changement cassant. En revanche, vous aurez la possibilité d’utiliser de nouvelles fonctionnalités, telles que Synapse Studio, Spark et des pools SQL serverless. Toutes les fonctionnalités du pool SQL dédié dans les espaces de travail Azure Synapse ne s’appliquent pas au pool SQL dédié (anciennement SQL DW), et inversement. Pour activer les fonctionnalités de l’espace de travail pour un pool SQL dédié (anciennement SQL DW) existant, reportez-vous au Guide pratique pour activer un espace de travail pour votre pool SQL dédié (anciennement SQL DW).

Par défaut, tous les nouveaux pools SQL dédiés sont déployés dans un espace de travail. Toutefois, si vous avez en besoin, vous pouvez toujours créer un pool SQL dédié (anciennement SQL DW) dans un facteur de forme autonome.

Avec ou sans réseau virtuel managé, vous pouvez vous connecter à votre espace de travail à partir de réseaux publics. Pour plus d’informations, consultez Paramètres de connectivité. L’accès à partir de réseaux publics peut être contrôlé en activant la fonctionnalité d’accès réseau public ou le pare-feu de l’espace de travail. Vous pouvez également vous connecter à votre espace de travail à l’aide d’un point de terminaison privé managé et de Private Link. Les espaces de travail Synapse sans réseau virtuel géré par Azure Synapse Analytics n’ont pas la possibilité de se connecter via des points de terminaison privés managés.

Étapes suivantes

• Bien démarrer avec Azure Synapse Analytics
• Créer un espace de travail
• Utiliser un pool SQL serverless
• Problèmes connus avec Azure Synapse Analytics
• Quelles sont les nouveautés d’Azure Synapse Analytics ?