Tag ETL

Illustration du flux de traitement complet

Architecture d’un projet Azure Data Factory v2

Fleid Laisser un commentaire

Je viens d’écrire une série d’article sur Azure Data Factory v2 que je ne voulais pas publier ici parce qu’elle est rédigée en anglais. Ceci n’étant pas une raison pour abandonner mes premières amours, voici la traduction du premier article de la série, centré sur l’architecture du projet.

Je ne pense pas traduire les autres: ils sont plus proches du code donc facile à comprendre même en traduction automatique. Désolé pour les fautes de frappes, je fais ce que je peux avec mon clavier qwerty 😉

Remarque: je suis employé de Microsoft au moment où je rédige cet article

Scenario

Périmètre

L’objectif de cet article est de partager les réflexions faites lors du design et de l’implémentation d’une pipeline d’ingestion de données, partie d’un projet plus large d’IoT basé sur des technologies Cloud.

Dans notre scenario, nous sommes un fournisseur de service gérant une plateforme Big Data centralisée. Les données que nous traitons viennent d’une multitude d’appareils similaires mais déployés chez plusieurs de nos clients (Company A, Company B…).

La chaîne de traitement va ingérer des fichiers publiés toutes les heures sur un serveur sFTP centralisé (un répertoire top niveau par client, cette étape est déjà implémentée). Elle va ensuite les décoder, les convertir (CSV a Parquet) et les déplacer dans le répertoire de staging de la plateforme Big Data.

Illustration de la chaine de traitement discute ci-dessus

Besoins techniques

  • Des fichiers encodés (raw) sont publiés toutes les heures sur un serveur sFTP déployé dans un Virtual Network
  • Le décodeur (decoder) est une application Windows qui convertit les fichiers en CSV
  • La plateforme Big Data attend des fichiers Parquet en entrée

En plus de cela, les fichiers doivent être réorganisés d’une structure de répertoires hiérarchisées (Company\Year\Month\Device ID\xyz.csv), vers une structure à plat (Staging\year_month_company_device_xyz.csv). Ceci afin de faciliter l’ingestion par la plateforme Big Data.

Illustration du changement de structure de repertoire

Approche générale

Nous allons traiter les fichiers dans un batch qui tournera toutes les heures, en s’alignant sur leur rythme de génération.

Cela étant dit, par nature (IoT) nous manipulons ici des évènements. L’approche naturelle pour traiter des évènements est le temps réel (streaming). Pour moi la vraie solution, pérenne à long terme, serait de régénérer un flux d’évènements (stream) à partir des fichiers et d’utiliser des technologies d’ingestion en temps réel (Event Hub, Functions, Stream Analytics…) pour la suite des traitements. L’ingestion et la consommation de ces données en batch n’étant que la conséquence d’un détail d’implémentation existant.

Nous sommes missionné pour délivrer une solution en production dans un temps raisonnable, sans risque technique… nous avons donc décidé d’attendre que le besoin d’analyse en temps réel se manifeste pour passer sur du temps réel 😉

Nous aurons besoin d’un ETL avec des capacités Cloud pour orchestrer et exécuter le job, de moteurs de traitement (compute) pour déplacer et convertir les fichiers, et de solutions de stockage.

Éléments de la solution

Nous commencerons par choisir l’ETL puisque c’est la pièce centrale du puzzle. De cet ETL découlera la liste de moteurs de traitement disponibles, qui à leur tour indiqueront les solutions de stockage que nous pourrons employer.

ETL dans le Cloud

Nous utiliserons Azure Data Factory v2 (ADFv2) pour nos besoins d’ETL. Ce service nous permettra d’accéder à un large choix de solution de processing, que l’on pourra intégrer dans un unique flux d’orchestration (Control Flow).

ADFv2 offre:

  • un connecteur natif sFTP
  • une méthode pour accéder à des ressources résidant dans un Virtual Network (via self-hosted integration runtime, discuté ci-dessous)
  • une conversion native de CSV à Parquet avec la Copy Activity
    • A noter que c’est une approche temporaire, les Data Flows étant à préférer pour ce cas, mais toujours en preview à l’écriture de cet article

