La nécessité clé de l’application de communauté sociale privée est de créer une plate-forme pour un réseau d’individus qui se réunissent en ligne pour socialiser et communiquer en publiant des informations sous forme d’images, de commentaires ou de messages. Outre les aspects fonctionnels, d’autres dimensions importantes à prendre en compte pour la conception de la plate-forme de réseautage social comprennent :
- Tolérance aux pannes contre les pannes matérielles et les erreurs humaines.
- Doit inclure des requêtes à faible latence ainsi que des mises à jour.
- Soutenez les communautés actives de millions d’utilisateurs.
- Utilisation de solutions Big Data open source pour réduire les coûts.
Architecture Lambda
L’architecture Lambda est un cadre très utile pour réfléchir à la conception d’applications Big Data et de systèmes de traitement de données distribués comme les plateformes de réseaux sociaux. Il fournit une plate-forme de traitement de données qui peut prendre en charge à la fois le traitement de données historiques et en temps réel, ce qui est une nécessité clé pour une application de communauté sociale. Le diagramme ci-dessous décrit une architecture appropriée de l’application de communauté sociale et des détails de haut niveau des composants impliqués à l’aide de cette architecture.
Les principaux composants d’une telle architecture comprennent :
- Couche d’application
- Couche de collecte de données
- Couche de traitement des données
Couche d’application (interface utilisateur)
La couche application sera généralement une interface utilisateur pouvant être utilisée par des utilisateurs ou des groupes communautaires authentifiés et autorisés. Cette couche inclurait les principaux services tels que les services Tweet, Timeline, User ou Search. Un service de tweet serait un service qui pourrait être utilisé pour créer des flux actifs, des publications ou partager des messages tandis qu’un service de chronologie permet d’afficher les tweets.
Le service de chronologie comprendrait en outre un service de chronologie à domicile (afficher les tweets d’amis ou des personnes que l’utilisateur suit) et un service de chronologie de l’utilisateur (afficher ses propres tweets). Les autres services de cette couche, tels que le service de recherche, peuvent être utilisés pour obtenir des informations affinées basées sur des mots-clés ou des hashtags et des services liés à l’utilisateur pour mettre à jour les données de profil utilisateur.
Couche de collecte de données
Dans les tweets généraux, le service d’écriture de la couche d’application insère tout le flux entrant dans la couche de collecte de données. La couche de collecte de données est une plate-forme de diffusion d’événements distribuée et des technologies comme Apache Kafka peuvent être utilisées pour la couche de collecte de données. L’objectif principal de cette couche de collecte de données est de :
- Fournissez la sémantique de livraison requise au moins une fois dans les systèmes de données en continu et assurez une livraison sûre des messages.
- Empêchez la couche de traitement des données d’un énorme retard de traitement.
Couche de traitement des données
La couche de traitement des données est en outre divisée en couches de lot, de vitesse et de service. Le flux de données actif provenant en continu de la couche de collecte de données est poussé dans l’ensemble de données maître qui est un ensemble immuable de données brutes) de la couche batch et simultanément dans la couche de vitesse pour le traitement des données en temps réel. La couche batch suit principalement l’approche ETL et l’entrepôt de données traditionnels. Cette couche est construite à l’aide d’un calendrier prédéfini, examine toutes les données à la fois et précalcule les vues par lots.
La couche de vitesse ne traite que les données récentes et crée des vues en temps réel. Les sorties de la couche batch (vues par lots) et de la couche speed (vues en temps quasi réel) sont transmises à la couche de service. Cette couche est utilisée pour indexer les vues batch à interroger de manière ad-hoc à faible latence. Comprenons le flux de données de l’architecture proposée avec le cas d’utilisation du flux de tweet et de la chronologie de l’utilisateur.
Chaque fois qu’un utilisateur publie un tweet sur sa timeline, le service de rédaction de tweet de l’architecture proposée déclenche un événement avec toutes les données de tweet associées (par exemple, TweetID, UserID, Tweet Message, Time Stamp, etc.) et l’envoie au sujet. de la plate-forme de streaming d’événements distribués. Le producteur associé au service de messagerie est informé de l’événement et de ses données associées, qui à leur tour dirigeront les données de tweet entrant vers les couches batch et speed pour un traitement ultérieur.
Couche par lots
La couche de traitement par lots est extrêmement fiable pour le traitement de grands ensembles de données et le travail de traitement par lots est exécuté selon un calendrier prédéfini (généralement une ou deux fois par jour). Les ensembles de données de couches par lots peuvent être stockés dans un système de fichiers distribué tandis que MapReduce peut être utilisé pour le traitement par lots. Supposons que tous les tweets entrants soient insérés dans la table « Tweets » de l’ensemble de données maître dans la couche batch. Une fois qu’un lot est traité, des vues de lot sont créées et stockées pour un traitement ultérieur dans la couche de service.
Couche de vitesse
La couche de vitesse ne traite que les données récentes, c’est-à-dire les données qui ne sont pas livrées dans la vue par lots en raison de la latence de la couche de lots. Les messages de tweet qui sont transmis à cette couche sont rapidement traités au fur et à mesure de leur réception et les vues en temps réel correspondantes sont générées et stockées. Des technologies comme Apache Spark ou Storm peuvent être utilisées pour un traitement en temps réel et quasi réel.
Couche de service
La couche de service indexe les vues par lots et contient également la logique de fusion des vues en temps réel et par lots. L’architecture lambda précalcule le flux de la chronologie une fois et le met simplement à jour avec les dernières vues en temps réel. De cette façon, la chronologie de l’utilisateur avec des données en temps réel et historiques est pré-calculée et stockée dans des systèmes de stockage distribués comme HBase ou Cassandra. Des champs tels que l’identifiant de tweet, l’identifiant d’utilisateur, le nom d’utilisateur, l’emplacement, le nombre d’amis peuvent être stockés dans la table des tweets qui ferait partie de l’ensemble de données principal, tandis que des champs tels que l’identifiant d’utilisateur, le nombre d’amis, la date de création dans le cadre d’un temps réel, batch ou fusionner des vues.
Nous avons donc compris le flux de données de l’architecture Lambda. Mais, comment l’architecture Lambda aide-t-elle avec d’autres dimensions de tolérance aux pannes, de robustesse et d’évolutivité ?
Robustesse et tolérance aux pannes: Il aide les systèmes à tolérer les pannes des machines et les erreurs humaines telles que la corruption de données. Les vues batch et temps réel peuvent toujours être recalculées à partir du jeu de données maître.
Lecture et mise à jour à faible latence : L’architecture Lambda permet d’obtenir à la fois une faible latence et une mise à jour sans compromettre la robustesse.
Évolutivité : Toutes les couches, de la collecte des données au traitement, peuvent être mises à l’échelle indépendamment.
Généralisation: L’architecture Lambda peut être utilisée dans de nombreuses applications différentes.
Bien que l’architecture Lambda soit la plus adaptée à la conception d’applications de type Twitter, le maintien de bases de code distinctes pour les couches batch et stream peut être extrêmement difficile, ce qui rend la conception et la maintenance de ce type d’architecture très complexes.