7. #JSS2015
• « La meilleure façon de prédire le futur
est de regarder le passé et le présent ! »
Introduction
• Pourquoi les architectures lambda ?
8. #JSS2015
• Historiquement, le BigData est une suite logique de la
B.I.
• Donc on a appliqué les techniques de la B.I. : Le Batch
• Ce n’est pas plus suffisant !
• Des flux de données à prendre en compte en temps-réel
• Des historiques très volumineux qui recèlent de la valeur
Introduction
Pourquoi les architectures lambda ?
10. #JSS2015
• La base de données classique :
• Ex d’une action utilisateur (changement d’adresse) :
• Chaque update écrase des données précédentes !
Principe de base
Architecture basée sur des données immuables
UPDATE
11. #JSS2015
• Stockage immuable :
• La mort de l’update, vive l’insert !
• Toute autre information peut être dérivée/reconstruite à partir de
ces données brutes
Principe de base
• Architecture basée sur des données immuables
13. #JSS2015
• Prenons un scénario Exemple :
– Site eCommerce / Retail
• Quels gains ?
• Analyse temps réel des comportements,
• Calcul du Taux d’abandon de panier,
• Prévision de stock
• Détection de Fraude
• Analyse d’une campagne marketing
• Quels produits ne déclenchent pas d’achat ? Problème de stock ? De
prix ?
Scénario
Architecture Lambda
16. #JSS2015
Azure Service Bus
Azure Service Bus
Relay
Queue
Topic
Notification Hub
Event Hub
NAT and Firewall Traversal Service
Request/Response Services
Unbuffered with TCP Throttling
Many publishers and many consumers to
communicate over a FIFO like channel.
(Competing consumers and Queue-based
Load leveling scenarios)
Pub / Sub communication channel. Each
Consumer subscribes to a copy of message
High-scale notification distribution
Most mobile push notification services
Millions of notification targets
18. #JSS2015
Event Hub : Principe général
Architecture Lambda
Event
Producers
Azure Event Hub
> 1M Producers
> 1GB/sec
Aggregate
Throughput
Up to 32 partitions via
portal, more on
request
Partitions
Direct
PartitionKey
Hash
Consumer
Group(s)
Receivers
AMQP 1.0
Credit-based flow control
Client-side cursors
Offset by Id or Timestamp
23. #JSS2015
Event Hub : Consommation multiple
Partition 1
Partition 2
Partition “n”
Consumer Group C
Callback for prtn. 6
Callback for prtn. 2
Worker “n”
Callback for prtn. 1
Callback “n”
Worker 1Consumer Group B
Callback for prtn. 6
Callback for prtn. 2
Worker “n”
Callback for prtn. 1
Callback “n”
Worker 1Consumer Group A
Worker “n”
Callback for prtn. 6
Callback for prtn. 2
Callback for prtn. 1
Callback “n”
Worker 1
28. #JSS2015
Données au repos
SELECT count(*) FROM ParkingLot
WHERE type = 'Auto'
AND color = 'Red'
Question
“Combien de voitures rouges dans le parking?”
Répondre avec une base de donnée relationnelle
Marcher jusqu’au parking
Compter les véhicules qui sont: Rouge, Voiture
29. #JSS2015
Données en mouvement
La question est différente
“Combien de voitures rouges sont passées au marqueur 18A sur l’A-10 dans
la dernière heure?”
Répondre avec une base de donnée relationnelle
S’arrêter, faire se garer toutes les voitures qui arrivent pendant l’heure dans
un parking, les compter
Pas la meilleure des solutions…
30. #JSS2015
L’avantage définitif
SELECT count(*) FROM A-10
WHERE Type = ‘Voiture’ and Color = ‘Rouge’
GROUP BY TumblingWindow(hour, 1)
La question est différente
“Combien de voitures rouges sont passées au marqueur 18A sur l’A-10 dans
la dernière heure?”
34. #JSS2015
• Agrégation simple :
– SELECT sensorId, MIN(temp) as temp
FROM SensorReadings
TIMESTAMP BY time
GROUP BY sensorId, SlidingWindow(second, 5)
HAVING MIN(temp) > 75
Exemples de requêtes
35. #JSS2015
• Agréagation plusieurs flux :
– SELECT s1.time, s1.dspl, s1.hmdt as previousHmdt, s2.hmdt as newHmdt, datediff(ss,
s1.time, s2.time) as secondsApart
FROM SensorData s1 timestamp by time
JOIN SensorData s2 timestamp by time
ON s1.dspl = s2.dspl
AND DATEDIFF(s, s1, s2) BETWEEN 0 AND 5
WHERE (s2.hmdt - s1.hmdt >= .1) or (s1.hmdt - s2.hmdt >= .1)
Exemples de requêtes
36. #JSS2015
• Jointure avec table de référence :
– SELECT SensorReadings.sensorID, SensorReadings.temp
FROM SensorReadings
JOIN thresholdRefData
ON SensorReadings.sensorID = thresholdRefData.sensorID
WHERE SensorReadings.temp > thresholdRefData.value
Exemples de requêtes
37. #JSS2015
• Plusieurs sorties :
– SELECT *
INTO outputLog
FROM SensorReadings
– SELECT *
INTO outputTempAlert
FROM SensorReadings
WHERE temp > 75
Exemples de requêtes
Performance du stockage
APPEND-only est très performant, ex. Hadoop/HDFS
Pensez-y, au cœur d’une base SQL, il y a un append-log, qui est le maître en cas de crash…
Robustesse aux erreurs humaines
Un bug ne viendra jamais détruire de la donnée, seulement ajouter des enregistrements erronés (ou doublonnés, ou…)
Facile à corriger :
Soit on vient supprimer les lignes erronées,
Soit on ajoute des lignes correctrices
La clé plus de différence entre les deux est balance. Un service de messagerie peut ramasser une sélection de forfaits et s'assurer qu'ils sont livrés. Mais si vous devez déplacer des centaines de milliers de paquets, vous pouvez le faire avec beaucoup de courriers, ou vous pourriez construire un centre de distribution capable de gérer ce genre de volume plus rapidement. Événement Hub est ce centre de distribution. Mais il est été construit comme un service géré, donc vous n'avez pas à construire votre propre installation coûteuse. Vous pouvez exploiter juste celui que nous avons créé pour vous
Here we have a simple sample implementation of the ProcessEventsAsync method. We have a try/catch block to handle errors, but within it a processing loop for the events. Inside this loop, we look at the event properties to help determine what type of event it is so we can deserialize the event and operate on it. I’m just writing it to the console, but in the real world, we may use this to notify an Orleans grain or save the data so that we can process it via an HDInsight cluster. For more about both of these options, be certain to check out the two sister sessions to this one tomorrow.
Lastly, note this block of code(1) where ever minute, we do a checkpoint operation. This tells the event hub that we’ve processed everything up to this point. Hence saving where we’re at in the event stream. This allows us to start and stop the processor and pick up near where we left off. This also really highlights the difference between event hubs and topics/queues. With topics/queues, the focus is more on ACID type operations again specific messages… put/get/delete… but in Event Hub, we have this buffered stream of events and we need to keep track of where we are in it. We can easily rewind to reprocess messages. So we need to account for this “at least once” possibility.
On parlait des speakers, il y a une chose qui leur tient à cœur !