J1 T1 5 - Stream Analytics - Cédric Charlier
- 1. BI & Data Architect Stream Analytics ou une nouvelle loi de l’action- réaction Cédric L. Charlier @Seddryck
- 2. In a nutshell Contributions open-sources Compétences Recognitions Agile data warehouse Orienté qualité Grand fan de l’automatisation Microsoft MVP Data Platform award Database architecture Data modeling Business intelligence Data warehousing ETL Olap/Tabular No SQL Big data Data analysis Stream analysis Machine learning Testing framework pour la BI www.nbi.io Autres projets sur github Deploiement SSRS – RsPackage TmBundle pour qques languages SSIS depuis .Net - Cassis Boites à outils pour la modélisation: ERMine et Tibre Et bien d’autres Experience 15 années d’experience avec SQL Server AzureData Platform Ancien consultant, travaillant en interne Elia Cédric L. Charlier @Seddryck seddryck.wordpress.com Data & BI architect
- 5. Cas d’usage du temps réel en BI?
- 6. Temps réel sur l’OLTP • Directement sur l’OLTP – Columnstore index – Direct Query
- 8. Agenda • Introduction (trop tard, c’est passé) • Event Hub • Azure Stream Analytics • Autres solutions (sur Azure) • Consommer les résultats • Intégrer ceci dans une architecture data warehouse
- 9. EVENT HUB La porte d’entrée des événements
- 10. Ingérer les données Event Hub
- 11. Event Hub • Event ingestor (porte-avant de la solution) • Découple la production d’événements (publishers) et la consommation (consumers) • « Low latency » et « High reliability »
- 12. Différences Messaging/Event Hub Messaging (queues et topics) • Sequencing • Dead-lettering • Transaction support Event Hub • Excellent débit • Flexibilité dans le traitement en aval • Protocoles – Publishers : HTTPS et AMQP 1.0 – Consummers : AMQP 1.0
- 13. IoT Hub vs Event Hub IoT Hub • Bi-directionnel • Protocole supp. MQTT • Sécurité plus granulaire (device) • Meilleur monitoring • Davantage scalable • Routing plus facile • Plus complet/puissant que Event Hub • A utiliser en combinaison • IoT Hub à l’avant • Event Hub dans la chaine
- 14. Event publishers (Event Hub) • Protocol – HTTPS – AMQP 1.0 • Identification – Shared Access Signature (SAS) token • Resource URI being accessed • Expiry signed with a configuration key – Common SAS token
- 15. • Chaque « consumer » lit un sous-ensemble (partition). • Les partitions facilitent le « scale-up » horizontal • Elles sont davantage liées au nombre de « consumer » concurrents qu’au débit d’ingestion • Un seul « consumer » par partition à un moment donné ! • AMQP Push et pas pull (HTTP GET) Partitions et « consumers » (Event hub)
- 16. Prix et configuration • Pricing (Basics) – 2,4 eurocents par million d’événements – 1,3 eurocents de l’heure (+/- 10€/mois) • Throughtput unit (débit) – Ingress: Max. 1MB/s ou 1000 événements/s – Egress: Max. 2MB/s – Maximum 20 unités
- 17. AZURE STREAM ANALYTICS Le moteur de décision
- 18. Des données à l’information
- 19. Des données à l’information Job stream analytics
- 20. Agrégations • AGV, MAX, MIN, SUM, COUNT • STDEV, STDEVP, VAR, VARP • CollectTop retourne un tableau d’événements ordonnés • TopOne retourne le premier élément selon une clause d’ordonnancement
- 21. Concept de fenêtres (windows) • Tumbling, hopping, sliding • De longueurs fixes • Chaque événement est lié (ou pas) à une fenêtre en fonction de son timestamp • A utiliser avec la notion de GROUP BY
- 22. Tumbling • Toutes les 10 secondes me donner le nombre d’événements capturés durant cette période 1 2 3 40 10 20 30 1 2 3 4
- 23. Hopping • Fenêtres se chevauchent • Toutes les 5 secondes me donner le nombre d’événements qui ont été capturé lors des 10 dernières secondes
- 24. Hopping 1 2 3 40 10 20 30 1 2 2 3 3 4
- 25. Sliding • Fenêtres créées en fonction des événements • A chaque événement me dire combien d’autres été créés dans la période de 10 secondes précédente
- 26. Sliding 1 2 3 40 10 20 30 1 2 5 32 32 4 3 4 5
- 28. Relier plusieurs flux • Différents inputs – Corrélation entre deux valeurs • Self-join: se relier à soit même – Détecter une augmentation/diminution • INNER ou LEFT OUTER
- 30. Données de référence • Corrélation entre des événements et des données de référence – Données changeant lentement ou pas • Même expérience que la jointure mais sans le contexte temporel
- 32. AUTRES SOLUTIONS DANS AZURE Quand Azure Stream Analytics ne suffit plus
- 33. Points forts de Azure Stream Analytics • Quelques lignes de code pour une fonction analytique • SQL-based syntax • Natif « scale-out » • Intégration avec Event Hub
- 34. Scale-out • Attention aux partitions! – Même clés traitées par la même partition – PARTITION BY … à chaque étape (WITH) • Pas de parallélisme possible si – La sortie n’est pas Event Hub ou Blob – Différence entre le # de partitions input/output
- 35. Points faibles • Pas de transformation des données • Support de formats limités (csv, json et avro) • Pas extensible
- 36. Apache Storm • Open-source mais supporté par Microsoft • Gestion d’un cluster de jobs (ou batchs) pas de jobs • Prix par cluster et pas par job
- 37. Apache Storm (experience dev.) • Pas de SQL-like mais du C#/Java • Pas d’opérateur temporal natif • Pas de support late-arrival • Développement via Visual Studio • Logs plus aboutis
- 38. Apache Storm (extensibilité) • Support de UDF/extensions • Tout format d’input • Connecteurs natifs mais également développables • Machine learning via Storm Bolts
- 39. Quand? Quoi?
- 40. POWER BI, MACHINE LEARNING, STOCKAGE, … Là où l’action est exécutée
- 41. Pour faire quoi? • Visualiser le résultat • A nouveau traiter ce résultat dans un autre flux – Conserver la nature « flux » • Stocker le résultat
- 42. Quelles sorties (Stockage) • Azure Data Lake • SQL Database • Blob storage • Table storage • Document DB
- 43. Quelles sorties (2) • Continuer à travailler sur le flux – Event Hub – Service Bus (Queue & Topics) • Affichage – Power BI
- 44. Et autres …
- 46. ARCHITECTURES Vue complète sur la solution BI
- 47. Lambda architecture Speed layer Events Batch layer Servinglayer Query • Données récentes uniquement • Données “impures” • Calculs dynamiques • Latence minimum/notion de stream • Données non-mutables, append-only • Données purifiées • Pré-calculs lourds des vues • Notion de batch (1x/nuit) • Stocke les résultats des autres layers • Réconsillie les données en provenance des deux autres layers
- 48. Lambda architecture on Azure Speed layer Events Batch layer Servinglayer Query
- 49. Lambda architecture on Azure (2) Speed layer Events Batch layer Servinglayer Query
- 50. Lambda architecture on Azure (3) Speed layer Events Batch layer Servinglayer Query
- 51. Cloud’s Natives Merci beaucoup à nos sponsors ! Thank you to all our sponsors! Join the conversation #MSCloudSummit @MSCloudSummit
- 52. Merci Beaucoup! Thank you! Join the conversation #MSCloudSummit @MSCloudSummit