Une autre bonne raison de choisir ADFv2 est simplement que nous voulions tester le produit, alors qu’il se positionne comme la solution d’intégration en batch par défaut sur Azure.

Processing

ADFv2 peut utiliser deux types de moteurs de traitement:

Toutes les activités natives d’ADFv2 sont exécutées par un IR. Ce qui est bien c’est que chaque Factory vient avec un IR par défaut, managé par Microsoft (autoResolve IR). Ce qui est moins bien c’est que cet IR ne peut pas être configuré, y compris autour du networking. Il n’est donc pas utilisable dans le contexte d’un Virtual Network, dans notre cas il ne pourra pas toucher le serveur sFTP qui met à disposition nos fichiers. Afin de résoudre ce problème, nous allons déployer nous-même un « self-hosted » IR, sur une VM Windows que nous provisionnerons dans le Virtual Network, et l’enregistrer dans notre Factory.

Dans notre Factory, nous déclarerons nos services de stockage et les ferons utiliser l’IR qui correspond (via la propriété connectVia):

  • soit self-hosted (pour accéder au Virtual Network)
  • soit autoResolve (car c’est la seule capable de faire la conversion csv-parquet)

Enfin, à l’écriture de cet article, il n’existe pas d’activité native dans ADFv2 pour effacer des fichiers. Pour ce faire nous avons décidé d’utiliser une Logic App, en suivant cette stratégie, appliquée sur un File Store (voir Stockage ci-dessous). En alternative, nous avons essayé d’appeler directement la Delete REST API du File Store via une Web Activity, mais sommes rester bloqués sur l’authentification (pas de MSI disponible, contrairement aux Blobs). Nous avons également essayé la même approche avec une Function, mais là non plus sans succès (pas de support via le SDK, l’authentification via REST n’est pas évidente).

Stockage

Le décodeur est une application Windows qui écoute un répertoire d’entrée A, attrape les fichiers qui y apparaissent, les décode et les déplace vers un répertoire de sortie B.

Le transfert sFTP étant opéré par ADFv2, par un self hosted IR déployé localement, la manière la plus simple de positionner le décodeur est de l’installer sur une VM située dans le même Virtual Network. Nous monterons deux File Stores sur cette VM: pour l’entrée (A) et la sortie (B) des fichiers. Ces espaces de stockage seront à la fois accessibles par les outils Cloud, et vus comme des répertoires locaux par le décodeur.

Les fichiers seront mis à disposition de la plateforme Big Data dans un Blob Store, beaucoup plus pratique à utiliser dans ce contexte.

Solution

Architecture

Illustration du flux de traitement complet

Vis à vis de la planification:

  • L’étape 1 (copie du serveur sFTP vers A) doit être déclenchée par un trigger externe (0), planifié pour s’exécuter toutes les heures
  • L’étape 2 (de A vers B) est rendu par le décodeur, déclenché automatiquement sur écoute du répertoire A (quand un nouveau fichier apparaît)
  • Ce qui veut dire qu’idéalement les étapes 3 et 4 (3: copie et conversion des fichiers de B vers le Blob, 4: Logic App qui efface les fichiers) devraient elles aussi être déclenchées sur écoute, mais du répertoire B. Malheureusement ce n’est pas une fonctionnalité existante des File Stores (via ADFv2, Logic App ou Function). Une solution de contournement satisfaisante dans notre cas sera de déclencher 3 et 4 via un trigger planifié pour s’exécuter toutes les 15 minutes

Pour le stockage:

Recapitulatif des operations sur les fichiers

Coûts

A partir du volume de donnée attendu et de la liste des services employés, nous pouvons utiliser la calculatrice des prix d’Azure et obtenir une première estimation de la consommation mensuelle pour notre solution (en USD):

  • Data Factory : 250$
  • Logic Apps : 70$
  • Storage : 140$
  • VMs : 600$
  • VNet : 2$
  • Total : 1062$ (USD, par mois, 24/7 toutes les 15 minutes)

