Selon un récent rapport d’IBM Marketing cloud, « 90 % des données dans le monde aujourd’hui ont été créées au cours des deux dernières années seulement, créant 2.5 quintillions d’octets de données chaque jour – et avec l’émergence de nouveaux appareils, capteurs et technologies, le taux de croissance des données va probablement s’accélérer encore plus ».
Techniquement, cela signifie que notre monde de traitement des Big Data va devenir plus complexe et plus difficile. Et de nombreux cas d’utilisation (par exemple, les publicités sur les applications mobiles, la détection des fraudes, la réservation de taxis, le suivi des patients, etc.) nécessitent un traitement des données en temps réel, au fur et à mesure de leur arrivée, afin de prendre des décisions rapides et exploitables. C’est pourquoi le traitement en flux distribué est devenu très populaire dans le monde du Big Data.
Aujourd’hui, il existe un certain nombre de frameworks de streaming open source disponibles. Il est intéressant de noter que presque tous sont assez récents et ont été développés au cours des dernières années seulement. Il est donc assez facile pour une nouvelle personne de s’embrouiller dans la compréhension et la différenciation des frameworks de streaming. Dans cet article, je vais d’abord parler des types et des aspects du traitement en continu en général, puis je comparerai les frameworks de streaming open source les plus populaires : Flink, Spark Streaming, Storm, Kafka Streams. J’essaierai d’expliquer comment ils fonctionnent (brièvement), leurs cas d’utilisation, leurs forces, leurs limites, leurs similitudes et leurs différences.
Qu’est-ce que le Streaming/Stream Processing :
La définition la plus élégante que j’ai trouvée est : un type de moteur de traitement de données qui est conçu avec des ensembles de données infinis à l’esprit. Rien de plus.
Contrairement au traitement par lots où les données sont délimitées avec un début et une fin dans un travail et où le travail se termine après avoir traité ces données finies, le Streaming est destiné à traiter des données non limitées arrivant en temps réel en continu pendant des jours, des mois, des années et pour toujours. En tant que telle, étant toujours destinée à être en marche, une application de streaming est difficile à mettre en œuvre et plus difficile à maintenir.
Aspects importants du traitement en streaming :
Il y a quelques caractéristiques et termes importants associés au traitement en streaming que nous devons connaître afin de comprendre les forces et les limites de tout framework de streaming :
- Garanties de livraison :
Cela signifie quelle est la garantie que quoi qu’il arrive, un enregistrement entrant particulier dans un moteur de streaming sera traité. Elle peut être soit Atleast-once (sera traité au moins une fois même en cas de défaillances) , Atmost-once (peut ne pas être traité en cas de défaillances) ou Exactly-once (sera traité une et exactement une fois même en cas de défaillances) . De toute évidence, Exactly-once est souhaitable mais est difficile à réaliser dans les systèmes distribués et s’accompagne de compromis avec les performances. - Tolérance aux pannes :
En cas de pannes comme les pannes de nœuds,les pannes de réseau,etc, le cadre devrait être capable de récupérer et devrait recommencer le traitement à partir du point où il est parti. Ceci est réalisé par le checkpointing de l’état du streaming à un certain stockage persistant de temps en temps. par exemple, le checkpointing des offsets kafka à zookeeper après avoir obtenu l’enregistrement de Kafka et le traiter. - Gestion de l’état :
Dans le cas des exigences de traitement avec état où nous devons maintenir un certain état (par ex.par exemple, les comptes de chaque mot distinct vu dans les enregistrements), le cadre devrait être en mesure de fournir un certain mécanisme pour préserver et mettre à jour les informations d’état. - Performance :
Cela inclut la latence(la rapidité avec laquelle un enregistrement peut être traité), le débit (enregistrements traités/seconde) et l’évolutivité. La latence doit être la plus faible possible tandis que le débit doit être le plus élevé possible. Il est difficile d’obtenir les deux en même temps. - Fonctions avancées : Traitement des temps événementiels, filigranes, fenêtrage
Ce sont des fonctionnalités nécessaires si les exigences de traitement des flux sont complexes. Par exemple, le traitement des enregistrements en fonction de l’heure à laquelle il a été généré à la source (traitement du temps événementiel). Pour en savoir plus en détail, veuillez lire ces posts incontournables du gars de Google Tyler Akidau : partie1 et partie2. - Maturité :
Important du point de vue de l’adoption, c’est bien si le framework est déjà éprouvé et testé en bataille à l’échelle par de grandes entreprises. Plus susceptible d’obtenir un bon soutien de la communauté et de l’aide sur stackoverflow.
Deux types de traitement de flux :
En étant maintenant conscient des termes que nous venons de discuter, il est maintenant facile de comprendre qu’il existe 2 approches pour mettre en œuvre un framework de Streaming :
Native Streaming :
Aussi connu sous le nom de Streaming natif. Cela signifie que chaque enregistrement entrant est traité dès qu’il arrive, sans attendre les autres. Il y a certains processus en cours d’exécution continue (que nous appelons opérateurs/tâches/bolts selon le framework) qui fonctionnent en permanence et chaque enregistrement passe par ces processus pour être traité. Exemples : Storm, Flink, Kafka Streams, Samza.
Micro-batching :
Aussi connu sous le nom de Fast Batching. Cela signifie que les enregistrements entrants toutes les quelques secondes sont mis en lots et ensuite traités en un seul mini lot avec un retard de quelques secondes. Exemples : Spark Streaming, Storm-Trident.
Les deux approches présentent des avantages et des inconvénients.
Le streaming natif semble naturel car chaque enregistrement est traité dès son arrivée, ce qui permet au framework d’atteindre la latence la plus faible possible. Mais cela signifie également qu’il est difficile d’atteindre la tolérance aux pannes sans compromettre le débit, car pour chaque enregistrement, nous devons suivre et faire un checkpoint une fois traité. En outre, la gestion de l’état est facile car il existe des processus à long terme qui peuvent maintenir l’état requis facilement.
Le micro-batching , d’autre part, est tout à fait opposé. La tolérance aux pannes est gratuite car il s’agit essentiellement d’un lot et le débit est également élevé car le traitement et le point de contrôle seront effectués en une seule fois pour un groupe d’enregistrements. Mais cela se fera au prix d’une certaine latence et on n’aura pas l’impression d’un flux naturel. De plus, une gestion efficace de l’état sera un défi à maintenir.
Les frameworks de streaming un par un :
Storm :
Storm est le hadoop du monde du streaming. C’est le plus ancien framework de streaming open source et l’un des plus matures et des plus fiables. C’est un véritable streaming et il est bon pour les cas d’utilisation simples basés sur des événements. J’ai partagé des détails sur Storm en long et en large dans ces posts : part1 et part2.
Avantages :
- Très faible latence,vrai streaming, mature et haut débit
- Excellent pour les cas d’utilisation de streaming non compliqués
Désavantages
- Pas de gestion d’état
- Pas de fonctionnalités avancées comme le traitement du temps événementiel, l’agrégation, le fenêtrage, les sessions, les filigranes, etc
- Garantie de l’atlas une fois
Spark Streaming :
Spark s’est imposé comme le véritable successeur d’hadoop en matière de traitement par lots et le premier framework à supporter pleinement l’architecture Lambda (où sont implémentés à la fois le Batch et le Streaming ; le Batch pour la correction, le Streaming pour la vitesse). Il est immensément populaire, mature et largement adopté. Spark Streaming est fourni gratuitement avec Spark et utilise le micro-batching pour le streaming. Avant la version 2.0, le streaming Spark présentait de sérieuses limitations de performance, mais avec la nouvelle version 2.0+, il est appelé streaming structuré et est équipé de nombreuses fonctionnalités intéressantes comme la gestion personnalisée de la mémoire (comme Flink) appelée Tungsten, les filigranes, la prise en charge du traitement des événements, etc. Le streaming structuré est également beaucoup plus abstrait et la version 2.3.0 offre la possibilité de passer du mode micro-batching au mode streaming continu. Le mode Streaming continu promet de donner une sous latence comme Storm et Flink, mais il est encore au stade de balbutiement avec de nombreuses limitations dans les opérations.
Avantages :
- Support de l’architecture Lambda, vient gratuitement avec Spark
- Haut débit, bon pour de nombreux cas d’utilisation où la sous-latence n’est pas requise
- Tolérance aux pannes par défaut en raison de la nature micro-batch
- Simple d’utiliser des API de plus haut niveau
- Grosse communauté et améliorations agressives
- Exactly Once
Inconvénients
- Non vrai streaming, ne convient pas aux exigences de faible latence
- Trop de paramètres à régler. Difficile de bien faire les choses. Ai écrit un post sur mon expérience personnelle tout en réglant Spark Streaming
- Stateless par nature
- Laisse derrière Flink dans de nombreuses fonctionnalités avancées
Flink :
Flink est également issu d’un parcours académique similaire à Spark. Alors que Spark vient de l’UC Berkley, Flink vient de l’université TU de Berlin. Comme Spark, il supporte également l’architecture Lambda. Mais la mise en œuvre est tout à fait opposée à celle de Spark. Alors que Spark est essentiellement un batch avec le streaming Spark comme micro-batching et cas particulier de Spark Batch, Flink est essentiellement un véritable moteur de streaming traitant le batch comme un cas particulier de streaming avec des données limitées. Bien que les API des deux frameworks soient similaires, leurs implémentations ne le sont pas. Dans Flink, chaque fonction comme map,filter,reduce,etc est implémentée comme un opérateur de longue durée (similaire à Bolt dans Storm)
Flink ressemble à un véritable successeur de Storm comme Spark a succédé à hadoop en batch.
Avantages :
- Leader de l’innovation dans le paysage du streaming open source
- Premier vrai framework de streaming avec toutes les fonctionnalités avancées comme le traitement du temps événementiel, les filigranes, etc
- La faible latence avec un haut débit, configurable en fonction des besoins
- Auto-ajustement, pas trop de paramètres à régler
- Exactement une fois
- En train d’être largement accepté par les grandes entreprises à l’échelle comme Uber,Alibaba.
Inconvénients
- Un peu tard dans le jeu, il y avait un manque d’adoption initialement
- La communauté n’est pas aussi grande que Spark mais se développe à un rythme rapide maintenant
- Pas d’adoption connue du Flink Batch pour le moment, seulement populaire pour le streaming.
Kafka Streams :
Kafka Streams , contrairement aux autres frameworks de streaming, est une bibliothèque légère. Elle est utile pour le streaming de données depuis Kafka , faire de la transformation et ensuite renvoyer à kafka. Il s’agit d’une bibliothèque similaire au Java Executor Service Thread pool, mais avec un support intégré pour Kafka. Il peut être bien intégré à n’importe quelle application et fonctionnera dès la boîte.
En raison de sa nature légère, peut être utilisé dans une architecture de type microservices. Il n’y a pas de match en termes de performance avec Flink, mais aussi ne nécessite pas de cluster séparé pour fonctionner, est très maniable et facile à déployer et à commencer à travailler . En interne, il utilise le groupe Kafka Consumer et fonctionne sur la philosophie du journal Kafka.
Ce post explique en détail les cas d’utilisation de Kafka Streams vs Flink Streaming.
Un avantage majeur de Kafka Streams est que son traitement est Exactement Une fois de bout en bout. C’est possible car la source ainsi que la destination, sont toutes deux Kafka et depuis la version 0.11 de Kafka sortie vers juin 2017, Exactly once est supporté. Pour activer cette fonctionnalité, nous avons juste besoin d’activer un drapeau et cela fonctionnera hors de la boîte. Pour plus de détails partagés ici et ici.
Avantages:
- Bibliothèque très légère, bonne pour les microservices, les applications IOT
- Ne nécessite pas de cluster dédié
- Hérite de toutes les bonnes caractéristiques de Kafka
- Porte les jointures de flux, utilise en interne rocksDb pour maintenir l’état.
- Exactly Once ( Kafka 0.11 et plus).
Inconvénients
- Très couplé avec Kafka, ne peut pas être utilisé sans Kafka dans l’image
- Quasiment nouveau au stade de l’enfance, doit encore être testé dans les grandes entreprises
- Pas pour les travaux lourds comme Spark Streaming,Flink.
Samza :
Je vais couvrir Samza en bref. Samza de 100 pieds ressemble à Kafka Streams dans l’approche. Il y a beaucoup de similitudes. Ces deux frameworks ont été développés à partir des mêmes développeurs qui ont mis en œuvre Samza chez LinkedIn et ont ensuite fondé Confluent où ils ont écrit Kafka Streams. Ces deux technologies sont étroitement couplées à Kafka, prennent les données brutes de Kafka et renvoient les données traitées à Kafka. Elles utilisent la même philosophie de Kafka Log. Samza est une sorte de version à l’échelle de Kafka Streams. Alors que Kafka Streams est une bibliothèque destinée aux microservices , Samza est un traitement en cluster complet qui fonctionne sur Yarn.
Avantages :
- Très bien pour maintenir de grands états d’information (bon pour le cas d’utilisation de la jonction des flux) en utilisant rocksDb et kafka log.
- Tolérance aux pannes et haute performance en utilisant les propriétés de Kafka
- Une des options à considérer si vous utilisez déjà Yarn et Kafka dans le pipeline de traitement.
- Bon citoyen de Yarn
- La faible latence , Le haut débit , mature et testé à l’échelle
Inconvénients :
- Très couplé avec Kafka et Yarn. Pas facile à utiliser si l’un ou l’autre n’est pas dans votre pipeline de traitement.
- Garantie d’un traitement unique (Atleast-Once). Je ne suis pas sûr qu’il supporte exactement une fois maintenant comme Kafka Streams après Kafka 0.11
- L’absence de fonctionnalités de streaming avancées comme les filigranes, les sessions, les déclencheurs, etc
Comparaison des frameworks de streaming:
Nous pouvons comparer les technologies uniquement avec des offres similaires. Alors que Storm, Kafka Streams et Samza semblent maintenant utiles pour des cas d’utilisation plus simples, la vraie compétition est claire entre les poids lourds avec les dernières fonctionnalités : Spark vs Flink
Lorsque nous parlons de comparaison, nous avons généralement tendance à demander : Montrez-moi les chiffres 🙂
Le benchmarking est une bonne façon de comparer seulement quand il a été fait par des tiers.
Par exemple, l’un des anciens bench marking était le suivant .
Mais c’était à des moments avant Spark Streaming 2.0 quand il avait des limitations avec RDDs et le projet tungsten n’était pas en place.
Maintenant avec Structured Streaming post 2.0 release , Spark Streaming essaie de rattraper beaucoup et il semble qu’il va y avoir une lutte difficile à venir.
Récemment le benchmarking est en quelque sorte devenu un combat de chat ouvert entre Spark et Flink.
Spark avait récemment fait une comparaison de benchmarking avec Flink à laquelle les développeurs de Flink ont répondu avec un autre benchmarking après quoi les gars de Spark ont édité le post.
Il est préférable de ne pas croire le benchmarking de nos jours parce que même un petit tweaking peut complètement changer les chiffres. Rien n’est mieux que d’essayer et de tester nous-mêmes avant de décider.
Aujourd’hui, il est tout à fait évident que Flink est en tête de l’espace Streaming Analytics, avec la plupart des aspects souhaités comme exactement une fois, le débit, la latence, la gestion des états, la tolérance aux pannes, les fonctionnalités avancées, etc.
Ces-ci ont été possibles grâce à certaines des véritables innovations de Flink comme les snapshots légers et la gestion de la mémoire personnalisée hors tas.
Une préoccupation importante avec Flink était la maturité et le niveau d’adoption jusqu’à un certain temps en arrière, mais maintenant des entreprises comme Uber, Alibaba, CapitalOne utilisent le streaming Flink à une échelle massive certifiant le potentiel du Streaming Flink.
Récemment, Uber a open sourcé leur dernier cadre d’analyse Streaming appelé AthenaX qui est construit au-dessus du moteur Flink. Dans ce post, ils ont discuté de la façon dont ils ont déplacé leurs analyses de streaming de STorm à Apache Samza et maintenant Flink.
Un point important à noter, si vous l’avez déjà remarqué, est que tous les frameworks de streaming natifs comme Flink, Kafka Streams, Samza qui supportent la gestion d’état utilisent RocksDb en interne. RocksDb est unique en ce sens qu’il maintient un état persistant localement sur chaque nœud et est très performant. Il est devenu un élément crucial des nouveaux systèmes de streaming. J’ai partagé des infos détaillées sur RocksDb dans l’un des posts précédents.
Comment choisir le meilleur framework de streaming :
C’est la partie la plus importante. Et la réponse honnête est : cela dépend 🙂
Il est important de garder à l’esprit qu’aucun framework de traitement ne peut être la solution miracle pour chaque cas d’utilisation. Chaque cadre a des forces et des limites aussi. Pourtant , avec une certaine expérience, va partager quelques pointeurs pour aider à prendre des décisions:
- Dépend des cas d’utilisation :
Si le cas d’utilisation est simple, il n’y a pas besoin d’aller pour le dernier et le plus grand cadre si elle est compliquée à apprendre et à mettre en œuvre. Cela dépend beaucoup de ce que nous sommes prêts à investir pour ce que nous voulons en retour. Par exemple, s’il s’agit d’un simple système d’alerte basé sur des événements de type IOT, Storm ou Kafka Streams est parfaitement bien pour travailler avec. - Préoccupations futures :
Dans le même temps, nous devons également avoir une considération consciente sur ce que seront les cas d’utilisation futurs possibles ? Est-il possible que des demandes de fonctionnalités avancées comme le traitement des temps événementiels, l’agrégation, les jointures de flux, etc. puissent venir dans le futur ? Si la réponse est oui ou possible, alors il est préférable d’aller de l’avant avec des frameworks de streaming avancés comme Spark Streaming ou Flink. Une fois que l’on a investi et mis en œuvre une technologie, il est difficile et très coûteux d’en changer par la suite. Par exemple, dans notre entreprise précédente, nous avions un pipeline Storm en place depuis deux ans et il fonctionnait parfaitement bien jusqu’à ce que nous ayons besoin d’unifier les événements entrants et de ne signaler que les événements uniques. Cela exigeait une gestion d’état qui n’est pas intrinsèquement prise en charge par Storm. Bien que j’aie implémenté l’utilisation d’un hashmap en mémoire basé sur le temps, la limitation était que l’état disparaissait au redémarrage. De plus, cela posait des problèmes lors de tels changements, que j’ai décrits dans l’un de mes précédents articles. Le point que j’essaie de faire est, si nous essayons de mettre en œuvre quelque chose sur notre propre que le cadre ne fournit pas explicitement, nous sommes tenus de frapper des problèmes inconnus. - Pile technologique existante :
Un point plus important est de considérer la pile technologique existante. Si la pile existante a Kafka en place de bout en bout, alors Kafka Streams ou Samza pourrait être plus facilement adapté. De même, si le pipeline de traitement est basé sur une architecture Lambda et que Spark Batch ou Flink Batch est déjà en place, il est logique d’envisager Spark Streaming ou Flink Streaming. Par exemple, dans l’un de mes projets précédents, j’avais déjà Spark Batch dans le pipeline et donc, lorsque le besoin de streaming est arrivé, il était assez facile de choisir Spark Streaming qui exigeait presque le même ensemble de compétences et la même base de code.
En bref, Si nous comprenons bien les forces et les limites des frameworks ainsi que nos cas d’utilisation, alors il est plus facile de choisir ou au moins de filtrer les options disponibles. Enfin, il est toujours bon d’avoir des POCs une fois que quelques options ont été sélectionnées. Tout le monde a des papilles différentes après tout.
Conclusion :
L’espace Streaming Apache évolue à un rythme si rapide que ce post pourrait être dépassé en termes d’informations dans quelques années. Actuellement, Spark et Flink sont les poids lourds menant de l’avant en termes de développements, mais certains nouveaux enfants peuvent encore venir et rejoindre la course. Apache Apex est l’un d’entre eux. Il existe également des solutions de streaming propriétaires que je n’ai pas abordées, comme Google Dataflow. L’objectif de cet article était d’aider les novices du streaming à comprendre, avec un minimum de jargon, certains concepts fondamentaux du streaming, ainsi que les forces, les limites et les cas d’utilisation des cadres de streaming open source les plus populaires. J’espère que ce post a été utile d’une certaine manière.
Happy Streaming!
Vous pouvez me suivre sur Linkedin et Quora
.