Azure Synapse Analytics est un service Azure axé, comme son nom l’indique, vers l’analytique. Il n’est pas toujours évident de savoir ce qu’il est possible de faire avec ce service. C’est pourquoi nous vous proposons aujourd’hui de le découvrir.

Les différentes briques que vous allez pouvoir utiliser à travers Azure Synapse Analytics sont les suivantes :

• Dedicated SQL pool
• Serverless SQL pool
• Spark pool
• Synapse pipeline
• Synapse Studio

A noter : lors de la création d’un service Azure Synapse Analytics, vous devrez définir un data lake primaire. Vous pourrez soit utiliser un data lake existant, soit en créer un pour l’occasion.

Dedicated SQL Pool

A l’origine, il y avait “Azure SQL DW” (Data Warehouse). Ce service a d’abord été renommé « Synapse Analytics » avant de devenir « Dedicated SQL Pool ». Le nom que vous allez retrouver dans le portail Azure est même « Dedicated SQL pool (formerly SQL DW) ».

Lorsque vous avez un volume conséquent de données (au minimum 1To) que vous souhaitez analyser dans une base de données relationnelle et que vous rencontrez des problèmes de performance avec un service Azure SQL Database (par exemple), Dedicated SQL Pool peut être une solution.

Dedicated SQL pool est donc bien une base de données relationnelles dans laquelle vous allez pouvoir stocker des tables, créer des index, créer des procédures stockées, maintenir des statistiques, créer des vues y compris des vues matérialisées (contrairement à Azure SQL Database).

Mais s’il s’agit d’une base de données relationnelle, quelle est la particularité de Dedicated SQL Pool ? Réponse : son moteur appelé Massively Parallel Processing (MPP).

Comme toutes les architectures distribuées, vous allez retrouver une organisation avec des nœuds. Il y a un nœud principal auquel vous vous adressez lorsque vous exécutez une requête appelé « control node ».

Le control node répartit ensuite les données et la charge aux différents « compute node ». En fonction de la répartition des données et de la requête, il se peut que des données soient amenées à transiter à travers les différents « compute node » via le Data Movement Service (DMS). Une fois que les « compute node » ont terminé leur travail, le « control node » prépare le résultat de la requête et la requête prend fin.

L’architecture MPP n’agit pas sur la façon dont les données sont stockées sur disque mais bel et bien au moment de l’exécution de la requête.

Le nombre de compute node et leur niveau de configuration va dépendre du nombre d’unités que vous allez positionner. Il s’agit de DWU (pour Data Warehousing Unit). Vous pourrez bien évidemment faire évoluer à la hausse ou à la baisse le nombre d’unités en fonction des montées en charge si elles sont prévisibles.

La façon dont les données sont réparties entre les compute node est déterminée en fonction de la distribution de chacune des tables. Pour plus d’informations, nous vous invitons à consulter la documentation Microsoft.

Il est possible de mettre en pause la partie traitement (« compute ») quand la base n’est pas utilisée puis de faire un « resume » quand elle doit l’être. L’avantage est que pendant cette période, seul le stockage est payé. Il est possible de le faire via le portail mais vous pouvez également utiliser les API REST pour Dedicated SQL Pool.

Dans le cadre de cet article, nous ne traiterons pas tous les tenants et aboutissants de Dedicated SQL pool (la distribution des tables, l’optimisation, la gestion des charges de travail, le result-cache, polybase, copy statement, etc.).

Notez qu’il est possible de provisionner un Dedicated SQL pool hors d’un workspace Azure Synapse Analytics.

Serverless SQL Pool

Serverless SQL pool s’appuie sur l’architecture MPP. Lorsqu’une requête est exécutée, le principe reste le même que pour le Dedicated SQL pool : la requête est adressée au « control node » qui répartit le travail auprès de différents « compute node ».

Mais contrairement au Dedicated SQL pool pour lequel le nombre de compute node est déterminé par le nombre de DWU positionnées, Serverless SQL pool va utiliser le nombre nécessaire de nœuds pour exécuter la requête. Il va alors varier en fonction de la charge de travail.

Vous n’avez donc pas à positionner un nombre de DWU comme c’est le cas pour le Dedicated SQL pool.

L’autre différence est que le Serverless SQL pool ne va pas pouvoir stocker des tables physiquement.

Ce service a vocation à requêter un data lake (Azure Storage plus largement) et plus précisément les fichiers stockés sur ce (ou ces) data lake.

Vous allez pouvoir utiliser du SQL pour visualiser et transformer le contenu des fichiers de 3 manières différentes :

• Une requête avec OPENROWSET
• Une table externe
• Une vue

Requête avec OPENROWSET

OPENROWSET est une fonction vous permettant d’accéder à des fichiers de Azure Storage.

Ainsi les données du fichier (ou des fichiers) vont pouvoir être manipulées sous la forme d’une table (consulter la documentation Microsoft).