Il est important de voir ce chiffre comme une hypothèse qui doit être testée et validée. Entre les métriques obscures de la calculatrice et les larges possibilités d’optimisation de coût, il faut savoir investir du temps pour maîtriser sa consommation à long terme.

Alternatives

Il existe un nombre d’alternatives valables, de la solution poids lourd (HDInsight, Databricks…) au serverless (Function, Logic Apps…).

La suite

En anglais:

 

 

 

Conseil aux développeurs d’ETL : automatisez vos traitements au plus tôt

Fleid Laisser un commentaire

Votre ETL est planifié en traitements périodiques ? Quotidiens, hebdomadaires, mensuels ?

Alors faites les tourner de manière automatique le plus tôt possible dans le projet, avec la fréquence la plus haute possible. Si vous avez des alimentations mensuelles qui, vous le savez, passent en hebdo, passez les en hebdo.

N’attendez pas la phase d’intégration (si vous en avez une), ou la phase de recette, pour les exécuter régulièrement. Dès qu’ils sont prêts, automatisez-les !

Pourquoi ?

Si je peux prendre une image, les premières alimentations d’un datawarehouse avec un ETL c’est l’équivalent de vider un étang avec une pompe fragile et un tuyau percé :

  • Plus vous utiliserez votre système, plus vous constaterez les fuites du tuyau. Si vous le faites suffisamment en amont, vous aurez un maximum de temps pour aller coller des rustines.
  • Au fond de l’étang, il y a la vase – les cas spécifiques tordus, les anomalies de production – et quoi qu’il se passe il va falloir l’aspirer. Le plus tôt ça passe dans le tuyau, le plus tôt ça fait étouffer la pompe, le plus vous aurez de marge de manœuvre pour adapter vos traitements et nettoyer tout ça. Mieux vaut s’en débarasser dans la phase de réalisation qu’en recette.
Eviter de patauger !

Eviter de patauger !

Cela peut paraître évident, mais cet été j’ai été confronté à 2 projets dont les ETL n’étaient toujours pas automatisés au lancement de la phase de recette fonctionnelle. Bon courage aux équipes de développement respectives pour éponger la dette technique.

Projet décisionnel : choisir la bonne technologie dans l’offre Microsoft SQL Server

Fleid 13 commentaires

Je vous parlais tantôt de gestion de projet décisionnel, et en passant je vous disais que le choix d’une technologie pour un projet décisionnel n’était pas une décision anodine. Je voulais vous en dire plus, c’est le moment !

Rappelons d’abord que les projets décisionnels répondent à 3 besoins (cf ma session aux Journées SQL Server pour ceux qui prennent le wagon en route) :

Le décisionnel : Besoin Historisation

Historisation. Les bases de données des applications de l’entreprise sont régulièrement purgées (commandes livrées = commandes effacées du système). Pourtant ces informations sont importantes, il faut les conserver.

Le décisionnel : Besoin Centralisation

Centralisation. Les applications de l’entreprise sont des silos indépendants. Pourtant être capable de croiser ces domaines pour comprendre, par exemple, l’impact des actes commerciaux (CRM) sur les ventes (Logiciel de caisse) est indispensable.

Le décisionnel : Besoin Analyse

Analyse. Mon entreprise est un organisme qui vit dans un environnement. Mes applications (CRM, RH, ERP…) sont des capteurs qui génèrent des informations, des stimuli locaux de ce qu’il se passe dans chaque processus métier. J’aimerai analyser ces informations pour obtenir une image globale et comprendre le monde autour de moi.

Dans un projet décisionnel, on répond à ces 3 besoins à travers 5 fonctions :

  1. L’extraction : à la charge du décisionnel d’aller chercher les données qu’il souhaite
  2. Le nettoyage : ces données doivent être uniformisées et transformées pour être exploitables
  3. Le stockage : on archive les données pour garantir leur pérennité, on les historise pour être capable de comparer le passé au présent
  4. L’analyse : on modélise et interprète les données  pour en tirer un sens
  5. Le reporting : on apporte le résultat des analyses et des requêtes aux utilisateurs

Le décisionnel : 3 Besoins 5 Fonctions
Dans le monde Microsoft, ces fonctions sont assurées par les produits suivants :

