[USI] Lambda-Architecture : comment réconcilier BigData et temps-réel

www.usievents.com #USI2014

Lambda-architecture

ou comment réconcilier les Big-Data avec le temps réel

Mathieu DESPRIEE

@mdeocto


λ-ARCHITECTURE

Quels use-cases ?

Qu’est-ce que la lambda-architecture ?

Quels sont ses principes, comment elle se construit ?

Quelles technologies pour l’implémenter ?


Origines

manning.com/marz

Nathan MarzEx-Backtype & Twitter

Initiateur des frameworksStorm

Cascalog

ElephantDB

BacktypeCapture d’événements et de logs Twitter pour analyse

25 TB binary data

100 Billions of records

400 QPS Average

http://manning.com/marz

http://manning.com/marz


BigData + Temps Réel :Pour quels use-cases ?

Recommandation en temps-réelPrise en compte de la navigation récente, geolocalisation

Pour : re-marketing, publicité en ligne…

Surveillance de larges infrastructures Telcos, Industrie, grands data-centers…

Smart-metering

Agrégation de données financières à l’échelle d’une banque

Internet des objets

…

Des flux de données à prendre en compte en temps-réelDes historiques très volumineux qui recèlent de la valeur


Prend en charge toutes les donnéesqu’elles soient historique ou datent de la dernière seconde

Capable de répondre à n’importe quel type de requête

analytique, datamining, search…

Tolérant les pannes

Robuste aux évolutions, aux erreurs

Scalable :x 10 TB en stockagex 1’000 evt / secondx 100 query / second

Basse latence en écriture ET en lecture

Le système BigData à construire

dataflow

big data system

queries

application


De quelles données parle-t-on ?

un tweet

un utilisateur qui se loggue

un utilisateur qui donne une nouvelle adresse

un hit sur un serveur web

un paiement

une métrique d’infrastructure

Tout est événementdes faits

datés

immuables (« éternellement vrais »)


La bonne vieille base de données

Ex d’une action utilisateur (changement d’adresse) :

Le problème : chaque UPDATE détruit les informations précédentes

UPDATE


Stockage immuable

Pas d’UPDATE, seulement des INSERT

Toute autre information peut être dérivée/reconstruite à partir de ces données brutes


Immuabilité : quels gains ?

Performance du stockageAPPEND-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 humainesUn 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


Principe #1

Une architecture basée sur des données immuables


Prend en charge toutes les donnéesqu’elles soient historique ou datent de la dernière seconde

Capable de répondre à n’importe quel type de requête

analytique, datamining, search…

Tolérant les pannes

Robuste aux évolutions, aux erreurs

Scalable :x 10 TB en stockagex 1’000 evt / secondx 100 query / second

Basse latence en écriture ET en lecture

Le système BigData à construire

dataflow

big data system

queries

application


query = function ( ALL data )


ALL DATA

precomputedview

query

( ie. on sépare les problèmes : stockage, calcul, lecture )

Principe #2

Une architecture basée sur des vues précalculées


hashtag hour_range count

#usi2014 09:00 12

#usi2014 10:00 138

#usi2014 11:00 12543

#lambda 11:00 42

… … …

hashtag day_range count

#usi2014 15/06 12

#usi2014 16/06 138

#lambda 15/06 5

… … …

hashtag user count

#lambda @mdeocto 5

#lambda @nathanmarz 2045

#lambda @mhausenblas 230

… … …

Vues précalculées

Pour chaque classe de requête, on précalcule des vues dédiées

dénormalisées

indexées

rapides à requêter

supportant des opérations simples (sum, count…)


SERVING LAYER

SPEED LAYER

BATCH LAYER

DATA FLOW QUERIES

λ-ARCHITECTURE

REAL TIMESTREAM

PROCESSING

BATCHPROCESSING

PRECOMPUTED

VIEWS


BATCH LAYER


DATA FLOW QUERIES

BATCH LAYER

BATCHPROCESSING

« BATCH VIEWS »

Batch Layer

Stockage maître + traitements batch

MASTER DATA


Batch Layer : quelle techno ?

Besoins :Stockage scalableTolérant aux pannesRobuste

