Avec Charles-Henri on parlera Azure Stream Analytics, le service de stream processing en SQL dont je suis l’un des product managers depuis pas loin d’un an maintenant.

Si vous parlez SQL, et que vous avez des données à traiter en temps réel, ça peut valoir le coup d’œil

Inscriptions gratuites par ici : Le bon développeur Azure Stream Analytics… | Meetup

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.

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.

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:

• Internes : les Integration Runtimes (IR)
• Externes : avec pour exemple HDInsight, Databricks, Azure SQL via les procédures stockées…

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

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:

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:

• ALM and Infrastructure : sur l’infrastructure et l’expérience développeur
• Notable Implementation Details : sur des détails importants d’implémentation

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:

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:

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:

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:

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:

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

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

Un petit guide pour savoir comment configurer la connexion:

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

On veut ensuite choisir nos tables:

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

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

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:

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 :

Et lorsqu’on déploie:

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

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

Excel: Get External Data > SSAS

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):

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

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.

J’ai ordonné mes besoins selon 2 axes qui m’allaient bien :

L’objectif c’est d’alléger au maximum le nombre de choses à garder en tête, la liste de courses, l’email à envoyer au client, se souvenir de préparer la réunion de la semaine prochaine… pour alléger le stress et concentrer son énergie cognitive sur des taches productives.

Dans le détail :

1. A Faire
   1. Court terme: une todo list pour la journée, avec max 5 items. Elle est mise à jour tous les jours si elle n’est pas finie la veille. Je n’utilise pas d’app, j’ai besoin du contact physique avec le papier, et de la satisfaction de la jeter une fois qu’elle est complétée. S’il y a plus d’items à mettre que ce qui est faisable en une journée, il est temps de définir des vraies priorités.
   2. Moyen terme: j’ai plusieurs Kanban boards en place : une pour la gestion de l’ensemble de mon portefeuille de clients hors mode projet sur Trello. Et en projet j’utilise une board par équipe sur Visual Studio Team Services, avec les items qui descendent jusque dans Visual Studio c’est magique.
   3. Long terme: là on est plus sur la mise en place de bonnes habitudes sur la durée, et une approche qui ne marche pas trop mal pour moi c’est le suivi de séries : les streaks. Pour ça une bonne app c’est juste Streaks (iOS). Un streak assez connu dans le milieu c’est celui de GitHub:
2. A Retenir
   1. Court terme: j’utilise encore beaucoup de papier. J’aime prendre des notes, gribouiller des schémas, ordonner ma pensée sur le papier. Régulièrement je vide mon bloc-notes : poubelle ou photo direction OneNote (voir plus bas).
   2. Moyen terme : je viens de me mettre au Mind Mapping avec XMind. Je ne l’utilise pas du tout pour construire des plans d’actions, mais uniquement pour ordonner des ressources que j’ai besoin de garder sous la main : articles de blog, liens intranet, shortcut vers un répertoire sur ma DropBox… Il m’arrivait trop souvent de redécouvrir accidentellement des ressources de haute qualité, 1 mois après en avoir eu vraiment besoin, en ayant complètement oublié qu’elles existaient. L’objectif ici est de garder une liste organisée de ressources de haut niveau que je ne veux pas que mon futur moi oublie. C’est flou, je sais, je vous en dirais plus quand j’aurai fini ma phase exploratoire.
   3. Long terme : et pour tout le reste, ce que je peux juste chercher, je le stocke dans EverNote ou OneNote. EverNote pour le contenu que je n’ai pas créé – principalement des liens internet – que je n’organise pas, je cherche dedans. OneNote pour du contenu que j’ai rédigé : comptes rendus de réunion, photos de mes notes… qui lui est hautement organisé (par client, date…)

En termes de workflows, j’essaye de tout faire passer par ma boite mail. Si je trouve un article intéressant sur Twitter ou autre : je m’envoie le lien par mail, si je dois me souvenir de faire quelque chose : je m’envoie un mail… Si je ne l’ai pas sur email alors ça n’existe pas 

Ensuite, tous les matins, je vide mon inbox : chaque item va soit dans ma todo list, sur le kanban, ou dans la zone de stockage qui lui convient (voir inbox triage). Ma boite mail est également bien organisée (un répertoire par client/projet…), et je conserve 100% des emails (je parle de la pro là, la perso c’est n’importe quoi), même s’ils ne génèrent aucune action/stockage de mon côté. A noter que certaines tâches qui n’ont pas vraiment leur place dans le Kanban mais que je n’ai pas besoin de faire dans la journée finissent souvent dans mon agenda comme un meeting de 15 minutes plus tard dans la semaine (par ex : préparer le voyage pour voir un client hors de la ville). Le tout c’est que ma tête et mon inbox doivent rester vides. D’ailleurs un bon indicateur que je suis sous l’eau c’est que je ne suis plus capable de vider mon inbox quotidiennement.