Le décisionnel : Produits Microsoft

Ma liste est limitée, il existe d’autres produits (ReportBuilder… et tous les nouveaux sur le Cloud dont Data Explorer) mais on a là les piliers de l’offre.

D’abord on peut se poser la question du pourquoi Microsoft et pas un autre éditeur? Ma réponse c’est que c’est la gamme de produits avec le rapport efficacité / facilité d’usage le plus élevé, et de loin, sur le marché à l’heure actuelle. Notez que ce n’est pas forcément le plus performant sur chaque problématique (Informatica sur l’ETL en temps réel par exemple), ni forcément le plus facile d’utilisation (SSRS…), mais le plus complet, le plus équilibré, celui qui flatte le plus le développeur et l’utilisateur.

On en revient au tableau, pour noter qu’il n’existe au final que 3 domaines ou un choix de technologie existe.

Côté Archivage (je stocke mes données au format source, pour répondre à un besoin d’audit et/ou de sécurité), on stocke directement les fichiers sources sur le disque, ou les tables sans transformation dans la base. Rien de très intéressant par ici. Au passage : attention à ne pas systématiquement utiliser ces données pour vider et régénérer complétement le DWH à tous les chargements. Cette pratique est une bonne pratique uniquement dans certains cas d’utilisation mais pas dans tous. Voir les 2 excellents documents de Marco Russo et Alberto Ferrari sur le sujet, spécifiquement le chapitre « Classification of BI solutions« , dans le PDF introduction.

Côté Reporting, le choix se fait en fonction du type d’utilisation souhaité. Des analyses à la demande ? Excel et les TCD. Du reporting de masse ? SSRS. Du « collaboratif » ? SharePoint et ses Services. Un tableau de bord ? PerformancePoi… non je blague, n’importe quoi d’autre 😉

Le problème avec l’offre jusqu’à aujourd’hui, c’était que le choix de solution de reporting impactait le choix du moteur d’analyse. En effet les tableaux croisés dynamiques d’Excel et les services SharePoint étaient obligatoirement branchés sur du SSAS classique (maintenent BISM-Multidimensional). Heureusement c’est une contrainte qui saute, ou plutôt qui évolue, avec SQL Server 2012 et la refonte de SSAS. Certes cette refonte introduit de nouvelles contraintes (PowerView sur du Tabular), mais elle libère Excel et les TCD.

Ce qui fait que le choix va se faire beaucoup plus librement sur le moteur d’analyse, entre :

  • Monter un datamart répondant à un besoin spécifique directement dans la base SQL
  • Construire un cube : SSAS – BISM Multidimensional
  • Construire un modèle tabulaire : SSAS – BISM Tabular

Et avec Excel 2010 (plus PowerPivot dans certains cas) on peut accéder facilement à ces 3 sources et offrir des tableaux croisés dynamiques bien velus à nos utilisateurs, indépendamment du moteur d’analyse. Ça c’est cool 🙂

La dernière question qui reste est donc quel moteur d’analyse choisir entre SSAS-Multidimensionnal, SSAS-Tabular ou le dB Engine ? La réponse n’est pas encore définitive, elle se précisera au fur et à mesure que nous ferons des projets sur les technos, mais des pistes apparaissent déjà:

  • BISM – Multidimensional : Techno « complexe », données hiérarchisées, grosses volumétries avec reporting à niveau agrégé, relations complexes (many to many…), comparaisons temporelles (mais pas trop les faits en période), des chiffres (pas trop des lettres)
  • BISM – Tabular : Techno simple et performante (elle rattrape les erreurs de développements assez bien), rapide à implémenter, beaucoup plus libre sur le modèle de données, agrège bien mais traite aussi bien le détail, costaud sur le distinct count, attention cependant aux trop grosses volumétries
  • Datamart SQL : J’entends par là des tables d’agrégats bien pensées. Dedans on mettra tout le reste 🙂

Pour plus d’infos, n’hésitez pas à consulter le webcast d’Aurélien Koppel et François Jehl sur le sujet, et n’hésitez pas non plus à en causer dans les commentaires, tous les avis sont bons à prendre!