Pile d’infra de données en temps réel

Un aperçu des options populaires disponibles

Auparavant, nous avons introduit l’évolution de l’infrastructure de données, où nous avons fait évoluer le monolithe de données d’origine étape par étape vers une architecture pouvant prendre en charge à la fois l’analyse en temps réel et diverses gouvernances de données.

Cependant, dans cet article, nous n’avons pas couvert les sélections techniques disponibles, mais seulement une vue de haut niveau du processus d’évolution de l’architecture.

Dans cet article, nous nous concentrerons sur la pile d’analyses en temps réel et énumérerons quelques options populaires ou progressivement populaires.

Avant de commencer, présentons brièvement toute l’architecture de l’analyse en temps réel.

Comme nous l’avons mentionné précédemment, le cœur de toute l’infrastructure en temps réel est le streaming.

Afin de traiter rapidement tous les événements des producteurs d’événements, le streaming joue un rôle important, et dans le streaming, il existe des plates-formes de flux et des processeurs de flux. La plate-forme de flux est le courtier du streaming, qui est utilisé pour stocker et distribuer les flux aux processeurs. Et le processeur renverra le flux à la plate-forme après avoir traité le flux.

Pourquoi les processeurs ne livrent-ils pas les flux directement vers l’arrière ?

Parce que le flux peut passer par plus d’un processeur. Pour compléter un cas d’utilisation complet, le flux peut passer par de nombreux processeurs, chacun d’entre eux se concentrant sur ce qu’ils sont censés faire. C’est le même concept qu’un pipeline de données.

Lorsque le streaming est traité, il est conservé et est disponible pour les utilisateurs selon leurs besoins. Par conséquent, la couche de service doit être un magasin de données à haut débit et fournir une variété de requêtes complexes. Pour cette exigence, le RDBMS traditionnel ne peut pas répondre aux exigences de débit, de sorte que la couche de service n’est généralement pas une base de données relationnelle.

Le dernier front sert à présenter les données à l’utilisateur final, qui peuvent être des tableaux, des diagrammes ou même un rapport complet.

Nous savons déjà que les producteurs d’événements sont chargés de générer divers « événements », mais quels types d’événements existe-t-il exactement ?

Il existe trois types.

• Base de données OLTP existante
• Suivi des événements
• SDK de langue

Base de données OLTP existante

Tout système aura une base de données, qu’il s’agisse d’une base de données relationnelle ou d’une base de données NoSQL, et tant que l’application aura des besoins de stockage, elle utilisera la base de données qui répond à ses besoins.

Pour capturer les changements de données de ces bases de données et les transmettre à la plateforme de streaming, nous utilisons souvent Débezium.

Suivi des événements

Lorsqu’un utilisateur exploite un système, qu’il s’agisse d’une interface Web ou d’une application mobile, nous souhaitons toujours capturer ces événements pour une analyse ultérieure du comportement de l’utilisateur.

Nous voulons que les trackers soient capables de digérer les événements générés rapidement pour nous, mais nous voulons également qu’ils aient une certaine personnalisation, comme l’enrichissement des événements. Par conséquent, les plug-ins et la personnalisation seront une priorité lors de la sélection d’un tracker.

Les options courantes sont répertoriées ci-dessous.

SNOWPLOW fournit une version open source, tandis que segment ne fait pas.

SDK de langue

Le dernier est les événements générés par divers backends d’application, qui sont livrés via le SDK fourni par la plate-forme de flux. La sélection technique ici dépendra de la plate-forme de flux et du langage de programmation utilisé.

Le concept de plateforme de flux est très simple, c’est un courtier à haut débit.

L’option la plus courante est Kafka, mais il existe également divers logiciels open source et services gérés. Soit dit en passant, l’ordre suivant ne représente pas l’ordre de recommandation.

Open source

Service géré

Un processeur de flux, comme son nom l’indique, est un rôle qui gère les flux. Il doit être évolutif, disponible et tolérant aux pannes, et la capacité à prendre en charge diverses sources et puits de données est également une considération importante.

La Apache Flinkqui est souvent mentionnée, est l’une de ces options, et il en existe bien d’autres.

Open source

Service géré

La fonction de la couche de service est de conserver les résultats du traitement du flux et de les rendre facilement accessibles aux utilisateurs. Par conséquent, il doit avoir deux conditions importantes, premièrement, un débit important et deuxièmement, la capacité de prendre en charge des opérations de requête plus complexes.

En général, il existe deux approches différentes, l’une consiste à choisir une base de données NoSQL commune, telle que MongoDB, Recherche élastique ou Apache Cassandre. Toutes ces bases de données NoSQL ont une bonne évolutivité et peuvent prendre en charge des requêtes complexes. De plus, ces bases de données sont très matures, donc la courbe d’apprentissage est faible tant pour l’utilisation que pour l’exploitation.

En outre, certaines bases de données NoSQL se développent pour une faible latence et le Big Data, par exemple, SCYLLA.

D’un autre côté, il y a beaucoup de nouveaux venus dans la famille SQL. Ces nouvelles bases de données compatibles SQL ont une logique de mise en œuvre complètement différente des bases de données relationnelles traditionnelles, et ont donc un débit élevé et peuvent même interagir directement avec les plateformes de flux.

De plus, ces bases de données ont l’évolutivité que les SGBDR traditionnels n’ont pas, et peuvent toujours avoir une faible latence de requête dans les scénarios de Big Data.

Le plus courant dans le frontend consiste toujours à créer des services à l’aide de frameworks Web courants, tels que ces trois frameworks les plus courants.

De plus, les frameworks low-code sont devenus populaires ces dernières années. Le faible code signifie que les développeurs n’ont besoin d’écrire qu’une petite quantité de code pour utiliser de nombreuses fonctions prédéfinies, ce qui peut réduire considérablement le temps de développement et accélérer la publication.

Afin de rendre les données plus en temps réel, l’objectif est de valoriser les données le plus tôt possible, de sorte qu’un développement agile dans l’environnement de production est également une considération raisonnable. Voici deux frameworks low-code populaires.

Enfin, il existe diverses plateformes de visualisation de données.

Bien que cet article répertorie de nombreuses cibles pour la sélection technique, il y en a certainement d’autres que je n’ai pas répertoriées, qui peuvent être des options obsolètes et moins utilisées telles que Tempête Apache ou hors de mon radar depuis le début, comme l’écosystème Java.

Par ailleurs, je n’ai pas mis de liens vers les trois grandes plateformes de cloud public qui sont déjà relativement matures (AWS, GCP, Azure), car celles-ci peuvent être trouvées dans de nombreuses ressources sur Internet à tout moment.

Même si ces piles techniques sont répertoriées par catégorie, certains champs se chevauchent. Par exemple, bien que Se concrétiser est classé comme un processeur de flux, il est logique de le traiter comme une couche de service car il s’agit essentiellement d’une base de données de flux, et il en va de même pour ksqlDB.

Chaque projet a ses propres forces et applications. Au moment de faire un choix, il est important de tenir compte des pratiques et des piles existantes au sein de l’organisation, ainsi que des objectifs que vous souhaitez atteindre, afin de pouvoir trouver la bonne réponse parmi les nombreuses options.

S’il y a un projet que je n’ai pas listé et que vous pensez qu’il vaut la peine d’être mentionné, n’hésitez pas à me laisser un commentaire et je trouverai le temps de l’étudier.