Catégorie Techno

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:

 

 

 

Analysis Services dans Azure!

Fleid 2 commentaires

Je suis sûr que vous avez noté l’arrivée récente de SSAS Tabular en mode PaaS dans Azure. Je voulais rapidement revenir dessus parce que ça faisait au moins 2 ans qu’on le sentait venir, et que finalement ça valait le coup d’attendre.

aas_1.png

Rappel : je bosse chez Microsoft maintenant. Même si ceux qui me connaissent savent que ça ne changera pas grand-chose à mon avis sur les produits, je préfère le rappeler pour être 100% transparent 😉

Azure Analysis Services c’est tout simplement la possibilité de déployer ses modèles SSAS Tabular dans le cloud sans se soucier du tout de l’installation ou de la configuration d’un serveur. Si on ajoute à ça le fait qu’il est désormais possible de développer un modèle Tabular dans SSDT en mode intégré (sans disposer d’une instance workspace), on peut donc aller du prototype à la production sans jamais toucher une ISO d’installation de SQL Server. Cool 😉

« Oui mais moi j’aime mieux Multidim ! » dirons certains. J’y répondrais qu’il n’est pas écarté qu’on voit les cubes rejoindre Tabular dans le service (le flou est maintenu dans l’annonce : « Support for multidimensional models will be considered for a future release, based on customer demand ». Mais surtout je dirais que SSAS Tabular est devenu vraiment solide avec SQL Server 2016, et qu’il est urgent de lui donner une deuxième chance (performance, support du many-to-many, nouvelles fonctions DAX…).

Je vous fais un petit tour d’horizon de comment c’est génial, en montant un datamart et le cube associé en moins de 30 minutes.

  • Au programme:
    • Création d’une base SQL Azure pour notre datamart
    • Création d’une instance Azure Analysis Services
    • Création d’un modèle SSAS Tabular dans Visual Studio (SSDT)
    • Déploiement du modèle dans Azure Analysis Services
    • Accès au modèle avec Power BI, Excel et SSMS

Tout commence dans le nouveau portail Azure : https://portal.azure.com. Si vous n’avez pas de compte Azure pas de problème, vous pouvez tout essayer gratuitement

  • Première étape : Création de la base de données sur Azure SQL Database pour mon datamart, histoire de tout faire en PaaS

Pour un DWH de taille respectable on devrait plutôt utiliser Azure SQL Data Warehouse, mais pour s’amuser une SQL Database suffit:

aas_2.png

Je vais la pré-remplir d’un sample: AdventureWorksLT v12. Notez que c’est une option à la création de la base, parfait quand on veut juste jouer avec le produit:

aas_3

Je valide, et on peut laisser tourner et passer à la suite en attendant 😉

  • Deuxième étape : la création de notre instance Azure Analysis Services

Cette fois-ci on regarde du côté Intelligence + Analytics:

aas_4.png

Ne vous embêtez pas pour le pricing tier, D1 suffit pour notre petit test. Idéalement on devrait mettre la base SQL et Analysis Services dans le même groupe de ressources, et donc la même location. Par grave pour notre test si ce n’est pas le cas:

aas_5.png

Là encore je valide et on laisse tourner.

  • Troisième étape: dans SSDT (SQL Server Data Tools, les templates data/BI pour Visual Studio) on va créer un nouveau projet SSAS Tabular

Pas de panique si vous n’avez pas SSDT, il est désormais disponible en download direct et gratuit, tout comme SSMS d’ailleurs. N’hésitez pas à télécharger la version la plus récente, elle se base sur Visual Studio 2015, et est capable de gérer des projets SSAS/SSIS/SSRS de SQL Server 2012 à 2016

New Project > BI > Analysis Services > AS Tabular:

aas_6

Profitez du mode intégré, c’est tellement plus pratique:

aas_7

De là on va pouvoir se connecter à notre datamart : Model > Import From Data Source:

aas_66

aas_8

Un petit guide pour savoir comment configurer la connexion:

aas_9

On passe sur l’impersonation pour le moment avec une option par défaut:

aas_91

On veut ensuite choisir nos tables:

aas_92

De quoi construire un petit modèle, avec 2 tables de fait et 4 dimensions :

aas_93

Ça charge, et on peut valider que le modèle ressemble bien à quelque chose grâce à la vue en diagramme:

aas_94

On peut ajouter des mesures, changer la direction du filtre en bidirectionnel entre les 2 tables de fait… Ou s’en passer 😉

La partie marrante c’est le déploiement. Dans les propriétés du modèle:

aas_95

On configure la destination du déploiement. Retenez le nom du serveur (asazure://…) c’est celle qu’on utilisera plus tard pour se connecter à SSAS avec Excel ou Power BI :

aas_96

Et lorsqu’on déploie:

aas_97

Après une demande de credentials pour le processing du cube post déploiement:

aas_98

On obtient un cube déployé dans les nuages !

  • Quatrième et dernière étape: on va se connecter à notre cube avec SSMS, Power BI ou encore Excel

Le nom du serveur on l’a déjà, c’est celui qu’on a utilisé plus tôt au moment du déploiement (asazure://…).

Power BI: Get Data > SSAS

aas_991

Excel: Get External Data > SSAS

aas_992

Notez qu’il faut choisir l’option User Name / Password, et utiliser le compte Azure qui vient de créer le service (c’est juste pour le test, évidemment il est possible de créer toute une liste d’utilisateurs via Azure AD):

aas_993

Enfin, avec SSMS, si vous êtes intégré avec Azure Active Directory ça marchera tout seul, sinon voir cet article (c’est simple):

aas_994

Magique non ? 😉

Si ça vous plait, je vous encourage à l’essayer ainsi qu’à suivre le compte Twitter @Azure_AS pour être mis au courant de toutes les nouveautés.

Revue : I <3 Logs (I Heart Logs) par Jay Kreps

Fleid Laisser un commentaire

Dans mon chemin d’apprentissage vers les nouvelles architectures de données, j’ai croisé ce petit bouquin rapide de Jay Kreps, et je ne peux que le recommander.

Jay Kreps c’est l’un des inventeurs d’Apache Kafka, quand il était encore chez Linkedin, et depuis c’est le co-fondateur de Confluent, la société commerciale qui édite la plateforme open source. Alors oui, fatalement, il a un petit biais en faveur des plateformes d’intégration basées sur les logs, mais il a surtout une grosse expérience sur le sujet à partager.

Couverture : I heart Log

Evacuons tout de suite le reproche principal qui est fait à ce bouquin: il est court, très court. Vu son prix, il est vrai que ça le rend vraiment cher à la page. Mais pour moi c’est le condensé parfait des idées sous-jacentes au grand retour à venir du temps réel dans l’intégration de données (confère). Donc je lui pardonne son prix (et j’aime signaler au marché qu’il va dans la bonne direction grace à mes achats). Pas de problème si vous surveillez votre budget, direction le blog de Confluent qui dans ses articles reprend beaucoup du contenu du livre. C’est moins bien organisé, mais avec un peu de patience on remet tout dans l’ordre. Dans le cas contraire, je vous encourage vivement de casser la tirelire 😉

Morceaux choisis:

  • La différence entre « Physical Logging » (on log le résultat de l’opération, ex: le contenu de la ligne) et « Logical Logging » (on log l’opération, ex : la requête SQL)
  • Différence qui découle dans 2 architectures de centralisation des logs: le « Primary Backup Model » pour le « Physical Logging » (on écrit sur un master, on forward le résultat de l’écriture aux systèmes esclaves), versus le « State Machine Model » pour le « Logical Logging » (on log la transaction en amont, elle est dupliquée pour traitements sur tous les systèmes en aval). Chacun avec ses avantages et inconvénients
  • Tout ça découle de l’idée de dualité de l’information: tables vs événements, une notion qu’on retrouve en BI, lorsqu’on modélise un processus métier et qu’on peut choisir entre conserver le stock vs les transactions d’un processus métier
  • Cette idée va être structurante dans la construction d’un système de log centralisé, à savoir comment connecter chaque type de système source. Les logs issus des applications auront tendance à être logiques, ceux connectés directement sur les bases plutôt physiques
  • L’objectif de mettre en place un système de log centralisé étant bien sûr d’isoler chaque consommateur de chaque source, pour que chacun puisse vivre sa vie en bonne intelligence
  • Le fait de mettre en place un système centralisé de log implique le passage au temps réel: l’unité de traitement n’étant plus le batch (à savoir une fenêtre temporelle: 1h, 1 jour, 1 semaine) mais bien le log, manifestation d’une opération unitaire du processus
  • A ce titre, on peut alors s’interroger sur la possibilité de mettre en place du « Stream Analytics » (merci Microsoft de nommer les produits de manière aussi explicite ;)), c’est à dire le traitement des informations en continu, plutôt que via un ETL, pour les contextes décisionnels. Il est à noter qu’il a été prouvé mathématiquement qu’il est possible d’implémenter toutes les opérations considérées comme bloquantes (distinct, max, top…) en streaming via le windowing et le caching

Je recommande vivement!

I heart Logs, Jay Kreps (Amazon.fr)

SQLRally Nordic : Construire une plateforme BI moderne en PaaS avec Azure

Fleid 6 commentaires

Si vous vous demandiez ce qui a expliqué ce long silence hivernal, voici l’une des principales raisons!

En effet j’ai été invité début mars à présenter une session au SQLRally Nordic 2015 à Copenhague. Pour ceux qui ne la connaissent pas, c’est une belle petite conférence sur 2 jours (4 tracks), payante, et si vous allez voir la liste des speakers vous verrez que le niveau est assez sympathique.

Tant qu’à me mettre en risque j’ai joué le tout pour le tout, en choisissant un sujet novateur et un peu provocateur. Parce que oui, faire de la BI en PaaS dans le Cloud, c’est provocateur!

Gif animé de Loki, personnage Marvel

Faîtes moi confiance, ça passe dans le Cloud, sans aucun problème!

Bon je ne m’attendais pas non plus à déclencher une bagarre générale dans la salle, mais j’ai quand même eu un peu d’appréhension que cela dégénère en un débat sur la théorie fondamentale du datawarehousing, dans la langue de Shakespeare. Rien de tout ça, la session s’est bien déroulée, la preuve en vidéo (oui je dois travailler sur mon accent… et ma démo!) :

Les idées que j’expose dans ce talk me parlent beaucoup en ce moment (architectures lamba/kappa, software containers, micro-services), si vous avez un peu de temps je pense que ça vaut le coup d’oeil. Par ailleurs j’ai proposé cette même session au PASS Summit 2015 (oui je suis un malade, mais ça n’est pas non plus un grand risque vu le peu de chance d’être sélectionné), et je vais globalement travailler dessus pour l’améliorer et pourquoi pas la présenter en France avant la fin de l’année.

Dans l’attente, les slides et les références que je conseille très vivement, avec une mention spéciale à Martin Kleppmann et son talk « Turning the database inside out« , juste exceptionnel:

Y’a un truc qui m’intrigue à Redmond…

Fleid 1 commentaire

Lors de la keynote du PASS Summit 2014, le mois dernier à Seattle, nous avions eu droit à la présentation de la nouvelle organisation de l’équipe Data Platform de Microsoft, par son leadership flambant neuf:

Des visages sur des noms

Trois patrons pour trois lignes de produit, alignées comme indiqué sur ce schéma (désolé pour la qualité patate):

L'organisation MS 2014 pour la Data en image

Si on repart du fond de la stack:

  1. Capture + Manage : T.K. « Ranga » Rengarajan, patron de Data Platform, Cloud & Entreprise. A comprendre : SQL Server, Azure SQL Database, Azure HDInsight, Azure DocumentDB, Azure Search and Analytics Platform System
  2. Transform + Analyze : Joseph Sirosh, patron de l’Information Management & Machine Learning. A comprendre : Tous les services Azure Data
  3. Visualize + Decide : James Phillips, patron de Power BI, tout du moins la partie sur O365 (dashboards, Q&A, Mobile…)

Là dessus je me fais les remarques suivantes:

  • Ranga ancien SAP, Joseph ancien Amazon, James co-fondateur de Couchbase, les 3 ont moins de 2 ans d’ancienneté chez MS, ça sent l’air frais, c’est plutôt bon signe
  • Ranga et Joseph sont CVP (haut gradés), James n’est « que » General Manager, bizarre cette différence de traitement…
  • Vis à vis des périmètres de chacun:
    • Pour Ranga on a une ligne claire de produits, énoncée dans sa fiche speaker, pas de doute possible
    • Pour Joseph, il fallait être là en scéance mais ont été nommés : Azure Data Factory, Azure Stream Analytics et Azure Machine Learning. On en reparle plus bas.
    • Pour James c’est moins clair. Power BI ça veut tout et rien dire, et si on s’en réfère au slide ci-dessus on note l’absence de la partie add-ins intégrée à Excel (soit à mon sens la plus importante), qui on le sait est retombée dans l’équipe Office. Bon il en parle quand même pendant la session, mais manifestement ça n’est pas dans son scope. Notons qu’il nous a parlé également de 2/3 autres trucs mignons qui arrivent et sont eux dans son scope : les Dashboards Power BI et l’amélioration du refresh on-premise/Power BI (genre SSAS et scheduling)

On en revient à Joseph, en reprennant le slide et en essayant de matcher les produits qu’on connaît en face:

  1. Orchestration -> Azure Data Factory
  2. Information Management -> ?
  3. Complex Event Processing -> Azure Stream Analytics
  4. Modeling -> ?
  5. Machine Learning -> Azure Machine Learning

Hum… Y’a des trous! Et si on observe le pattern, ça sent les services Azure managés, pour de l’Information Management et du Modeling! Wait, what?

Je ne sais pas vous, mais moi ça m’intrigue définitivement 😉

J'ai hâte!!

Un excellent conseil pour améliorer ses graphiques et rapports

Fleid Laisser un commentaire

C’est Edward Tufte qui l’a remarqué en premier et Stephen Few qui l’a bien vulgarisé : une bonne technique de communication visuelle est de maximiser la quantité d’encre utilisée effectivement pour les données, plutôt que pour la décoration.

Une très bonne illustration de ce principe c’est ce petit GIF, très joliment réalisé par DarkHorse Analytics, des experts canadiens du dataviz. data-ink

A retrouver avec plus de détail dans leur blog (dont une version ralentie).