Architecture Data sur une stack Azure Datalake, Snowflake et Semarchy XDI

Quid du lien entre différents outils Data (Azure, Snowflake et Semarchy XDI)

Dans le contexte du développement d'une plateforme data visant à de futurs projets de Business Intelligence (BI), beaucoup de nos client souhaitent mettre en œuvre une architecture complète de la donnée, depuis sa source jusqu’à un Datawarehouse et des Datamarts, de manière à centraliser toutes les données utiles à de l’analyse par des outils de data vizualisation.

Pour ce faire, des outils tels que le Datalake Azure (stockage blob ADLS Gen2), Snowflake (Data Warehouse cloud), Semarchy xDI (ETL) ont été évoqués comme la stack technique potentielle de ce projet. Par la suite, un outil de data vizualisation viendra se brancher sur l’aval du projet (dans notre cas, Qlik, mais nous ne parlerons pas de cela dans cet article).

L'objectif du POC est de mettre en place une architecture pré-industrialisée portant sur la partie blob storage / SGBD / ETL et de découvrir les fonctionnalités utilisables de ces outils dans notre contexte (seuls et entre eux).

Dans cet article, nous allons étudier comment les technologies peuvent communiquer entre elles et nous évoquerons un exemple d’implémentation possible pour convenir à notre projet (URL back 2). De ce fait, nous allons voir ensemble les points suivants :

  • Importer quelques fichiers comportant des données liées depuis un Datalake Azure vers la base de données Snowflake
  • Pré-industrialiser l'import de fichier générique et mettre en place les process de transformation des données (selon une architecture simple que nous allons définir)
  • Faire une étude et une analyse de performances / coûts de notre implémentation en soumettant plusieurs scénarios

Découverte et fonctionnalités de Snowflake

Ce qu’il faut retenir de Snowflake (dans notre projet) est qu’il utilise toute la puissance d’un SGBD/Datalake Cloud. Cela impliquant que toute la partie « gestion des ressources» peut donc être déléguée à Snowflake, pour se concentrer uniquement sur le plus intéressant : son utilisation.

Ainsi, Snowflake peut facilement lire dans des sources de données externes (SGBD ou Fichier comme des CSV, JSON, etc.). Il est aussi très à l’aise avec les gros montants de données.

La scalabilité est très facile à mettre en place et Snowflake nous met à disposition plusieurs leviers pour pouvoir gagner du temps sur nos traitements :

  • Warehouses: c’est l’unité de ressources de calculs de Snowflake (CPU, RAM, mémoire temporaire). Un Warehouse permet d’effectuer des requêtes SQL de DDL et de DML. Si l’on multiplie le nombre de Warehouse, on peut multiplier les traitements en parallèles.
  • Clusters: dans notre contexte, nous allons parler de Warehouse à plusieurs clusters. Ces clusters sont indépendants et permettent de mettre en parallèle des calculs et/ou des requêtes.
  • Niveau de service: le niveau de service définira la puissance des ressources allouées. Plus le niveau de service est élevé, plus la consommation de crédits est élevée.

Fonctionnalités de Semarchy XDI utilisable

Snowflake est bien intégré dans Semarchy xDI avec le respect des bonnes pratiques, que ce soit dans les templates utilisables dans des mappings, la technologie métadata et le reverse, ainsi que les outils transverse (replicator). On notera aussi que le principe de SCD (Slowly changing dimension) peut être utilisé avec la technologie Snowflake.

Cependant, du fait de sa philosophie orienté modèles, xDI ne sera pas à l'aise quand il s'agira de traiter des objets de manière générique. Cette problématique sera donc plus déléguée à Snowflake qui le fait beaucoup plus simplement via des procédures stockées.

À propos des Snowpipes

L’éditeur de xDI va bientôt pouvoir implémenter l’intégration des Snowpipes dans son ETL. Les Snowpipes permettent de récupérer des données depuis des référentiels de dépôts dés qu’elles sont disponibles.

Dans notre cas, on pourrait avoir un Pipe branché sur une zone de dépôt (notre Datalake), qui nous transfèrerait petit à petit toutes les données qui arrivent dans ce dépôt vers un stage interne à Snowflake. Puis, nous pourrions utiliser ces données en stage pour faire la suite de notre traitement de manière un peu plus classique.

L’avantage des Snowpipes est qu’elles posent un pied dans les concepts ESB. L’inconvénient est qu’elle coute plus chère à l’utilisation en termes de crédits Snowflake. Bien que cet outil puisse gérer une ingestion simplement et rapidement, nous n’allons pas l’étudier dans cet article. Nous allons rester sur une méthode d’ingestion classique.

Problématiques techniques du projet