Au moment de l’écriture de cet article, les formats possibles sont JSON, CSV (fichiers délimités), parquet et delta lake (lire notre précédent article sur « pourquoi utiliser Delta Lake »).

Créer une table externe

Il n’est pas possible de créer des tables à proprement parler, mais il est possible de créer des tables externes. Serverless SQL pool va produire des métadonnées contenant la définition de cette table externe.

Avant de pouvoir créer des tables externes et des vues, vous allez devoir créer une base de données. A l’exception des métadonnées qui la définissent, elle n’aura pas d’existence physique. Il faut voir cela comme une manière d’organiser les tables externes, les vues et également les autorisations.

Comme prérequis à la création d’une table externe, vous allez devoir définir deux éléments :

• Une source de données externe
• Un format de fichier externe

La déclaration de la table externe utilise ainsi :

• Le schéma de la table
• L’emplacement du fichier ou des fichiers
• La source de données externe
• Le format de fichier externe

Exemple d’une source de données externe appelée « SqlOnDemandDemo » :

Exemple d’un format de fichier externe appelé « QuotedCsvWithHeaderFormat » :

Exemple d’une table externe « populationExternalTable » qui utilise la source de données externe ainsi que le format de fichier externe :

A noter : il est également possible de créer des tables externes dans Dedicated SQL pool (consulter la documentation Microsoft)

Créer une vue

Il est également possible de créer des vues, si vous souhaitez, par exemple, exposer le résultat de requêtes à des utilisateurs.

Exemple de la création d’une vue « populationView » dans la base de données « mydbname » qui utilise la source de données externe « SqlOnDemandDemo » vu dans l’exemple de table externe :

En termes de facturation, à l’heure de l’écriture de cet article, vous payez 5$ par TB de données remontées (voir les tarifs publiés par Microsoft). Afin de limiter le volume de données traités, vous pouvez positionner des quotas.

Dès lors que vous avez créé un service Azure Synapse Analytics, vous aurez accès à un Serverless SQL pool, ce qui n’est pas vrai pour le Dedicated SQL pool, Spark pool ou Synapse Pipeline avec les pipelines.

Spark pool

Dans Azure Synapse Analytics, vous pouvez créer des clusters Spark, ici appelés « Spark pool ».

Une fois le Spark pool créé et démarré, vous allez pouvoir créer des notebooks pour manipuler, transformer et préparer des données.

Synapse pipeline

Si vous êtes familier de Azure Data Factory, vous ne serez pas dépaysé par Synapse Pipeline.

Le fonctionnement est le même : définir des linked services, des datasets puis créer des pipelines avec un enchainement d’activités qui exploitent les datasets au travers des linked services.

Quelques des fonctionnalités présentes dans Data Factory ne le sont pas (encore) dans Synapse Pipeline. Vous pouvez retrouver ces différences dans la documentation Microsoft.

Côté Synapse Pipeline, vous aurez accès à des activités supplémentaires :

• L’activité « Notebook » pour appeler un notebook créé dans Azure Synapse Analytics ;
• L’activité « Spark job definition » pour exécuter un job Spark (voir le tutoriel Microsoft) ;
• L’activité “SQL pool stored procedure” pour exécuter une procédure stockée de Dedicated SQL pool.

Synapse studio

Synapse studio est l’interface graphique pour utiliser Azure Synapse Analytics.

Synapse Studio est inspiré de l’interface de Azure Data Factory.

Vous allez pouvoir naviguer en utilisant le bandeau de gauche avec les sections suivantes :

• Data : avec les parties :
  • Workspace : les bases de données de votre workspace, qu’il s’agisse des bases du Serverless SQL pool ou du Dedicated SQL pool.
  • Linked : c’est à partir de là que vous pourrez créer des datasets ou vous connecter à des données externes (ce qui aura pour effet de vous amener à créer un linked service puis un dataset) et que vous pourrez naviguer dans votre data lake principal.
• Develop : depuis cette section, vous allez pouvoir créer :
  • Des scripts SQL
  • Des notebooks Spark
  • Des Data flow
  • Des définitions de job Spark
• Integrate : c’est l’endroit pour créer des pipelines Synapse Pipeline comme vous le feriez avec Data Factory
• Monitor : monitorer l’exécution des notebooks ou des data flow, des pipelines, etc.
• Manage : c’est de là que vous pourrez gérer les pools Apache Spark, SQL pools, linked services, triggers, integration runtimes, la sécurité et également la gestion de configuration.

Des outils complémentaires

Vous devez avoir maintenant une idée plus claire de ce qui compose Azure Synapse Analytics, à savoir :

• Dedicated SQL pool
• Serverless SQL pool
• Spark pool
• Synapse pipeline
• Synapse Studio

Nous avons vu qu’il est possible d’utiliser une des briques sans pour autant utiliser les autres mais que dans le cas où vous utilisez plusieurs de ces briques, elles s’avéreront complémentaires : par exemple Synapse pipeline permettant d’orchestrer des notebooks Spark pool.