notamment aux évolutions de schéma

Permettant tout type de processing


SERVING LAYER


real-timeprocessing

SPEED LAYER

REAL TIMESTREAM

PROCESSING

DATA FLOW QUERIES

BATCH LAYER

SERVING LAYER

Vues précalculées

2

1batch processingfull dataset

BATCH VIEWDATABASE

publish


Stockage des vues : quelle techno ?

Besoins :Ecritures massivesLectures indexées (accès aléatoire) à faible temps de réponseScalable et tolérant à la panne


maintenant

TEMPS

Données prises en comptedans les batch views

Pas encore absorbées

QUELQUES HEURESDE DONNÉES


SPEED LAYER


SPEED LAYER

REAL TIMESTREAM

PROCESSING

DATA FLOW QUERIES

Speed Layer

Le rôle du speed layer est de mettre à jour des vues, en continu, de manière incrémentale

La latence de traitement doit être de l’ordre de 10ms à qqs secondes

« REAL-TIME VIEWS »


Speed layer : caractéristiques recherchées

Traitement en continu (stream processing)

Architecture asynchrone, distribuée et scalable

Tolérant à la panne

Si possible avec des garanties de traitementcapacité à rejouer automatiquement des messages en cas de perte d’un nœud


Speed layer : technologies

Pour des petites topologies : Queues + Workers

Storm

Spark


Focus : Storm

Framework initié par N. Marz

Storm est un framework de traitement distribué orienté flux d’événements prenant en charge :

management de multiple nœuds

queueing, routage

serialisation / de-serialisation

reprise sur panne

Storm est nativement distribué, performant, tolérant les pannes, et permet de garantir le traitement des événements


SPEED LAYER

REAL TIMESTREAM

PROCESSING

DATA FLOW QUERIES

Real-time views

Les vues produites doivent pouvoir être requêtées de façon intensive et performante

temps de réponse court

et fort débit de requête attendu

« REAL-TIME VIEWS »

SERVING LAYER


Real-time views : quelle techno ?

Besoins :Doit supporter de fortes sollicitations en lecture (requêtes) et écritures (mises-à-jour incrémentales)Doit être scalable et tolérant à la panneDes fonctions avancées peuvent être utiles à ce niveau

ex : compteurs atomiques distribués, structures type hashsets…


…pour finir…


SERVING LAYER QUERIES

Fusion des données batch et real-time

La logique de fusion est un développement custom qui dépend des vues et de leur modélisation

Pas un sujet facile : expiration des vues

recouvrement possible entre données batch et temps-réel

…

real-timeviews

batchviews


SERVING LAYERDATA FLOW QUERIES

SPEED LAYER

BATCH LAYER

real-timeprocessing

REAL TIMESTREAM

PROCESSING

BATCHPROCESSING

PRECOMPUTED

VIEWS

λ-ARCHITECTURE


Mathieu DESPRIEE

@mdeocto


Backup


BATCH LAYER SPEED LAYER

Persistance Données maîtres Données volatiles

Type de calcul Full-scan Incrémental

Latence des traitements Heures / Jour Secondes

Cohérence vs. Fraicheur Données cohérentes à terme

Données fraiches mais calculs moins précis

Contrainte hardware CPU-boundDisk-bound

Memory-bound

Exemple de tradeoff possible dans la conception

Preprocessing ++Batch views + rapidesDurée processing ++

Taille des vues temps-réèl ++Imprécision ++


Eventual accuracy (précision à terme)

Certains calculs sont difficiles à réaliser en incrémental

ex. Visiteurs uniques d’un site web

un comptage exact nécessite de conserver toutes les visites en mémoire

Une alternative : HyperLogLog est un algorithme qui permet de faire une approximation d’un unique count, avec un espace mémoire très limité

ex2. Le visiteur navigue sur mon site en anonyme, puis se loggue. On ne peut savoir que le visiteur est unique qu’après cette opération de login…

Seules les vues batch peuvent calculer cette information précisément

[USI] Lambda-Architecture : comment réconcilier BigData et temps-réel

Technology

Transcript of [USI] Lambda-Architecture : comment réconcilier BigData et temps-réel