Retours de Strata + Hadoop World 2016 - Partie 1
Nous proposons de découper ce compte-rendu en deux parties. Dans ce premier article, nous nous focaliserons les retour d’expériences de technologies en production (nous parlerons Kafka, Spark, Hadoop, architecture Kappa, Docker, etc.) et sur les technologies de streaming (Apache Beam, Kafka Streams, Samza, Spark Streaming...). Dans le second article, nous nous concentrerons sur les autres technologies abordées pendant la conférence (Apache Nifi, Apache Drill, GPU, Hadoop Recordservice…), sur les sujets liées à la donnée (traitement du langage, data-driven business, partage de la donnée...), et nous terminerons par quelques inclassables futuristes ou philosophiques (le futur de l’IA, le futur d’Hadoop, le relativisme des données…).
Liste des sessions :
Putting Kafka into overdrive Using Spark and Hadoop in high-speed trading environments Scaling out to 10 clusters, 1,000 users, and 10,000 flows: The Dali experience at LinkedIn Floating elephants: Developing data wrangling systems on Docker Kappa architecture in the telecom industry The evolution of massive scale data processing Triggers in Apache Beam: user-controlled balance of completeness, latency and cost in streaming big data pipelines Watermarks: time and progress in streaming Dataflow and beyond Streaming analytics at 300 billion events per day with Kafka, Samza, and Druid Introducing Kafka Streams, Apache Kafka's new stream processing library So you think you can stream: Use cases and design patterns for Spark Streaming
Putting Kafka into overdrive
Gwen Shapira (Confluent), Todd Palino (Linkedin)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49455
TL;DR : Gwen Shapira, commiter Kafka chez Confluent et Todd Palino, Software Reliability Engineer responsable de Kafka chez Linkedin, ont présenté lors de cette session une mine d’information sur la manière d’opérer un cluster Kafka en production.
Dans une première partie, Todd a partagé avec l’audience un certain nombre de recommandations pour tuner Kafka : le broker lui-même, le hardware, l’OS, Java, etc. Puis il a exposé toutes les métriques qu’il convient de superviser pour comprendre et prévenir un problème avec un broker Kafka. Todd est par ailleurs le comitteur principal du projet Burrow (https://github.com/linkedin/Burrow), qui permet de superviser les consommateurs Kafka. Confluent met pour sa part à disposition une solution de monitoring appelée “Control Center”, qui n’est toutefois présente que dans son offre entreprise payante.
Gwen a ensuite argué du fait que dans la moitié des cas, un problème Kafka n’est pas lié au broker, mais au client (consommateur ou producteur). Elle a détaillé les pistes à suivre pour déterminer si un problème vient du client ou du broker. Il faut en retenir que les clients ne peuvent pas traiter Kafka comme une boite noire : ils doivent avoir une connaissance de son fonctionnement, et accepter de travailler en bonne intelligence avec les personnes qui opèrent le broker.
La liste des points à tuner et superviser pour bien faire tourner Kafka en production ne rentrerait pas dans cette synthèse : nous vous invitons à consulter les slides !
Les slides sont disponibles à cette adresse :
http://fr.slideshare.net/ToddPalino/putting-kafka-into-overdrive.
Using Spark and Hadoop in high-speed trading environments
Fergal Toomey (Corvil)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49722
TL;DR : Quelle architecture à mettre en place pour faire du monitoring de High Speed Trading ? En bref : Kafka, Spark Streaming, HBase, Phoenix et Tableau.
Ce talk était donné par Fergal Toomey de la société Corvil qui se spécialise dans la mise en place d'architectures pour faire du monitoring de système High Speed Trading (HST).
Le but de l’exposé était de nous présenter les choix architecturaux faits par Corvil pour superviser les systèmes de trading sans introduire de latence. Bien sûr, comme nous nous en douterons, la latence est une variable importante puisque plus vos systèmes sont rapides, plus vous êtes profitables, puisque vous réagissez avant la concurrence. Cependant, Mr Toomey observe que les efforts déployés pour atteindre des latences toujours plus faibles lors de l’émission d’une transaction deviennent superflus au vu des latences supplémentaires et aléatoires introduites par des organismes intermédiaires entre l’émetteur et le marché.
Une longue partie de la présentation était donc axée sur la présentation du métier de la société Corvil comprenant une mise à niveau sur le cycle de vie d’une transaction émise (intermédiaire, régulation, feedback sur transaction accomplie, etc…) ainsi qu’un état de l’art des performances des systèmes mis en place à ce jour.
Vers la fin de la session, on apprend quelle architecture de monitoring des systèmes HST Corvil a mis en place : des appliances dédiées conçues par leurs soins et installées chez les clients se chargent de mettre les informations nécessaires (fichier de logs) sur des topics Kafka. Vient ensuite Spark Streaming pour effectuer des jointures complexes (jusqu'à 10 streams de données différents à joindre, avec les challenges qui en découlent) et corréler les trades émis avec les feedbacks reçus (complexe à cause du format de la donnée renvoyée sur la boucle de feedback). Un cluster HBase est utilisé pour stocker les résultats avec une surcouche Phoenix pour pouvoir effectuer du SQL classique sur HBase qui est orienté familles de colonnes. Pour finir Tableau est connecté à HBase via Phoenix pour effectuer des analyses statistiques visuelles et détecter les erreurs dans les transactions envoyées.
Scaling out to 10 clusters, 1,000 users, and 10,000 flows: The Dali experience at LinkedIn
Carl Steinbach (LinkedIn)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49741
TL;DR : Comment gérer le cycle de développement applicatif sur des clusters multi-versions et multitenants.
Actuellement, l’infrastructure LinkedIn est composée de 10 clusters Hadoop pour un total de 10000 noeuds qui sont exploités par 1000 users. Cette masse d’utilisateurs de background divers travaillant sur de multiples clusters avec de nombreux produits de version différentes génère un nombre incalculable de mauvaises pratiques ralentissant considérablement l’avancée des projets et le suivi applicatif associé. Carl Steinbach nous propose de présenter une solution made in LinkedIn à ce challenge considérable.
En premier lieu Mr Steinbach nous rappelle que l’approche des plus évidentes, celle d’un cluster unique de 10000 noeuds, a déjà été testée et n’a pas été jugée viable pour des questions de limitations au niveau du système de stockage. Si bien qu'ils se sont rabattus sur des clusters plus petits avec load balancing entre chacun pour repartir les requêtes, ce qui a conduit à la réflexion d’aujourd’hui.
Le réel impact sur le déroulement des projets aujourd’hui provient du fait que chaque utilisateur chez LinkedIn a des besoins différents que ce soit pour les sources de données à croiser, les formats de données ou les mises en forme à appliquer pour les applications liées à leur coeur de métier. A ceci se rajoute les différentes version de chacun des produits manipulés par ceux-ci.
La conséquence principale de ces contraintes fut que chaque utilisateur dupliqua les données de la source avec un format et une normalisation correspondant aux besoins de son application. Avec cette pratique appliquée sur une échelle de 1000 users, les sources de données ont donc été copiées et modifiées à la marge des dizaines de fois par cluster sous des formes utilisables seulement par l’instigateur de la copie. Ceci occasionnant du même coup des latences au niveau du système de fichier ainsi qu’une perte de contrôle des sources de données.
Pour faire face à cette évolution de la volumétrie, Mr Steinbach a créé DALI, une API pour récupérer de la métadonnée sur les sources de données. Le but de l'API étant de découpler les producteurs de la donnée de ses consommateurs. L'API permet de façon générale aux consommateurs d'obtenir des renseignements sur chaque dataset e.g. chemin sur HDFS, format de stockage, schéma, partitionnement, indexing, etc... ainsi qu’une interface de requêtage de celui-ci appelé View. C’est principalement sur ce sujet que Mr Steinbach s’est concentré.
Pour chaque source de données (principalement stockée dans Hive) de multiples Views sont créées et représentent différentes façons de lire cette donnée avec des formats de données et normalisations variés. Ces Views sont maintenues par les producteurs de la donnée dans un gestionnaire de code et profitent des UDFs (User Defined Function) pour fournir les transformations du jeu de données brut. Ces UDFs sont également versionnées. Ainsi chaque développeur est à même d’utiliser une certaine version d’une View représentant, par exemple, un certain formatage de la donnée originale et utilisant des UDFs compatible avec la version de son application sans pour autant copier la donnée.
Dans le cas où le développeur ne trouverait pas son bonheur, il est alors possible de soumettre des changements sur le système de versioning qui seront approuvés ou non par les producteurs des datasets.
Grâce à DALI, le contrôle de la donnée est donc de nouveau entre les mains des producteurs qui maintiennent les manières de lire celle-ci et peuvent empêcher sa copie directe ainsi que la surcharge en découlant.
Floating elephants: Developing data wrangling systems on Docker
Seshadri Malahingam (Trifacta)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49727
TL;DR : Comment utiliser Docker pour déployer des environnements de développement Hadoop
Mr Seshadri Mahalingam présentait la démarche itérative entreprise par Trifacta et Docker pour combler le fossé séparant le développement et la production lors du développement d'applications Hadoop.
Aujourd'hui, plusieurs stratégies existent pour faire collaborer des développeurs sur ce type de projet. Vous pouvez soit avoir un cluster de développement par équipe de développement, soit un cluster commun à toutes vos équipes ou alors un cluster par poste de développement et ce pour que chaque développeur soit à même de tester son application. Chacune de ses approches a des défauts majeurs allant de la lourdeur de la maintenance de configuration iso-production à la consommation excessive de ressources en passant par les problématiques de partage de la donnée et les conséquences d'une panne software ou hardware sur le rythme des développements...
La solution détaillée lors de la présentation est le fruit de plusieurs itérations afin de trouver le meilleur compromis en terme de performance, modularité et simplicité. Elle tire parti des Docker Networks combiné à un set de containers docker, ces containers étant reliés sur ce réseau. Chaque image de container peut correspondre à un service (par exemple HBase ou HDFS) d’une plateforme (Cloudera, Hortonworks ....) dans une version bien définie (2.3, 2.4 dans le cas Hortonworks) ou à une image de la configuration de l’un de vos environnements, le plus souvent celui de production.
En employant cette approche, un développeur peut facilement déployer sur son poste un Docker Network, choisir les conteneurs de services correspondant au projet qu'il développe (par exemple une stack à base de HBase, Spark et Kafka) et les ajouter au réseau. Puis ajouter un conteneur de configuration iso-production. Cet environnement iso-production lui permettra alors de tester ses applications.
Cette réponse permet à chacun des développeurs d'avoir un environnement personnalisé en fonction de son projet et d’orchestrer plus rapidement les déploiements d’application. En utilisant Docker, il est également possible de déployer des environnements sur des usines de développements (UDD) comme sur le poste de développement. Toutes les images Docker peuvent être versionnées et maintenues par des opérationnels qui sont alors garants de leur intégrité.
Kappa architecture in the telecom industry
Ignacio Manuel Mulas Viela (Ericsson), Nicolas Seyvet (Ericsson AB)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49506
TL;DR : Ericsson fait un retour d’expérience sur une architecture Kappa basée sur Kafka et Apache Beam sur Flink pour implémenter de la détection de fraude en streaming et en batch.
Ericsson a besoin de faire des analyses statistiques sur des événements, et en particulier de la détection d’anomalies/de nouveauté. Ils souhaitent faire ces traitement à la fois en batch, donc sur des données bornées, et en streaming, sur des données non bornées. Pour répondre à ce besoin, une solution classique est d’adopter une architecture Lambda, constituée de deux pipelines indépendants, avec des codes différents. Cette solution est toutefois complexe à maintenir et la fusion des données des deux pipelines peut être complexe.
La décision est prise de mettre en place une architecture Kappa (voir le post de blog initial qui a proposé cette architecture : https://www.oreilly.com/ideas/questioning-the-lambda-architecture). Dans cette architecture, toute donnée est considérée comme un flux : les traitements batch sont également traités par le moteur de streaming. Les garanties de cohérence d’Apache Storm sont alors considérées comme insuffisantes : il n’est pas possible de récupérer des données perdues par Storm. D’autres moteurs de streaming sont donc considérés : Millwheel, Spark Streaming et Flink.
La pile technique se constitue finalement des briques suivantes : Apache Beam est choisi car il constitue une interface unifiée pour le batch et le streaming, avec Apache Flink comme moteur d’exécution sous-jacent. La donnée brute provient d’une file Kafka, elle est envoyée pour analyse dans Flink, puis la donnée enrichie est réintégrée dans Kafka pour être enfin insérée dans Elasticsearch, et visualisée grâce à Kibana. Les modèles de détection d’anomalies évoluent alors avec le temps : détecteur bayesien, puis extraction d’informations de fréquence via Flink en amont du détecteur.
Les présentateurs se disent satisfaits de l’utilisation des API d’Apache Beam avec Flink pour former une architecture Kappa qui unifie le streaming et le batch. Il leur a donc été possible d'entraîner un algorithme de machine learning avec des données en flux, en les traitant dans Apache Beam comme des transformations complexes (il faut simplement que l’algorithme puisse être entraîné au fur et à mesure).
Si le sujet vous intéresse, un article de blog reprenant le contenu de la session a été posté : https://www.oreilly.com/ideas/applying-the-kappa-architecture-in-the-telco-industry.
The evolution of massive scale data processing
Tyler Akidau (Software engineer, Google)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49760
TL;DR : Tyler Akidau adopte dans cette session une vision rétrospective très intéressante du traitement de données massives chez Google, à travers une évocation chronologique des différentes technologies utilisées, depuis MapReduce jusqu’à Apache Beam avec Google Dataflow.
L’histoire commence en 2003 avec l’utilisation de MapReduce, qui répond au besoin initial de traiter les données de manière scalable et tolérante à la panne. Mapreduce sera abandonné chez Google à partir de 2014. Apparaît ensuite Hadoop qui implémente MapReduce dans une solution open source ; ce projet fait naître un véritable écosystème open source autour des problématiques Big Data. FlumeJava, en 2007, apporte une couche d’optimisation et d’orchestration de haut niveau qui n’était pas inclus dans Hadoop.
Storm, arrivé en 2010, permet de traiter des données massives en temps réel. Il offre une latence faible mais une cohérence faible (des données peuvent être perdues) et entraîne la création de l’architecture Lambda. Si cette architecture permet de gérer à la fois des traitements batch et streaming, elle apporte toutefois une complexité non négligeable. Spark, en 2009, puis sa version Spark Streaming, apporte des fonctionnalités de fenêtrage avec des garanties de cohérence fortes, même si il ne supporte pas le “out of order processing” (cette fonctionnalité arrive avec Spark 2.0 en 2016).
MillWheel, un produit Google, voit le jour en 2007 et se concentre sur la réduction de la latence, la cohérence de la donnée et le processing “out-of-order” (pouvoir gérer des événements dans un ordre différent que l’ordre d’arrivée): il introduit des mécanismes de timers et de watermark (voir la session sur les watermarks) pour permettre le fenêtrage de données qui arrivent en retard, après la fermeture de la fenêtre. Nephele (ancêtre de Flink), dont la version 1.0 date de 2009, utilise un mécanisme pour permettre ce processing “out-of-order” : c’est le premier produit open source à proposer véritablement cette fonctionnalité. La version 1.0 de Flink arrivera en 2016.
En 2013, Google crée Dataflow, qui vise à unifier les traitements batch et streaming, en donnant la possibilité de gérer tout le spectre entre ces deux extrêmes. Il propose une API basée sur des transformations (what ?), du fenêtrage (where ?), des mécanismes de watermark et de triggers (when ?), et des options d’accumulation (how ?). Je vous invite à lire la session sur les triggers pour plus d’information. Enfin, Apache Beam (en incubation), créé en 2016, vise à être la lingua franca open source pour le traitement de données unifié. Il propose une API extensible qui reprend les quatre volets de Cloud Dataflow, et qui s’exécute sur le “runner” de son choix. Pour l’instant, les runners disponibles sont Flink, Spark, Google Cloud Dataflow, et le run local.
Les slides sont disponibles ici : https://docs.google.com/presentation/d/13YZy2trPugC8Zr9M8_TfSApSCZBGUDZdzi-WUz95JJw
Triggers in Apache Beam: user-controlled balance of completeness, latency and cost in streaming big data pipelines
Kenneth Knowles (software engineer at Google), comitteur fondatuer d’Apache Beam
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49592
TL;DR : Kenneth Knowles expose dans cette session comment Apache Beam permet de dépasser la dichotomie batch/streaming, en contrôlant l’équilibre entre complétude de la donnée, latence et coût de traitement.
L’importance à donner à chacun de ces critères dépend du cas d’usage. Par exemple, pour le calcul d’une facture, la complétude de la donnée est le critère le plus important, tandis que la latence et le coût réduit sont peu importants. Au contraire, pour une tâche d’estimation de facture, la complétude est moins importante, mais la latence et le coût réduit le sont.
Avant de rentrer dans l’API d’Apache Beam, rappelons la différence entre deux concepts : l’event time (le moment où un événement s’est produit) et le processing time (le moment où un événement est reçu et traité par un programme). Le processing time est toujours postérieur à l’event time. Si une fenêtre est fermée avant qu’un événement prévu pour cette fenêtre n’arrive, on dit que cet événement est en retard. Apache Beam permet donc de faire différents arbitrages sur le temps que nous accepterons à attendre des données en retard ou à relancer des calculs sur des données en retard.
Beam supporte plusieurs “runners” ou exécuteurs (Spark, Flink, Google Dataflow), mais son API est unique. Cette API définit le concept de Pipeline, constitué de PCollections (les données) et de PTransform (les traitements). Elle comprendre quatre grands modules qui répondent à quatre questions :
- “What” ? Qu’est-ce qui est calculé ? Cette brique comprend les méthodes de transformation, d’agrégation.
- “Where” ? Où sont les données à traiter selon leur event time ? Cette brique comprend les méthodes de fenêtrage.
- “When ?” A partir de quand est-ce que les données seront-elles traitées. Cette brique comprend les méthodes de triggers et de watermarks.
- “How ?” Comment s'enchaînent les différentes étapes de traitement ?
Cette session approfondir ensuite le “where" (les fenêtres) et le “when" (les watermark et les triggers).
Différentes options de fenêtrage peuvent être utilisées. Elles permettent de diviser les éléments d’une PCollection en fenêtre, puis le trigger permet de contrôler à partir de quel moment cette fenêtre est fermée et les transformations effectuées. Par défaut, le fenêtrage est basé sur l’event time, mais il est possible de créer des fenêtres basées sur le processing time. Plusieurs types de fenêtres sont disponibles : fenêtre de temps fixes, fenêtres glissantes, fenêtres de session, etc.
Plusieurs triggers peuvent également être utilisés, qui utilisent ou pas les watermarks (voir la session sur les watermarks). On peut par exemple utiliser un cutoff fixe : on attend 10 minutes après la fin de la fenêtre pour la fermer ; on laisse donc 10 minutes de temps pour que des événements en retard puissent arriver et être pris en compte dans la fenêtre. On peut également utiliser un trigger basé sur watermark comme Afteratermark.PastEndOfWindow(), qui fermera la fenêtre en se basant sur le watermark (complétude élevée mais latence faible). Autre exemple : on peut fermer une fenêtre après avoir reçu n éléments (latence faible mais complétude faible). Il est enfin possible de combiner ces méthodes : on peut effectuer un traitement sur une fenêtre après 1 minute, tout à mettant à jour ce traitement si un événement arrive en retard (avec les mécanismes de early firings et late firings).
Notons que beaucoup de triggers ne sont supportés que par Dataflow et Flink, et pas Spark : la matrice de compatibilité entre l’API et les runners et disponible 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.
Watermarks: time and progress in streaming Dataflow and beyond
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.
Streaming analytics at 300 billion events per day with Kafka, Samza, and Druid
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.
Introducing Kafka Streams, Apache Kafka's new stream processing library
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 :
- Kafka Streams offre un DSL (Domain Specific Language) simple pour délivrer du calcul au dessus des fonctionnalités actuelles de Kafka. Les fonctionnalités habituelles de map, filter, join etc... sont inclues.
- Kafka Streams n'est pas limité par des frameworks de scheduling de ressources.
- L’ordre des évènements est garanti en mappant les consommateurs d’évènements Kafka Streams directement sur les partitions Kafka.
- Des fonctionnalités de tolérance à la panne, time windowing, reprocessing d'évènements, etc… sont disponibles.
- De la même manière que Samza, quand plusieurs traitements s'enchaînent avec Kafka Streams, des topics sont automatiquement créés pour stocker la donnée entre chaque étape de calcul. Cela permet d'avoir une queue entre chaque étape et d'éviter l'engorgement des étapes de streaming.
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.
So you think you can stream: Use cases and design patterns for Spark Streaming
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 :
- Fonctionnement des receivers dans Spark Streaming
- Explication de la façon dont Spark construit ses DAGs d'exécution
- Comment utiliser les mécanismes de checkpoint pour faire des agrégations plus efficaces
- Comment maintenir des états en mémoire grâce à mapWithState et comment les configurer pour faire du Dynamic Partition Pruning (DPP) de ceux-ci pour ne pas occuper trop de mémoire ainsi que la possibilité de faire du SQL sur un stream.
- Comment faire du SQL en streaming.
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 !