GALOIS : Une nouvelle approche pour le traitement des données de bord
GALOIS propose une solution flexible pour gérer les données IoT de manière efficace à la périphérie.
― 8 min lire
Table des matières
Avec la montée des appareils de l'Internet des objets (IoT), il y a un besoin croissant de gérer de grandes quantités de données provenant de nombreuses sources. Ces données viennent souvent sous forme de flux qui doivent être traités rapidement, ce qui peut être un sacré défi. Une façon de gérer ça, c'est à travers les systèmes de Traitement de Flux de Données à la Périphérie (DSPoE), qui permettent de traiter les données plus près de leur source au lieu de tout envoyer à un serveur central. Cependant, ces systèmes rencontrent des problèmes à cause des différents types de matériel et de plateformes, ce qui rend leur gestion efficace difficile.
Le défi des environnements divers
Dans les usines modernes, les machines peuvent produire des données à des vitesses incroyablement élevées. Par exemple, durant un processus de stamping, une seule ligne de production peut générer des données à un débit de 6 gigabits par seconde. Pour donner un sens rapide à cette énorme quantité de données, il est essentiel de les partager et de les analyser entre différentes organisations.
Cependant, la variété des machines et des connexions réseau dans une usine crée des défis pour le traitement des données. De plus, le besoin de réponses rapides aux problèmes et l'adaptation à différentes variations de la ligne de production ajoutent une couche de complexité supplémentaire. Les systèmes actuels, comme Apache Storm ou Twitter Heron, sont conçus pour gérer de grands flux de données, mais ils fonctionnent mieux avec des ressources serveur uniformes, ce qui n'est pas le cas sur le terrain de production.
Quand les données de diverses machines sont envoyées à un serveur central, cela peut entraîner des ralentissements et des délais inacceptables pour des applications en temps réel. Pour résoudre cela, un traitement peut être effectué plus près des sources de données – c'est ce qu'on appelle le traitement à la périphérie. Cette approche apporte ses propres défis, y compris des connexions réseau peu fiables et une large gamme de capacités matérielles.
Présentation de GALOIS
Pour relever ces défis, nous proposons une nouvelle architecture appelée GALOIS. Ce système est conçu pour fonctionner sur différents types de matériel, de plateformes et de langages de programmation. Il combine des méthodes de réseaux pair-à-pair (P2P) et des configurations classiques maître-esclave pour améliorer la communication entre les composants du système.
Une des caractéristiques uniques de GALOIS est son utilisation de WebAssembly (Wasm), une technologie qui permet d'exécuter du code dans différents environnements sans avoir besoin d'ajustements spécifiques pour chacun. En utilisant Wasm, les opérateurs dans GALOIS peuvent être légers, nécessitant moins de ressources tout en restant efficaces.
Efficacité énergétique et performance
Des tests ont montré que les opérateurs fonctionnant sous Wasm consomment moins d'énergie et de ressources CPU par rapport à ceux fonctionnant sous Docker, une plateforme populaire pour containeriser des applications. Cette différence d'efficacité fait de GALOIS une option prometteuse pour les systèmes qui traitent des données en streaming à la périphérie.
Exigences clés pour un traitement efficace
Pour que GALOIS fonctionne bien dans des environnements dynamiques, il devait répondre à plusieurs exigences essentielles :
- Exécution indépendante de la plateforme : Les opérateurs devraient pouvoir fonctionner sur n'importe quel matériel ou logiciel sans restrictions.
- Traitement direct à la périphérie : Les données devraient circuler directement entre les appareils proches, accélérant les temps de réponse.
- Gestion consciente du réseau : Le système devrait prendre en compte les conditions réseau pour minimiser les délais lors du traitement des données.
- Optimisation globale et locale : Des stratégies globales et des ajustements locaux devraient être employés pour améliorer la performance sans surcharger le réseau.
- Organisation spatiale : Les opérateurs devraient être regroupés en fonction de leur emplacement physique pour réduire les temps de communication.
- Ajustements décentralisés : Les modifications des plans de requête devraient se faire de manière indépendante, sans avoir à arrêter tout le processus.
- Tolérance aux pannes : Le système devrait continuer à fournir des résultats même si certains composants échouent.
Ces exigences ont guidé la conception de l'architecture de GALOIS.
Aperçu de l'architecture
L'architecture de GALOIS est structurée de manière à promouvoir une communication efficace à travers différents niveaux. Elle se compose de plusieurs composants classés en différentes couches :
- Niveau Cluster : C'est ici que les nœuds sont regroupés en clusters. Chaque nœud peut partager des données avec d'autres dans son cluster.
- Gestionnaires de Région : Ils supervisent plusieurs clusters et aident à gérer la communication entre eux.
- Gestionnaire Global : Ce composant s'occupe de l'optimisation globale et de l'enregistrement de schémas.
Le système est conçu de telle sorte que si un cluster rencontre des problèmes, cela ne stoppe pas tout le processus. Au lieu de ça, d'autres composants peuvent prendre le relais ou se reconfigurer selon les besoins.
Mise en œuvre de GALOIS
Pour mettre GALOIS en pratique, nous avons créé un prototype qui peut démontrer ses capacités. L’objectif principal était de tester comment Wasm se comportait par rapport à Docker lors de l'exécution des opérateurs.
Deux appareils Raspberry Pi ont été utilisés comme nœuds à la périphérie, simulant l'environnement de traitement. Un ordinateur séparé agissait comme un producteur de flux de données pour tester comment les données circulent à travers le système. Des compteurs d'énergie ont été utilisés pour mesurer la consommation d'énergie lors de ces tests.
L'objectif était de voir si Wasm pouvait offrir de meilleures performances que Docker en termes de vitesse de traitement, de consommation d'énergie et d'efficacité globale.
Résultats des tests
Au cours des tests, nous avons observé quelques résultats clés :
- Temps de traitement : Les opérateurs Wasm avaient systématiquement des temps de traitement plus courts par rapport à leurs homologues sous Docker.
- Consommation d'énergie : L'énergie utilisée par Wasm était significativement inférieure à celle utilisée par Docker, surtout à mesure que le taux d'entrée des données augmentait.
- Charge CPU : La charge CPU de Wasm était plus basse, indiquant qu'il exploitait mieux la puissance de traitement disponible.
Ces résultats suggèrent que les opérateurs Wasm sont une option viable pour traiter des flux de données, en particulier dans des environnements périphériques où l'efficacité est cruciale.
Comparaison avec d'autres systèmes
GALOIS s'appuie sur les leçons tirées des systèmes DSPoE existants comme NebulaStream et MobiStream. Bien que beaucoup de ces systèmes reposent sur un composant de contrôle central, GALOIS combine des méthodes décentralisées avec une gestion centralisée pour offrir à la fois flexibilité et évolutivité.
La plupart des systèmes existants dépendent de Machines Virtuelles Java, ce qui peut limiter la flexibilité. GALOIS, avec son utilisation de Wasm, présente une alternative qui pourrait supporter divers langages de programmation et environnements, rendant plus facile l'adaptation à différentes situations.
Directions futures
Malgré les résultats prometteurs jusqu'à présent, il reste encore beaucoup de travail pour GALOIS. Les améliorations futures incluent l'expansion de la bibliothèque d'opérateurs disponibles en Wasm, l'intégration d'une surveillance de la qualité pour une gestion de requêtes plus dynamique, et le développement d'un prototype plus complet qui englobe tous les niveaux de l'architecture.
En abordant les limitations inhérentes à Wasm, comme sa gestion des types de données complexes et la nécessité de code additionnel, GALOIS peut fournir un cadre robuste pour le traitement efficace des flux de données.
Conclusion
GALOIS représente une avancée significative dans la gestion et le traitement de volumes importants de données provenant des dispositifs IoT en temps réel. En utilisant une architecture hybride et en s'appuyant sur les forces de WebAssembly, il s'attaque à certains des plus grands défis du traitement en périphérie tout en garantissant flexibilité sur différentes plateformes et langages.
Au fur et à mesure de l'évolution des systèmes, GALOIS pourrait établir une nouvelle norme pour la façon dont nous abordons le traitement des flux de données dans des environnements dynamiques, ouvrant la voie à des pratiques de fabrication et de production plus intelligentes et plus efficaces.
Titre: GALOIS: A Hybrid and Platform-Agnostic Stream Processing Architecture
Résumé: With the increasing prevalence of IoT environments, the demand for processing massive distributed data streams has become a critical challenge. Data Stream Processing on the Edge (DSPoE) systems have emerged as a solution to address this challenge, but they often struggle to cope with the heterogeneity of hardware and platforms. To address this issue, we propose a new hybrid DSPoE architecture named GALOIS, which is based on WebAssembly (Wasm) and is hardware-, platform-, and language-agnostic. GALOIS employs a multi-layered approach that combines P2P and master-worker concepts for communication between components. We present experimental results showing that operators executed in Wasm outperform those in Docker in terms of energy and CPU consumption, making it a promising option for streaming operators in DSPoE. We therefore expect Wasm-based solutions to significantly improve the performance and resilience of DSPoE systems.
Auteurs: Tarek Stolz, István Koren, Liam Tirpitz, Sandra Geisler
Dernière mise à jour: 2023-05-03 00:00:00
Langue: English
Source URL: https://arxiv.org/abs/2305.02063
Source PDF: https://arxiv.org/pdf/2305.02063
Licence: https://creativecommons.org/licenses/by/4.0/
Changements: Ce résumé a été créé avec l'aide de l'IA et peut contenir des inexactitudes. Pour obtenir des informations précises, veuillez vous référer aux documents sources originaux dont les liens figurent ici.
Merci à arxiv pour l'utilisation de son interopérabilité en libre accès.