N’hésitez pas à partager vos bonnes pratiques, je suis toujours preneur !

Je vous arrête tout de suite sur les blaguounettes: il ne neige quasiment pas à Vancouver (à part sur les stations de skis a 30 minutes/ 1h du centre-ville), la température ne descend que rarement en dessous de 0° Celsius, par contre… il pleut. Point de vue climat on peut dire que c’est la Bretagne du Canada. C’est certainement la raison pour laquelle 50% des français qu’on croise ici sont Bretons!

On a choisi Vancouver en grande partie pour son climat, et parce que l’on voulait vivre dans une ville anglophone. Egalement sur la liste, l’atmosphère définitivement West Coast (San-Francisco / Portland / Seattle / Vancouver), et bien évidemment la nature:

Le vue depuis West End, c’est genre, le centre ville de Vancouver…

Pourquoi partir? Principalement pour améliorer notre qualité de vie. Paris devenait étouffante pour nous. Je suis convaincu que c’est la promiscuité engendrée par la trop grande densité qui génère autant de comportements antisociaux. Dans tous les cas pour nous c’était trop. La France aussi devenait étouffante. Je ne tiens pas à parler politique ici, ou épiloguer sur les terribles évènements qui ont eu lieu juste après notre départ, et leurs conséquences désastreuses, mais il est clair que des raisons géopolitiques ont également motivées notre décision.

Ici l’herbe est un peu plus verte (heureusement que Justin est passé) mais pas tant que ça – par contre on se sent moins concernés (pour le moment), et juste plus loin. C’est un répit.

Je vous rassure de suite, l’amélioration de qualité de vie nous l’avons bien trouvé. Tout est plus facile ici, l’administratif, la vie de tous les jours, le boulot (pas en trouver, mais une fois en poste), les loisirs… Rien à voir! Mon niveau de stress n’a jamais été aussi bas !

Tout n’est pas rose non plus. Il existe une réelle différence culturelle avec les locaux (vrais Vancouverites) qui se manifeste toujours quand on ne l’attend pas, de façon assez désagréable, dont je vous reparlerai peut être plus tard. Par contre il y a tellement d’expatriés de toutes les nationalités qu’il est plutôt facile de faire des belles rencontres – et on en a fait !

Egalement pénible, le marché du travail vraiment concurrentiel, et la encore des différences culturelles qui ne nous favorisent pas dans la compétition. Enfin les loyers sont élevés et la vie culturelle certainement moins folle qu’à Paris – oui je confirme les clichés de Vancouver, mais ça n’en fait pas moins une ville que j’adore.

Pour partir nous avons profités du programme PVT. Pour ceux qui connaissent, merci à la fibre optique d’Orange: une connexion optimale au site web qui gèrait les inscriptions le jour J nous a permis à ma femme et moi d’avoir chacun un visa. Pour ceux qui ne connaissent pas, le permis Vacances Travail permet de travailler (ou pas) pendant 2 ans au Canada, sans être lié à un employeur et sans avoir à prouver qu’on ne vole pas le travail d’un local. C’est définitivement la meilleure option pour partir, il est donc évidemment victime de son succès. C’est un programme d’échange et le fait qu’il y ait 5 fois plus de français qui veulent partir au Canada que de canadiens qui veulent venir en France n’aide en rien.

J’en profite pour adresser un grand merci à toute l’équipe de pvtistes.net qui fait un travail formidable pour expliquer comment le tout fonctionne, leur contribution est inestimable. C’est LE point de départ si l’aventure vous tente.

Quand je fais la rétrospective de l’année passée, notre départ au Canada me semble parfois relativement facile et sans encombres. En réalité cela aura été un ascenseur émotionnel continu, un rollercoaster comme on dit par ici ! Les doutes, les remises en question, la synchronisation de tous les processus administratifs, le risque financier (et toutes les dépenses), et certainement le plus dur: laisser toute le monde derrière, famille et amis.

En passant je reconnais l’apport énorme que sont Facetime, Skype et les autres moyens de communication modernes à ce sujet. Je n’ose pas imaginer vivre la même aventure 20 ans plus tôt, quand rien de tout cela ne permettait de rester connecté avec ses proches.

Bla, bla, bla… cet article est déjà assez long comme ça. On se reparle bientôt, avec un sujet plus dans la ligne éditoriale de ce blog : est-ce que la Business Intelligence est la même à Vancouver qu’en France ?