Lors de ce projet, nous devrons être capable

  • D’ingérer des données fichier, cela impliquant de pouvoir :
    • Lire des données dans des fichiers formatés (hiérarchiques ou, dans notre cas, plats)
    • Importer les données depuis le Datalake vers le SGBD Snowflake (que ce soit via xDI ou par des procédures Snowflake)
  • De qualifier les données ingérées :
    • Trouver des règles et contraintes d’unicités techniques et/ou fonctionnelles.
    • Connaitre l’identité d’un enregistrement (savoir comment gérer un même enregistrement présent dans plusieurs fichiers importés)
    • Recréer des relations techniques entre les données «brutes»
  • De transformer les données pour générer un datawarehouse selon des règles métiers
  • Mettre à disposition un modèle spécifique pour l’analyse des données via des datamarts

Architecture Applicative envisagée

Maintenant que nous avons cadré nos technologies, nous allons pouvoir commencer à utiliser les points forts de chacune d’entre elles pour répondre à nos problématiques

Nous allons penser une architecture «simple» dans un premier temps, qui ne prendra pas forcément en compte toutes les problématiques techniques que l’on peut trouver dans un projet «data», mais qui sera capable de les accueillir sans modification majeur (par exemple, la détection de suppression physique dans la source, le «tracking» des données, mécanisme de chargement par incrément, etc.).

  • Landing / RAW (ingestion des données) : phase de récupération des données depuis Azure vers Snowflake
    • Le landing peut être une source d'erreur de typage. Ici, nous voulons d'abord déplacer les données depuis les fichiers vers un moteur SQL et éviter des itérations coûteuses en temps en cas d'erreur. Le mieux est donc de déporter les erreurs de typage vers la phase de chargement de l'ODS (plus courte, plus maîtrisable, moins contraignante). On peut donc se permettre de mettre nos tables de landing avec un type par défaut sous forme de chaînes de caractères.
    • Peut être délégué à Snowflake par une procédure stockée générique (+ une table de configuration) et les mécanismes internes d'ingestion de fichiers (cette dernière option étant préférable).

Staging / RAW (première transformation "technique" des données) : Cette phase va nous permettre de préparer la phase suivante en ajoutant les données techniques telles que la date du fichier importé et son nom/path sur le Datalake

  • Si l'on utilise Snowflake pour le landing, on pourra fusionner cette étape avec la précédente.
  • ODS : C'est une phase de réduction, qui permet de ne récupérer que les versions des enregistrements les plus à jour (en se basant sur leur clef d’unicité). Cette phase nous permet de garder une trace des données que l'on utilise pour alimenter le DWH
    • Il est possible de trouver une méthode générique via les procédures stockées Snowflake. La procédure ici serait configurable par une table de paramètres, qui stockeront les différentes clefs d'unicités pour chaque table.
    • On voudra aussi re-typer les données qui nous arrivent du schéma de landing.
  • Data-warehousing : mise en dépôt des données de l'ODS avec des transformations et des agrégations définies par des règles techniques répondants à des besoins métiers.
    • Nous devrons aussi retravailler les identifiants.
    • On ne peut pas trouver de méthode générique ici, du fait des besoins métiers, le plus simple serait de gérer cette étape via des mappings xDI
  • Data-marting: Transformation des données du DWH pour répondre à des besoins fonctionnels de la BI et de la visualisation des données. C’est ici que les besoin métiers vont devoir être définis et influeront sur la modélisation du DWH.
    • Ici aussi, on préférera utiliser les mappings xDI

Comme énoncé plus tôt, en utilisant l'ingestion de données par des procédures stockées Snowflake, le landing et le staging peuvent être confondus en une seule étape.

Pour les étapes dites génériques (landing/staging, ODS), xDI serait plus puissant en tant d'ordonnanceur de flux ELT, lançant des procédures stockées Snowflake en fonction d'une configuration donnée par une table de paramètres.

On notera qu'il nous faudra seulement deux procédures génériques Snowflake, mais un mapping par table pour l'entreposage et pour les datamarts. Cela ne peut pas être géré automatiquement ni génériquement, du fait des règles métiers.

Cette architecture demandera des connaissances techniques sur le SGBD Snowflake (procédures stockées à développer, adapter, mettre à jour), mais reste générique. Cela simplifie énormément l' ajout de nouveaux éléments (table / fichiers) dans le projet. Il faudra bien préciser les besoins métiers en amont de la modélisation des datamart et du datawarehouse.

Suite de l'article ici

Vous souhaitez bénéficier d'experts, de développeurs, ou d'une formation sur Snowflake ou Semarchy xDI ? Rendez vous sur la page Contact