sur le site d’Apache Beam.
Si le sujet vous intéresse, Kenneth Knowles conseille la lecture de l’article The World Beyond Batch : Streaming 101 et The World Beyond Batch: Streaming 102.
Slava Chernyak (Google Inc.)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49605
TL;DR : Salva Chernyak entre pour cette présentation dans les détails du fonctionnement des watermarks dans Google Dataflow, un des environnements d’exécution du projet Apache Beam présenté ci-dessus.
Salva présente sommairement Apache Beam et il est regrettable que cette session ait eu lieu avant celle sur les triggers. Nous vous conseillons de lire la synthèse ci-dessus sur les triggers avant celle-ci.
Un exemple de traitement batch est pris en exemple : des données textuelles sont lues, des tags extraits, un comptage est effectué et les 3 tags les plus occurrents sont retournés. En rajoutant simplement une instruction de fenêtrage et en lisant depuis système de pub-sub, on passe d’un code qui fonctionnait en batch à un code en streaming.
Toutefois, dans le cas d’un traitement batch, on travaille sur des données qui sont délimitées, et il est en général simple de savoir si toutes les données attendues sont présentes. En streaming, certaines données peuvent arriver en retard, et ne pourrons être inclues dans la bonne fenêtre, sans que nous puissions le savoir à l’avance.
Il faut donc qu’à chaque étape du workflow, on puisse savoir si toutes les données nous sont arrivées ou si certaines sont en retard. Le mécanisme de watermark résout ce problème : c’est une métrique basée sur des heuristiques, qui permet d’estimer le progrès d’une tâche à chaque étape. En pratique, si le watermark sur une étape de fenêtrage est à 2:00:00, cela permet d’avoir la garantie que nous avons bien reçu tous les événements avant ce timestamp. On peut ainsi fermer notre fenêtre en étant sûrs de ne pas rater d’événements en retard.
Dataflow implémente leur propre système de watermark pour l’ensemble de l’API d’Apache Beam : il faut cependant implémenter sa propre logique de watermark si, par exemple, l’on décide de créer sa propre source de données.
Les slides entrent davantage dans le détail et sont disponible à cette adresse : goo.gl/K4FnqQ.
Xavier Léauté (Metamarkets)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49606
TL;DR : Présentation d'une architecture lambda à forte charge s’appuyant sur les outils susnommés.
Xavier Léauté, ingénieur à Metamarkets, présente un REX sur l’architecture déployée et nous parle des challenges rencontrés pour absorber 300 milliards d'évènements par jour et répondre à 100 milliards de transactions.
L’architecture mise en place chez Metamarkets est une architecture lambda, il y a donc une partie batch et une partie streaming. Celle-ci est composée comme suit : en frontal d’un load balancer à base d’AWS ELB pour répartir la charge entre brokers Kafka, à partir de ces brokers la donnée sera soit stockée dans S3 pour être traitée avec Spark en batch puis insérée dans Druid, soit ingérée par Samza en streaming puis entreposée dans Druid (système de stockage qui sera décrit plus loin sur le fil du REX).
Le nombre d'évènements reçus par jour et la charge des requêtes à servir leur a fait toucher des points sensibles de chacun des outils, uniquement visibles quand l’on commence à scaler horizontalement à grande échelle. Ainsi Mr Leauté nous fait un retour d'expérience sur les problèmes rencontrés avec certains outils dans leur contexte particulier.
Kafka par exemple à partir de 100 noeuds commence à générer des saturations de réseau lors de l'ajout de partition ou de noeuds supplémentaires. Ou encore dans l’éventualité où vous perdez un noeud Kafka, à son retour les données y seront répliquées avec le timestamp de la nouvelle réplique et pas celui de la donnée originale, ceci engendrant des erreurs au niveau fonctionnel de l’application.
Sur la fin de l’exposé, l'accent est particulièrement mis sur Druid. Celui-ci est au coeur du système de leur architecture lambda mais il est aussi un système de remontée de métrique sur toute la chaîne d'ingestion de donnée. Ce qui implique à la fois de l’ingestion de donnée et du requêtage de la part d’applications tierces.
Druid est dépeint comme un système de stockage de donnée orienté colonnes rapide et capable de stocker des séries temporelles. Plusieurs avantages selon le speaker qui est aussi un commiteur Druid : pas de downtime, mise à jour ou remplacement de noeud à chaud sans aucun impact, les composants ne conservent pas d’état et il est possible de faire du memory mapping ainsi que de la priorisation de requêtes.
En résumé, un REX intéressant sur une architecture à forte scalabilité et les challenges associés ainsi qu’un chapitre éducatif sur les possibilités de Druid.
Neha Narkhede (Confluent)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49703
TL;DR : Présentation de Kafka Streams et de ses fonctionnalités par Confluent.
Neha Narkhede, ancienne de LinkedIn et nouvellement cofondatrice de Confluent présente le dernier outil construit par dessus Kafka : Kafka Streams.
Kafka Streams, contrairement à Samza ou Flink, est simplement une librairie et non un service. Il se compare à ceux-ci puisque le but du produit est également de faire du stream processing.
De nombreuses fonctionnalités et points de comparaisons avec les autres frameworks ont été annoncés. En voici quelques uns :
Il est également fait mention de Kafka Connect qui sert à prendre la donnée sur Kafka et l'insérer dans divers systèmes de stockage distribué.
Pour conclure, ce talk visait principalement à présenter le produit qui apporte un framework de calcul à la plate-forme Confluent ainsi que quelques autres nouveautés. Des compléments sur Kafka Streams sont disponibles ici.
Vida Ha (Databricks), Prakash Chockalingam (Databricks)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49697
TL;DR : Présentation des fonctionnalités utiles de Spark sur le streaming, plus des fonctionnalités de Spark que de réels patterns d'architecture.
Deux speakers de Databricks sont venus présenter des patterns d'architecture de Streaming applicables à Spark.
Le talk débute avec un rappel succinct de ce qu'est l'outil Spark Streaming et dans quel cas son utilisation est appropriée.
Le reste de la présentation sera principalement axé sur des fonctionnalités de Spark Streaming qui permettent d'optimiser le temps de processing sur du streaming mais pas de réels patterns qui impliqueraient d'autres outils comme Kafka ou un système de stockage.
Au programme des features Spark :
En résumé, les speakers sont revenus sur un certain nombre d'optimisations intéressantes sur l'outil mais pour la plupart déjà connues si vous avez lu la documentation. De plus la nouvelle version 2.0 de Spark pourrait encore changer les choses.
Beaucoup de retours d’expériences et de technologies de streaming cette année ! Rendez-vous sur la deuxième partie de l’article pour les sessions orientées sur les autres technologies abordées, la donnée, et le futur !